idnits 2.17.1 draft-farinacci-lisp-te-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 : ---------------------------------------------------------------------------- == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An ELP that is first used by an ITR must be inspected for encoding loops. If any RLOC appears twice in the ELP, it MUST not be used. -- The document date (July 3, 2012) is 4308 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-23 == Outdated reference: A later version (-14) exists of draft-ietf-lisp-multicast-13 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-10) exists of draft-farinacci-lisp-lcaf-09 == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Farinacci 3 Internet-Draft cisco Systems 4 Intended status: Experimental P. Lahiri 5 Expires: January 4, 2013 Microsoft Corporation 6 M. Kowal 7 cisco Systems 8 July 3, 2012 10 LISP Traffic Engineering Use-Cases 11 draft-farinacci-lisp-te-01 13 Abstract 15 This document describes how LISP reencapsulating tunnels can be used 16 for Traffic Engineering purposes. The mechanisms described in this 17 document require no LISP protocol changes but do introduce a new 18 locator (RLOC) encoding. The Traffic Engineering features provided 19 by these LISP mechanisms can span intra-domain, inter-domain, or 20 combination of both. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 4, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 59 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Explicit Locator Paths . . . . . . . . . . . . . . . . . . . . 9 61 5.1. ELP Re-optimization . . . . . . . . . . . . . . . . . . . 10 62 5.2. Using Recursion . . . . . . . . . . . . . . . . . . . . . 10 63 5.3. ELP Selection based on Class of Service . . . . . . . . . 11 64 5.4. Packet Loop Avoidance . . . . . . . . . . . . . . . . . . 12 65 6. Service Chaining . . . . . . . . . . . . . . . . . . . . . . . 13 66 7. RLOC Probing by RTRs . . . . . . . . . . . . . . . . . . . . . 14 67 8. Interworking Considerations . . . . . . . . . . . . . . . . . 15 68 9. Multicast Considerations . . . . . . . . . . . . . . . . . . . 16 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 73 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 75 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 23 76 B.1. Changes to draft-farinacci-lisp-te-01.txt . . . . . . . . 23 77 B.2. Changes to draft-farinacci-lisp-te-00.txt . . . . . . . . 23 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 80 1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Introduction 88 This document describes the Locator/Identifier Separation Protocol 89 (LISP), which provides a set of functions for routers to exchange 90 information used to map from non globally routeable Endpoint 91 Identifiers (EIDs) to routeable Routing Locators (RLOCs). It also 92 defines a mechanism for these LISP routers to encapsulate IP packets 93 addressed with EIDs for transmission across the Internet that uses 94 RLOCs for routing and forwarding. 96 When LISP routers encapsulate packets to other LISP routers, the path 97 stretch is typically 1, meaning the packet travels on a direct path 98 from the encapsulating ITR to the decapsulating ETR at the 99 destination site. The direct path is determined by the underlying 100 routing protocol and metrics it uses to find the shortest path. 102 This specification will examine how reencapsulating tunnels [LISP] 103 can be used so a packet can take an adminstratively specified path, a 104 congestion avoidance path, a failure recovery path, or multiple load- 105 shared paths, as it travels from ITR to ETR. By introducing an 106 Explicit Locator Path (ELP) locator encoding [LISP-LCAF], an ITR can 107 encapsulate a packet to a Reencapsulating Tunnel Router (RTR) which 108 decapsulates the packet, then encapsulates it to the next locator in 109 the ELP. 111 3. Definition of Terms 113 Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for 114 IPv6) value used in the source and destination address fields of 115 the first (most inner) LISP header of a packet. The host obtains 116 a destination EID the same way it obtains an destination address 117 today, for example through a Domain Name System (DNS) [RFC1034] 118 lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. 119 The source EID is obtained via existing mechanisms used to set a 120 host's "local" IP address. An EID used on the public Internet 121 must have the same properties as any other IP address used in that 122 manner; this means, among other things, that it must be globally 123 unique. An EID is allocated to a host from an EID-prefix block 124 associated with the site where the host is located. An EID can be 125 used by a host to refer to other hosts. EIDs MUST NOT be used as 126 LISP RLOCs. Note that EID blocks MAY be assigned in a 127 hierarchical manner, independent of the network topology, to 128 facilitate scaling of the mapping database. In addition, an EID 129 block assigned to a site may have site-local structure 130 (subnetting) for routing within the site; this structure is not 131 visible to the global routing system. In theory, the bit string 132 that represents an EID for one device can represent an RLOC for a 133 different device. As the architecture is realized, if a given bit 134 string is both an RLOC and an EID, it must refer to the same 135 entity in both cases. When used in discussions with other 136 Locator/ID separation proposals, a LISP EID will be called a 137 "LEID". Throughout this document, any references to "EID" refers 138 to an LEID. 140 Routing Locator (RLOC): A RLOC is an IPv4 [RFC0791] or IPv6 141 [RFC2460] address of an egress tunnel router (ETR). A RLOC is the 142 output of an EID-to-RLOC mapping lookup. An EID maps to one or 143 more RLOCs. Typically, RLOCs are numbered from topologically- 144 aggregatable blocks that are assigned to a site at each point to 145 which it attaches to the global Internet; where the topology is 146 defined by the connectivity of provider networks, RLOCs can be 147 thought of as PA addresses. Multiple RLOCs can be assigned to the 148 same ETR device or to multiple ETR devices at a site. 150 Reencapsulating Tunnel Router (RTR): An RTR is a router that acts 151 as an ETR (or PETR) by decapsulating packets where the destination 152 address in the "outer" IP header is one of its own RLOCs. Then 153 acts as an ITR (or PITR) by making a decision where to encapsulate 154 the packet based on the next locator in the ELP towards the final 155 destination ETR. 157 Explicit Locator Path (ELP): The ELP is an explicit list of RLOCs 158 for each RTR a packet must travel to along its path toward a final 159 destination ETR (or PETR). The list is a strict ordering where 160 each RLOC in the list is visited. However, the path from one RTR 161 to another is determined by the underlying routing protocol and 162 how the infrastructure assigns metrics and policies for the path. 164 Recursive Tunneling: Recursive tunneling occurs when a packet has 165 more than one LISP IP header. Additional layers of tunneling MAY 166 be employed to implement traffic engineering or other re-routing 167 as needed. When this is done, an additional "outer" LISP header 168 is added and the original RLOCs are preserved in the "inner" 169 header. Any references to tunnels in this specification refers to 170 dynamic encapsulating tunnels and they are never statically 171 configured. 173 Reencapsulating Tunnels: Reencapsulating tunneling occurs when an 174 ETR removes a LISP header, then acts as an ITR to prepend another 175 LISP header. Doing this allows a packet to be re-routed by the 176 reencapsulating router without adding the overhead of additional 177 tunnel headers. Any references to tunnels in this specification 178 refers to dynamic encapsulating tunnels and they are never 179 statically configured. When using multiple mapping database 180 systems, care must be taken to not create reencapsulation loops 181 through misconfiguration. 183 4. Overview 185 Typically, a packet's path from source EID to destination EID travels 186 through the locator core via the encapsulating ITR directly to the 187 decapsulating ETR as the following diagram illustrates: 189 Legend: 191 seid: Packet is originated by source EID 'seid'. 193 deid: Packet is consumed by destination EID 'deid'. 195 A,B,C,D : Core routers in different ASes. 197 ---> : The physical topological path between two routers. 199 ===> : A multi-hop LISP dynamic tunnel between LISP routers. 201 Core Network 202 Source site (----------------------------) Destination Site 203 +--------+ ( ) +---------+ 204 | \ ( ) / | 205 | seid ITR ---(---> A --> B --> C --> D ---)---> ETR deid | 206 | / || ( ) ^^ \ | 207 +--------+ || ( ) || +---------+ 208 || (----------------------------) || 209 || || 210 =========================================== 211 LISP Tunnel 213 Typical Data Path from ITR to ETR 215 Let's introduce RTRs 'X' and 'Y' so that, for example, if it is 216 desirable to route around the path from B to C, one could provide an 217 ELP of (X,Y,etr): 219 Core Network 220 Source site (----------------------------) Destination Site 221 +--------+ ( ) +---------+ 222 | \ ( ) / | 223 | seid ITR ---(---> A --> B --> C --> D ---)---> ETR deid | 224 | / || ( / ^ ) ^^ \ | 225 | / || ( | \ ) || \ | 226 +-------+ || ( v | ) || +--------+ 227 || ( X ======> Y ) || 228 || ( ^^ || ) || 229 || (--------||---------||-------) || 230 || || || || 231 ================= ================= 232 LISP Tunnel LISP Tunnel 234 ELP tunnel path ITR ==> X, then X ==> Y, and then Y ==> ETR 236 There are various reasons why the path from 'seid' to 'deid' may want 237 to avoid the path from B to C. To list a few: 239 o There may not be sufficient capacity provided by the networks that 240 connect B and C together. 242 o There may be a policy reason to avoid the ASes that make up the 243 path between B and C. 245 o There may be a failure on the path between B and C which makes the 246 path unreliable. 248 o There may be monitoring or traffic inspection resources close to 249 RTRs X and Y that do network accounting or measurement. 251 o There may be a chain of services performed at RTRs X and Y 252 regardless if the path from ITR to ETR is through B and C. 254 5. Explicit Locator Paths 256 The notation for a general formatted ELP is (x, y, etr) which 257 represents the list of RTRs a packet SHOULD travel through to reach 258 the final tunnel hop to the ETR. 260 The procedure for using an ELP at each tunnel hop is as follows: 262 1. The ITR will retrieve the ELP from the mapping database. 264 2. The ITR will encapsulate the packet to RLOC 'x'. 266 3. The RTR with RLOC 'x' will decapsulate the packet. It will use 267 the decapsulated packet's destination address as a lookup into 268 the mapping database to retrieve the ELP. 270 4. RTR 'x' will encapsulate the packet to RTR with RLOC 'y'. 272 5. The RTR with RLOC 'y' will decapsulate the packet. It will use 273 the decapsulated packet's destination address as a lookup into 274 the mapping database to retrieve the ELP. 276 6. RTR 'y' will encapsulate the packet on the final tunnel hop to 277 ETR with RLOC 'etr'. 279 7. The ETR will decapsulate the packet and deliver the packet to the 280 EID inside of its site. 282 The specific format for the ELP can be found in [LISP-LCAF]. It is 283 defined that an ELP will appear as a single encoded locator in a 284 locator-set. Say for instance, we have a mapping entry for EID- 285 prefix 10.0.0.0/8 that is reachable via 4 locators. Two locators are 286 being used as active/active and the other two are used as active/ 287 active if the first two go unreachable (as noted by the priority 288 assignments below). This is what the mapping entry would look like: 290 EID-prefix: 10.0.0.0/8 291 Locator-set: ETR-A: priority 1, weight 50 292 ETR-B: priority 1, weight 50 293 ETR-C: priority 2, weight 50 294 ETR-D: priority 2, weight 50 296 If an ELP is going to be used to have a policy path to ETR-A and 297 possibly another policy path to ETR-B, the locator-set would be 298 encoded as follows: 300 EID-prefix: 10.0.0.0/8 301 Locator-set: (x, y, ETR-A): priority 1, weight 50 302 (q, r, ETR-B): priority 1, weight 50 303 ETR-C: priority 2, weight 50 304 ETR-D: priority 2, weight 50 306 The mapping entry with ELP locators is registered to the mapping 307 database system just like any other mapping entry would. The 308 registration is typically performed by the ETR(s) that are assigned 309 and own the EID-prefix. That is, the destination site makes the 310 choice of the RTRs in the ELP. However, it may be common practice 311 for a provisioning system to program the mapping database with ELPs. 313 Another case where a locator-set can be used for flow-based load- 314 sharing across multiple paths to the same destination site: 316 EID-prefix: 10.0.0.0/8 317 Locator-set: (x, y, ETR-A): priority 1, weight 75 318 (q, r, ETR-A): priority 1, weight 25 320 Using this mapping entry, an ITR would load split 75% of the EID 321 flows on the (x, y, ETR-A) ELP path and 25% of the EID flows on the 322 (q, r, ETR-A) ELP path. If any of the ELPs go down, then the other 323 can take 100% of the load. 325 5.1. ELP Re-optimization 327 ELP re-optimization is a process of changing the RLOCs of an ELP due 328 to underlying network change conditions. Just like when there is any 329 locator change for a locator-set, the procedures from the main LISP 330 specification [LISP] are followed. 332 When a RLOC from an ELP is changed, Map-Notify messages [LISP-MS] can 333 be used to inform the existing RTRs in the ELP so they can do a 334 lookup to obtain the latest version of the ELP. Map-Notify messages 335 can also be sent to new RTRs in an ELP so they can get the ELP in 336 advance to receiving packets that will use the ELP. This can 337 minimize packet loss during mapping database lookups in RTRs. 339 5.2. Using Recursion 341 In the previous examples, we showed how an ITR encapsulates using an 342 ELP of (x, y, etr). When a packet is encapsulated from the ITR to 343 RTR 'x', the RTR may want a policy path to RTR 'y' and run another 344 level of reencapsulating tunnels for packets destined to RTR 'y'. In 345 this case, RTR 'x' does not decapsulate packets from the ITR, but 346 rather performs a mapping database lookup on the address 'y'. This 347 can be done when using a public or private mapping database. The 348 decision to use address 'y' as an encapsulation address versus a 349 lookup address is based on the L-bit setting for 'y' in the ELP 350 entry. The decision and policy of ELP encodings are local to the 351 entity which registers the EID-prefix associated with the ELP. 353 Another example of recursion is when the ITR uses the ELP (x, y, etr) 354 to first prepend a header with a destination RLOC of the ETR and then 355 prepend another header and encapsulate the packet to RTR 'x'. When 356 RTR 'x' decapsulates the packet, rather than doing a mapping database 357 lookup on RTR 'y' the last example showed, instead RTR 'x' does a 358 mapping database lookup on ETR 'etr'. In this scenario, RTR 'x' can 359 choose an ELP from the locator-set by considering the source RLOC 360 address of the ITR versus considering the source EID. 362 This additional level of recursion also brings advantages for the 363 provider of RTR 'x' to store less state. Since RTR 'x' does not need 364 to look at the inner most header, it does not need to store EID 365 state. It only stores an entry for RTR 'y' which many EID flows 366 could share for scaling benefits. The locator-set for entry 'y' 367 could either be a list of typical locators, a list of ELPs, or 368 combination of both. Another advantage is that packet load-splitting 369 can be accomplished by examining the source of a packet. If the 370 source is an ITR versus the source being the last-hop of an ELP the 371 last-hop selected, different forwarding paths can be used. 373 5.3. ELP Selection based on Class of Service 375 Paths to an ETR may want to be selected based on different classes of 376 service. Packets from a set of sources that have premium service can 377 use ELP paths that are less congested where normal sources use ELP 378 paths that compete for less resources or use longer paths for best 379 effort service. 381 Using source/destination lookups into the mapping database can yield 382 different ELPs. So for example, a premium service flow with 383 (source=1.1.1.1, dest=10.1.1.1) can be described by using the 384 following mapping entry: 386 EID-prefix: (1.0.0.0/8, 10.0.0.0/8) 387 Locator-set: (x, y, ETR-A): priority 1, weight 50 388 (q, r, ETR-A): priority 1, weight 50 390 And all other best-effort sources would use different mapping entry 391 described by: 393 EID-prefix: (0.0.0.0/0, 10.0.0.0/8) 394 Locator-set: (x, x', y, y', ETR-A): priority 1, weight 50 395 (q, q', r, r', ETR-A): priority 1, weight 50 397 If the source/destination lookup is coupled with recursive lookups, 398 then an ITR can encapsulate to the ETR, prepending a header that 399 selects source address ITR-1 based on the premium class of service 400 source, or selects source address ITR-2 for best-effort sources with 401 normal class of service. The ITR then does another lookup in the 402 mapping database on the prepended header using lookup key 403 (source=ITR-1, dest=10.1.1.1) that returns the following mapping 404 entry: 406 EID-prefix: (ITR-1, 10.0.0.0/8) 407 Locator-set: (x, y, ETR-A): priority 1, weight 50 408 (q, r, ETR-A): priority 1, weight 50 410 And all other sources would use different mapping entry with a lookup 411 key of (source=ITR-2, dest=10.1.1.1): 413 EID-prefix: (ITR-2, 10.0.0.0/8) 414 Locator-set: (x, x', y, y', ETR-A): priority 1, weight 50 415 (q, q', r, r', ETR-A): priority 1, weight 50 417 This will scale the mapping system better by having fewer source/ 418 destination combinations. Refer to the Source/Dest LCAF type 419 described in [LISP-LCAF] for encoding EIDs in Map-Request and Map- 420 Register messages. 422 5.4. Packet Loop Avoidance 424 An ELP that is first used by an ITR must be inspected for encoding 425 loops. If any RLOC appears twice in the ELP, it MUST not be used. 427 Since it is expected that multiple mapping systems will be used, 428 there can be a loop across ELPs when registered in different mapping 429 systems. The TTL copying procedures for reencapsulating tunnels and 430 recursive tunnels in [LISP] MUST be followed. 432 6. Service Chaining 434 An ELP can be used to deploy services at each reencapsulation point 435 in the network. One example is to implement a scrubber service when 436 a destination EID is being DoS attacked. That is, when a DoS attack 437 is recognized when the encapsulation path is between ITR and ETR, an 438 ELP can be registered for a destination EID to the mapping database 439 system. The ELP can include an RTR so the ITR can encapsulate 440 packets to the RTR which will decapsulate and deliver packets to a 441 scrubber service device. The scrubber could decide if the offending 442 packets are dropped or allowed to be sent to the destination EID. In 443 which case, the scurbber delivers packets back to the RTR which 444 encapsulates to the ETR. 446 7. RLOC Probing by RTRs 448 Since an RTR knows the next tunnel hop to encapsulate to, it can 449 monitor the reachability of the next-hop RTR RLOC by doing RLOC- 450 probing according to the procedures in [LISP]. When the RLOC is 451 determined unreachable by the RLOC-probing mechanisms, the RTR can 452 use another locator in the locator-set. That could be the final ETR, 453 a RLOC of another RTR, or an ELP where it must search for itself and 454 use the next RLOC in the ELP list to encapsulate to. 456 RLOC-probing can also be used to measure delay on the path between 457 RTRs and when it is desirable switch to another lower delay ELP. 459 8. Interworking Considerations 461 [LISP-IW] defines procedures for how non-LISP sites talk to LISP 462 sites. The network elements defined in the Interworking 463 specification, the proxy ITR (PITR) and proxy ETR (PETR) (as well as 464 their multicast counterparts defined in [LISP-MCAST]) can participate 465 in LISP-TE. That is, a PITR and a PETR can appear in an ELP list and 466 act as an RTR. 468 Note when an RLOC appears in an ELP, it can be of any address-family. 469 There can be a mix of IPv4 and IPv6 locators present in the same ELP. 470 This can provide benefits where islands of one address-family or the 471 other are supported and connectivity across them is necessary. For 472 instance, an ELP can look like: 474 (x4, a46, b64, y4, etr) 476 Where an IPv4 ITR will encapsulate using an IPv4 RLOC 'x4' and 'x4' 477 could reach an IPv4 RLOC 'a46', but RTR 'a46' encapsulates to an IPv6 478 RLOC 'b64' when the network between them is IPv6-only. Then RTR 479 'b64' encapsulates to IPv4 RLOC 'y4' if the network between them is 480 dual-stack. 482 Note that RTRs can be used for NAT-traversal scenarios [LISP-NATT] as 483 well to reduce the state in both an xTR that resides behind a NAT and 484 the state the NAT needs to maintain. In this case, the xTR only 485 needs a default map-cache entry pointing to the RTR for outbound 486 traffic and all remote ITRs can reach EIDs through the xTR behind a 487 NAT via a single RTR (or a small set RTRs for redundancy). 489 RTRs have some scaling features to reduce the number of locator-set 490 changes, the amount of state, and control packet overhead: 492 o When ITRs and PITRs are using a small set of RTRs for 493 encapsulating to "orders of magnitude" more EID-prefixes, the 494 probability of locator-set changes are limited to the RTR RLOC 495 changes versus the RLOC changes for the ETRs associated with the 496 EID-prefixes if the ITRs and PITRs were directly encapsulating to 497 the ETRs. This comes at an expense in packet stretch, but 498 depending on RTR placement, this expense can be mitigated. 500 o When RTRs are on-path between many pairwise EID flows, ITRs and 501 PITRs can store a small number of coarse EID-prefixes. 503 o RTRs can be used to help scale RLOC-probing. Instead of ITRs 504 RLOC-probing all ETRs for each destination site it has cached, the 505 ITRs can probe a smaller set of RTRs which in turn, probe the 506 destination sites. 508 9. Multicast Considerations 510 ELPs have application in multicast environments. Just like RTRs can 511 be used to provide connectivity across different address family 512 islands, RTRs can help concatenate a multicast region of the network 513 to one that does not support native multicast. 515 Note there are various combinations of connectivity that can be 516 accomplished with the deployment of RTRs and ELPs: 518 o Providing multicast forwarding between IPv4-only-unicast regions 519 and IPv4-multicast regions. 521 o Providing multicast forwarding between IPv6-only-unicast regions 522 and IPv6-multicast regions. 524 o Providing multicast forwarding between IPv4-only-unicast regions 525 and IPv6-multicast regions. 527 o Providing multicast forwarding between IPv6-only-unicast regions 528 and IPv4-multicast regions. 530 o Providing multicast forwarding between IPv4-multicast regions and 531 IPv6-multicast regions. 533 An ITR or PITR can do a (S-EID,G) lookup into the mapping database. 534 What can be returned is a typical locator-set that could be made up 535 of the various RLOC addresses: 537 Multicast EID key: (seid, G) 538 Locator-set: ETR-A: priority 1, weight 25 539 ETR-B: priority 1, weight 25 540 g1: priority 1, weight 25 541 g2: priority 1, weight 25 543 An entry for host 'seid' sending to application group 'G' 545 The locator-set above can be used as a replication list. That is 546 some RLOCs listed can be unicast RLOCs and some can be delivery group 547 RLOCs. A unicast RLOC in this case is used to encapsulate a 548 multicast packet originated by a multicast source EID into a unicast 549 packet for unicast delivery on the underlying network. ETR-A could 550 be a IPv4 unicast RLOC address and ETR-B could be a IPv6 unicast RLOC 551 address. 553 A delivery group address is used when a multicast packet originated 554 by a multicast source EID is encapsulated in a multicast packet for 555 multicast delivery on the underlying network. Group address 'g1' 556 could be a IPv4 delivery group RLOC and group address 'g2' could be 557 an IPv6 delivery group RLOC. 559 Flexibility for these various types of connectivity combinations can 560 be achieved and provided by the mapping database system. And the RTR 561 placement allows the connectivity to occur where the differences in 562 network functionality are located. 564 Extending this concept by allowing ELPs in locator-sets, one could 565 have this locator-set registered in the mapping database for (seid, 566 G). For example: 568 Multicast EID key: (seid, G) 569 Locator-set: (x, y, ETR-A): priority 1, weight 50 570 (a, g, b, ETR-B): priority 1, weight 50 572 Using ELPs for multicast flows 574 In the above situation, an ITR would encapsulate a multicast packet 575 originated by a multicast source EID to the RTR with unicast RLOC 576 'x'. Then RTR 'x' would decapsulate and unicast encapsulate to RTR 577 'y' ('x' or 'y' could be either IPv4 or IPv6 unicast RLOCs), which 578 would decapsulate and unicast encapsulate to the final RLOC 'ETR-A'. 579 The ETR 'ETR-A' would decapsulate and deliver the multicast packet 580 natively to all the receivers joined to application group 'G' inside 581 the LISP site. 583 Let's look at the ITR using the ELP (a, g, b, ETR-B). Here the 584 encapsulation path would be the ITR unicast encapsulates to unicast 585 RLOC 'a'. RTR 'a' multicast encapsulates to delivery group 'g'. The 586 packet gets to all ETRs that have joined delivery group 'g' so they 587 can deliver the multicast packet to joined receivers of application 588 group 'G' in their sites. RTR 'b' is also joined to delivery group 589 'g'. Since it is in the ELP, it will be the only RTR that unicast 590 encapsulates the multicast packet to ETR 'ETR-B'. Lastly, 'ETR-B' 591 decapsulates and delivers the multicast packet to joined receivers to 592 application group 'G' in its LISP site. 594 As one can see there are all sorts of opportunities to provide 595 multicast connectivity across a network with non-congruent support 596 for multicast and different address-families. One can also see how 597 using the mapping database can allow flexible forms of delivery 598 policy, rerouting, and congestion control management in multicast 599 environments. 601 10. Security Considerations 603 When an RTR receives a LISP encapsulated packet, it can look at the 604 outer source address to verify that RLOC is the one listed as the 605 previous hop in the ELP list. If the outer source RLOC address 606 appears before the RLOC which matches the outer destination RLOC 607 address, the decapsulating RTR (or ETR if last hop), MAY choose to 608 drop the packet. 610 11. IANA Considerations 612 At this time there are no requests for IANA. 614 12. References 616 12.1. Normative References 618 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 619 "Locator/ID Separation Protocol (LISP)", 620 draft-ietf-lisp-23.txt (work in progress). 622 [LISP-IW] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 623 "Interworking LISP with IPv4 and IPv6", 624 draft-ietf-lisp-interworking-06.txt (work in progress). 626 [LISP-MCAST] 627 Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 628 "LISP for Multicast Environments", 629 draft-ietf-lisp-multicast-13.txt (work in progress). 631 [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface", 632 draft-ietf-lisp-ms-16.txt (work in progress). 634 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 635 September 1981. 637 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 638 STD 13, RFC 1034, November 1987. 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, March 1997. 643 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 644 (IPv6) Specification", RFC 2460, December 1998. 646 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 647 A., Peterson, J., Sparks, R., Handley, M., and E. 648 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 649 June 2002. 651 12.2. Informative References 653 [LISP-LCAF] 654 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 655 Address Format", draft-farinacci-lisp-lcaf-09.txt (work in 656 progress). 658 [LISP-NATT] 659 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 660 F., and C. White, "NAT traversal for LISP", 661 draft-ermagan-lisp-nat-traversal-01.txt (work in 662 progress). 664 Appendix A. Acknowledgments 666 The authors would like to thank the following people for their ideas 667 and comments. They are Albert Cabellos, Khalid Raza, and Vina 668 Ermagan, and Gregg Schudel. 670 Appendix B. Document Change Log 672 B.1. Changes to draft-farinacci-lisp-te-01.txt 674 o Posted July 2012. 676 o Add the Lookup bit to allow an ELP to be a list of encapsulation 677 and/or mapping database lookup addresses. 679 o Indicate that ELPs can be used for service chaining. 681 o Add text to indicate that Map-Notify messages can be sent to new 682 RTRs in a ELP so their map-caches can be pre-populated to avoid 683 mapping database lookup packet loss. 685 o Fixes to editorial comments from Gregg. 687 B.2. Changes to draft-farinacci-lisp-te-00.txt 689 o Initial draft posted March 2012. 691 Authors' Addresses 693 Dino Farinacci 694 cisco Systems 695 Tasman Ave. 696 San Jose, California 697 USA 699 Phone: 408-718-2001 700 Email: dino@cisco.com 702 Parantap Lahiri 703 Microsoft Corporation 704 Redmond, WA 705 USA 707 Email: parantal@microsoft.com 709 Michael Kowal 710 cisco Systems 711 111 Wood Avenue South 712 ISELIN, NJ 713 USA 715 Email: mikowal@cisco.com