idnits 2.17.1 draft-minei-mpls-ldp-p2mp-01.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 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 468. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 17, 2005) is 6851 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) ** Obsolete normative reference: RFC 3036 (ref. '1') (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) == Outdated reference: A later version (-03) exists of draft-leroux-mpls-mp-ldp-reqs-00 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-01 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group I. Minei 2 Internet-Draft K. Kompella 3 Expires: January 18, 2006 Juniper Networks 4 J-L. Le Roux 5 France Telecom 6 L. Fang 7 AT&T 8 L. Wang 9 Telenor 10 S. Amante 11 Level 3 Communications, LLC 12 July 17, 2005 14 Label Distribution Protocol Extensions for Point-to-Multipoint Label 15 Switched Paths 16 draft-minei-mpls-ldp-p2mp-01 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 18, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 This document describes extensions to the Label Distribution Protocol 49 (LDP) for the setup of point to multi-point (P2MP) Label Switched 50 Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The 51 solution relies on LDP without requiring a multicast routing protocol 52 in the network. Protocol elements and procedures for this solution 53 are described. There can be various applications for P2MP LSPs such 54 as IP multicast. Specification of how such applications can use a 55 LDP signaled P2MP LSP is outside the scope of this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Conventions used in this document . . . . . . . . . . . . 3 61 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1 The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 5 64 2.2 Using the P2MP FEC Element . . . . . . . . . . . . . . . . 6 65 2.2.1 Label Map . . . . . . . . . . . . . . . . . . . . . . 7 66 2.2.2 Label Withdraw . . . . . . . . . . . . . . . . . . . . 8 67 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4. Security considerations . . . . . . . . . . . . . . . . . . . 11 69 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.1 Normative References . . . . . . . . . . . . . . . . . . . 13 72 6.2 Informative References . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . 15 76 1. Introduction 78 The LDP protocol is described in [1]. It defines mechanisms for 79 setting up point to point (P2P) and multi-point to point (MP2P) LSPs 80 in the network. This document describes extensions to LDP for 81 setting up point to multi-point (P2MP) LSPs. Specifically, this 82 document describes how a P2MP LSP can be set up that allows traffic 83 from a single root (or ingress) node to be delivered to a number of 84 leaf (or egress) nodes. Only a single copy of the packet will be 85 sent on any link traversed by the P2MP LSP (see note at end of 86 Section 2.2.1). This is accomplished without the use of a multicast 87 protocol in the network. There can be several P2MP LSPs rooted at a 88 given ingress node, each with its own identifier. 90 The solution assumes that the leaf nodes of the P2MP LSP know the 91 root node and identifier of the P2MP LSP to which they belong. The 92 mechanisms for the distribution of this information are outside the 93 scope of this document. The specification of how an application can 94 use a P2MP LSP signaled by LDP is also outside the scope of this 95 document. 97 Interested readers may also wish to peruse the documents [4] and [6]. 99 1.1 Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [2]. 105 1.2 Terminology 107 The following terminology is taken from [4]. 109 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 111 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 112 LSRs. 114 MP2P LSP: A LSP that has one or more Ingress LSRs and one unique 115 Egress LSR. 117 MP2MP LSP: A LSP that has one or more Ingress LSRs and one or more 118 Egress LSRs. 120 Ingress LSR: Source of the P2MP LSP, also referred to as root node. 122 Egress LSR: One of potentially many destinations of an LSP, also 123 referred to as leaf node in the case of P2MP and MP2MP LSPs. 125 Transit LSR: An LSR that has one or more directly connected 126 downstream LSRs. 128 Bud LSR: An LSR that is an egress but also has one or more directly 129 connected downstream LSRs. 131 2. Protocol Operation 133 A P2MP LSP consists of a single root node, zero or more transit nodes 134 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 135 tear-down. Leaf nodes also install forwarding state to deliver the 136 traffic received on a P2MP LSP to wherever it needs to go; how this 137 is done is outside the scope of this document. Transit nodes install 138 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 139 down) toward the root. The root node installs forwarding state to 140 map traffic into the P2MP LSP; how the root node determines which 141 traffic should go over the P2MP LSP is outside the scope of this 142 document. 144 For the setup of a P2MP LSP with LDP, we define one new protocol 145 entity, the P2MP FEC Element to be used in the FEC TLV. The 146 description of the P2MP FEC Element follows. 148 2.1 The P2MP FEC Element 150 The P2MP FEC Element consists of the address of the root of the P2MP 151 LSP and an opaque identifier. The opaque identifier is unique within 152 the context of the root node. The combination of (root LSR address, 153 opaque identifier) uniquely identifies a P2MP LSP within the MPLS 154 network. 156 The P2MP FEC element is encoded as follows: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type (TBD) | Address Family | Address Length| 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Root Node Address | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Opaque Identifier Type | Opaque Identifier Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Opaque Identifier ... | 168 . . 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Type: The type of the P2MP FEC element is to be assigned by IANA. 173 Address Family: Two octet quantity containing a value from ADDRESS 174 FAMILY NUMBERS in [3] that encodes the address family for the Root 175 LSR Address. 177 Address Length: Length of the Root LSR Address in octets. 179 Root Node Address: A host address encoded according to the Address 180 Family field. 182 Opaque Identifier Type: The type of Opaque Identifier. 184 Length: The length of the P2MP Opaque Identifier, in octets. 186 Opaque Identifier: An opaque identifier of Length octets, padded at 187 the end with zeros so as to be 4-octet aligned. 189 If Address Family is IPv4, the Address Length MUST be 4; if the 190 Address Family is IPv6, the Address Length MUST be 16. No other 191 Address Lengths are defined at present. 193 If the Address Length doesn't match the defined length for the 194 Address Family, the receiver SHOULD abort processing the message 195 containing the FEC Element, and send an "Unknown FEC" Notification 196 message to its LDP peer signaling an error. 198 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 199 be the only FEC Element in the FEC TLV. 201 2.2 Using the P2MP FEC Element 203 This section defines the rules for the processing and propagation of 204 the P2MP FEC Element. The following notation is used in the 205 processing rules: 207 1. P2MP FEC Element : a FEC Element with Root Node Address X 208 and Opaque Identifier Y. 210 2. P2MP Label Map : a Label Map message with a FEC TLV with 211 a single P2MP FEC Element and Label TLV with label L. 213 3. P2MP Label Withdraw : a Label Withdraw message with a 214 FEC TLV with a single P2MP FEC Element and Label TLV with 215 label L. 217 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 218 Address X and Opaque Identifier Y. 220 The procedures below are organized by the role which the node plays 221 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 222 process which is outside the scope of this document. During the 223 course of protocol operation, the root node recognizes its role 224 because it owns the Root Node Address. A transit node is any node 225 (other than the root node) that receives a P2MP Label Map message 226 (i.e., one that has leaf nodes downstream of it). 228 Note that a transit node (and indeed the root node) may also be a 229 leaf node. 231 2.2.1 Label Map 233 The following lists procedures for generating and processing P2MP 234 Label Map messages for nodes that participate in a P2MP LSP. An LSR 235 should apply those procedures that apply to it, based on its role in 236 the P2MP LSP. 238 In the current approach, if there are several receivers for a P2MP 239 LSP on a LAN, packets are replicated over the LAN. This may not be 240 optimal; optimizing this case is for further study. 242 2.2.1.1 Determining one's 'upstream LSR' 244 A node Z that is part of P2MP LSP determines the LDP peer U 245 which lies on the best path from Z to the root node X. If there are 246 more than one such LDP peers, only one of them is picked. U is Z's 247 "Upstream LSR" for . 249 2.2.1.2 Leaf Operation 251 A leaf node Z of P2MP LSP determines its upstream LSR U for 252 as per Section 2.2.1.1, allocates a label L, and sends a P2MP 253 Label Map to U. 255 2.2.1.3 Transit Node operation 257 Suppose a transit node Z receives a P2MP Label Map over 258 interface I. Z checks whether it already has state for . If 259 not, Z allocates a label L', and installs state to swap L' with L 260 over interface I. Z also determines its upstream LSR U for as 261 per Section 2.2.1.1, and sends a P2MP Label Map to U. 263 If Z already has state for , then Z adds "swap L, send over 264 interface I" to the nexthop. Z does not send a Label Map message for 265 P2MP LSP . 267 2.2.1.4 Root Node Operation 269 Suppose the root node Z receives a P2MP Label Map over 270 interface I. Z checks whether it already has forwarding state for . If not, Z creates forwarding state to push label L onto the 272 traffic that Z wants to forward over the P2MP LSP (how this traffic 273 is determined is outside the scope of this document). 275 If Z already has forwarding state for , then Z adds "push label 276 L, send over interface I" to the nexthop. 278 2.2.2 Label Withdraw 280 The following lists procedures for generating and processing P2MP 281 Label Withdraw messages for nodes that participate in a P2MP LSP. An 282 LSR should apply those procedures that apply to it, based on its role 283 in the P2MP LSP. 285 2.2.2.1 Leaf Operation 287 If a leaf node Z discovers (by means outside the scope of this 288 document) that it is no longer a leaf of the P2MP LSP, it SHOULD send 289 a Label Withdraw to its upstream LSR U for , where L 290 is the label it had previously advertised to U for . 292 2.2.2.2 Transit Node Operation 294 If a transit node Z receives a Label Withdraw message from 295 a node W, it deletes label L from its forwarding state, and sends a 296 Label Release message with label L to W. 298 If deleting L from Z's forwarding state for P2MP LSP results 299 in no state remaining for , then Z propagates the Label 300 Withdraw to its upstream for . 302 2.2.2.3 Root Node Operation 304 The procedure when the root node of a P2MP LSP receives a Label 305 Withdraw message are the same as for transit nodes, except that it 306 would not propagate the Label Withdraw upstream (as it has no 307 upstream). 309 2.2.2.4 Upstream LSR change 311 If, for a given node Z participating in a P2MP LSP , the 312 upstream LSR changes, say from U to U', then Z MUST 313 1. send a Label Withdraw to U, where L is the label Z had 314 previously sent to U for ; 316 2. delete all forwarding state for the P2MP LSP ; 318 3. allocate a label L' for , and send a Label Map 319 to U'; 321 4. install forwarding state for label L'. 323 3. Shared Trees 325 The mechanism described above shows how to build a tree with a single 326 root and multiple leaves, i.e., a P2MP LSP. One can use essentially 327 the same mechanism to build Shared Trees with LDP. A Shared Tree can 328 be used by a group of routers that want to multicast traffic among 329 themselves, i.e., each node is both a root node (when it sources 330 traffic) and a leaf node (when any other member of the group sources 331 traffic). A Shared Tree offers similar functionality to a MP2MP LSP, 332 but the underlying multicasting mechanism uses a P2MP LSP. One 333 example where a Shared Tree is useful is video-conferencing. Another 334 is Virtual Private LAN Service (VPLS) [5], where for some types of 335 traffic, each device participating in a VPLS must send packets to 336 every other device in that VPLS. 338 One way to build a Shared Tree is to build an LDP P2MP LSP rooted at 339 a common point, the Shared Root (SR), and whose leaves are all the 340 members of the group. Each member of the Shared Tree unicasts 341 traffic to the SR (using, for example, the MP2P LSP created by the 342 unicast LDP FEC advertised by the SR); the SR then splices this 343 traffic into the LDP P2MP LSP. The SR may be (but need not be) a 344 member of the multicast group. 346 A major advantage of this approach is that no further protocol 347 mechanisms beyond the one already described are needed to set up a 348 Shared Tree. Furthermore, a Shared Tree is very efficient in terms 349 of the multicast state in the network, and is reasonably efficient in 350 terms of the bandwidth required to send traffic. 352 An important consideration in this approach is that a sender will 353 receive its own packets as part of the multicast; thus a sender must 354 be prepared to recognize and discard packets that it itself has sent. 355 For a number of applications (for example, VPLS), this requirement is 356 easy to meet. Another consideration is the various techniques that 357 can be used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; 358 these will be described in a later revision. 360 4. Security considerations 362 The same security considerations apply as for the base LDP 363 specification, as described in [1]. 365 5. Acknowledgments 367 The authors would like to thank Nischal Sheth, Yakov Rekhter and 368 Rahul Aggarwal for their suggestions and review. 370 6. References 372 6.1 Normative References 374 [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 375 Thomas, "LDP Specification", RFC 3036, January 2001. 377 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 378 Levels", BCP 14, RFC 2119, March 1997. 380 [3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 381 October 1994. 383 [4] Roux, J., "Requirements for multipoint extensions to the Label 384 Distribution Protocol", draft-leroux-mpls-mp-ldp-reqs-00 (work 385 in progress), July 2005. 387 6.2 Informative References 389 [5] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 390 Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05 391 (work in progress), June 2004. 393 [6] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE 394 LSPs", draft-ietf-mpls-rsvp-te-p2mp-01 (work in progress), 395 January 2005. 397 Authors' Addresses 399 Ina Minei 400 Juniper Networks 401 1194 N. Mathilda Ave. 402 Sunnyvale, CA 94089 403 US 405 Email: ina@juniper.net 407 Kireeti Kompella 408 Juniper Networks 409 1194 N. Mathilda Ave. 410 Sunnyvale, CA 94089 411 US 413 Email: kireeti@juniper.net 414 Jean-Louis Le Roux 415 France Telecom 416 2, avenue Pierre-Marzin 417 Lannion Cedex 22307 418 France 420 Email: jeanlouis.leroux@francetelecom.com 422 Luyuan Fang 423 AT&T 424 200 Laurel Avenue, Room C2-3B35 425 Middletown, NJ 07748 426 US 428 Email: luyuanfang@att.com 430 Lei Wang 431 Telenor 432 Snaroyveien 30 433 Fornebu 1331 434 Norway 436 Email: lei.wang@telenor.com 438 Shane Amante 439 Level 3 Communications, LLC 440 1025 Eldorado Blvd 441 Broomfield, CO 80021 442 US 444 Email: Shane.Amante@Level3.com 446 Intellectual Property Statement 448 The IETF takes no position regarding the validity or scope of any 449 Intellectual Property Rights or other rights that might be claimed to 450 pertain to the implementation or use of the technology described in 451 this document or the extent to which any license under such rights 452 might or might not be available; nor does it represent that it has 453 made any independent effort to identify any such rights. Information 454 on the procedures with respect to rights in RFC documents can be 455 found in BCP 78 and BCP 79. 457 Copies of IPR disclosures made to the IETF Secretariat and any 458 assurances of licenses to be made available, or the result of an 459 attempt made to obtain a general license or permission for the use of 460 such proprietary rights by implementers or users of this 461 specification can be obtained from the IETF on-line IPR repository at 462 http://www.ietf.org/ipr. 464 The IETF invites any interested party to bring to its attention any 465 copyrights, patents or patent applications, or other proprietary 466 rights that may cover technology that may be required to implement 467 this standard. Please address the information to the IETF at 468 ietf-ipr@ietf.org. 470 Disclaimer of Validity 472 This document and the information contained herein are provided on an 473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 475 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 476 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 477 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 Copyright Statement 482 Copyright (C) The Internet Society (2005). This document is subject 483 to the rights, licenses and restrictions contained in BCP 78, and 484 except as set forth therein, the authors retain all their rights. 486 Acknowledgment 488 Funding for the RFC Editor function is currently provided by the 489 Internet Society.