idnits 2.17.1 draft-farinacci-lisp-mr-signaling-06.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 (February 16, 2015) is 3319 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-07 == Outdated reference: A later version (-08) exists of draft-coras-lisp-re-06 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-07 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: August 20, 2015 AT&T 6 February 16, 2015 8 LISP Control-Plane Multicast Signaling 9 draft-farinacci-lisp-mr-signaling-06 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 August 20, 2015. 35 Copyright Notice 37 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . 2 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 55 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Join-Request/Leave-Request Encoding Formats . . . . . . . . . 6 57 6. Replication Considerations . . . . . . . . . . . . . . . . . 8 58 7. Interworking Considerations . . . . . . . . . . . . . . . . . 8 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 63 10.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 65 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 66 B.1. Changes to draft-farinacci-lisp-mr-signaling-06.txt . . . 10 67 B.2. Changes to draft-farinacci-lisp-mr-signaling-05.txt . . . 10 68 B.3. Changes to draft-farinacci-lisp-mr-signaling-04.txt . . . 10 69 B.4. Changes to draft-farinacci-lisp-mr-signaling-03.txt . . . 10 70 B.5. Changes to draft-farinacci-lisp-mr-signaling-02.txt . . . 10 71 B.6. Changes to draft-farinacci-lisp-mr-signaling-01.txt . . . 10 72 B.7. Changes to draft-farinacci-lisp-mr-signaling-00.txt . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Requirements Language 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 2. Introduction 83 The Locator/ID Separation Architecture [RFC6830] provides a mechanism 84 to separate out Identification and Location semantics from the 85 current definition of an IP address. By creating two namespaces, an 86 Endpoint ID (EID) namespace used by sites and a Routing Locator 87 (RLOC) namespace used by core routing, the core routing 88 infrastructure can scale by doing topological aggregation of routing 89 information. 91 Since LISP creates a new namespace, a mapping function must exist to 92 map a site's EID prefixes to its associated locators. For unicast 93 packets, both the source address and destination address must be 94 mapped. For multicast packets, only the source address needs to be 95 mapped. The destination group address doesn't need to be mapped 96 because the semantics of an IPv4 or IPv6 group address are logical in 97 nature and not topology-dependent. Therefore, this specification 98 focuses on the procedures of how to map a source EID address and 99 destination group address of a multicast flow during distribution 100 tree setup and packet delivery. 102 The LISP Multicast specification [RFC6831] addresses the following 103 procedures: 105 1. How a multicast source host in a LISP site sends multicast 106 packets to receivers inside of its site as well as to receivers 107 in other sites that are LISP enabled. 109 2. How inter-domain (or inter-LISP sites) multicast distribution 110 trees are built and how forwarding of multicast packets leaving a 111 source site toward receivers sites is performed. 113 3. What protocols are affected and what changes are required to such 114 multicast protocols. 116 4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source 117 Multicast), and Bidir-mode (Bidirectional Shared Trees) service 118 models will operate. 120 5. How multicast packet flow will occur for multiple combinations of 121 LISP and non-LISP capable source and receiver sites. 123 The distribution tree mechanism in [RFC6831] specifies the use of the 124 PIM multicast routing protocol and how PIM is used between xTRs 125 connecting multicast capable source sites and receiver sites 126 together. 128 This specification will describe an alternate method for connecting 129 multicast capable sites together by using Map-Requests instead of the 130 PIM protocol. The advantages this brings is a single LISP control- 131 plane mechanism used for both unicast and multicast packet flow. 133 This specification does not describe how (S-EID,G) multicast 134 distribution tree state is built in multicast receiver sites and in 135 multicast source sites. This specification also does not describe 136 how (S-RLOC,G) or (S-RLOC,DG) multicast distribution tree state is 137 built in the core network. This specification defines how (S-EID,G) 138 state is propagated from multicast receiver site resident ETRs to 139 multicast ITRs. This signaling is needed so the (S-EID,G) state can 140 be propagated from the ITR to the source host in the multicast source 141 site. 143 3. Definition of Terms 145 Note that all the definitions that apply in [RFC6831] apply in this 146 specification as well. And the following definitions are specific to 147 this specification. 149 Join-Request: This is a reference to a Map-Request that allows the 150 joining to a multicast tree by an ETR to an ITR (or PITR) for a 151 given (S-EID,G) entry. 153 Leave-Request: This is a reference to a Map-Request that allows the 154 leaving from a multicast tree by an ETR to an ITR (or PITR) for a 155 given (S-EID,G) entry. 157 LISP-RE: RE stands for "Replication Engineering" which is a term 158 used to design algorithms, protocols, and networks to optimize 159 where multicast packet replication is performed in the network. 161 Unicast Replication: Is the notion of replicating a multicast 162 packet at an ITR (or PITR) by encapsulating it into a unicast 163 packet. That is, the oif-list of a multicast routing table entry 164 can not only have interfaces present for link-layer replication 165 and for multicast encapsulation but also for unicast 166 encapsulation. 168 Delivery Group: This is the outer packet's (or encapsulating 169 header's) destination address when encapsulating a multicast 170 packet inside of a multicast packet. There is a one-to-one and 171 one-to-many relationship between the inner header's destination 172 group address and the outer header's destination group address. 173 Notation for a delivery group entry is (S-RLOC,DG). 175 (S-EID,G): This is multicast state notation which is signaled from 176 ETR to ITR in Map-Request messages. 'G' is the group address 177 multicast hosts send and/or join to. 'S-EID' can be a host EID 178 that sends multicast packets. 'S-EID' can be a Rendezvous Point 179 (RP) that resides in the LISP multicast site so (*,G) state can be 180 signaled from ETR to ITR. All of PIM (S,G), (*,G), and (S,G,RP- 181 bit) state can be conveyed via the Multicast Info Type format 182 [LISP-LCAF] in Map-Request messages. 184 (S-RLOC,DG): This is multicast state notation which is kept by the 185 multicast core network. An (S-EID,G) packet originated by a 186 multicast source is encapsulated by an ITR (or PITR) which maps 187 the source EID (S-EID) to a source RLOC (S-RLOC) and the 188 destination group address G to a Delivery Group address (DG). 190 4. Overview 192 In [RFC6831], there is a two step approach for an ETR to join the 193 distribution tree (S-EID,G) at an ITR where that distribution tree 194 connects to a core distribution tree. In the first step, the ETR 195 must look up which ITR is associated with S-EID. That is performed 196 with a mapping database lookup and having the ETR select an ITR from 197 the list of high priority RLOCs. In the second step, a unicast PIM 198 join must be sent by the ETR to the ITR. 200 In the design here within, we transmit the join and leave semantic in 201 a Map-Request message. In this case, both the S-EID lookup and the 202 the fact the ETR wants to join the distribution tree S-EID for a 203 particular multicast group can be conveyed in one message exchange. 204 The advantages of this are: 206 1. Less message overhead used for signaling. 208 2. State signaling comes together in a single message. If an ETR 209 has a map-cache entry for the S-EID, it also knows that the Join 210 for (S-EID,G) reliably made it to the ITR. If there is message 211 loss both pieces of state fate-share the loss. 213 3. The Map-Reply is used as an acknowledgement where as with unicast 214 PIM Join-Prune messages, they must be sent periodically which may 215 create scalability problems in networks with a lot of multicast 216 state. 218 Here is the basic procedure that a multicast ETR or multicast PETR 219 uses to convey (S-EID,G) join state to a multicast ITR or multicast 220 PITR: 222 1. When an ETR creates (S-EID,G) from a site based PIM Join message 223 and the oif-list goes non-empty, a Join-Request is sent. If a 224 map-cache entry exists for S-EID, then the Map-Request is sent to 225 the highest multicast priority RLOC. If a map-cache entry does 226 not exist, the Map-Request is sent to the mapping database 227 system. 229 2. When a Map-Reply is not returned, the Map-Request is 230 retransmitted. When a Map-Reply is returned, the ETR can be 231 assured that the ITR will replicate packets to the ETR. 233 3. When unicast replication is performed, no additional action needs 234 to be performed by the ETR. 236 4. When multicast replication is performed, the ETR must send a PIM 237 Join message for (S-RLOC,G) or (S-RLOC,DG) into the core as 238 specified in [RFC6831]. See Section 6 for details when ITR 239 unicast and/or multicast replication is done and how it is 240 decided. 242 An ETR must detect when an ITR has reloaded or cleared its state so 243 that the ETR can resend Join-Requests for all the (S-EID,G) state it 244 has cached. Procedures for how to achieve this will be discussed in 245 future versions of this specification. 247 Here is the basic procedure a multicast ETR or multicast PETR uses to 248 convey (S-EID,G) leave state to a multicast ITR or multicast PITR: 250 1. When an ETR (S-EID,G) oif-list state goes empty, a Leave-Request 251 is sent. If a map-cache entry exists for S-EID, then the Map- 252 Request is sent to the highest multicast priority RLOC. If a 253 map-cache entry does not exist, the Map-Request is sent to the 254 mapping database system. 256 2. When a Map-Reply is not returned, the Map-Request is 257 retransmitted. When a Map-Reply is returned, the ETR can be 258 assured that the ITR will no longer replicate packets to the ETR. 260 3. When unicast replication is performed, no additional action needs 261 to be performed by the ETR. 263 4. When multicast replication is performed, the ETR must send a PIM 264 Leave message for (S-RLOC,G) or (S-RLOC,DG) into the core network 265 as specified in [RFC6831]. 267 5. Join-Request/Leave-Request Encoding Formats 269 A Join-Request and Leave-Request are encoded as follows: 271 o (S-EID,G) is encoded in the destination EID-prefix field of a Map- 272 Request [RFC6830]. 274 o The encoding format of the destination EID-prefix is in LCAF 275 format Type 'Multicast Info' [LISP-LCAF]. The J-bit and L-bit 276 indicate if the Map-Request is a Join-Request or a Leave-Request, 277 respectively. 279 o (S-RLOC,DG) is encoded in the Source EID Address field of the Map- 280 Request. It is also encoded in the same LCAF Type 'Multicast 281 Info'. 283 o If S-RLOC is not known, then AFI=0 is encoded in the Source 284 Address field of the LCAF type. 286 o If S-RLOC is known, then the RLOC of the ITR is encoded in the 287 Source Address field of the LCAF type. 289 o If a Delivery Group is being requested by the ETR, then DG is 290 encoded in the Group Address field of the LCAF type. 292 o If a unicast replication is being requested by the ETR, then ETR 293 encodes a unicast RLOC address in the Group Address field of the 294 LCAF type. 296 A Map-Reply is returned for a Join-Request or a Leave-Request with 297 the following format encoding: 299 1. The destination EID-prefix encoded in the Map-Request is copied 300 to the EID-record field of the Map-Reply. The address encoding 301 is (S-EID,G). The nonce field is used to match replies with 302 requests. 304 2. The RLOC-record for the (S-EID,G) EID-record in the Map-Reply is 305 multicast specific replication information the ITR is conveying 306 to the ETR. It can be (ITR-RLOC,DG) or (ITR-RLOC,ETR-RLOC). It 307 is encoded as a "Multicast Info" LCAF [LISP-LCAF] as well. 309 3. When the ETR requested unicast replication, then the returned 310 RLOC-record contains (ITR-RLOC,ETR-RLOC) 312 4. When the ETR requested a DG for multicast replication, then the 313 returned RLOC-record contains (ITR-RLOC,DG). 315 5. When the ITR overrides a requested (ITR-RLOC,ETR-RLOC) with a 316 returned (ITR-RLOC,DG), then the ETR must send a join (or leave) 317 for (ITR-RLOC,DG) into the core network. 319 6. When the ITR overrides a join-requested (ITR-RLOC,DG1) with a 320 returned value of (ITR-RLOC,DG2), then the ETR must send a Join- 321 Request for (ITR-RLOC,DG2) and send a Leave-Request for (ITR- 322 RLOC,DG1) into the core network. 324 7. When the ITR with RLOC 'RLOC-ITR1' returns (RLOC-ITR2,DG) in a 325 Map-Reply, the ETR must send a Join-Request to RLOC-ITR2 and send 326 a Leave-Request to RLOC-ITR1 for (RLOC-ITR1,DG). Same action is 327 performed when (RLOC-ITR2,ETR-RLOC) is returned for a join- 328 requested value of (RLOC-ITR1,ETR-RLOC). 330 6. Replication Considerations 332 When an ITR processes a received multicast packet sourced by a host 333 in its site, the oif-list for the (S-EID,G) entry it maintains can 334 have the following entries: 336 1. An interface entry that leads to multicast receivers inside of 337 the site. 339 2. An encapsulation entry that can be targeted to a Delivery Group 340 or a unicast RLOC. The Delivery Group can either be the same or 341 map from the group address of the packet originated by the 342 multicast source host. 344 The oif-list entries can be created by the signaling mechanisms 345 defined in [RFC6831] using the PIM protocol or by the signaling 346 mechanisms in this specification using Map-Requests. 348 Another option is to have an external orchestration system program 349 the mapping database explicitly so ETR signaling to the ITR can be 350 reduced or even eliminated. Also by the use of Explicit-Locator- 351 Paths (ELPs) [LISP-TE], LISP-RE capabilities can be explored. For 352 more details see [LISP-RE]. 354 Since an oif-list can contain either a Delivery Group or a unicast 355 RLOC as a destination address for the outer header, a question is 356 raised where the decision is made to use one or the other, or both. 358 It is desirable to use multicast routing in the core network where it 359 is available. However, if ETRs are attached to a multicast capable 360 core network, the ITR may not be. In this case, unicast RLOC 361 encapsulation will be necessary to deliver multicast packets directly 362 to the ETR. It will left to the network administrator to configure 363 the decision on Delivery Group versus unicast RLOCs is done by the 364 ETRs, the ITR, or an orchestration system directly programming the 365 mapping database. This specification allows and permits for the ETR 366 to request the encapsulation destination address as well as allowing 367 the ITR to override it. 369 7. Interworking Considerations 371 The Map-Request multicast signaling between ETR(s) and an ITR 372 described in this specification is also used by ETR(s) to multicast 373 PITRs which are deployed to support non-LISP multicast source sites. 374 This is true for multicast PETRs that signal to an ITR or mPITR which 375 support non-LISP multicast receiver sites. 377 8. Security Considerations 379 The security concerns for LISP multicast are mainly the same as for 380 the base LISP specification [RFC6830] and the LISP multicast 381 specification [RFC6831], including PIM-ASM [RFC4601]. 383 Where there are security concerns with respect to unicast PIM 384 messages, as discussed in [RFC6831], the same may also be true for 385 multicast signaling with Map-Request messages. 387 9. IANA Considerations 389 At this time there are no requests for IANA. 391 10. References 393 10.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 399 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 400 Protocol Specification (Revised)", RFC 4601, August 2006. 402 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 403 Locator/ID Separation Protocol (LISP)", RFC 6830, January 404 2013. 406 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 407 Locator/ID Separation Protocol (LISP) for Multicast 408 Environments", RFC 6831, January 2013. 410 10.2. Informative References 412 [LISP-LCAF] 413 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 414 Address Format", draft-ietf-lisp-lcaf-07.txt (work in 415 progress), . 417 [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 418 Maino, F., and D. Farinacci, "LISP Replication 419 Engineering", draft-coras-lisp-re-06.txt (work in 420 progress), . 422 [LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic 423 Engineering Use-Cases", draft-farinacci-lisp-te-07.txt 424 (work in progress), . 426 Appendix A. Acknowledgments 428 The authors would like to thank the following people for their 429 participation in conversations on the topic. They are Gregg Schudel, 430 Florin Coras, Darrel Lewis, Fabio Maino, and Noel Chiappa. 432 Appendix B. Document Change Log 434 B.1. Changes to draft-farinacci-lisp-mr-signaling-06.txt 436 o Posted February 2015. 438 o Reset document timer and updated references. 440 B.2. Changes to draft-farinacci-lisp-mr-signaling-05.txt 442 o Posted August 2014. 444 o Reset document timer and updated references. 446 B.3. Changes to draft-farinacci-lisp-mr-signaling-04.txt 448 o Posted March 2014. 450 o Fixed titled "Join-Request/Leave-Request Encoding Formats" based 451 on comments from Florin. 453 B.4. Changes to draft-farinacci-lisp-mr-signaling-03.txt 455 o Posted September 2013. 457 o Add clarificaiton text through out to reflect comments from Noel 458 Chiappa. 460 B.5. Changes to draft-farinacci-lisp-mr-signaling-02.txt 462 o Refreshing references and document timer. 464 B.6. Changes to draft-farinacci-lisp-mr-signaling-01.txt 466 o Refreshing references and document timer. 468 B.7. Changes to draft-farinacci-lisp-mr-signaling-00.txt 470 o Initial draft posted July 2012. 472 Authors' Addresses 474 Dino Farinacci 475 lispers.net 476 San Jose, California 477 USA 479 Phone: 408-718-2001 480 Email: farinacci@gmail.com 482 Maria Napierala 483 AT&T 484 Middletown, NJ 485 USA 487 Email: mnapierala@att.com