idnits 2.17.1 draft-farinacci-lisp-mr-signaling-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 : ---------------------------------------------------------------------------- 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 (July 9, 2012) is 4302 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 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-08) exists of draft-coras-lisp-re-00 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-00 Summary: 1 error (**), 0 flaws (~~), 6 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 M. Napierala 5 Expires: January 10, 2013 AT&T 6 July 9, 2012 8 LISP Control-Plane Multicast Signaling 9 draft-farinacci-lisp-mr-signaling-00 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 January 10, 2013. 35 Copyright Notice 37 Copyright (c) 2012 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-00.txt . . . 17 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 69 1. Requirements Language 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 2. Introduction 77 The Locator/ID Separation Architecture [LISP] provides a mechanism to 78 separate out Identification and Location semantics from the current 79 definition of an IP address. By creating two namespaces, an Endpoint 80 ID (EID) namespace used by sites and a Routing Locator (RLOC) 81 namespace used by core routing, the core routing infrastructure can 82 scale by doing topological aggregation of routing information. 84 Since LISP creates a new namespace, a mapping function must exist to 85 map a site's EID prefixes to its associated locators. For unicast 86 packets, both the source address and destination address must be 87 mapped. For multicast packets, only the source address needs to be 88 mapped. The destination group address doesn't need to be mapped 89 because the semantics of an IPv4 or IPv6 group address are logical in 90 nature and not topology-dependent. Therefore, this specification 91 focuses on the procedures of how to map a source EID address of a 92 multicast flow during distribution tree setup and packet delivery. 94 The LISP Multicast specification [LISP-MCAST] addresses the following 95 procedures: 97 1. How a multicast source host in a LISP site sends multicast 98 packets to receivers inside of its site as well as to receivers 99 in other sites that are LISP enabled. 101 2. How inter-domain (or inter-LISP sites) multicast distribution 102 trees are built and how forwarding of multicast packets leaving a 103 source site toward receivers sites is performed. 105 3. What protocols are affected and what changes are required to such 106 multicast protocols. 108 4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source 109 Multicast), and Bidir-mode (Bidirectional Shared Trees) service 110 models will operate. 112 5. How multicast packet flow will occur for multiple combinations of 113 LISP and non-LISP capable source and receiver sites. 115 The distribution tree mechanism in [LISP-MCAST] specifies the use of 116 the PIM multicast routing protocol and how PIM is used between xTRs 117 connecting multicast capable source sites and receiver sites 118 together. 120 This specification will describe an alternate method for connecting 121 multicast capable sites together by using Map-Requests instead of the 122 PIM protocol. The advantages this brings is a single LISP control- 123 plane mechanism used for both unicast and multicast packet flow. 125 This specification does not describe how (S-EID,G) multicast 126 distribution tree state is built in multicast receiver sites and in 127 multicast source sites. This specification also does not describe 128 how (S-RLOC,G) or (S-RLOC,DG) multicast distribution tree state is 129 built in the core network. This specification defines how (S-EID,G) 130 state is propagated from multicast receiver site resident ETRs to 131 multicast ITRs. This signaling is needed so the (S-EID,G) state can 132 be propagated from the ITR to the source host in the multicast source 133 site. 135 3. Definition of Terms 137 Note that all the definitions that apply in [LISP-MCAST] apply in 138 this specification as well. And the following definitions are 139 specific to this specification. 141 Join-Request: This is a reference to a Map-Request that allows the 142 joining to a multicast tree by an ETR to an ITR (or PITR) for a 143 given (S-EID,G) entry. 145 Leave-Request: This is a reference to a Map-Request that allows the 146 leaving from a multicast tree by an ETR to an ITR (or PITR) for a 147 given (S-EID,G) entry. 149 LISP-RE: RE stands for "Replication Engineering" which is a term 150 used to design algorithms, protocols, and networks to optimize 151 where multicast packet replication is performed in the network. 153 Unicast Replication: Is the notion of replicating a multicast 154 packet at an ITR (or PITR) by encapsulating it into a unicast 155 packet. That is, the oif-list of a multicast routing table entry 156 can not only have interfaces present for link-layer replication 157 and for multicast encapsulation but also for unicast 158 encapsulation. 160 Delivery Group: This is the outer packet's (or encapsulating 161 header's) destination address when encapsulating a multicast 162 packet inside of a multicast packet. There is a one-to-one and 163 one-to-many relationship between the inner header's destination 164 group address and the outer header's destination group address. 165 Notation for a delivery group entry is (S-RLOC,DG). 167 (S-EID,G): This is multicast state notation which is signaled from 168 ETR to ITR in Map-Request messages. 'G' is the group address 169 multicast hosts send and/or join to. 'S-EID' can be a host EID 170 that sends multicast packets. 'S-EID' can be a Rendezvous Point 171 (RP) that resides in the LISP multicast site so (*,G) state can be 172 signaled from ETR to ITR. All of PIM (S,G), (*,G), and (S,G,RP- 173 bit) state can be conveyed via the Multicast Info Type format 174 [LISP-LCAF] in Map-Request messages. 176 4. Overview 178 In [LISP-MCAST], there is a two step approach for an ETR to join 179 (S-EID,G) to an ITR. In the first step, the ETR must look up which 180 ITR is associated with S-EID. That is performed with a mapping 181 database lookup and having the ETR select an ITR from the list of 182 high priority RLOCs. In the second step, a unicast PIM join must be 183 sent by the ETR to the ITR. 185 In the design here within, we transmit the join and leave semantic in 186 a Map-Request message. In this case, both the S-EID lookup and the 187 the fact the ETR wants to join S-EID for a particular multicast group 188 can be conveyed in one message exchange. The advantages of this are: 190 1. Less message overhead used for signaling. 192 2. State signaling comes together in a single message. If an ETR 193 has a map-cache entry for the S-EID, it also knows that the Join 194 for (S-EID,G) reliably made it to the ITR. If there is message 195 loss both pieces of state fate-share the loss. 197 3. The Map-Reply is used as an acknowledgement where as with unicast 198 PIM Join-Prune messages, they must be sent periodically which may 199 create scalability problems in networks with a lot of multicast 200 state. 202 Here is the basic procedure that a multicast ETR or multicast PETR 203 uses to convey (S-EID,G) join state to a multicast ITR or multicast 204 PITR: 206 1. When an ETR creates (S-EID,G) from a site based PIM Join message 207 and the oif-list goes non-empty, a Join-Request is sent. If a 208 map-cache entry exists for S-EID, then the Map-Request is sent to 209 the highest multicast priority RLOC. If a map-cache entry does 210 not exist, the Map-Request is sent to the mapping database 211 system. 213 2. When a Map-Reply is not returned, the Map-Request is 214 retransmitted. When a Map-Reply is returned, the ETR can be 215 assured that the ITR will replicate packets to the ETR. 217 3. When unicast replication is performed, no additional action needs 218 to be performed by the ETR. 220 4. When multicast replication is performed, the ETR must send a PIM 221 Join message for (S-RLOC,G) or (S-RLOC,DG) into the core as 222 specified in [LISP-MCAST]. See Section 6 for details when ITR 223 unicast and/or multicast replication is done and how it is 224 decided. 226 An ETR must detect when an ITR has reloaded or cleared its state so 227 that the ETR can resend Join-Requests for all the (S-EID,G) state it 228 has cached. Procedures for how to achieve this will be discussed in 229 future versions of this specification. 231 Here is the basic procedure a multicast ETR or multicast PETR uses to 232 convey (S-EID,G) leave state to a multicast ITR or multicast PITR: 234 1. When an ETR (S-EID,G) oif-list state goes empty, a Leave-Request 235 is sent. If a map-cache entry exists for S-EID, then the Map- 236 Request is sent to the highest multicast priority RLOC. If a 237 map-cache entry does not exist, the Map-Request is sent to the 238 mapping database system. 240 2. When a Map-Reply is not returned, the Map-Request is 241 retransmitted. When a Map-Reply is returned, the ETR can be 242 assured that the ITR will no longer replicate packets to the ETR. 244 3. When unicast replication is performed, no additional action needs 245 to be performed by the ETR. 247 4. When multicast replication is performed, the ETR must send a PIM 248 Leave message for (S-RLOC,G) or (S-RLOC,DG) into the core network 249 as specified in [LISP-MCAST]. 251 5. Join-Request/Leave-Request Encoding Formats 253 A Join-Request and Leave-Request are encoded as follows: 255 o (S-EID,G) is encoded in the destination EID-prefix field of a Map- 256 Request [LISP]. 258 o The encoding format of the destination EID-prefix is in LCAF 259 format Type 'Multicast Info' [LISP-LCAF]. The J-bit and L-bit 260 indicate if the Map-Request is a Join-Request or a Leave-Request, 261 respectively. 263 o (S-RLOC,DG) is encoded in the Source EID Address field of the Map- 264 Request. It is also encoded in the same LCAF Type 'Multicast 265 Info'. 267 o If S-RLOC is not known, then AFI=0 is encoded in the Source 268 Address field of the LCAF type. 270 o If S-RLOC is known, then the RLOC of the ITR is encoded in the 271 Source Address field of the LCAF type. 273 o If a Delivery Group is being requested by the ETR, then DG is 274 encoded in the Group Address field of the LCAF type. 276 o If a unicast replication is being requested by the ETR, then ETR 277 encodes a unicast RLOC address in the Group Address field of the 278 LCAF type. 280 A Map-Reply is returned for a Join-Request or a Leave-Request with 281 the following format encoding: 283 1. The destination EID-prefix encoding in the Map-Request is copied 284 and encoded in the Source EID Address field of the Map-Reply. 285 This is so the ETR can match Map-Replies with Map-Requests. The 286 nonce field may be used for this purpose as well. The address 287 encoding is (S-EID,G). 289 2. The destination EID-prefix in the Map-Reply is the multicast 290 information the ITR is conveying to ETR. It can be (ITR-RLOC,DG) 291 or (ITR-RLOC,ETR-RLOC). 293 3. When the ETR requested unicast replication, then the returned 294 destination EID-prefix contains (ITR-RLOC,ETR-RLOC) 296 4. When the ETR requested a DG for multicast replication, then the 297 returned destination EID-prefix contains (ITR-RLOC,DG). 299 5. When the ITR overrides a requested (ITR-RLOC,ETR-RLOC) with a 300 returned (ITR-RLOC,DG), then the ETR must send a join (or leave) 301 for (ITR-RLOC,DG) into the core network. 303 6. When the ITR overrides a join-requested (ITR-RLOC,DG1) with a 304 returned value of (ITR-RLOC,DG2), then the ETR must send a Join- 305 Request for (ITR-RLOC,DG2) and send a Leave-Request for (ITR- 306 RLOC,DG1) into the core network. 308 7. When the ITR with RLOC 'RLOC-ITR1' returns (RLOC-ITR2,DG) in a 309 Map-Reply, the ETR must send a Join-Request to RLOC-ITR2 and send 310 a Leave-Request to RLOC-ITR1 for (RLOC-ITR1,DG). Same action is 311 performed when (RLOC-ITR2,ETR-RLOC) is returned for a join- 312 requested value of (RLOC-ITR1,ETR-RLOC). 314 6. Replication Considerations 316 When an ITR processes a received multicast packet sourced by a host 317 in its site, the oif-list for the (S-EID,G) entry it maintains can 318 have the following entries: 320 1. An interface entry that leads to multicast receivers inside of 321 the site. 323 2. An encapsulation entry that can be targeted to a Delivery Group 324 or a unicast RLOC. 326 The oif-list entries can be created by the signaling mechanisms 327 defined in [LISP-MCAST] using the PIM protocol or by the signaling 328 mechanisms in this specification using Map-Requests. 330 Another option is to have an external orchestration system program 331 the mapping database explicitly so ETR signaling to the ITR can be 332 reduced or even eliminated. Also by the use of Explicit-Locator- 333 Paths (ELPs) [LISP-TE], LISP-RE capabilities can be explored. For 334 more details see [LISP-RE]. 336 Since an oif-list can contain either a Delivery Group or a unicast 337 RLOC as a destination address for the outer header, a question is 338 raised where the decision is made to use one or the other, or both. 340 It is desirable to use multicast routing in the core network where it 341 is available. However, if ETRs are attached to a multicast capable 342 core network, the ITR may not be. In this case, unicast RLOC 343 encapsulation will be necessary to deliver multicast packets directly 344 to the ETR. It will left to the network administrator to configure 345 the decision on Delivery Group versus unicast RLOCs is done by the 346 ETRs, the ITR, or an orchestration system directly programming the 347 mapping database. This specification allows and permits for the ETR 348 to request the encapsulation destination address as well as allowing 349 the ITR to override it. 351 7. Interworking Considerations 353 The Map-Request multicast signaling between ETR(s) and an ITR 354 described in this specification is also used by ETR(s) to multicast 355 PITRs which are deployed to support non-LISP multicast source sites. 356 This is true for multicast PETRs that signal to an ITR or mPITR which 357 support non-LISP multicast receiver sites. 359 8. Security Considerations 361 The security concerns for LISP multicast are mainly the same as for 362 the base LISP specification [LISP] and the LISP multicast 363 specification [LISP-MCAST], including PIM-ASM [RFC4601]. 365 Where there are security concerns with respect to unicast PIM 366 messages, as discussed in [LISP-MCAST], the same may also be true for 367 multicast signaling with Map-Request messages. 369 9. IANA Considerations 371 At this time there are no requests for IANA. 373 10. References 375 10.1. Normative References 377 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 378 "Locator/ID Separation Protocol (LISP)", 379 draft-ietf-lisp-23.txt (work in progress). 381 [LISP-MCAST] 382 Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 383 "LISP for Multicast Environments", 384 draft-ietf-lisp-multicast-13.txt (work in progress). 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 390 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 391 Protocol Specification (Revised)", RFC 4601, August 2006. 393 10.2. Informative References 395 [LISP-LCAF] 396 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 397 Address Format", draft-farinacci-lisp-lcaf-10.txt (work in 398 progress). 400 [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 401 Maino, F., and D. Farinacci, "LISP Replication 402 Engineering", draft-coras-lisp-re-00.txt (work in 403 progress). 405 [LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic 406 Engineering Use-Cases", draft-farinacci-lisp-te-00.txt 407 (work in progress). 409 Appendix A. Acknowledgments 411 The authors would like to thank the following people for their 412 participation in conversations on the topic. They are Gregg Schudel, 413 Florin Coras, Darrel Lewis, and Fabio Maino. 415 Appendix B. Document Change Log 417 B.1. Changes to draft-farinacci-lisp-mr-signaling-00.txt 419 o Initial draft posted July 2012. 421 Authors' Addresses 423 Dino Farinacci 424 cisco Systems 425 Tasman Ave. 426 San Jose, California 427 USA 429 Phone: 408-718-2001 430 Email: dino@cisco.com 432 Maria Napierala 433 AT&T 434 Middletown, NJ 435 USA 437 Email: mnapierala@att.com