idnits 2.17.1 draft-boucadair-lisp-subscribe-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 15, 2015) is 3139 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-09 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental France Telecom 5 Expires: March 18, 2016 September 15, 2015 7 Improving Mapping Services in LISP Networks 8 draft-boucadair-lisp-subscribe-00 10 Abstract 12 Mapping Services in Locator/ID Separation Protocol (LISP) networks 13 are key to proper LISP forwarding operation. When considering the 14 deployment of LISP at large scale, these Mapping Services are even 15 more crucial for the sake of the LISP forwarding efficiency. This 16 document introduces two additional LISP messages that are meant to 17 facilitate the dynamic discovery of Mapping Systems, improve Ingress 18 Tunnel Routers (ITR) recovery times and optimize the solicitation of 19 the LISP Mapping System as a function of the ITR location, in 20 particular. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 18, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.3. Improving LISP Mapping Services . . . . . . . . . . . . . 4 66 2. Map-Subscribe Message Format . . . . . . . . . . . . . . . . 5 67 3. Map-Subscribe-Ack Message Format . . . . . . . . . . . . . . 6 68 4. Generating a Map-Subscribe Message . . . . . . . . . . . . . 9 69 5. Processing a Map-Subscribe Message . . . . . . . . . . . . . 10 70 6. Processing a Map-Subscribe-Ack Message . . . . . . . . . . . 12 71 7. Subscription to Multiple Resolvers . . . . . . . . . . . . . 13 72 8. Mapping Policy Table . . . . . . . . . . . . . . . . . . . . 13 73 9. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Map-Resolver Redirect . . . . . . . . . . . . . . . . . . 14 75 9.2. Mapping Cache Retrieval . . . . . . . . . . . . . . . . . 15 76 9.3. Unsolicited Map-Reply . . . . . . . . . . . . . . . . . . 18 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 13.1. Normative references . . . . . . . . . . . . . . . . . . 18 82 13.2. Informative references . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 88 upon a mapping mechanism that is used by ingress/egress Tunnel 89 Routers (xTR) to forward traffic over the LISP network. The ability 90 of dynamically discovering the Map-Resolver and Map-Server entities 91 that provide such mapping services is meant to facilitate global LISP 92 operation. In particular, the ability to inform Ingress Tunnel 93 Routers (ITR) of a LISP network about the availability and the status 94 of several Mapping Services is likely to improve the overall LISP 95 forwarding serviceability. 97 1.1. Issues 99 This section lists a set of issues that need further investigation: 101 Discover ITRs: Current LISP design does not allow to automatically 102 discover active ITRs of a LISP domain (nor the mapping system of a 103 given domain is aware of ITRs of the same domaine that can solicit 104 its services, let alone ITRs of other domains). The solution 105 proposed in this document allows to fill that gap. 107 Optimize EID-ROLC resolution time: Leaf LISP networks can be better 108 serviced, for example by avoiding the cascading of Map-Resolvers, 109 or by avoiding the solicitation of a Map-Resolver that is located 110 an ocean away, etc. Policies should be taken into account when 111 configuring Map-Resolver information on an ITR for improving EID- 112 to-RLOC resolution. These policies should be modified and 113 adjusted according to various events (e.g., installation of an 114 additional Map-Resolver). 116 Accomodate Map-Resolvers constraints: Allows for the protocol to 117 redirect a requesting ITR to another Map-Resolver when some events 118 occur, such as an overload of the initially targeted Map-Resolver 119 or when Map-Resolvers are optimized to service a set of 120 destination EIDs, etc. 122 Faster Recovery of mapping entries: Whenever an ITR fails for some 123 reason, the faulty ITR needs to recover at least the list of 124 mappings for the most popular prefixes in a timely manner, in 125 particular. Policies for mapping entries (to be recovered) are 126 deployment-specific. 128 Receive push notifications: For LISP leaf networks that would need 129 to maintain an up-to-date mapping table for a set of destination 130 EIDs (or even the global mapping table) to avoid issues such as 131 the loss of a first packet or to optimize LISP forwarding delay 132 (and therefore the overall forwarding efficiency), a dynamic push 133 mechanism would be helpful. 135 1.2. Assumptions 137 This document makes the following assumptions: 139 o Various LISP players (network operators, service providers, etc.) 140 are likely to deploy and operate different LISP Mapping Systems. 142 Multiple Mapping Systems will therefore coexist for various 143 reasons, e.g., avoid country-centric governance, allow for 144 distinct technologies to implement the mapping service, business 145 opportunities, service innovation, etc. 147 o Interconnection between these Mapping Systems is required for the 148 sake of global connectivity and also to minimize the risk of 149 fragmenting the Internet. 151 o Mapping Services are supposed to be dimensioned to maintain a 152 global mapping database for the entire LISP-enabled Internet. 154 o Mapping Service providers may offer advanced services to their 155 customers such as maintain local caches (a la CDN), or update ITR 156 mapping entries that match some criteria requested by a leaf LISP 157 network, redirect ITR requests to the closest Map-Resolvers, 158 structure the mapping resolution service so that the resolution 159 time is optimized, etc. 161 o The entries of the mapping tables are exchanged between these 162 Mapping systems so that Map-Request messages can be processed as 163 close to the LISP leaf networks as possible. 165 o A leaf LISP-enabled network subscribes to the Mapping Service 166 provided by one or several Mapping Service operators. 168 o The contribution of each player involved in the provisioning and 169 the operation of a LISP-based connectivity forwarding service 170 should be rationalized so that clear interfaces are defined and 171 adequate mechanisms for troubleshooting, diagnosis and repair 172 purposes can be easily implemented and adopted. The inability of 173 identifying what is at the origin of the degradation of a LISP 174 connectivity service is seen as one of the hurdles that are likely 175 to jeopardize LISP deployments at large scale. 177 1.3. Improving LISP Mapping Services 179 This document specifies a couple of additional LISP messages that are 180 meant to improve the subscription to Mapping Services, let alone 181 their serviceability. They are described in the following sections. 183 A simple method to redirect ITR-originated mapping requests towards 184 another Map-Resolver when some conditions are met (e.g., overload of 185 a Map-Resolver, enforcement of traffic engineering policies, etc.) is 186 defined in Section 2 and Section 3. Section 8 specifies how advanced 187 Map-Resolver forwarding policies are installed in ITRs. 189 2. Map-Subscribe Message Format 191 The format of the Map-Subscribe message is shown in Figure 1. 193 0 1 2 3 194 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type |U|B|I| Reserved | Filter Len | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Nonce . . . | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | . . . Nonce | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Key ID | Authentication Data Length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 ~ Authentication Data ~ 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Expiry Timer | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Length | | 209 +-+-+-+-+-+-+-+-+ : 210 : Filter : 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 ... 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Length | | 215 +-+-+-+-+-+-+-+-+ : 216 : Filter : 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 1: Map-Subscribe Message Format 221 The description of the fields is as follows: 223 o Type is to be defined (see Section 11). 225 o U (unsolicited-map-reply bit): When set, this flag indicates that 226 the originating ITR is ready to receive unsolicited Map-Reply 227 messages. 229 o B (bulk-support bit): When set, this flag indicates that the 230 originating ITR supports mapping bulk retrieval method (e.g., 231 [I-D.boucadair-lisp-bulk]). 233 o I (immediate-retrieval bit): When set, this flag indicates that 234 the originating ITR requests immediate retrieval of the portion of 235 the mapping table that matches the filters included in the 236 request. 238 o Reserved: reserved bits, MUST be sent as 0 and MUST be ignored 239 when received. 241 o Filter Len: This field indicates in bytes, the length of the 242 filters included in the request. It is equal to (sum of "8+Length 243 of Filter"), where "Filter" denotes the filters included in the 244 message. 246 o Nonce, Key ID, Authentication Data Length, and Authentication Data 247 are similar to those of a LISP Map-Request message ([RFC6830]). 249 o Expiry Timer: This field indicates, in seconds, the validity timer 250 for the subscription. 252 o Length: This field indicates, in octets, the length of the filter 253 that is encoded in the "Filter" field. 255 o Filter: This field carries a destination EID (or a set thereof) 256 that is encoded as an UTF-8 string. This specification allows to 257 convey IP prefix literals, Names and/or AS numbers. One or 258 multiple filters may be present in a request. IPv4 prefixes are 259 encoded as IPv4-mapped IPv6 prefixes [RFC4291] (i.e., starting 260 with ::ffff:0:0/96). A mix of names, IP prefixes and AS numbers 261 may be enclosed in the same request. The value 0 is used to 262 delete existing filters. Filters MUST be applied in the order 263 they appear in the request. 265 3. Map-Subscribe-Ack Message Format 267 The format of the Map-Subscribe-Ack message is shown in Figure 2. 269 0 1 2 3 270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type |U|B|I|R| Reserved | Result | Filter Len | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Nonce . . . | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | . . . Nonce | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Key ID | Authentication Data Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 ~ Authentication Data ~ 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Expiry Timer | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Length | | 285 +-+-+-+-+-+-+-+-+ : 286 : Filter : 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 ... 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Length | | 291 +-+-+-+-+-+-+-+-+ : 292 : Filter : 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 | Redirect Map-Resolver | 296 | IP Address (128 bits) | 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 2: Map-Subscribe-Ack Message Format 302 The description of the fields is as follows: 304 o Type is to be defined (see Section 11). 306 o U (unsolicited-map-reply bit): When set, this flag indicates that 307 the Map-Resolver can issue unsolicited Map-Reply messages. 309 o B (bulk-support bit): When set, this flag indicates that the Map- 310 Resolver supports mapping bulk retrieval method (e.g., 311 [I-D.boucadair-lisp-bulk]). 313 o I (immediate-retrieval bit): When set, this flag indicates that 314 the Map-Resolver will initiate an immediate retrieval cycle of the 315 portion of the mapping table that matches the filters included in 316 the request. 318 o R (Redirect bit): When set, this flag indicates that a redirect 319 Map-Resolver is enclosed in the message. 321 o Reserved: reserved bits, MUST be set to 0 and MUST be ignored when 322 received. 324 o Result: indicates the result code of the processing of the Map- 325 Subscribe request. The following codes are defined: 327 0: SUCCESS. This code is used to indicate the request is 328 successfully processed. 330 1: PARTIAL-FILTERS-INSTALLED-LIMIT. This code is used to indicate 331 a request is successfully processed but some filters were not 332 installed because the number of filters carried in the initial 333 Map-Subscribe message exceeds the filter limit. 335 2: PARTIAL-FILTERS-INSTALLED-BAD. This code is used to indicate a 336 request is successfully processed but some filters were not 337 installed because they were malformed. 339 3: PARTIAL-FILTERS-INSTALLED-LOCAL. This code is used to indicate 340 a request is successfully processed but some filters were not 341 installed because of local reasons. The ITR SHOULD, after a 342 certain timer expires, send a Map-Subscribe request message for 343 the set of filters that are not included in the Map-Subscribe- 344 Ack message received by the ITR in response to its initial Map- 345 Subscribe request message. 347 4: FILTERS-PROHIBITED. This code is used to indicate a request is 348 successfully processed but the installation of filters is 349 prohibited. 351 o Filter Len: This field indicates in bytes, the length of the 352 filters included in the request. It is equal to (sum of "8+Length 353 of Filter"), where Filter represents the filters included in the 354 message. 356 o Nonce, Key ID, Authentication Data Length, and Authentication Data 357 are similar to those of a LISP Map-Request message ([RFC6830]). 359 o Expiry Timer: This field indicates, in seconds, the validity timer 360 for the subscription. 362 o Length: This field indicates, in octets, the length of the filter 363 that is encoded in the "Filter" field. 365 o Filter: This field carries a destination EID (or a set thereof, if 366 several filters are carried in the message) that is encoded as an 367 UTF-8 string. This specification allows to convey IP prefix 368 literals, Names and/or AS numbers. One or multiple filters may be 369 present in a request. IPv4 prefixes are encoded as IPv4-mapped 370 IPv6 prefixes [RFC4291] (i.e., starting with ::ffff:0:0/96). A 371 mix of names, IP prefixes and AS numbers may be enclosed in the 372 same request. 374 o Redirect Map-Resolver IP Address (128 bits): When the R-bit is 375 set, this field carries the IP address of the Map-Resolver where 376 mapping requests should be redirected. An IPv4 address is encoded 377 as an IPv4-mapped IPv6 address. 379 4. Generating a Map-Subscribe Message 381 An ITR uses the U-bit to inform a Map-Resolver whether it is ready to 382 handle unsolicited Map-Reply messages or not. The ITR MUST set the 383 U-bit when it supports such capability. 385 An ITR uses the B-bit to inform a Map-Resolver whether it supports 386 the mapping bulk transfer method or not. The ITR MUST set to the 387 B-bit when it supports such method (e.g., [I-D.boucadair-lisp-bulk]). 389 An ITR that joins the LISP network is likely to delete all 390 notifications that are bound to its RLOCs. It does so by including a 391 Null filter prior to any filter that it wishes the Map-Resolver to 392 record. 394 An ITR that loses its mapping cache for some reason SHOULD generate a 395 Map-Subscribe message towards its Map-Resolver(s) with the I-bit set. 397 An ITR MAY generate several Map-Subscribe messages to make the Map- 398 Resolver install the required filters. Nevertheless, an ITR MUST 399 expect that the Map-Resolver may limit the number of filters that may 400 be installed. Filters that are not accepted or not processed by the 401 Map-Resolvers are not included in a Map-Subscribe-Ack message. 403 An ITR that wants to delete one or a set of filters MUST generate a 404 Map-Subscribe message which carries those filters with an Expiry 405 Timer set to 0. 407 5. Processing a Map-Subscribe Message 409 A Map-Resolver that does not support the Map-Subscribe message MUST 410 silently ignore any Map-Subscribe message it receives. 412 Map-Resolvers MUST support a configurable parameter to enable/disable 413 the processing of Map-Subscribe messages. The default value is set 414 to "enabled". 416 A Map-Resolver SHOULD support a configuration parameter to limit the 417 number of filters per leaf LISP network, per ITR, etc. 419 If a Map-Resolver receives a Map-Subscribe message and is enabled to 420 process it, a Map-Resolver MUST reply with a Map-Subscribe-Ack 421 message to acknowledge the receipt of the corresponding Map-Subscribe 422 message. 424 When building a Map-Subscribe-Ack message, the Map-Resolver MUST: 426 o Set the U-bit if it supports the unsolicited Map-Reply capability, 427 except if a redirect Map-Resolver is to be returned. 429 o Set the B-bit if it supports a method for mapping bulk transfer, 430 except if a redirect Map-Resolver is to be returned. 432 o Set the R-bit if it wants to inform the requesting ITR about 433 another Map-Resolver it should contact. The Map-Resolver MAY 434 return a set of filters that are to be applied by the ITR to 435 select the Map-Resolver (i.e., destination EID Map-Resolver 436 address selection). 438 o Echo the I-bit if the Map-Resolver accepts to initiate unsolicited 439 mapping retrievals, except if a redirect Map-Resolver is to be 440 returned. 442 o If no redirect is enabled and the request includes one or several 443 filters, the Map-Resolver MUST echo the filters it succeeds to 444 install, and in the same order of appearance, in the Map- 445 Subscribe-Ack message. 447 o If the Map-Resolver is configured with maximum and minimum values 448 for the expiry timer, the Map-Resolver MUST adjust the Expiry 449 Timer enclosed in the request so that it does not exceed these 450 boundary values. 452 If the I-bit is set in the Map-Subscribe request and the Map-Resolver 453 supports the unsolicited mapping retrieval capability, the Map- 454 Resolver SHOULD generate unsolicited Map-Reply messages or dedicated 455 bulk transfer messages that carry the EID-RLOC mapping entries that 456 match the filters already present in the Mapping System for that ITR 457 or that match those carried by the Map-Subscribe message. 459 If filters are included in the request, the Map-Resolver MUST extract 460 those filters and update its mapping system subscription for that ITR 461 accordingly. In particular, the Map-Resolver MUST delete all filters 462 that are active for that ITR if a Null filter is included in the Map- 463 Subscribe request or if the expiry timer is null. 465 If filters are not allowed for a given ITR, the 'Result' field MUST 466 be set to FILTERS-PROHIBITED. 468 If all filters are successfully installed, the 'Result' field MUST be 469 set to SUCCESS. 471 If the Map-Resolver fails to install some of the filters included in 472 a request because the filter limits for that ITR are exceeded, it 473 MUST NOT echo the corresponding filters in the Map-Subscribe-Ack 474 message. The 'Result' field MUST be set to PARTIAL-FILTERS- 475 INSTALLED-LIMIT. 477 If the Map-Resolver fails to install some of the filters included in 478 a request because these filters were malformed, it MUST NOT echo the 479 corresponding filters in the Map-Subscribe-Ack message; only 480 successfully installed filters MUST be included. The 'Result' field 481 MUST be set to PARTIAL-FILTERS-INSTALLED-BAD. 483 If, for some other reasons, the Map-Resolver fails to apply the 484 filters included in a request, it MUST NOT echo the said filters in 485 the Map-Subscribe-Ack message; only the successfully installed 486 filters MUST be included. The 'Result' field MUST be set to PARTIAL- 487 FILTERS-INSTALLED-LOCAL. 489 If a filter that is included in the request is more specific than a 490 filter that is already present in the mapping system for the same 491 ITR, the Map-Resolver MUST NOT add a new filter but MUST include the 492 old filter in the response to the requesting ITR. 494 If a more specific filter exists in the mapping system for the same 495 ITR, the Map-Resolver MUST replace the old filter (i.e., the one 496 already stored in the system) with the new filter (i.e., the one 497 included in the Map-Subscribe message). 499 A Map-Resolver that is overloaded or configured by means of a 500 specific policy to redirect requests sent by a set of ITRs to other 501 Map-Resolvers, the Map-Resolver MUST reply with a Map-Subscribe-Ack 502 message with the R-bit set and 'Redirect Map-Resolver IP Address' 503 field set to the redirect Map-Resolver'address. All other bit flags 504 MUST be returned unset. Moreover, the Expiry Timer MUST be set to 0. 505 No Filter MUST be included in the message. 507 If an event matches one of the filters that have been installed by an 508 ITR, the Map-Resolvers MUST generate the corresponding unsolicited 509 mapping update message (e.g., Map-Reply, mapping bulk method). 511 Upon expiry of the validity timer associated with a filter, the Map- 512 Resolver MUST delete that filter from its mapping subscription 513 system. 515 6. Processing a Map-Subscribe-Ack Message 517 Upon receipt of a Map-Subscribe-Ack message, the ITR MUST check 518 whether the message matches a Map-Subscribe message it sent to the 519 same Map-Resolver. If no matching state is found, the message MUST 520 be silently dropped. If a state is found, in addition to 521 authentication checks, the ITR MUST proceed as follows: 523 o If the U-bit is set, it should expect that unsolicited Map-Reply 524 messages will be received from this Map-Resolver. Appropriate 525 security mechanisms (e.g., Access Control Lists) SHOULD be 526 activated to allow the processing of these incoming unsolicited 527 Map-Reply messages. 529 o If the B-bit is set, it should expect that (unsolicited) mapping 530 bulk transfer messages are supported by this Map-Resolver. 531 Appropriate security mechanisms (e.g., Access Control Lists) 532 SHOULD be activated to allow the processing of these incoming 533 unsolicited bulk transfer messages. 535 o If the R-bit is set and the 'Redirect Map-Resolver IP Address' 536 field embeds a valid IP address, the ITR MUST update its Map- 537 Resolver contact information with the new Map-Resolver's IP 538 address. The ITR MUST use that IP address for subsequent 539 exchanges. Optionally, if filters were included in the reply sent 540 by the Map-Resolver, these filters are used for the destination 541 EID Map-Resolver address selection. 543 o If the message includes one or several filters, the ITR MUST check 544 whether the same set of filters as those included in the Map- 545 Subscribe request are carried in the Map-Subscribe-Ack message. 546 Filters that are not returned in the Map-Subscribe-Ack message may 547 not be valid or have exceeded a limit. The "Result" code 548 indicates the reason for not installing these filters. In 549 particular: 551 * An ITR that receives the result code set to PARTIAL-FILTERS- 552 INSTALLED-LIMIT MUST NOT try to install new filters unless it 553 clears all the filters maintained by the Map-Resolver or it 554 removes some of them. 556 * An ITR that receives the result code set to PARTIAL-FILTERS- 557 INSTALLED-BAD MUST NOT resend the same filters that were not 558 returned in the Map-Subscribe-Ack message, in subsequent Map- 559 Subscribe requests. 561 * An ITR that receives the result code set to FILTERS-PROHIBITED 562 MUST NOT include the filters that were not returned in the Map- 563 Subscribe-Ack message, in a Map-Subscribe message sent to that 564 Map-Resolver. 566 * An ITR that receives the result code set to PARTIAL-FILTERS- 567 INSTALLED-LOCAL SHOULD wait for at least 60 seconds before 568 issuing another Map-Subscribe message to install the filters 569 that were not returned in the Map-Subscribe-Ack message. 571 o The ITR MUST adjust the Expiry Timer carried in the Map-Subscribe- 572 Ack. Subscription should be renewed before the expiry of that 573 timer. 575 7. Subscription to Multiple Resolvers 577 In order to subscribe to multiple Map-Resolvers, an ITR sends Map- 578 Subscribe messages to a list of Map-Resolvers. Each of these 579 requests is handled as specified in Section 4. 581 8. Mapping Policy Table 583 Section 2 and Section 3 specifies a solution for a Map-Resolver to 584 redirect an ITR to another Map-Resolver. This section focuses on the 585 dynamic provisioning of advanced mapping resolution forwarding policy 586 tables. 588 This section assumes that the entity managing a leaf LISP network has 589 subscribed to a Mapping Service using a variety of means, including 590 static or dynamic such as 591 [I-D.boucadair-connectivity-provisioning-protocol]. For the sake of 592 network automation, we assume that the outcome of such negotiation is 593 translated into appropriate provisioning actions, which include in 594 particular the identity of Map-Resolvers that will be solicited by 595 the ITRs of the leaf LISP network. 597 The provisioning information may be as simple as a list of IP 598 addresses or names, but it may also be enriched with traffic 599 engineering rules, such as priority information, geolocation 600 information of the a Map-Resolver, the set of destination EIDs that 601 are serviced by a given Map-Resolver, etc. A leaf LISP network can 602 be provisioned with a list of Map-Resolvers together with policies to 603 instruct the ITR how to contact these Map-Resolvers. These policies 604 are enclosed in a Mapping Policy Table. This table is similar to the 605 one defined in [RFC6724]. 607 Typically, the Mapping Policy Table may be structured as follows: 609 o Destination EID range 611 o Map-Resolver IP address 613 o Tie-breaking rules 615 An ITR may use the selection algorithm defined in Section 6 of 616 [RFC6724] to contact a Map-Resolver. 618 <> 620 9. Sample Examples 622 This section includes a set of examples to illustrate the usage of 623 the methods defined in Section 2. 625 9.1. Map-Resolver Redirect 627 The example shown in Figure 3, illustrates an example of an ITR 628 (ITR1) that is redirected to another Map-Resolver (MR2). 630 +--------+ +--------+ +--------+ 631 | ITR1 | | MR1 | | MR2 | 632 +--------+ +--------+ +--------+ 633 | | | 634 |Map-Subscribe | | 635 |-------------------------->| | 636 | Map-Subscribe-Ack (R, MR2)| | 637 |<--------------------------| | 638 |Map-Subscribe | | 639 |------------------------------------->| 640 | Map-Subscribe-Ack| 641 |<-------------------------------------| 642 | | 643 |Map-Request | 644 |------------------------------------->| 645 | Map-Reply| 646 |<-------------------------------------| 648 Figure 3: Example of Map-Resolver Redirection 650 9.2. Mapping Cache Retrieval 652 The example shown in Figure 4, illustrates an example of an ITR 653 (ITR1) that restores its mapping tables upon reboot according to the 654 filters already present in the mapping system. The example in 655 Figure 4, indicates how an ITR retrieves the mappings that match the 656 filters included in the Map-Subscribe request. The example in 657 Figure 5, assumes that multiple records bound to distinct EIDs are 658 included in the same Map-Reply message. 660 This procedure applies to ITRs which do not store the mapping table 661 in a permanent memory storage facility. 663 Owing to this procedure, the ITR is ready-to-serve as soon as reboot 664 is completed or right after a mapping cache clear event. 666 +--------+ +--------+ 667 | ITR1 | | MR | 668 +--------+ +--------+ 669 | | 670 | | 671 |Map-Subscribe(d_EID, d_EID2,| 672 |..., d_EIDn) | 673 |--------------------------->| 674 | Map-Subscribe-Ack (d_EID,| 675 | d_EID2, ..., d_EIDn)| 676 |<---------------------------| 677 | | 678 <> 679 |Map-Subscribe(I) | 680 |--------------------------->| 681 | Map-Subscribe-Ack (I)| 682 |<---------------------------| 683 | Map-Reply (d_EID)| 684 |<---------------------------| 685 | Map-Reply (d_EID2)| 686 |<---------------------------| 687 .... 688 | Map-Reply (d_EIDn)| 689 |<---------------------------| 691 Figure 4: Example of Mapping Cache Retrieval: Matching the Filters 692 Installed in the Mapping System 694 +--------+ +--------+ 695 | ITR1 | | MR | 696 +--------+ +--------+ 697 | | 698 | | 699 |Map-Subscribe(d_EID, d_EID2,| 700 |..., d_EIDn) | 701 |--------------------------->| 702 | Map-Subscribe-Ack (d_EID,| 703 | d_EID2, ..., d_EIDn)| 704 |<---------------------------| 705 | | 706 <> 707 |Map-Subscribe(I) | 708 |--------------------------->| 709 | Map-Subscribe-Ack (I)| 710 |<---------------------------| 711 | Map-Reply (d_EID, d_EID2, 712 | ..., )| 713 |<---------------------------| 715 Figure 5: Example of Bulk Mapping Cache Retrieval: Matching the 716 Filters Installed in the Mapping System 718 +--------+ +--------+ 719 | ITR1 | | MR | 720 +--------+ +--------+ 721 | | 722 | | 723 <> 724 | | 725 |Map-Subscribe(I, d_EID | 726 | d_EID2, ..., d_EIDn) | 727 |--------------------------->| 728 | Map-Subscribe-Ack (I, d_EID| 729 | d_EID2, ..., d_EIDn)| 730 |<---------------------------| 731 | Map-Reply (d_EID)| 732 |<---------------------------| 733 | Map-Reply (d_EID2)| 734 |<---------------------------| 735 .... 736 | Map-Reply (d_EIDn)| 737 |<---------------------------| 739 Figure 6: Example of Mapping Cache Retrieval: Matching the Filters 740 Conveyed in the request 742 9.3. Unsolicited Map-Reply 744 The example shown in Figure 7, illustrates an ITR (ITR1) that is 745 notified with the new EID-RLOC mapping that it subscribed to. 747 +--------+ +--------+ +--------+ 748 | ITR1 | | MR | | ETR | 749 +--------+ +--------+ +--------+ 750 | | | 751 | | | 752 |Map-Subscribe | | 753 |--------------------------->| | 754 | Map-Subscribe-Ack (d_EID)| | 755 |<---------------------------| | 756 | | | 757 | Map-Reply (d_EID)| | 758 |<---------------------------| | 759 .... 760 src=s_EID| | 761 -------->|src=RLOC_itr1 dst=RLOC_etr|src=s_EID 762 dst=d_EID|==============Encapsulated Packet==========>|--------> 763 | |dst=d_EID 764 .... 766 Figure 7: Example of Unsolicited Map-Reply 768 10. Security Considerations 770 This document does not introduce any additional security issues other 771 than those discussed in [RFC6830] and [RFC6833]. 773 11. IANA Considerations 775 To be completed. 777 12. Acknowledgments 779 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 780 009-X. 782 13. References 784 13.1. Normative references 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, 788 DOI 10.17487/RFC2119, March 1997, 789 . 791 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 792 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 793 2006, . 795 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 796 "Default Address Selection for Internet Protocol Version 6 797 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 798 . 800 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 801 Locator/ID Separation Protocol (LISP)", RFC 6830, 802 DOI 10.17487/RFC6830, January 2013, 803 . 805 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 806 Protocol (LISP) Map-Server Interface", RFC 6833, 807 DOI 10.17487/RFC6833, January 2013, 808 . 810 13.2. Informative references 812 [I-D.boucadair-connectivity-provisioning-protocol] 813 Boucadair, M., Jacquenet, C., Zhang, D., and P. 814 Georgatsos, "Connectivity Provisioning Negotiation 815 Protocol (CPNP)", draft-boucadair-connectivity- 816 provisioning-protocol-09 (work in progress), March 2015. 818 [I-D.boucadair-lisp-bulk] 819 Boucadair, M., and C. Jacquenet, "LISP Mapping Bulk 820 Retrieval", September 2015, 821 . 824 Authors' Addresses 826 Mohamed Boucadair 827 France Telecom 828 Rennes 35000 829 France 831 EMail: mohamed.boucadair@orange.com 832 Christian Jacquenet 833 France Telecom 834 Rennes 35000 835 France 837 EMail: christian.jacquenet@orange.com