idnits 2.17.1 draft-farinacci-lisp-mr-signaling-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 14, 2013) is 3870 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-00 == Outdated reference: A later version (-08) exists of draft-coras-lisp-re-01 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-02 Summary: 2 errors (**), 0 flaws (~~), 5 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 lispers.net 4 Intended status: Experimental M. Napierala 5 Expires: March 18, 2014 AT&T 6 September 14, 2013 8 LISP Control-Plane Multicast Signaling 9 draft-farinacci-lisp-mr-signaling-03 11 Abstract 13 This document describes an alternate method to signal multicast tree 14 building among xTRs in multicast capable LISP sites. This approach 15 avoids the need to run a multicast routing protocol on the LISP 16 overlay. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 18, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 55 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Join-Request/Leave-Request Encoding Formats . . . . . . . . . 9 57 6. Replication Considerations . . . . . . . . . . . . . . . . . . 11 58 7. Interworking Considerations . . . . . . . . . . . . . . . . . 12 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 63 10.2. Informative References . . . . . . . . . . . . . . . . . 15 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 65 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 17 66 B.1. Changes to draft-farinacci-lisp-mr-signaling-03.txt . . . 17 67 B.2. Changes to draft-farinacci-lisp-mr-signaling-02.txt . . . 17 68 B.3. Changes to draft-farinacci-lisp-mr-signaling-01.txt . . . 17 69 B.4. Changes to draft-farinacci-lisp-mr-signaling-00.txt . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 72 1. Requirements Language 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [RFC2119]. 78 2. Introduction 80 The Locator/ID Separation Architecture [RFC6830] provides a mechanism 81 to separate out Identification and Location semantics from the 82 current definition of an IP address. By creating two namespaces, an 83 Endpoint ID (EID) namespace used by sites and a Routing Locator 84 (RLOC) namespace used by core routing, the core routing 85 infrastructure can scale by doing topological aggregation of routing 86 information. 88 Since LISP creates a new namespace, a mapping function must exist to 89 map a site's EID prefixes to its associated locators. For unicast 90 packets, both the source address and destination address must be 91 mapped. For multicast packets, only the source address needs to be 92 mapped. The destination group address doesn't need to be mapped 93 because the semantics of an IPv4 or IPv6 group address are logical in 94 nature and not topology-dependent. Therefore, this specification 95 focuses on the procedures of how to map a source EID address and 96 destination group address of a multicast flow during distribution 97 tree setup and packet delivery. 99 The LISP Multicast specification [RFC6831] addresses the following 100 procedures: 102 1. How a multicast source host in a LISP site sends multicast 103 packets to receivers inside of its site as well as to receivers 104 in other sites that are LISP enabled. 106 2. How inter-domain (or inter-LISP sites) multicast distribution 107 trees are built and how forwarding of multicast packets leaving a 108 source site toward receivers sites is performed. 110 3. What protocols are affected and what changes are required to such 111 multicast protocols. 113 4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source 114 Multicast), and Bidir-mode (Bidirectional Shared Trees) service 115 models will operate. 117 5. How multicast packet flow will occur for multiple combinations of 118 LISP and non-LISP capable source and receiver sites. 120 The distribution tree mechanism in [RFC6831] specifies the use of the 121 PIM multicast routing protocol and how PIM is used between xTRs 122 connecting multicast capable source sites and receiver sites 123 together. 125 This specification will describe an alternate method for connecting 126 multicast capable sites together by using Map-Requests instead of the 127 PIM protocol. The advantages this brings is a single LISP control- 128 plane mechanism used for both unicast and multicast packet flow. 130 This specification does not describe how (S-EID,G) multicast 131 distribution tree state is built in multicast receiver sites and in 132 multicast source sites. This specification also does not describe 133 how (S-RLOC,G) or (S-RLOC,DG) multicast distribution tree state is 134 built in the core network. This specification defines how (S-EID,G) 135 state is propagated from multicast receiver site resident ETRs to 136 multicast ITRs. This signaling is needed so the (S-EID,G) state can 137 be propagated from the ITR to the source host in the multicast source 138 site. 140 3. Definition of Terms 142 Note that all the definitions that apply in [RFC6831] apply in this 143 specification as well. And the following definitions are specific to 144 this specification. 146 Join-Request: This is a reference to a Map-Request that allows the 147 joining to a multicast tree by an ETR to an ITR (or PITR) for a 148 given (S-EID,G) entry. 150 Leave-Request: This is a reference to a Map-Request that allows the 151 leaving from a multicast tree by an ETR to an ITR (or PITR) for a 152 given (S-EID,G) entry. 154 LISP-RE: RE stands for "Replication Engineering" which is a term 155 used to design algorithms, protocols, and networks to optimize 156 where multicast packet replication is performed in the network. 158 Unicast Replication: Is the notion of replicating a multicast 159 packet at an ITR (or PITR) by encapsulating it into a unicast 160 packet. That is, the oif-list of a multicast routing table entry 161 can not only have interfaces present for link-layer replication 162 and for multicast encapsulation but also for unicast 163 encapsulation. 165 Delivery Group: This is the outer packet's (or encapsulating 166 header's) destination address when encapsulating a multicast 167 packet inside of a multicast packet. There is a one-to-one and 168 one-to-many relationship between the inner header's destination 169 group address and the outer header's destination group address. 170 Notation for a delivery group entry is (S-RLOC,DG). 172 (S-EID,G): This is multicast state notation which is signaled from 173 ETR to ITR in Map-Request messages. 'G' is the group address 174 multicast hosts send and/or join to. 'S-EID' can be a host EID 175 that sends multicast packets. 'S-EID' can be a Rendezvous Point 176 (RP) that resides in the LISP multicast site so (*,G) state can be 177 signaled from ETR to ITR. All of PIM (S,G), (*,G), and (S,G,RP- 178 bit) state can be conveyed via the Multicast Info Type format 179 [LISP-LCAF] in Map-Request messages. 181 (S-RLOC,DG): This is multicast state notation which is kept by the 182 multicast core network. An (S-EID,G) packet originated by a 183 multicast source is encapsulated by an ITR (or PITR) which maps 184 the source EID (S-EID) to a source RLOC (S-RLOC) and the 185 destination group address G to a Delivery Group address (DG). 187 4. Overview 189 In [RFC6831], there is a two step approach for an ETR to join the 190 distribution tree (S-EID,G) at an ITR where that distribution tree 191 connects to a core distribution tree. In the first step, the ETR 192 must look up which ITR is associated with S-EID. That is performed 193 with a mapping database lookup and having the ETR select an ITR from 194 the list of high priority RLOCs. In the second step, a unicast PIM 195 join must be sent by the ETR to the ITR. 197 In the design here within, we transmit the join and leave semantic in 198 a Map-Request message. In this case, both the S-EID lookup and the 199 the fact the ETR wants to join the distribution tree S-EID for a 200 particular multicast group can be conveyed in one message exchange. 201 The advantages of this are: 203 1. Less message overhead used for signaling. 205 2. State signaling comes together in a single message. If an ETR 206 has a map-cache entry for the S-EID, it also knows that the Join 207 for (S-EID,G) reliably made it to the ITR. If there is message 208 loss both pieces of state fate-share the loss. 210 3. The Map-Reply is used as an acknowledgement where as with unicast 211 PIM Join-Prune messages, they must be sent periodically which may 212 create scalability problems in networks with a lot of multicast 213 state. 215 Here is the basic procedure that a multicast ETR or multicast PETR 216 uses to convey (S-EID,G) join state to a multicast ITR or multicast 217 PITR: 219 1. When an ETR creates (S-EID,G) from a site based PIM Join message 220 and the oif-list goes non-empty, a Join-Request is sent. If a 221 map-cache entry exists for S-EID, then the Map-Request is sent to 222 the highest multicast priority RLOC. If a map-cache entry does 223 not exist, the Map-Request is sent to the mapping database 224 system. 226 2. When a Map-Reply is not returned, the Map-Request is 227 retransmitted. When a Map-Reply is returned, the ETR can be 228 assured that the ITR will replicate packets to the ETR. 230 3. When unicast replication is performed, no additional action needs 231 to be performed by the ETR. 233 4. When multicast replication is performed, the ETR must send a PIM 234 Join message for (S-RLOC,G) or (S-RLOC,DG) into the core as 235 specified in [RFC6831]. See Section 6 for details when ITR 236 unicast and/or multicast replication is done and how it is 237 decided. 239 An ETR must detect when an ITR has reloaded or cleared its state so 240 that the ETR can resend Join-Requests for all the (S-EID,G) state it 241 has cached. Procedures for how to achieve this will be discussed in 242 future versions of this specification. 244 Here is the basic procedure a multicast ETR or multicast PETR uses to 245 convey (S-EID,G) leave state to a multicast ITR or multicast PITR: 247 1. When an ETR (S-EID,G) oif-list state goes empty, a Leave-Request 248 is sent. If a map-cache entry exists for S-EID, then the Map- 249 Request is sent to the highest multicast priority RLOC. If a 250 map-cache entry does not exist, the Map-Request is sent to the 251 mapping database system. 253 2. When a Map-Reply is not returned, the Map-Request is 254 retransmitted. When a Map-Reply is returned, the ETR can be 255 assured that the ITR will no longer replicate packets to the ETR. 257 3. When unicast replication is performed, no additional action needs 258 to be performed by the ETR. 260 4. When multicast replication is performed, the ETR must send a PIM 261 Leave message for (S-RLOC,G) or (S-RLOC,DG) into the core network 262 as specified in [RFC6831]. 264 5. Join-Request/Leave-Request Encoding Formats 266 A Join-Request and Leave-Request are encoded as follows: 268 o (S-EID,G) is encoded in the destination EID-prefix field of a Map- 269 Request [RFC6830]. 271 o The encoding format of the destination EID-prefix is in LCAF 272 format Type 'Multicast Info' [LISP-LCAF]. The J-bit and L-bit 273 indicate if the Map-Request is a Join-Request or a Leave-Request, 274 respectively. 276 o (S-RLOC,DG) is encoded in the Source EID Address field of the Map- 277 Request. It is also encoded in the same LCAF Type 'Multicast 278 Info'. 280 o If S-RLOC is not known, then AFI=0 is encoded in the Source 281 Address field of the LCAF type. 283 o If S-RLOC is known, then the RLOC of the ITR is encoded in the 284 Source Address field of the LCAF type. 286 o If a Delivery Group is being requested by the ETR, then DG is 287 encoded in the Group Address field of the LCAF type. 289 o If a unicast replication is being requested by the ETR, then ETR 290 encodes a unicast RLOC address in the Group Address field of the 291 LCAF type. 293 A Map-Reply is returned for a Join-Request or a Leave-Request with 294 the following format encoding: 296 1. The destination EID-prefix encoding in the Map-Request is copied 297 and encoded in the Source EID Address field of the Map-Reply. 298 This is so the ETR can match Map-Replies with Map-Requests. The 299 nonce field may be used for this purpose as well. The address 300 encoding is (S-EID,G). 302 2. The destination EID-prefix in the Map-Reply is the multicast 303 information the ITR is conveying to ETR. It can be (ITR-RLOC,DG) 304 or (ITR-RLOC,ETR-RLOC). 306 3. When the ETR requested unicast replication, then the returned 307 destination EID-prefix contains (ITR-RLOC,ETR-RLOC) 309 4. When the ETR requested a DG for multicast replication, then the 310 returned destination EID-prefix contains (ITR-RLOC,DG). 312 5. When the ITR overrides a requested (ITR-RLOC,ETR-RLOC) with a 313 returned (ITR-RLOC,DG), then the ETR must send a join (or leave) 314 for (ITR-RLOC,DG) into the core network. 316 6. When the ITR overrides a join-requested (ITR-RLOC,DG1) with a 317 returned value of (ITR-RLOC,DG2), then the ETR must send a Join- 318 Request for (ITR-RLOC,DG2) and send a Leave-Request for (ITR- 319 RLOC,DG1) into the core network. 321 7. When the ITR with RLOC 'RLOC-ITR1' returns (RLOC-ITR2,DG) in a 322 Map-Reply, the ETR must send a Join-Request to RLOC-ITR2 and send 323 a Leave-Request to RLOC-ITR1 for (RLOC-ITR1,DG). Same action is 324 performed when (RLOC-ITR2,ETR-RLOC) is returned for a join- 325 requested value of (RLOC-ITR1,ETR-RLOC). 327 6. Replication Considerations 329 When an ITR processes a received multicast packet sourced by a host 330 in its site, the oif-list for the (S-EID,G) entry it maintains can 331 have the following entries: 333 1. An interface entry that leads to multicast receivers inside of 334 the site. 336 2. An encapsulation entry that can be targeted to a Delivery Group 337 or a unicast RLOC. The Delivery Group can either be the same or 338 map from the group address of the packet originated by the 339 multicast source host. 341 The oif-list entries can be created by the signaling mechanisms 342 defined in [RFC6831] using the PIM protocol or by the signaling 343 mechanisms in this specification using Map-Requests. 345 Another option is to have an external orchestration system program 346 the mapping database explicitly so ETR signaling to the ITR can be 347 reduced or even eliminated. Also by the use of Explicit-Locator- 348 Paths (ELPs) [LISP-TE], LISP-RE capabilities can be explored. For 349 more details see [LISP-RE]. 351 Since an oif-list can contain either a Delivery Group or a unicast 352 RLOC as a destination address for the outer header, a question is 353 raised where the decision is made to use one or the other, or both. 355 It is desirable to use multicast routing in the core network where it 356 is available. However, if ETRs are attached to a multicast capable 357 core network, the ITR may not be. In this case, unicast RLOC 358 encapsulation will be necessary to deliver multicast packets directly 359 to the ETR. It will left to the network administrator to configure 360 the decision on Delivery Group versus unicast RLOCs is done by the 361 ETRs, the ITR, or an orchestration system directly programming the 362 mapping database. This specification allows and permits for the ETR 363 to request the encapsulation destination address as well as allowing 364 the ITR to override it. 366 7. Interworking Considerations 368 The Map-Request multicast signaling between ETR(s) and an ITR 369 described in this specification is also used by ETR(s) to multicast 370 PITRs which are deployed to support non-LISP multicast source sites. 371 This is true for multicast PETRs that signal to an ITR or mPITR which 372 support non-LISP multicast receiver sites. 374 8. Security Considerations 376 The security concerns for LISP multicast are mainly the same as for 377 the base LISP specification [RFC6830] and the LISP multicast 378 specification [RFC6831], including PIM-ASM [RFC4601]. 380 Where there are security concerns with respect to unicast PIM 381 messages, as discussed in [RFC6831], the same may also be true for 382 multicast signaling with Map-Request messages. 384 9. IANA Considerations 386 At this time there are no requests for IANA. 388 10. References 390 10.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 396 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 397 Protocol Specification (Revised)", RFC 4601, August 2006. 399 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 400 Locator/ID Separation Protocol (LISP)", RFC 6830, 401 January 2013. 403 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 404 Locator/ID Separation Protocol (LISP) for Multicast 405 Environments", RFC 6831, January 2013. 407 10.2. Informative References 409 [LISP-LCAF] 410 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 411 Address Format", draft-ietf-lisp-lcaf-00.txt (work in 412 progress). 414 [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 415 Maino, F., and D. Farinacci, "LISP Replication 416 Engineering", draft-coras-lisp-re-01.txt (work in 417 progress). 419 [LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic 420 Engineering Use-Cases", draft-farinacci-lisp-te-02.txt 421 (work in progress). 423 Appendix A. Acknowledgments 425 The authors would like to thank the following people for their 426 participation in conversations on the topic. They are Gregg Schudel, 427 Florin Coras, Darrel Lewis, Fabio Maino, and Noel Chiappa. 429 Appendix B. Document Change Log 431 B.1. Changes to draft-farinacci-lisp-mr-signaling-03.txt 433 o Posted September 2013. 435 o Add clarificaiton text through out to reflect comments from Noel 436 Chiappa. 438 B.2. Changes to draft-farinacci-lisp-mr-signaling-02.txt 440 o Refreshing references and document timer. 442 B.3. Changes to draft-farinacci-lisp-mr-signaling-01.txt 444 o Refreshing references and document timer. 446 B.4. Changes to draft-farinacci-lisp-mr-signaling-00.txt 448 o Initial draft posted July 2012. 450 Authors' Addresses 452 Dino Farinacci 453 lispers.net 454 San Jose, California 455 USA 457 Phone: 408-718-2001 458 Email: farinacci@gmail.com 460 Maria Napierala 461 AT&T 462 Middletown, NJ 463 USA 465 Email: mnapierala@att.com