idnits 2.17.1 draft-boucadair-lisp-subscribe-01.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 21, 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-10 == Outdated reference: A later version (-07) exists of draft-boucadair-lisp-bulk-00 Summary: 2 errors (**), 0 flaws (~~), 3 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 24, 2016 September 21, 2015 7 Improving Mapping Services in LISP Networks 8 draft-boucadair-lisp-subscribe-01 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 24, 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 . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . 17 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 13.1. Normative references . . . . . . . . . . . . . . . . . . 18 82 13.2. Informative references . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 message. 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 the set of filters that were 366 successfully installed. 368 o Redirect Map-Resolver IP Address (128 bits): When the R-bit is 369 set, this field carries the IP address of the Map-Resolver where 370 mapping requests should be redirected. An IPv4 address is encoded 371 as an IPv4-mapped IPv6 address. 373 4. Generating a Map-Subscribe Message 375 An ITR uses the U-bit to inform a Map-Resolver whether it is ready to 376 handle unsolicited Map-Reply messages or not. The ITR MUST set the 377 U-bit when it supports such capability. 379 An ITR uses the B-bit to inform a Map-Resolver whether it supports 380 the mapping bulk transfer method or not. The ITR MUST set to the 381 B-bit when it supports such method (e.g., [I-D.boucadair-lisp-bulk]). 383 An ITR that joins the LISP network is likely to delete all 384 notifications that are bound to its RLOCs. It does so by including a 385 Null filter prior to any filter that it wishes the Map-Resolver to 386 record. 388 An ITR that loses its mapping cache for some reason SHOULD generate a 389 Map-Subscribe message towards its Map-Resolver(s) with the I-bit set. 391 An ITR MAY generate several Map-Subscribe messages to make the Map- 392 Resolver install the required filters. Nevertheless, an ITR MUST 393 expect that the Map-Resolver may limit the number of filters that may 394 be installed. Filters that are not accepted or not processed by the 395 Map-Resolvers are not included in a Map-Subscribe-Ack message. 397 An ITR that wants to delete one or a set of filters MUST generate a 398 Map-Subscribe message which carries those filters with an Expiry 399 Timer set to 0. 401 5. Processing a Map-Subscribe Message 403 A Map-Resolver that does not support the Map-Subscribe message MUST 404 silently ignore any Map-Subscribe message it receives. 406 Map-Resolvers MUST support a configurable parameter to enable/disable 407 the processing of Map-Subscribe messages. The default value is set 408 to "enabled". 410 A Map-Resolver SHOULD support a configuration parameter to limit the 411 number of filters per leaf LISP network, per ITR, etc. 413 If a Map-Resolver receives a Map-Subscribe message and is enabled to 414 process it, a Map-Resolver MUST reply with a Map-Subscribe-Ack 415 message to acknowledge the receipt of the corresponding Map-Subscribe 416 message. 418 When building a Map-Subscribe-Ack message, the Map-Resolver MUST: 420 o Set the U-bit if it supports the unsolicited Map-Reply capability, 421 except if a redirect Map-Resolver is to be returned. 423 o Set the B-bit if it supports a method for mapping bulk transfer, 424 except if a redirect Map-Resolver is to be returned. 426 o Set the R-bit if it wants to inform the requesting ITR about 427 another Map-Resolver it should contact. The Map-Resolver MAY 428 return a set of filters that are to be applied by the ITR to 429 select the Map-Resolver (i.e., destination EID Map-Resolver 430 address selection). 432 o Echo the I-bit if the Map-Resolver accepts to initiate unsolicited 433 mapping retrievals, except if a redirect Map-Resolver is to be 434 returned. 436 o If no redirect is enabled and the request includes one or several 437 filters, the Map-Resolver MUST echo the filters it succeeds to 438 install, and in the same order of appearance, in the Map- 439 Subscribe-Ack message. 441 o If the Map-Resolver is configured with maximum and minimum values 442 for the expiry timer, the Map-Resolver MUST adjust the Expiry 443 Timer enclosed in the request so that it does not exceed these 444 boundary values. 446 If the I-bit is set in the Map-Subscribe request and the Map-Resolver 447 supports the unsolicited mapping retrieval capability, the Map- 448 Resolver SHOULD generate unsolicited Map-Reply messages or dedicated 449 bulk transfer messages that carry the EID-RLOC mapping entries that 450 match the filters already present in the Mapping System for that ITR 451 or that match those carried by the Map-Subscribe message. 453 If filters are included in the request, the Map-Resolver MUST extract 454 those filters and update its mapping system subscription for that ITR 455 accordingly. In particular, the Map-Resolver MUST delete all filters 456 that are active for that ITR if a Null filter is included in the Map- 457 Subscribe request or if the expiry timer is null. 459 If filters are not allowed for a given ITR, the 'Result' field MUST 460 be set to FILTERS-PROHIBITED. 462 If all filters are successfully installed, the 'Result' field MUST be 463 set to SUCCESS. 465 If the Map-Resolver fails to install some of the filters included in 466 a request because the filter limits for that ITR are exceeded, it 467 MUST NOT echo the corresponding filters in the Map-Subscribe-Ack 468 message. The 'Result' field MUST be set to PARTIAL-FILTERS- 469 INSTALLED-LIMIT. 471 If the Map-Resolver fails to install some of the filters included in 472 a request because these filters were malformed, it MUST NOT echo the 473 corresponding filters in the Map-Subscribe-Ack message; only 474 successfully installed filters MUST be included. The 'Result' field 475 MUST be set to PARTIAL-FILTERS-INSTALLED-BAD. 477 If, for some other reasons, the Map-Resolver fails to apply the 478 filters included in a request, it MUST NOT echo the said filters in 479 the Map-Subscribe-Ack message; only the successfully installed 480 filters MUST be included. The 'Result' field MUST be set to PARTIAL- 481 FILTERS-INSTALLED-LOCAL. 483 If a filter that is included in the request is more specific than a 484 filter that is already present in the mapping system for the same 485 ITR, the Map-Resolver MUST NOT add a new filter but MUST include the 486 old filter in the response to the requesting ITR. 488 If a more specific filter exists in the mapping system for the same 489 ITR, the Map-Resolver MUST replace the old filter (i.e., the one 490 already stored in the system) with the new filter (i.e., the one 491 included in the Map-Subscribe message). 493 A Map-Resolver that is overloaded or configured by means of a 494 specific policy to redirect requests sent by a set of ITRs to other 495 Map-Resolvers, the Map-Resolver MUST reply with a Map-Subscribe-Ack 496 message with the R-bit set and 'Redirect Map-Resolver IP Address' 497 field set to the redirect Map-Resolver'address. All other bit flags 498 MUST be returned unset. Moreover, the Expiry Timer MUST be set to 0. 499 No Filter MUST be included in the message. 501 If an event matches one of the filters that have been installed by an 502 ITR, the Map-Resolvers MUST generate the corresponding unsolicited 503 mapping update message (e.g., Map-Reply, mapping bulk method). 505 Upon expiry of the validity timer associated with a filter, the Map- 506 Resolver MUST delete that filter from its mapping subscription 507 system. 509 6. Processing a Map-Subscribe-Ack Message 511 Upon receipt of a Map-Subscribe-Ack message, the ITR MUST check 512 whether the message matches a Map-Subscribe message it sent to the 513 same Map-Resolver. If no matching state is found, the message MUST 514 be silently dropped. If a state is found, in addition to 515 authentication checks, the ITR MUST proceed as follows: 517 o If the U-bit is set, it should expect that unsolicited Map-Reply 518 messages will be received from this Map-Resolver. Appropriate 519 security mechanisms (e.g., Access Control Lists) SHOULD be 520 activated to allow the processing of these incoming unsolicited 521 Map-Reply messages. 523 o If the B-bit is set, it should expect that (unsolicited) mapping 524 bulk transfer messages are supported by this Map-Resolver. 525 Appropriate security mechanisms (e.g., Access Control Lists) 526 SHOULD be activated to allow the processing of these incoming 527 unsolicited bulk transfer messages. 529 o If the R-bit is set and the 'Redirect Map-Resolver IP Address' 530 field embeds a valid IP address, the ITR MUST update its Map- 531 Resolver contact information with the new Map-Resolver's IP 532 address. The ITR MUST use that IP address for subsequent 533 exchanges. Optionally, if filters were included in the reply sent 534 by the Map-Resolver, these filters are used for the destination 535 EID Map-Resolver address selection. 537 o If the message includes one or several filters, the ITR MUST check 538 whether the same set of filters as those included in the Map- 539 Subscribe request are carried in the Map-Subscribe-Ack message. 540 Filters that are not returned in the Map-Subscribe-Ack message may 541 not be valid or have exceeded a limit. The "Result" code 542 indicates the reason for not installing these filters. In 543 particular: 545 * An ITR that receives the result code set to PARTIAL-FILTERS- 546 INSTALLED-LIMIT MUST NOT try to install new filters unless it 547 clears all the filters maintained by the Map-Resolver or it 548 removes some of them. 550 * An ITR that receives the result code set to PARTIAL-FILTERS- 551 INSTALLED-BAD MUST NOT resend the same filters that were not 552 returned in the Map-Subscribe-Ack message, in subsequent Map- 553 Subscribe requests. 555 * An ITR that receives the result code set to FILTERS-PROHIBITED 556 MUST NOT include the filters that were not returned in the Map- 557 Subscribe-Ack message, in a Map-Subscribe message sent to that 558 Map-Resolver. 560 * An ITR that receives the result code set to PARTIAL-FILTERS- 561 INSTALLED-LOCAL SHOULD wait for at least 60 seconds before 562 issuing another Map-Subscribe message to install the filters 563 that were not returned in the Map-Subscribe-Ack message. 565 o The ITR MUST adjust the Expiry Timer carried in the Map-Subscribe- 566 Ack. Subscription should be renewed before the expiry of that 567 timer. 569 7. Subscription to Multiple Resolvers 571 In order to subscribe to multiple Map-Resolvers, an ITR sends Map- 572 Subscribe messages to a list of Map-Resolvers. Each of these 573 requests is handled as specified in Section 4. 575 8. Mapping Policy Table 577 Section 2 and Section 3 specifies a solution for a Map-Resolver to 578 redirect an ITR to another Map-Resolver. This section focuses on the 579 dynamic provisioning of advanced mapping resolution forwarding policy 580 tables. 582 This section assumes that the entity managing a leaf LISP network has 583 subscribed to a Mapping Service using a variety of means, including 584 static or dynamic such as 585 [I-D.boucadair-connectivity-provisioning-protocol]. For the sake of 586 network automation, we assume that the outcome of such negotiation is 587 translated into appropriate provisioning actions, which include in 588 particular the identity of Map-Resolvers that will be solicited by 589 the ITRs of the leaf LISP network. 591 The provisioning information may be as simple as a list of IP 592 addresses or names, but it may also be enriched with traffic 593 engineering rules, such as priority information, geolocation 594 information of the a Map-Resolver, the set of destination EIDs that 595 are serviced by a given Map-Resolver, etc. A leaf LISP network can 596 be provisioned with a list of Map-Resolvers together with policies to 597 instruct the ITR how to contact these Map-Resolvers. These policies 598 are enclosed in a Mapping Policy Table. This table is similar to the 599 one defined in [RFC6724]. 601 Typically, the Mapping Policy Table may be structured as follows: 603 o Destination EID range 605 o Map-Resolver IP address 607 o Tie-breaking rules 609 An ITR may use the selection algorithm defined in Section 6 of 610 [RFC6724] to contact a Map-Resolver. 612 <> 614 9. Sample Examples 616 This section includes a set of examples to illustrate the usage of 617 the methods defined in Section 2. 619 9.1. Map-Resolver Redirect 621 The example shown in Figure 3, illustrates an example of an ITR 622 (ITR1) that is redirected to another Map-Resolver (MR2). 624 +--------+ +--------+ +--------+ 625 | ITR1 | | MR1 | | MR2 | 626 +--------+ +--------+ +--------+ 627 | | | 628 |Map-Subscribe | | 629 |-------------------------->| | 630 | Map-Subscribe-Ack (R, MR2)| | 631 |<--------------------------| | 632 |Map-Subscribe | | 633 |------------------------------------->| 634 | Map-Subscribe-Ack| 635 |<-------------------------------------| 636 | | 637 |Map-Request | 638 |------------------------------------->| 639 | Map-Reply| 640 |<-------------------------------------| 642 Figure 3: Example of Map-Resolver Redirection 644 9.2. Mapping Cache Retrieval 646 The example shown in Figure 4, illustrates an example of an ITR 647 (ITR1) that restores its mapping tables upon reboot according to the 648 filters already present in the mapping system. The example in 649 Figure 4, indicates how an ITR retrieves the mappings that match the 650 filters included in the Map-Subscribe request. The example in 651 Figure 5, assumes that multiple records bound to distinct EIDs are 652 included in the same Map-Reply message. 654 This procedure applies to ITRs which do not store the mapping table 655 in a permanent memory storage facility. 657 Owing to this procedure, the ITR is ready-to-serve as soon as reboot 658 is completed or right after a mapping cache clear event. 660 +--------+ +--------+ 661 | ITR1 | | MR | 662 +--------+ +--------+ 663 | | 664 | | 665 |Map-Subscribe(d_EID, d_EID2,| 666 |..., d_EIDn) | 667 |--------------------------->| 668 | Map-Subscribe-Ack (d_EID,| 669 | d_EID2, ..., d_EIDn)| 670 |<---------------------------| 671 | | 672 <> 673 |Map-Subscribe(I) | 674 |--------------------------->| 675 | Map-Subscribe-Ack (I)| 676 |<---------------------------| 677 | Map-Reply (d_EID)| 678 |<---------------------------| 679 | Map-Reply (d_EID2)| 680 |<---------------------------| 681 .... 682 | Map-Reply (d_EIDn)| 683 |<---------------------------| 685 Figure 4: Example of Mapping Cache Retrieval: Matching the Filters 686 Installed in the Mapping System 688 +--------+ +--------+ 689 | ITR1 | | MR | 690 +--------+ +--------+ 691 | | 692 | | 693 |Map-Subscribe(d_EID, d_EID2,| 694 |..., d_EIDn) | 695 |--------------------------->| 696 | Map-Subscribe-Ack (d_EID,| 697 | d_EID2, ..., d_EIDn)| 698 |<---------------------------| 699 | | 700 <> 701 |Map-Subscribe(I) | 702 |--------------------------->| 703 | Map-Subscribe-Ack (I)| 704 |<---------------------------| 705 | Map-Reply (d_EID, d_EID2, 706 | ..., )| 707 |<---------------------------| 709 Figure 5: Example of Bulk Mapping Cache Retrieval: Matching the 710 Filters Installed in the Mapping System 712 +--------+ +--------+ 713 | ITR1 | | MR | 714 +--------+ +--------+ 715 | | 716 | | 717 <> 718 | | 719 |Map-Subscribe(I, d_EID | 720 | d_EID2, ..., d_EIDn) | 721 |--------------------------->| 722 | Map-Subscribe-Ack (I, d_EID| 723 | d_EID2, ..., d_EIDn)| 724 |<---------------------------| 725 | Map-Reply (d_EID)| 726 |<---------------------------| 727 | Map-Reply (d_EID2)| 728 |<---------------------------| 729 .... 730 | Map-Reply (d_EIDn)| 731 |<---------------------------| 733 Figure 6: Example of Mapping Cache Retrieval: Matching the Filters 734 Conveyed in the request 736 9.3. Unsolicited Map-Reply 738 The example shown in Figure 7, illustrates an ITR (ITR1) that is 739 notified with the new EID-RLOC mapping that it subscribed to. 741 +--------+ +--------+ +--------+ 742 | ITR1 | | MR | | ETR | 743 +--------+ +--------+ +--------+ 744 | | | 745 | | | 746 |Map-Subscribe | | 747 |--------------------------->| | 748 | Map-Subscribe-Ack (d_EID)| | 749 |<---------------------------| | 750 | | | 751 | Map-Reply (d_EID)| | 752 |<---------------------------| | 753 .... 754 src=s_EID| | 755 -------->|src=RLOC_itr1 dst=RLOC_etr|src=s_EID 756 dst=d_EID|==============Encapsulated Packet==========>|--------> 757 | |dst=d_EID 758 .... 760 Figure 7: Example of Unsolicited Map-Reply 762 10. Security Considerations 764 This document does not introduce any additional security issues other 765 than those discussed in [RFC6830] and [RFC6833]. 767 11. IANA Considerations 769 To be completed. 771 12. Acknowledgments 773 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR-009. 775 Many thanks to Stefano Secci and Chi-Dung Phung for their review. 777 13. References 778 13.1. Normative references 780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, 782 DOI 10.17487/RFC2119, March 1997, 783 . 785 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 786 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 787 2006, . 789 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 790 "Default Address Selection for Internet Protocol Version 6 791 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 792 . 794 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 795 Locator/ID Separation Protocol (LISP)", RFC 6830, 796 DOI 10.17487/RFC6830, January 2013, 797 . 799 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 800 Protocol (LISP) Map-Server Interface", RFC 6833, 801 DOI 10.17487/RFC6833, January 2013, 802 . 804 13.2. Informative references 806 [I-D.boucadair-connectivity-provisioning-protocol] 807 Boucadair, M., Jacquenet, C., Zhang, D., and P. 808 Georgatsos, "Connectivity Provisioning Negotiation 809 Protocol (CPNP)", draft-boucadair-connectivity- 810 provisioning-protocol-10 (work in progress), September 811 2015. 813 [I-D.boucadair-lisp-bulk] 814 Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk 815 Retrieval", draft-boucadair-lisp-bulk-00 (work in 816 progress), September 2015. 818 Authors' Addresses 820 Mohamed Boucadair 821 France Telecom 822 Rennes 35000 823 France 825 EMail: mohamed.boucadair@orange.com 826 Christian Jacquenet 827 France Telecom 828 Rennes 35000 829 France 831 EMail: christian.jacquenet@orange.com