idnits 2.17.1 draft-wijnands-mpls-ldp-mcast-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 492. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 16 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 209 has weird spacing: '...ow they deter...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2005) is 6975 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1700' is mentioned on line 146, but not defined ** Obsolete undefined reference: RFC 1700 (Obsoleted by RFC 3232) == Unused Reference: 'MPLS' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'LDP' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'MPLS-PIM' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC2547bis' is defined on line 421, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BIDIR' == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-06 ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group IJsbrand Wijnands 2 Internet Draft Bob Thomas 3 Expiration Date: September 2005 Cisco Systems, Inc. 4 Yuji Kamite 5 Hitoshi Fukuda 6 NTT Communications 8 March 2005 10 Multicast Extensions for LDP 12 draft-wijnands-mpls-ldp-mcast-ext-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79." 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 Forwarding multicast packets efficiently over an MPLS core requires 40 Point-to-Multi-Point (P2MP) or Multi-Point-to-Multi-Point (MP2MP) 41 LSP's between one or more Ingress routers and one or more Egress 42 routers. For efficient forwarding core LSRs need to replicate 43 labeled multicast packets where the branches of the P2MP/MP2MP tree 44 diverge. This draft specifies LDP extensions that enable it to build 45 P2MP/MP2MP LSPs in a receiver initiated manner. 47 Table of Contents 49 1 Specification of Requirments ....................... 2 50 2 Terminology ........................................ 3 51 3 Introduction ....................................... 3 52 4 Label distribution ................................. 3 53 5 Label allocation ................................... 4 54 6 MP-T FEC element ................................... 4 55 7 In-band signaling using LDP ........................ 5 56 8 Out-of-band signaling with LDP ..................... 5 57 9 Building a P2MP LSP tree ........................... 6 58 9.1 Label mapping ...................................... 6 59 9.2 Label withdraw ..................................... 6 60 10 Building a MP2MP tree .............................. 7 61 11 Assigning Labels for MP2MP upstream Traffic ........ 9 62 12 Acknowledgments .................................... 10 63 13 References ......................................... 10 64 13.1 Normative References ............................... 10 65 13.2 Informational References ........................... 10 66 14 Authors' Addresses ................................. 11 67 15 Full Copyright Statement ........................... 11 68 16 Intellectual Property .............................. 12 70 1. Specification of Requirments 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119. 76 2. Terminology 78 P2MP - Point to Multipoint Label Switched Tree. 79 MP2MP - Multipoint to Multipoint Label Switched Tree. 80 MP-T - Multipoint Tree, either a P2MP or MP2MP Tree. 81 Ingess - Router that is a sender on the MP-T. 82 Egress - Router that is a receiver of a MP-T. 83 Root - Router that acts as the Rendezvous point of the MP-T. 85 3. Introduction 87 Multicast trees are built using Protocol Indenpendent Multicast 88 [PIMv2]. PIM supports three different modes of operation: PIM 89 sparse-mode, PIM bidir [BIDIR] and PIM SSM. This draft specifies 90 extensions to LDP that enable it to build point-to-multipoint and 91 multipoint-to-multipoint trees for MPLS packet forwarding. These 92 P2MP and MP2MP MPLS trees are comparable to multicast PIM SSM and PIM 93 Bidir mode trees and may be used to support multicast over MPLS 94 LSP's. This draft does not specify procedures analogous to PIM 95 sparse-mode multicast. 97 PIM is a receiver driven soft state periodic protocol that builds 98 trees to a source or rendezvous point. Its receiver driven nature 99 allows it to scale well with dynamic multicast group membership and 100 large receiver populations. A router forwards tree membership 101 upstream, but does not forward any information about downstream 102 receivers. LDP extensions in this draft support receiver driven 103 construction of MP-T's. An advantage that the LDP extensions for 104 multicast have over PIM extensions for signaling labels is that LDP 105 has built-in reliability and flow control. 107 4. Label distribution 109 The labels which are mapped to MP-T LSPs are distributed by LDP in 110 Downstream Unsolicited Ordered Mode and retained using the 111 Conservative Label Retention mode. An LSR distributes the label for 112 an MP-T LSP to an upstream peer only if the peer is the its next hop 113 for the root of the MP-T. 115 5. Label allocation 117 Since the extensions for signaling MP-T's use downstream label 118 allocation MP-T LSPs may share the platform wide label space with 119 unicast LSPs. The MPLS forwarding engine is reponsible for deciding 120 to replicate packets using information supplied by LDP. Since MP-T 121 and unicast LSPs share the same label space there is no need for a 122 separate LDP session for MP-T's. 124 6. MP-T FEC element 126 The MP-T FEC element identifes an MP-T by means of the tree's root 127 address, the tree type and information that is opaque to core LSRs. 129 MP-T type FEC Element encoding: 131 0 1 2 3 132 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | MP-T Type(TBD)| Address Family | Address Length| 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Root Address | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Tree Type(TBD)| Opaque Len | Opaque value ... 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 MP-T Type 142 MP-T type FEC element, value to be assigned by IANA. 144 Address family 145 Two octet quantity containing a value from ADDRESS FAMILY 146 NUMBERS in [RFC1700] that encodes the address family for the 147 Root address field. 149 Address Length 150 Length of the Root address value in octets. 152 Root Address 153 The root address of the MP-T. Used by receiving LSR to 154 determine the next-hop toward the MP-T root. 156 Tree Type 157 1 octet that identifies the tree type ie. 158 - P2MP LSP. 160 - MP2MP downstream LSP. 161 - MP2MP upstream LSP. 163 Opaque Len 164 Length of the opaque value in octets. 166 Opaque value 167 Variable length opaque value that uniquely identifies the MP-T. 169 The triple uniquely identifies 170 the MP-T. LDP uses the Root Address to determine the upstream LSR 171 toward the MP-T; the Tree Type determines the nature of LDP 172 protocol interactions required to establish the MP-T LSP; and, the 173 Opaque Value carries information that may be meaningful to edge LSRs. 175 7. In-band signaling using LDP 177 LDP is used to build Label Switched paths through a network. The 178 packets that traverse the LSP are not of interest to LDP. Edge LSRs 179 may use the Opaque field of the MP-T FEC element to encode multicast 180 stream information. Egress LSRs may encode the source and group for 181 a multicast stream in the Opaque field. Of course, different Egress 182 LSRs which receive the same multicast stream must use the same 183 source/group encoding. Such an opaque value could be used to signal 184 the Root LSR which multicast stream is to be forwared on the MP-T. 185 Specification of such encodings is outside the scope of this draft. 187 The multicast component that wishes to receive multicast packets over 188 a LDP created MP-T creates the opaque FEC value. Depending on the 189 different applications there will be different Opaque FEC encodings. 190 Different FEC encodings are to be documented elsewhere. 192 8. Out-of-band signaling with LDP 194 When an egress router wishes to receive a multicast stream over a 195 MP-T it needs to know the identifier of that MP-T. Using in-band 196 signaling the egress router can create the MP-T identifier (Opaque 197 FEC) using a pre-defined algorithm, so there no need for other 198 signaling. If the egress router is not able to use in-band signaling, 199 for example when different multicast streams are aggregated over the 200 same MP-T then an out-of-band form of signaling is required to learn 201 the MP-T identifier. Such out-of-band signaling is beyond the scope 202 of this document. 204 9. Building a P2MP LSP tree 206 In order for a set of LSRs to become egress LSRs of the same P2MP or 207 MP2MP LSP, they must encode the same "root node" and "opaque 208 identifier" values into the FEC element of the LDP Mapping messages 209 that they send. How they determine what the proper root node and 210 opaque identifier values are is outside the scope of this 211 specification. 213 9.1. Label mapping 215 An LSR which is setting up a particular MP-T only sends a Label 216 Mapping Message for a P2MP LSP to the LSR which is to be its 217 "upstream neighbor" on that LSP. The upstream neighbor is the one 218 which is the next hop on the best path to the root. If there are 219 multiple paths to the root which are equally good, one is chosen. 220 However, once a label for a given P2MP LSP has been advertised to an 221 upstream LSR, no further label mapping messages for that LSP are sent 222 upstream, until such time as the label has been withdrawn, released, 223 or the LDP connection has failed. 225 When an LSR receives a Label Mapping it determines if it already has 226 state for this MP-T. If it does, it updates its MPLS forwarding 227 engine to reflect the new MP-T branch. 229 If the receiving LSR does not have state and is not the the Root LSR 230 for the MP-T it allocates a label, sends a Label Mapping for the MP-T 231 toward the Root LSR, and installs the binding on its chosen upstream 232 interface. This process is repeated until a Label Mapping message 233 for the MP-T reaches the Root LSR. 235 If the receiving LSR is the Root, it simply informs any subscribing 236 applicaton that the P2MP tree exists. How this is done is beyond the 237 scope of this document. 239 9.2. Label withdraw 241 When an MP-T egress LSR is no longer interested in an MP-T it 242 withdraws its label for the MP-T by means of a Label Withdraw message 243 using the MP-T FEC Element to identify the MP-T. 245 The LSR receiving a Label Withdraw message for an MP-T from a peer 246 updates its MPLS forwarding engine by removing the output information 247 for the MP-T that corresponds to the peer and sends a Label Release 248 message in reply. If no output information for the MP-T remains in 249 its MPLS forwarding engine the LSR sends a Label Withdraw for the 250 MP-T upstream. 252 10. Building a MP2MP tree 254 A MP2MP LSP is much like a P2MP LSP, is has a Root node and multiple 255 LSP-egress routers. The big difference compared with a P2MP tree is 256 that there will be multiple senders that can forward MPLS packets 257 upstream in the direction of the tree root. Each LSP-egress can be a 258 LSP-ingress router for the same tree. The root node for a P2MP tree 259 is always the same as the LSP-ingress router. This is not the case 260 for MP2MP trees, it can be an LSP-ingress router but can also be a 261 P-router in the core. 263 MPLS forwards packets based on the incoming label. The incomming 264 label identifies the next-hop(s) to which the MPLS packet should be 265 sent. For any MP-T tree there can be multiple next-hops. For an P2MP 266 tree there is only one interface that receives (i.e has forwarding 267 state for) packets belonging to the tree. For MP2MP there is some 268 set of interfaces which have state for the tree. Packets received on 269 any of these interfaces are replicated to each of the other members 270 of this set. 272 From the perspective of a given LSR, a MP2MP "tree" consists of n 273 P2MP LSPs, where n is the number of interfaces (upstream + 274 downstream) on the tree. Thus the forwarding state if O(number of 275 interfaces). If you instead used one P2MP LSP for each member of the 276 tree, your state would be O(number of members), which scales much 277 more poorly. 279 Root 280 +---+ +---+ +---+ +---+ +---+ 281 Rcv |PE1|------|P1 |-------| P | -----|P3 |----|PE2| Rcv 282 +---+ +---+ +---+ +---+ +---+ 283 |S0 284 |S1 285 +---+ 286 |P2 | 287 +---+ 288 S2 | | S3 289 +---+ +---+ | | +---+ +---+ 290 Rcv |PE3|------|P4 |------- -----|P5 |----|PE4| Rcv 291 Src +---+ +---+ +---+ +---+ 293 Figure 1. 295 Router P4 sends a label mapping to P2 and tells P2 to use label L2 for 296 downstream traffic. Router P5 does the same and makes P2 assigned L3 297 for downstream traffic. If we look at P2 the downstream state is as 298 follows. 300 Incoming Outgoing 301 ---------------------------- 302 | L1, S1 | L2, S2 | 303 | | L3, S3 | 304 ---------------------------- 305 Table 1. 307 Based on the label mapping send from P4 router P2 will send a label 308 mapping reply to P4 with a label that is required for upstream traffic 309 to P2. Same will happen for the upstream state from P5. Router P2 310 tells router P5 to use label L5 for upstream traffic. 312 From P2 to the root of the tree (P) the same protocol operations 313 occur. We send a label mapping including a downstream label L1 (see 314 table 1) and we receive an upstream label L6 mapping back for the 315 upstream state. The upstream label we received in the label mapping 316 reply is shared between the 2 upstream states since they both need to 317 go to the same root via the same path, so we merge them 318 together. Router P2 has the following upstream states: 320 Incoming Outgoing 321 ---------------------------- 322 | L4, S2 | L6, S1 | 323 ---------------------------- 324 Table 2. 326 Incoming Outgoing 327 ---------------------------- 328 | L5, S3 | L6, S1 | 329 ---------------------------- 330 Table 3. 332 The P (root) router will have the following upstream state. 334 Incoming Outgoing 335 ---------------------------- 336 | L6, S0 | | 337 ---------------------------- 338 Table 4. 340 The upstream state has been setup and packets can travel to the root 341 of the tree. However, while forwarding on a MP2MP tree we want to send 342 packets down the tree on intermediate nodes while packets travel 343 upstream. That means packets received from PE3 and PE4 need to be sent 344 to P5 via P2. We don't need to depend on the root to send the packets 345 downstream. We do this by merging the downstream state and the 346 upstream states. Each upstream state will copy the interfaces from the 347 downstream state replication list, except if it's the same as its 348 incoming interface. So the upstream state's on router P2 look like 349 this: 351 Incoming Outgoing 352 ---------------------------- 353 | L4, S2 | L6, S1 | 354 | | L3, S3 | 355 ---------------------------- 356 Table 5. 358 Incoming Outgoing 359 ---------------------------- 360 | L5, S3 | L6, S1 | 361 | | L2, S2 | 362 ---------------------------- 363 Table 6. 365 Using the technique of creating specific upstream states in 366 combination with merging the downstream replication list we are able to build a 367 full feature MP2MP LSP tree. The LSP tree does contain more then one 368 LSP path which costs extra labels, but the advantage is that the 369 forwarding logic does not need to deal with any specific forwarding 370 exceptions like we have in PIM bidir trees (forwarding packet that are 371 received on an Outgoing Interface List). 373 11. Assigning Labels for MP2MP upstream Traffic 375 To support MP2MP (bidirectional tree) LSP's we need to setup both a 376 downstream and a upstream LSP. The downstream path has the same 377 protocol operation as is used for P2MP LSP's, the upstream path is 378 different. The upstream path is setup in response to the downstream 379 path that is build. For a label mapping we sent to an upstream 380 router, the upstream router sends a label mapping in the opposite 381 direction to assign us a label for upstream traffic for this MP2MP 382 FEC. 384 The label mapping for the upstream path has the same encoding as the 385 downstream path. To be able to distinguish between the two we use the 386 Tree type encoded in the MP-T FEC. If an LSR receives a label 387 mapping of the type "upstream LSP" then this router will respond with 388 a label mapping of type "downstream LSP". When the downstream router 389 receives this label mapping it knows what this labbel mapping is for 390 the upstream path. 392 12. Acknowledgments 394 The authors would like to thank Arjen Boers, Eric Rosen, Nidhi 395 Bhaskar, Toerless Eckert and George Swallow for their contribution. 397 13. References 399 13.1. Normative References 401 [MPLS] "Multiprotocol Label Switching Architecture", Rosen, E., 402 Viswanathan, A. and R. Callon, RFC 3031, January 2001. 404 [BIDIR] "Bi-directional Protocol Independent Multicast", Handley, 405 Kouvelas, Speakman, Vicisano, June 2002, 408 [PIMv2] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", 409 Fenner, Handley, Holbrook, Kouvelas, December 2002, draft-ietf-pim- 410 sm-v2-new-06.txt. 412 [LDP] "LDP Specification", Andersson, Doolan, Feldman, Fredette, 413 Thomas, January 2001, rfc3036. 415 13.2. Informational References 417 [MPLS-PIM] "Using PIM to Distribute MPLS Labels for Multicast 418 Routes", Farinacci, Rekhter, Rosen, Qian, November 2000, 421 [RFC2547bis] "BGP/MPLS VPNs", Rosen, et. al., November 2002, draft- 422 ietf-ppvpn-rfc2547bis-03.txt 424 14. Authors' Addresses 426 IJsbrand Wijnands 427 Cisco Systems, Inc. 428 De kleetlaan 6a 429 1831 Diegem 430 Belgium 431 E-mail: ice@cisco.com 433 Bob Thomas 434 Cisco Systems, Inc. 435 300 Beaver Brook Road 436 Boxborough, MA, 01719 437 E-mail: rhthomas@cisco.com 439 Yuji Kamite 440 NTT Communications Corporation 441 Tokyo Opera City Tower 442 3-20-2 Nishi Shinjuku, Shinjuku-ku, 443 Tokyo 163-1421, 444 Japan 445 Email: y.kamite@ntt.com 447 Hitoshi Fukuda 448 NTT Communications Corporation 449 1-1-6, Uchisaiwai-cho, Chiyoda-ku 450 Tokyo 100-8019, 451 Japan 452 Email: hitoshi.fukuda@ntt.com 454 15. Full Copyright Statement 456 Copyright (C) The Internet Society (2005). 458 This document is subject to the rights, licenses and restrictions 459 contained in BCP 78, and except as set forth therein, the authors 460 retain all their rights." 462 "This document and the information contained herein are provided on 463 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 464 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 465 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 466 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 467 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 468 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 470 16. Intellectual Property 472 The IETF takes no position regarding the validity or scope of any 473 Intellectual Property Rights or other rights that might be claimed to 474 pertain to the implementation or use of the technology described in 475 this document or the extent to which any license under such rights 476 might or might not be available; nor does it represent that it has 477 made any independent effort to identify any such rights. Information 478 on the procedures with respect to rights in RFC documents can be 479 found in BCP 78 and BCP 79. 481 Copies of IPR disclosures made to the IETF Secretariat and any 482 assurances of licenses to be made available, or the result of an 483 attempt made to obtain a general license or permission for the use of 484 such proprietary rights by implementers or users of this 485 specification can be obtained from the IETF on-line IPR repository at 486 http://www.ietf.org/ipr. 488 The IETF invites any interested party to bring to its attention any 489 copyrights, patents or patent applications, or other proprietary 490 rights that may cover technology that may be required to implement 491 this standard. Please address the information to the IETF at ietf- 492 ipr@ietf.org.