idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-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 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 860. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 850. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (February 26, 2006) is 6633 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-01 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-02 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-00 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Minei (Editor) 3 Internet-Draft K. Kompella 4 Expires: August 30, 2006 Juniper Networks 5 I. Wijnands (Editor) 6 B. Thomas 7 Cisco Systems, Inc. 8 February 26, 2006 10 Label Distribution Protocol Extensions for Point-to-Multipoint and 11 Multipoint-to-Multipoint Label Switched Paths 12 draft-ietf-mpls-ldp-p2mp-00 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/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 30, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document describes extensions to the Label Distribution Protocol 46 (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- 47 multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol 48 Label Switching (MPLS) networks. The solution relies on LDP without 49 requiring a multicast routing protocol in the network. Protocol 50 elements and procedures for this solution are described for building 51 such LSPs in a receiver-initiated manner. There can be various 52 applications for P2MP/MP2MP LSPs, for example IP multicast or support 53 for multicast in BGP/MPLS L3VPNs. Specification of how such 54 applications can use a LDP signaled P2MP/MP2MP LSP is outside the 55 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. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 4 63 2.1. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 4 64 2.2. The LDP MP Opaque Value Element . . . . . . . . . . . . . 6 65 2.3. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 6 66 2.3.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 8 68 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 10 70 4.1. The MP2MP downstream and upstream FEC elements. . . . . . 10 71 4.2. Using the MP2MP FEC elements . . . . . . . . . . . . . . . 11 72 4.2.1. MP2MP Label Map upstream and downstream . . . . . . . 12 73 4.2.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 14 74 5. Upstream label allocation on Ethernet networks . . . . . . . . 15 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 78 9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 16 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 83 Intellectual Property and Copyright Statements . . . . . . . . . . 20 85 1. Introduction 87 The LDP protocol is described in [1]. It defines mechanisms for 88 setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs 89 in the network. This document describes extensions to LDP for 90 setting up point-to-multipoint (P2MP) and multipoint-to-multipoint 91 (MP2MP) LSPs. These are collectively referred to as multipoint LSPs 92 (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) 93 node to be delivered to a number of leaf (or egress) nodes. A MP2MP 94 LSP allows traffic from multiple ingress nodes to be delivered to 95 multiple egress nodes. Only a single copy of the packet will be sent 96 on any link traversed by the MP LSP (see note at end of 97 Section 2.3.1). This is accomplished without the use of a multicast 98 protocol in the network. There can be several MP LSPs rooted at a 99 given ingress node, each with its own identifier. 101 The solution assumes that the leaf nodes of the MP LSP know the root 102 node and identifier of the MP LSP to which they belong. The 103 mechanisms for the distribution of this information are outside the 104 scope of this document. The specification of how an application can 105 use a MP LSP signaled by LDP is also outside the scope of this 106 document. 108 Interested readers may also wish to peruse the requirement draft [4] 109 and other documents [8] and [9]. 111 1.1. Conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [2]. 117 1.2. Terminology 119 The following terminology is taken from [4]. 121 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 123 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 124 LSRs. 126 MP2P LSP: A LSP that has one or more Ingress LSRs and one unique 127 Egress LSR. 129 MP2MP LSP: A LSP that connects a set of leaf nodes, acting 130 indifferently as ingress or egress. 132 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 134 Ingress LSR: Source of the P2MP LSP, also referred to as root node. 136 Egress LSR: One of potentially many destinations of an LSP, also 137 referred to as leaf node in the case of P2MP and MP2MP LSPs. 139 Transit LSR: An LSR that has one or more directly connected 140 downstream LSRs. 142 Bud LSR: An LSR that is an egress but also has one or more directly 143 connected downstream LSRs. 145 2. Setting up P2MP LSPs with LDP 147 A P2MP LSP consists of a single root node, zero or more transit nodes 148 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 149 tear-down. Leaf nodes also install forwarding state to deliver the 150 traffic received on a P2MP LSP to wherever it needs to go; how this 151 is done is outside the scope of this document. Transit nodes install 152 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 153 down) toward the root. The root node installs forwarding state to 154 map traffic into the P2MP LSP; how the root node determines which 155 traffic should go over the P2MP LSP is outside the scope of this 156 document. 158 For the setup of a P2MP LSP with LDP, we define one new protocol 159 entity, the P2MP FEC Element to be used in the FEC TLV. The 160 description of the P2MP FEC Element follows. 162 2.1. The P2MP FEC Element 164 The P2MP FEC Element consists of the address of the root of the P2MP 165 LSP and an opaque value. The opaque value consists of one or more 166 LDP MP Opaque Value Elements. The opaque value is unique within the 167 context of the root node. The combination of (Root Node Address, 168 Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. 170 The P2MP FEC element is encoded as follows: 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |P2MP Type (TBD)| Address Family | Address Length| 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Root Node Address | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Opaque Length | Opaque Value ... | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 181 ~ ~ 182 | | 183 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Type: The type of the P2MP FEC element is to be assigned by IANA, 188 such that the U-bit is set (=1) and the F-bit is clear (=0). This 189 ensures that an LSR which cannot process the P2MP FEC element, 190 silently ignores it. 192 Address Family: Two octet quantity containing a value from ADDRESS 193 FAMILY NUMBERS in [3] that encodes the address family for the Root 194 LSR Address. 196 Address Length: Length of the Root LSR Address in octets. 198 Root Node Address: A host address encoded according to the Address 199 Family field. 201 Opaque Length: The length of the Opaque Value, in octets. 203 Opaque Value: One or more MP Opaque Value elements, uniquely 204 identifying the P2MP LSP in the context of the Root Node. This is 205 described in the next section. 207 If the Address Family is IPv4, the Address Length MUST be 4; if the 208 Address Family is IPv6, the Address Length MUST be 16. No other 209 Address Lengths are defined at present. 211 If the Address Length doesn't match the defined length for the 212 Address Family, the receiver SHOULD abort processing the message 213 containing the FEC Element, and send an "Unknown FEC" Notification 214 message to its LDP peer signaling an error. 216 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 217 be the only FEC Element in the FEC TLV. 219 2.2. The LDP MP Opaque Value Element 221 The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC 222 elements defined in subsequent sections. It carries information that 223 is meaningful to leaf (and bud) LSRs, but need not be interpreted by 224 non-leaf LSRs. 226 The LDP MP Opaque Value Element is encoded as follows: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type(TBD) | Length | Value ... | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 233 ~ ~ 234 | | 235 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Type: The type of the LDP MP Opaque Value Element is to be assigned 241 by IANA. 243 Length: The length of the Value field, in octets. 245 Value: String of Length octets, to be interpreted as specified by the 246 Type field. 248 2.3. Using the P2MP FEC Element 250 This section defines the rules for the processing and propagation of 251 the P2MP FEC Element. The following notation is used in the 252 processing rules: 254 1. P2MP FEC Element : a FEC Element with Root Node Address X 255 and Opaque Value Y. 257 2. P2MP Label Map : a Label Map message with a FEC TLV with 258 a single P2MP FEC Element and Label TLV with label L. 260 3. P2MP Label Withdraw : a Label Withdraw message with a 261 FEC TLV with a single P2MP FEC Element and Label TLV with 262 label L. 264 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 265 Address X and Opaque Value Y. 267 5. The notation L' -> { ..., } on LSR X 268 means that on receiving a packet with label L', X makes n copies 269 of the packet. For copy i of the packet, X swaps L' with Li and 270 sends it out over interface Ii. 272 The procedures below are organized by the role which the node plays 273 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 274 process which is outside the scope of this document. During the 275 course of protocol operation, the root node recognizes its role 276 because it owns the Root Node Address. A transit node is any node 277 (other than the root node) that receives a P2MP Label Map message 278 (i.e., one that has leaf nodes downstream of it). 280 Note that a transit node (and indeed the root node) may also be a 281 leaf node. 283 2.3.1. Label Map 285 The following lists procedures for generating and processing P2MP 286 Label Map messages for nodes that participate in a P2MP LSP. An LSR 287 should apply those procedures that apply to it, based on its role in 288 the P2MP LSP. 290 For the approach described here we use downstream assigned labels. 291 On Ethernet networks this may be less optimal, see Section 5. 293 2.3.1.1. Determining one's 'upstream LSR' 295 A node Z that is part of P2MP LSP determines the LDP peer U 296 which lies on the best path from Z to the root node X. If there are 297 more than one such LDP peers, only one of them is picked. U is Z's 298 "Upstream LSR" for . 300 2.3.1.2. Leaf Operation 302 A leaf node Z of P2MP LSP determines its upstream LSR U for 303 as per Section 2.3.1.1, allocates a label L, and sends a P2MP 304 Label Map to U. 306 2.3.1.3. Transit Node operation 308 Suppose a transit node Z receives a P2MP Label Map over 309 interface I. Z checks whether it already has state for . If 310 not, Z allocates a label L', and installs state to swap L' with L 311 over interface I. Z also determines its upstream LSR U for as 312 per Section 2.3.1.1, and sends a P2MP Label Map to U. 314 If Z already has state for , then Z does not send a Label Map 315 message for P2MP LSP . All that Z needs to do in this case is 316 update its forwarding state. Assuming its old forwarding state was 317 L'-> { ..., }, its new forwarding state 318 becomes L'-> { ..., , }. 320 2.3.1.4. Root Node Operation 322 Suppose the root node Z receives a P2MP Label Map over 323 interface I. Z checks whether it already has forwarding state for . If not, Z creates forwarding state to push label L onto the 325 traffic that Z wants to forward over the P2MP LSP (how this traffic 326 is determined is outside the scope of this document). 328 If Z already has forwarding state for , then Z adds "push label 329 L, send over interface I" to the nexthop. 331 2.3.2. Label Withdraw 333 The following lists procedures for generating and processing P2MP 334 Label Withdraw messages for nodes that participate in a P2MP LSP. An 335 LSR should apply those procedures that apply to it, based on its role 336 in the P2MP LSP. 338 2.3.2.1. Leaf Operation 340 If a leaf node Z discovers (by means outside the scope of this 341 document) that it is no longer a leaf of the P2MP LSP, it SHOULD send 342 a Label Withdraw to its upstream LSR U for , where L 343 is the label it had previously advertised to U for . 345 2.3.2.2. Transit Node Operation 347 If a transit node Z receives a Label Withdraw message from 348 a node W, it deletes label L from its forwarding state, and sends a 349 Label Release message with label L to W. 351 If deleting L from Z's forwarding state for P2MP LSP results 352 in no state remaining for , then Z propagates the Label 353 Withdraw to its upstream for . 355 2.3.2.3. Root Node Operation 357 The procedure when the root node of a P2MP LSP receives a Label 358 Withdraw message are the same as for transit nodes, except that it 359 would not propagate the Label Withdraw upstream (as it has no 360 upstream). 362 2.3.2.4. Upstream LSR change 364 If, for a given node Z participating in a P2MP LSP , the 365 upstream LSR changes, say from U to U', then Z MUST update its 366 forwarding state by deleting the state for label L, allocating a new 367 label, L', for , and installing the forwarding state for L'. In 368 addition Z MUST send a Label Map to U' and send a Label 369 Withdraw to U. 371 3. Shared Trees 373 The mechanism described above shows how to build a tree with a single 374 root and multiple leaves, i.e., a P2MP LSP. One can use essentially 375 the same mechanism to build Shared Trees with LDP. A Shared Tree can 376 be used by a group of routers that want to multicast traffic among 377 themselves, i.e., each node is both a root node (when it sources 378 traffic) and a leaf node (when any other member of the group sources 379 traffic). A Shared Tree offers similar functionality to a MP2MP LSP, 380 but the underlying multicasting mechanism uses a P2MP LSP. One 381 example where a Shared Tree is useful is video-conferencing. Another 382 is Virtual Private LAN Service (VPLS) [7], where for some types of 383 traffic, each device participating in a VPLS must send packets to 384 every other device in that VPLS. 386 One way to build a Shared Tree is to build an LDP P2MP LSP rooted at 387 a common point, the Shared Root (SR), and whose leaves are all the 388 members of the group. Each member of the Shared Tree unicasts 389 traffic to the SR (using, for example, the MP2P LSP created by the 390 unicast LDP FEC advertised by the SR); the SR then splices this 391 traffic into the LDP P2MP LSP. The SR may be (but need not be) a 392 member of the multicast group. 394 A major advantage of this approach is that no further protocol 395 mechanisms beyond the one already described are needed to set up a 396 Shared Tree. Furthermore, a Shared Tree is very efficient in terms 397 of the multicast state in the network, and is reasonably efficient in 398 terms of the bandwidth required to send traffic. 400 A property of this approach is that a sender will receive its own 401 packets as part of the multicast; thus a sender must be prepared to 402 recognize and discard packets that it itself has sent. For a number 403 of applications (for example, VPLS), this requirement is easy to 404 meet. Another consideration is the various techniques that can be 405 used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will 406 be described in a later revision. 408 4. Setting up MP2MP LSPs with LDP 410 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 411 root node, zero or more transit nodes and one or more leaf LSRs 412 acting equally as Ingress or Egress LSR. A leaf node participates in 413 the setup of an MP2MP LSP by establishing both a downstream LSP, 414 which is much like a P2MP LSP from the root, and an upstream LSP 415 which is used to send traffic toward the root and other leaf nodes. 416 Transit nodes support the setup by propagating the upstream and 417 downstream LSP setup toward the root and installing the necessary 418 MPLS forwarding state. The transmission of packets from the root 419 node of a MP2MP LSP to the receivers is identical to that for a P2MP 420 LSP. Traffic from a leaf node follows the upstream LSP toward the 421 root node and branches downward along the downstream LSP as required 422 to reach other leaf nodes. Mapping traffic to the MP2MP LSP may 423 happen at any leaf node. How that mapping is established is outside 424 the scope of this document. 426 Due to how a MP2MP LSP is built a leaf LSR that is sending packets on 427 the MP2MP LSP does not receive its own packets. There is also no 428 additional mechanism needed on the root or transit LSR to match 429 upstream traffic to the downstream forwarding state. Packets that 430 are forwarded over a MP2MP LSP will not traverse a link more than 431 once, with the exception of LAN links which are discussed in 432 Section 4.2.1 434 For the setup of a MP2MP LSP with LDP we define 2 new protocol 435 entities, the MP2MP downstream FEC and upstream FEC element. Both 436 elements will be used in the FEC TLV. The description of the MP2MP 437 elements follow. 439 4.1. The MP2MP downstream and upstream FEC elements. 441 The structure, encoding and error handling for the MP2MP downstream 442 and upstream FEC elements are the same as for the P2MP FEC element 443 described in Section 2.1. The difference is that two new FEC types 444 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 446 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 447 MUST be the only FEC Element in the FEC TLV. 449 4.2. Using the MP2MP FEC elements 451 This section defines the rules for the processing and propagation of 452 the MP2MP FEC elements. The following notation is used in the 453 processing rules: 455 1. MP2MP downstream LSP (or simply downstream ): an 456 MP2MP LSP downstream path with root node address X and opaque 457 value Y. 459 2. MP2MP upstream LSP (or simply upstream ): a 460 MP2MP LSP upstream path for downstream node D with root node 461 address X and opaque value Y. 463 3. MP2MP downstream FEC element : a FEC element with root node 464 address X and opaque value Y used for a downstream MP2MP LSP. 466 4. MP2MP upstream FEC element : a FEC element with root node 467 address X and opaque value Y used for an upstream MP2MP LSP. 469 5. MP2MP Label Map downstream : A Label Map message with a 470 FEC TLV with a single MP2MP downstream FEC element and 471 label TLV with label L. 473 6. MP2MP Label Map upstream : A Label Map message with a 474 FEC TLV with a single MP2MP upstream FEC element and label 475 TLV with label Lu. 477 7. MP2MP Label Withdraw downstream : a Label Withdraw 478 message with a FEC TLV with a single MP2MP downstream FEC element 479 and label TLV with label L. 481 8. MP2MP Label Withdraw upstream : a Label Withdraw 482 message with a FEC TLV with a single MP2MP upstream FEC element 483 and label TLV with label Lu. 485 The procedures below are organized by the role which the node plays 486 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 487 process which is outside the scope of this document. During the 488 course of the protocol operation, the root node recognizes its role 489 because it owns the root node address. A transit node is any node 490 (other then the root node) that receives a MP2MP Label Map message 491 (i.e., one that has leaf nodes downstream of it). 493 Note that a transit node (and indeed the root node) may also be a 494 leaf node and the root node does not have to be an ingress LSR or 495 leaf of the MP2MP LSP. 497 4.2.1. MP2MP Label Map upstream and downstream 499 The following lists procedures for generating and processing MP2MP 500 Label Map messages for nodes that participate in a MP2MP LSP. An LSR 501 should apply those procedures that apply to it, based on its role in 502 the MP2MP LSP. 504 For the approach described here if there are several receivers for a 505 MP2MP LSP on a LAN, packets are replicated over the LAN. This may 506 not be optimal; optimizing this case is for further study, see [5]. 508 4.2.1.1. Determining one's upstream MP2MP LSR 510 Determining the upstream LDP peer U for a MP2MP LSP follows 511 the procedure for a P2MP LSP described in Section 2.3.1.1. 513 4.2.1.2. Determining one's downstream MP2MP LSR 515 A LDP peer U which receives a MP2MP Label Map downstream from a LDP 516 peer D will treat D as downstream MP2MP LSR. 518 4.2.1.3. MP2MP leaf node operation 520 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 521 as per Section 4.2.1.1, allocates a label L, and sends a MP2MP 522 Label Map downstream to U. 524 Leaf node Z expects an MP2MP Label Map upstream from node 525 U in response to the MP2MP Label Map downstream it sent to node U. Z 526 checks whether it already has forwarding state for upstream . 527 If not, Z creates forwarding state to push label Lu onto the traffic 528 that Z wants to forward over the MP2MP LSP. How it determines what 529 traffic to forward on this MP2MP LSP is outside the scope of this 530 document. 532 4.2.1.4. MP2MP transit node operation 534 When node Z receives a MP2MP Label Map downstream over 535 interface I from node D it checks whether it has forwarding state for 536 downstream . If not, Z allocates a label L' and installs 537 downstream forwarding state to swap label L' with label L over 538 interface I. Z also determines its upstream LSR U for as per 539 Section 4.2.1.1, and sends a MP2MP Label Map downstream to 540 U. 542 If Z already has forwarding state for downstream , all that Z 543 needs to do is update its forwarding state. Assuming its old 544 forwarding state was L'-> { ..., }, its new 545 forwarding state becomes L'-> { ..., , }. 548 Node Z checks whether it already has forwarding state upstream . If it does, then no further action needs to happen. If it does 550 not, it allocates a label Lu and creates a new label swap for Lu from 551 the label swap(s) from the forwarding state downstream , 552 omitting the swap on interface I for node D. This allows upstream 553 traffic to follow the MP2MP tree down to other node(s) except the 554 node from which Z received the MP2MP Label Map downstream . 555 Node Z determines the downstream MP2MP LSR as per Section 4.2.1.2, 556 and sends a MP2MP Label Map upstream to node D. 558 Transit node Z will also receive a MP2MP Label Map upstream in response to the MP2MP Label Map downstream sent to node U over 560 interface Iu. Node Z will add label swap Lu over interface Iu to the 561 forwarding state upstream . This allows packets to go up 562 the tree towards the root node. 564 4.2.1.5. MP2MP root node operation 566 4.2.1.5.1. Root node is also a leaf 568 Suppose root/leaf node Z receives a MP2MP Label Map downstream over over interface I from node D. Z checks whether it already has 570 forwarding state downstream . If not, Z creates forwarding 571 state for downstream to push label L on traffic that Z wants to 572 forward down the MP2MP LSP. How it determines what traffic to 573 forward on this MP2MP LSP is outside the scope of this document. If 574 Z already has forwarding state for downstream , then Z will add 575 the label push for L over interface I to it. 577 Node Z checks if it has forwarding state for upstream . If 578 not, Z allocates a label Lu and creates upstream forwarding state to 579 push Lu with the label push(s) from the forwarding state downstream 580 , except the push on interface I for node D. This allows 581 upstream traffic to go down the MP2MP to other node(s), except the 582 node from which the traffic was received. Node Z determines the 583 downstream MP2MP LSR as per section Section 4.2.1.2, and sends a 584 MP2MP Label Map upstream to node D. Since Z is the root of 585 the tree Z will not send a MP2MP downstream map and will not receive 586 a MP2MP upstream map. 588 4.2.1.5.2. Root node is not a leaf 590 Suppose the root node Z receives a MP2MP Label Map dowbstream over over interface I from node D. Z checks whether it already has 592 forwarding state for downstream . If not, Z creates downstream 593 forwarding state and installs a outgoing label L over interface I. If 594 Z already has forwarding state for downstream , then Z will add 595 label L over interface I to the existing state. 597 Node Z checks if it has forwarding state for upstream . If 598 not, Z allocates a label Lu and creates forwarding state to swap Lu 599 with the label swap(s) from the forwarding state downstream , 600 except the swap for node D. This allows upstream traffic to go down 601 the MP2MP to other node(s), except the node is was received from. 602 Root node Z determines the downstream MP2MP LSR D as per 603 Section 4.2.1.2, and sends a MP2MP Label Map upstream to 604 it. Since Z is the root of the tree Z will not send a MP2MP 605 downstream map and will not receive a MP2MP upstream map. 607 4.2.2. MP2MP Label Withdraw 609 The following lists procedures for generating and processing MP2MP 610 Label Withdraw messages for nodes that participate in a MP2MP LSP. 611 An LSR should apply those procedures that apply to it, based on its 612 role in the MP2MP LSP. 614 4.2.2.1. MP2MP leaf operation 616 If a leaf node Z discovers (by means outside the scope of this 617 document) that it is no longer a leaf of the MP2MP LSP, it SHOULD 618 send a downstream Label Withdraw to its upstream LSR U for 619 , where L is the label it had previously advertised to U for 620 . 622 Leaf node Z expects the upstream router U to respond by sending a 623 downstream label release for L and a upstream Label Withdraw for to remove Lu from the upstream state. Node Z will remove 625 label Lu from its upstream state and send a label release message 626 with label Lu to U. 628 4.2.2.2. MP2MP transit node operation 630 If a transit node Z receives a downstream label withdraw message from node D, it deletes label L from its forwarding state 632 downstream and from all its upstream states for . Node 633 Z sends a label release message with label L to D. Since node D is no 634 longer part of the downstream forwarding state, Z cleans up the 635 forwarding state upstream and sends a upstream Label 636 Withdraw for to D. 638 If deleting L from Z's forwarding state for downstream results 639 in no state remaining for , then Z propagates the Label 640 Withdraw to its upstream node U for . 642 4.2.2.3. MP2MP root node operation 644 The procedure when the root node of a MP2MP LSP receives a label 645 withdraw message is the same as for transit nodes, except that the 646 root node would not propagate the Label Withdraw upstream (as it has 647 no upstream). 649 4.2.2.4. MP2MP Upstream LSR change 651 The procedure for changing the upstream LSR is the same as documented 652 in Section 2.3.2.4, except it is applied to MP2MP FECs, using the 653 procedures described in Section 4.2.1 through Section 4.2.2.3. 655 5. Upstream label allocation on Ethernet networks 657 On Ethernet networks the upstream LSR will send a copy of the packet 658 to each receiver individually. If there is more then one receiver on 659 the Ethernet we don't take full benefit of the multi-access 660 capability of the network. We may optimize the bandwidth consumption 661 on the Ethernet and replication overhead on the upstream LSR by using 662 upstream label allocation [5]. Procedures on how to distribute 663 upstream labels using LDP is documented in [6]. 665 6. Security Considerations 667 The same security considerations apply as for the base LDP 668 specification, as described in [1]. 670 7. IANA considerations 672 This document creates a new name space (the LDP MP Opaque Value 673 Element type) that is to be managed by IANA. Also, this document 674 requires allocation of three new LDP FEC element types: the P2MP 675 type, the MP2MP-up and the MP2MP-down types. 677 8. Acknowledgments 679 The authors would like to thank the following individuals for their 680 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 681 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert and 682 George Swallow. 684 9. Contributing authors 686 Below is a list of the contributing authors in alphabetical order: 688 Shane Amante 689 Level 3 Communications, LLC 690 1025 Eldorado Blvd 691 Broomfield, CO 80021 692 US 693 Email: Shane.Amante@Level3.com 695 Luyuan Fang 696 AT&T 697 200 Laurel Avenue, Room C2-3B35 698 Middletown, NJ 07748 699 US 700 Email: luyuanfang@att.com 702 Hitoshi Fukuda 703 NTT Communications Corporation 704 1-1-6, Uchisaiwai-cho, Chiyoda-ku 705 Tokyo 100-8019, 706 Japan 707 Email: hitoshi.fukuda@ntt.com 709 Yuji Kamite 710 NTT Communications Corporation 711 Tokyo Opera City Tower 712 3-20-2 Nishi Shinjuku, Shinjuku-ku, 713 Tokyo 163-1421, 714 Japan 715 Email: y.kamite@ntt.com 716 Kireeti Kompella 717 Juniper Networks 718 1194 N. Mathilda Ave. 719 Sunnyvale, CA 94089 720 US 721 Email: kireeti@juniper.net 723 Ina Minei 724 Juniper Networks 725 1194 N. Mathilda Ave. 726 Sunnyvale, CA 94089 727 US 728 Email: ina@juniper.net 730 Jean-Louis Le Roux 731 France Telecom 732 2, avenue Pierre-Marzin 733 Lannion, Cedex 22307 734 France 735 Email: jeanlouis.leroux@francetelecom.com 737 Bob Thomas 738 Cisco Systems, Inc. 739 300 Beaver Brook Road 740 Boxborough, MA, 01719 741 E-mail: rhthomas@cisco.com 743 Lei Wang 744 Telenor 745 Snaroyveien 30 746 Fornebu 1331 747 Norway 748 Email: lei.wang@telenor.com 750 IJsbrand Wijnands 751 Cisco Systems, Inc. 752 De kleetlaan 6a 753 1831 Diegem 754 Belgium 755 E-mail: ice@cisco.com 757 10. References 758 10.1. Normative References 760 [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 761 Thomas, "LDP Specification", RFC 3036, January 2001. 763 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 764 Levels", BCP 14, RFC 2119, March 1997. 766 [3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 767 October 1994. 769 [4] Roux, J., "Requirements for point-to-multipoint extensions to 770 the Label Distribution Protocol", 771 draft-leroux-mpls-mp-ldp-reqs-01 (work in progress), July 2005. 773 [5] Aggarwal, R., "MPLS Upstream Label Assignment and Context 774 Specific Label Space", draft-raggarwa-mpls-upstream-label-01 775 (work in progress), October 2005. 777 [6] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for 778 RSVP-TE and LDP", draft-raggarwa-mpls-rsvp-ldp-upstream-00 (work 779 in progress), July 2005. 781 10.2. Informative References 783 [7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 784 Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05 785 (work in progress), June 2004. 787 [8] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE 788 LSPs", draft-ietf-mpls-rsvp-te-p2mp-02 (work in progress), 789 July 2005. 791 [9] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", 792 draft-ietf-l3vpn-2547bis-mcast-00 (work in progress), June 2005. 794 Authors' Addresses 796 Ina Minei 797 Juniper Networks 798 1194 N. Mathilda Ave. 799 Sunnyvale, CA 94089 800 US 802 Email: ina@juniper.net 804 Kireeti Kompella 805 Juniper Networks 806 1194 N. Mathilda Ave. 807 Sunnyvale, CA 94089 808 US 810 Email: kireeti@juniper.net 812 IJsbrand Wijnands 813 Cisco Systems, Inc. 814 De kleetlaan 6a 815 Diegem 1831 816 Belgium 818 Email: ice@cisco.com 820 Bob Thomas 821 Cisco Systems, Inc. 822 300 Beaver Brook Road 823 Boxborough 01719 824 US 826 Email: rhthomas@cisco.com 828 Intellectual Property Statement 830 The IETF takes no position regarding the validity or scope of any 831 Intellectual Property Rights or other rights that might be claimed to 832 pertain to the implementation or use of the technology described in 833 this document or the extent to which any license under such rights 834 might or might not be available; nor does it represent that it has 835 made any independent effort to identify any such rights. Information 836 on the procedures with respect to rights in RFC documents can be 837 found in BCP 78 and BCP 79. 839 Copies of IPR disclosures made to the IETF Secretariat and any 840 assurances of licenses to be made available, or the result of an 841 attempt made to obtain a general license or permission for the use of 842 such proprietary rights by implementers or users of this 843 specification can be obtained from the IETF on-line IPR repository at 844 http://www.ietf.org/ipr. 846 The IETF invites any interested party to bring to its attention any 847 copyrights, patents or patent applications, or other proprietary 848 rights that may cover technology that may be required to implement 849 this standard. Please address the information to the IETF at 850 ietf-ipr@ietf.org. 852 Disclaimer of Validity 854 This document and the information contained herein are provided on an 855 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 856 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 857 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 858 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 859 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 860 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 862 Copyright Statement 864 Copyright (C) The Internet Society (2006). This document is subject 865 to the rights, licenses and restrictions contained in BCP 78, and 866 except as set forth therein, the authors retain all their rights. 868 Acknowledgment 870 Funding for the RFC Editor function is currently provided by the 871 Internet Society.