idnits 2.17.1 draft-farinacci-lisp-te-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 : ---------------------------------------------------------------------------- == 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 (March 24, 2012) is 4415 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-22 == Outdated reference: A later version (-14) exists of draft-ietf-lisp-multicast-13 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-15 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-10) exists of draft-farinacci-lisp-lcaf-07 == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-00 Summary: 1 error (**), 0 flaws (~~), 8 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: September 25, 2012 Microsoft Corporation 6 M. Kowal 7 cisco Systems 8 March 24, 2012 10 LISP Traffic Engineering Use-Cases 11 draft-farinacci-lisp-te-00 13 Abstract 15 This document describes how LISP re-encapsulating 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 September 25, 2012. 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. RLOC Probing by RTRs . . . . . . . . . . . . . . . . . . . . . 13 66 7. Interworking Considerations . . . . . . . . . . . . . . . . . 14 67 8. Multicast Considerations . . . . . . . . . . . . . . . . . . . 15 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 72 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 74 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 22 75 B.1. Changes to draft-farinacci-lisp-te-00.txt . . . . . . . . 22 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 78 1. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. Introduction 86 This document describes the Locator/Identifier Separation Protocol 87 (LISP), which provides a set of functions for routers to exchange 88 information used to map from non globally routeable Endpoint 89 Identifiers (EIDs) to routeable Routing Locators (RLOCs). It also 90 defines a mechanism for these LISP routers to encapsulate IP packets 91 addressed with EIDs for transmission across the Internet that uses 92 RLOCs for routing and forwarding. 94 When LISP routers encapsulate packets to other LISP routers, the path 95 stretch is typically 1, meaning the packet travels on a direct path 96 from the encapsulating ITR to the decapsulating ETR at the 97 destination site. The direct path is determined by the underlying 98 routing protocol and metrics it uses to find the shortest path. 100 This specification will examine how re-encapsulating tunnels [LISP] 101 can be used so a packet can take a policy path, a congestion 102 avoidance path, a failure recovery path, or multiple load-shared 103 paths, as it travels from ITR to ETR. By introducing an Explicit 104 Locator Path (ELP) locator encoding [LISP-LCAF], an ITR can 105 encapsulate a packet to a Re-encapsulating Tunnel Router (RTR) which 106 decapsulates the packet, then encapsulates it to the next locator in 107 the ELP. 109 3. Definition of Terms 111 Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for 112 IPv6) value used in the source and destination address fields of 113 the first (most inner) LISP header of a packet. The host obtains 114 a destination EID the same way it obtains an destination address 115 today, for example through a Domain Name System (DNS) [RFC1034] 116 lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. 117 The source EID is obtained via existing mechanisms used to set a 118 host's "local" IP address. An EID used on the public Internet 119 must have the same properties as any other IP address used in that 120 manner; this means, among other things, that it must be globally 121 unique. An EID is allocated to a host from an EID-prefix block 122 associated with the site where the host is located. An EID can be 123 used by a host to refer to other hosts. EIDs MUST NOT be used as 124 LISP RLOCs. Note that EID blocks MAY be assigned in a 125 hierarchical manner, independent of the network topology, to 126 facilitate scaling of the mapping database. In addition, an EID 127 block assigned to a site may have site-local structure 128 (subnetting) for routing within the site; this structure is not 129 visible to the global routing system. In theory, the bit string 130 that represents an EID for one device can represent an RLOC for a 131 different device. As the architecture is realized, if a given bit 132 string is both an RLOC and an EID, it must refer to the same 133 entity in both cases. When used in discussions with other 134 Locator/ID separation proposals, a LISP EID will be called a 135 "LEID". Throughout this document, any references to "EID" refers 136 to an LEID. 138 Routing Locator (RLOC): A RLOC is an IPv4 [RFC0791] or IPv6 139 [RFC2460] address of an egress tunnel router (ETR). A RLOC is the 140 output of an EID-to-RLOC mapping lookup. An EID maps to one or 141 more RLOCs. Typically, RLOCs are numbered from topologically- 142 aggregatable blocks that are assigned to a site at each point to 143 which it attaches to the global Internet; where the topology is 144 defined by the connectivity of provider networks, RLOCs can be 145 thought of as PA addresses. Multiple RLOCs can be assigned to the 146 same ETR device or to multiple ETR devices at a site. 148 Re-encapsulating Tunnel Router (RTR): An RTR is a router that acts 149 as an ETR (or PETR) by decapsulating packets which are RLOC 150 addressed to it. Then acts as an ITR (or PITR) by making a 151 decision where to encapsulate the packet on the next tunnel hop 152 towards the destination ETR. 154 Explicit Locator Path (ELP): The ELP is an explicit list of RLOCs 155 for each RTR a packet must travel to. The list is a strict 156 ordering where each RLOC in the list is visited. However, the 157 path from one RTR to another is determined by the underlying 158 routing protocol and how the infrastructure assigns metrics and 159 policies for the path. 161 Recursive Tunneling: Recursive tunneling occurs when a packet has 162 more than one LISP IP header. Additional layers of tunneling MAY 163 be employed to implement traffic engineering or other re-routing 164 as needed. When this is done, an additional "outer" LISP header 165 is added and the original RLOCs are preserved in the "inner" 166 header. Any references to tunnels in this specification refers to 167 dynamic encapsulating tunnels and they are never statically 168 configured. 170 Re-encapsulating Tunnels: Re-encapsulating tunneling occurs when an 171 ETR removes a LISP header, then acts as an ITR to prepend another 172 LISP header. Doing this allows a packet to be re-routed by the 173 re-encapsulating router without adding the overhead of additional 174 tunnel headers. Any references to tunnels in this specification 175 refers to dynamic encapsulating tunnels and they are never 176 statically configured. When using multiple mapping database 177 systems, care must be taken to not create re-encapsulation loops 178 through misconfiguration. 180 4. Overview 182 Typically, a packet's path from source EID to destination EID travels 183 through the locator core via the encapsulating ITR directly to the 184 decapsulating ETR as the following diagram illustrates: 186 Legend: 188 seid: Packet is originated by source EID 'seid'. 190 deid: Packet is consumed by destination EID 'deid'. 192 A,B,C,D : Core routers in different ASes. 194 ---> : The physical topological path between two routers. 196 ===> : A multi-hop LISP tunnel between LISP routers. 198 Core Network 199 Source site (----------------------------) Destination Site 200 +--------+ ( ) +---------+ 201 | \ ( ) / | 202 | seid ITR ---(---> A --> B --> C --> D ---)---> ETR deid | 203 | / || ( ) ^^ \ | 204 +--------+ || ( ) || +---------+ 205 || (----------------------------) || 206 || || 207 =========================================== 208 LISP Tunnel 210 Typical Data Path from ITR to ETR 212 Let's introduce RTRs 'X' and 'Y' so if it is desirable to route 213 around the path from B to C, one could provide an ELP of (X,Y,etr): 215 Core Network 216 Source site (----------------------------) Destination Site 217 +--------+ ( ) +---------+ 218 | \ ( ) / | 219 | seid ITR ---(---> A --> B --> C --> D ---)---> ETR deid | 220 | / || ( / ^ ) ^^ \ | 221 | / || ( | \ ) || \ | 222 +-------+ || ( v | ) || +--------+ 223 || ( X ======> Y ) || 224 || ( ^^ || ) || 225 || (--------||---------||-------) || 226 || || || || 227 ================= ================= 228 LISP Tunnel LISP Tunnel 230 ELP tunnel path ITR ==> X, then X ==> Y, and then Y ==> ETR 232 There are various reasons why the path from 'seid' to 'deid' may want 233 to avoid the path from B to C. To list a few: 235 o There may not be sufficient capacity provided by the networks that 236 connect B and C together. 238 o There may be a policy reason to avoid the ASes that make up the 239 path between B and C. 241 o There may be a failure on the path between B and C which makes the 242 path unreliable. 244 o There may be monitoring or traffic inspection resources close to 245 RTRs X and Y that do network accounting or measurement. 247 5. Explicit Locator Paths 249 The notation for a general formatted ELP is (x, y, etr) which 250 represents the list of RTRs a packet SHOULD travel through to reach 251 the final tunnel hop to the ETR. 253 The procedure for using an ELP at each tunnel hop is as follows: 255 1. The ITR will retrieve the ELP from the mapping database. 257 2. The ITR will encapsulate the packet to RLOC 'x'. 259 3. The RTR with RLOC 'x' will decapsulate the packet. It will use 260 the decapsulated packet's destination address as a lookup into 261 the mapping database to retrieve the ELP. 263 4. RTR 'x' will encapsulate the packet to RTR with RLOC 'y'. 265 5. The RTR with RLOC 'y' will decapsulate the packet. It will use 266 the decapsulated packet's destination address as a lookup into 267 the mapping database to retrieve the ELP. 269 6. RTR 'y' will encapsulate the packet on the final tunnel hop to 270 ETR with RLOC 'etr'. 272 7. The ETR will decapsulate the packet and deliver the packet to the 273 EID inside of its site. 275 The specific format for the ELP can be found in [LISP-LCAF]. It is 276 defined that an ELP will appear as a single encoded locator in a 277 locator-set. Say for instance, we have a mapping entry for EID- 278 prefix 10.0.0.0/8 that is reachable via 4 locators. Two locators are 279 being used as active/active and the other two are used as active/ 280 active if the first two go unreachable (as noted by the priority 281 assignments below). This is what the mapping entry would look like: 283 EID-prefix: 10.0.0.0/8 284 Locator-set: ETR-A: priority 1, weight 50 285 ETR-B: priority 1, weight 50 286 ETR-C: priority 2, weight 50 287 ETR-D: priority 2, weight 50 289 If an ELP is going to be used to have a policy path to ETR-A and 290 possibly another policy path to ETR-B, the locator-set would be 291 encoded as follows: 293 EID-prefix: 10.0.0.0/8 294 Locator-set: (x, y, ETR-A): priority 1, weight 50 295 (q, r, ETR-B): priority 1, weight 50 296 ETR-C: priority 2, weight 50 297 ETR-D: priority 2, weight 50 299 The mapping entry with ELP locators is registered to the mapping 300 database system just like any other mapping entry would. The 301 registration is typically performed by the ETR(s) that are assigned 302 and own the EID-prefix. That is, the destination site makes the 303 choice of the RTRs in the ELP. However, it may be common practice 304 for a provisioning system to program the mapping database with ELPs. 306 Another case where a locator-set can be used for flow-based load- 307 sharing across multiple paths to the same destination site: 309 EID-prefix: 10.0.0.0/8 310 Locator-set: (x, y, ETR-A): priority 1, weight 75 311 (q, r, ETR-A): priority 1, weight 25 313 Using this mapping entry, an ITR would load split 75% of the EID 314 flows on the (x, y, ETR-A) ELP path and 25% of the EID flows on the 315 (q, r, ETR-A) ELP path. If any of the ELPs go down, then the other 316 can take 100% of the load. 318 5.1. ELP Re-optimization 320 ELP re-optimization is a process of changing the RLOCs of an ELP due 321 to underlying network change conditions. Just like when there is any 322 locator change for a locator-set, the procedures from the main LISP 323 specification [LISP] are followed. 325 When a RLOC from an ELP is changed, Map-Notify messages [LISP-MS] can 326 be used to inform the existing RTRs in the ELP so they can do a 327 lookup to obtain the latest version of the ELP. 329 5.2. Using Recursion 331 In the previous examples, we showed how an ITR encapsulates using an 332 ELP of (x, y, etr). When a packet is encapsulated from the ITR to 333 RTR 'x', the RTR may want a policy path to RTR 'y' and run another 334 level of re-encapsulating tunnels for packets destined to RTR 'y'. 335 In this case, RTR 'x' does not decapsulate packets from the ITR. But 336 rather performs a mapping database lookup on the address 'y'. This 337 can be done in a public or private mapping database. The decision 338 and the encoding of the ELP is local to the provider who operates RTR 339 'x'. 341 Another example of recursion is when the ITR uses the ELP (x, y, etr) 342 to first prepend a header with a destination RLOC of the ETR and then 343 prepend another header and encapsulate the packet to RTR 'x'. When 344 RTR 'x' decapsulates the packet, rather than doing a mapping database 345 lookup on RTR 'y' the last example showed, instead RTR 'x' does a 346 mapping database lookup on ETR 'etr'. In this scenario, RTR 'x' can 347 choose an ELP from the locator-set by considering the source RLOC 348 address of the ITR versus considering the source EID. 350 This additional level of recursion also brings advantages for the 351 provider of RTR 'x' to store less state. Since RTR 'x' does not need 352 to look at the inner most header, it does not need to store EID 353 state. It only stores an entry for RTR 'y' which many EID flows 354 could share for scaling benefits. The locator-set for entry 'y' 355 could either be a list of typical locators, a list of ELPs, or 356 combination of both. Another advantage is that packet load-splitting 357 can be accomplished by examining the source of a packet. If the 358 source is an ITR versus the source is the last-hop of an ELP the 359 last-hop selected, different forwarding paths can be used. 361 5.3. ELP Selection based on Class of Service 363 Paths to an ETR may want to be selected based on different classes of 364 service. Packets from a set of sources that have premium service can 365 use ELP paths that are less congested where normal sources use ELP 366 paths that compete for less resources or use longer paths for best 367 effort service. 369 Using source/destination lookups into the mapping database can yield 370 different ELPs. So for example a premium service flow with 371 (source=1.1.1.1, dest=10.1.1.1) can be described by using the 372 following mapping entry: 374 EID-prefix: (1.0.0.0/8, 10.0.0.0/8) 375 Locator-set: (x, y, ETR-A): priority 1, weight 50 376 (q, r, ETR-A): priority 1, weight 50 378 And all other best-effort sources would use different mapping entry 379 described by: 381 EID-prefix: (0.0.0.0/0, 10.0.0.0/8) 382 Locator-set: (x, x', y, y', ETR-A): priority 1, weight 50 383 (q, q', r, r', ETR-A): priority 1, weight 50 385 If the source/destination lookup is coupled with recursive lookups, 386 then an ITR can encapsulate to the ETR, prepending a header that 387 selects source address ITR-1 based on the premium class of service 388 source, or selects source address ITR-2 for best-effort sources with 389 normal class of service. Then the ITR does another lookup in the 390 mapping database on the prepended header using lookup key 391 (source=ITR-1, dest=10.1.1.1) that returns the following mapping 392 entry: 394 EID-prefix: (ITR-1, 10.0.0.0/8) 395 Locator-set: (x, y, ETR-A): priority 1, weight 50 396 (q, r, ETR-A): priority 1, weight 50 398 And all other sources would use different mapping entry with a lookup 399 key of (source=ITR-2, dest=10.1.1.1): 401 EID-prefix: (ITR-2, 10.0.0.0/8) 402 Locator-set: (x, x', y, y', ETR-A): priority 1, weight 50 403 (q, q', r, r', ETR-A): priority 1, weight 50 405 This will scale the mapping system better by having fewer source/ 406 destination combinations. Refer to the Source/Dest LCAF type 407 described in [LISP-LCAF] for encoding EIDs in Map-Request and Map- 408 Register messages. 410 5.4. Packet Loop Avoidance 412 An ELP that is first used by an ITR must be inspected for encoding 413 loops. If any RLOC appears twice in the ELP, it MUST not be used. 415 Since it is expected that multiple mapping systems will be used, 416 there can be a loop across ELPs when registered in different mapping 417 systems. The TTL copying procedures for re-encapsulating tunnels and 418 recursive tunnels in [LISP] MUST be followed. 420 6. RLOC Probing by RTRs 422 Since an RTR knows the next tunnel hop to encapsulate to, it can 423 monitor the reachability of the next-hop RTR RLOC by doing RLOC- 424 probing according to the procedures in [LISP]. When the RLOC is 425 determined unreachable by the RLOC-probing mechanisms, the RTR can 426 use another locator in the locator-set. That could be the final ETR, 427 a RLOC of another RTR, or an ELP where it must search for itself and 428 use the next RLOC in the ELP list to encapsulate to. 430 RLOC-probing can also be used to measure delay on the path between 431 RTRs and when it is desirable switch to another lower delay ELP. 433 7. Interworking Considerations 435 [LISP-IW] defines procedures for how non-LISP sites talk to LISP 436 sites. The network elements defined in the Interworking 437 specification, the proxy ITR (PITR) and proxy ETR (PETR) (as well as 438 their multicast counterparts defined in [LISP-MCAST]) can participate 439 in LISP-TE. That is, a PITR and a PETR can appear in an ELP list and 440 act as an RTR. 442 Note when an RLOC appears in an ELP, it can be of any address-family. 443 There can be a mix of IPv4 and IPv6 locators present in the same ELP. 444 This can provide benefits where islands of one address-family or the 445 other are supported and connectivity across them is necessary. For 446 instance, an ELP can look like: 448 (x4, a6, b6, y4, etr) 450 Where an IPv4 ITR will encapsulate using an IPv4 RLOC 'x4' and 'x4' 451 could reach an IPv4 RLOC 'a6', but RTR 'a6' encapsulates to an IPv6 452 RLOC 'b6' when the network between them is IPv6-only. Then RTR 'b6' 453 encapsulates to IPv4 RLOC 'y4' if the network between them is dual- 454 stack. 456 Note that RTRs can be used for NAT-traversal scenarios [LISP-NATT] as 457 well to reduce the state in both an xTR that resides behind a NAT and 458 the state the NAT needs to maintain. In this case, the xTR only 459 needs a default map-cache entry pointing to the RTR for outbound 460 traffic and all remote ITRs can reach EIDs through the xTR behind a 461 NAT via a single RTR (or a small set RTRs for redundancy). 463 RTRs have some scaling features to reduce the number of locator-set 464 changes, the amount of state, and control packet overhead: 466 o When ITRs and PITRs are using a small set of RTRs for 467 encapsulating to orders of magnitude more EID-prefixes, the 468 probability of locator-set changes are limited to the RTR RLOC 469 changes versus the RLOC changes for the ETRs associated with the 470 EID-prefixes if the ITRs and PITRs were directly encapsulating to 471 the ETRs. This comes at an expense in packet stretch, but 472 depending on RTR placement, this expense can be mitigated. 474 o When RTRs are on path between many pairwise EID flows, ITRs and 475 PITRs can store a small number of coarse EID-prefixes. 477 o RTRs can be used to help scale RLOC-probing. Instead of ITRs 478 RLOC- probing all ETRs for each destination site it has cached, 479 the ITRs can probe a smaller set of RTRs which in turn, probe the 480 destination sites. 482 8. Multicast Considerations 484 ELPs have application in multicast environments. Just like RTRs can 485 be used to provide connectivity across different address family 486 islands, RTRs can help concatenate a multicast region of the network 487 to one that does not support native multicast. 489 Note there are various combinations of connectivity that can be 490 accomplished with the deployment of RTRs and ELPs: 492 o Providing multicast forwarding between IPv4-only-unicast regions 493 and IPv4-multicast regions. 495 o Providing multicast forwarding between IPv6-only-unicast regions 496 and IPv6-multicast regions. 498 o Providing multicast forwarding between IPv4-only-unicast regions 499 and IPv6-multicast regions. 501 o Providing multicast forwarding between IPv6-only-unicast regions 502 and IPv4-multicast regions. 504 o Providing multicast forwarding between IPv4-multicast regions and 505 IPv6-multicast regions. 507 An ITR or PITR can do a (S-EID,G) lookup into the mapping database. 508 What can be returned is a typical locator-set that could be made up 509 of the various RLOC addresses: 511 Multicast EID key: (seid, G) 512 Locator-set: ETR-A: priority 1, weight 25 513 ETR-B: priority 1, weight 25 514 g1: priority 1, weight 25 515 g2: priority 1, weight 25 517 An entry for host 'seid' sending to application group 'G' 519 The locator-set above can be used as a replication list. That is 520 some RLOCs listed can be unicast RLOCs and some can be delivery group 521 RLOCs. A unicast RLOC in this case is used to encapsulate a 522 multicast packet originated by a multicast source EID into a unicast 523 packet for unicast delivery on the underlying network. ETR-A could 524 be a IPv4 unicast RLOC address and ETR-B could be a IPv6 unicast RLOC 525 address. 527 A delivery group address is used when a multicast packet originated 528 by a multicast source EID is encapsulated in a multicast packet for 529 multicast delivery on the underlying network. Group address 'g1' 530 could be a IPv4 delivery group RLOC and group address 'g2' could be 531 an IPv6 delivery group RLOC. 533 Flexibility for these various types of connectivity combinations can 534 be achieved and provided by the mapping database system. And the RTR 535 placement allows the connectivity to occur where the differences in 536 network functionality are located. 538 Extending this concept by allowing ELPs in locator-sets, one could 539 have this locator-set registered in the mapping database for (seid, 540 G): 542 Multicast EID key: (seid, G) 543 Locator-set: (x, y, ETR-A): priority 1, weight 50 544 (a, g, b, ETR-B): priority 1, weight 50 546 Using ELPs for multicast flows 548 In the above situation, an ITR would encapsulate a multicast packet 549 originated by a multicast source EID to the RTR with unicast RLOC 550 'x'. Then RTR 'x' would decapsulate and unicast encapsulate to RTR 551 'y' ('x' or 'y' could be either IPv4 or IPv6 unicast RLOCs), which 552 would decapsulate and unicast encapsulate to the final RLOC "ETR-A". 553 The ETR "ETR-A" would decapsulate and deliver the multicast packet 554 natively to all the receivers joined to application group 'G' inside 555 the LISP site. 557 Let's look at the ITR using the ELP (a, g, b, ETR-B). Here the 558 encapsulation path would be the ITR unicast encapsulates to unicast 559 RLOC 'a'. RTR 'a' multicast encapsulates to delivery group 'g'. The 560 packet gets to all ETRs that have joined delivery group 'g' so they 561 can deliver the multicast packet to joined receivers of application 562 group 'G' in their sites. RTR 'b' is also joined to delivery group 563 'g'. Since it is in the ELP, it will be the only RTR that unicast 564 encapsulates the multicast packet to ETR 'ETR-B'. Lastly, ETR-B 565 decapsulates and delivers the multicast packet to joined receivers to 566 application group 'G' in its LISP site. 568 As one can see there are all sorts of opportunities to provide 569 multicast connectivity across a network with non-congruent support 570 for multicast and different address-families. One can also see how 571 using the mapping database can allow flexible forms of delivery 572 policy, rerouting, and congestion control management in multicast 573 environments. 575 9. Security Considerations 577 When an RTR receives a LISP encapsulated packet, it can look at the 578 outer source address to verify that RLOC is the one listed as the 579 previous hop in the ELP list. If the outer source RLOC address 580 appears before the RLOC which matches the outer destination RLOC 581 address, the decapsulating RTR (or ETR if last hop), MAY choose to 582 drop the packet. 584 10. IANA Considerations 586 At this time there are no requests for IANA. 588 11. References 590 11.1. Normative References 592 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 593 "Locator/ID Separation Protocol (LISP)", 594 draft-ietf-lisp-22.txt (work in progress). 596 [LISP-IW] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 597 "Interworking LISP with IPv4 and IPv6", 598 draft-ietf-lisp-interworking-06.txt (work in progress). 600 [LISP-MCAST] 601 Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 602 "LISP for Multicast Environments", 603 draft-ietf-lisp-multicast-13.txt (work in progress). 605 [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface", 606 draft-ietf-lisp-ms-15.txt (work in progress). 608 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 609 September 1981. 611 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 612 STD 13, RFC 1034, November 1987. 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 618 (IPv6) Specification", RFC 2460, December 1998. 620 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 621 A., Peterson, J., Sparks, R., Handley, M., and E. 622 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 623 June 2002. 625 11.2. Informative References 627 [LISP-LCAF] 628 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 629 Address Format", draft-farinacci-lisp-lcaf-07.txt (work in 630 progress). 632 [LISP-NATT] 633 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 634 F., and C. White, "NAT traversal for LISP", 635 draft-ermagan-lisp-nat-traversal-00.txt (work in 636 progress). 638 Appendix A. Acknowledgments 640 The authors would like to thank the following people for their ideas 641 and comments. They are Albert Cabellos. 643 Appendix B. Document Change Log 645 B.1. Changes to draft-farinacci-lisp-te-00.txt 647 o Initial draft posted March 2012. 649 Authors' Addresses 651 Dino Farinacci 652 cisco Systems 653 Tasman Ave. 654 San Jose, California 655 USA 657 Phone: 408-718-2001 658 Email: dino@cisco.com 660 Parantap Lahiri 661 Microsoft Corporation 662 Redmond, WA 663 USA 665 Email: parantal@microsoft.com 667 Michael Kowal 668 cisco Systems 669 111 Wood Avenue South 670 ISELIN, NJ 671 USA 673 Email: mikowal@cisco.com