idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If Z already has state for , then Z does not send a Label Map message for P2MP LSP . All that Z needs to do in this case is check that LSR T is not equal to the upstream LSR of and update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. If the LSR T is equal to the installed upstream LSR, the Label Map from LSR T MUST be retained and MUST not update the label forwarding table. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If Z already has forwarding state for downstream , all that Z needs to do in this case is check that LSR D is not equal to the upstream LSR of and update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. If the LSR D is equal to the installed upstream LSR, the Label Map from LSR D MUST be retained and MUST not update the label forwarding table. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2009) is 5401 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3232 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-05 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-ldp-upstream-02 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-capabilities-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mp-ldp-reqs-04 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-06 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-multicast-encaps-09 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 3 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 Intended status: Standards Track Juniper Networks 5 Expires: January 13, 2010 I. Wijnands (Editor) 6 B. Thomas 7 Cisco Systems, Inc. 8 July 12, 2009 10 Label Distribution Protocol Extensions for Point-to-Multipoint and 11 Multipoint-to-Multipoint Label Switched Paths 12 draft-ietf-mpls-ldp-p2mp-07 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 13, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes extensions to the Label Distribution Protocol 60 (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- 61 multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol 62 Label Switching (MPLS) networks. These extensions are also referred 63 to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs 64 without interacting with or relying upon any other multicast tree 65 construction protocol. Protocol elements and procedures for this 66 solution are described for building such LSPs in a receiver-initiated 67 manner. There can be various applications for P2MP/MP2MP LSPs, for 68 example IP multicast or support for multicast in BGP/MPLS L3VPNs. 69 Specification of how such applications can use a LDP signaled P2MP/ 70 MP2MP LSP is outside the scope of this document. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.1. Conventions used in this document . . . . . . . . . . . . 5 76 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6 78 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 7 79 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7 80 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9 81 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 9 82 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 10 83 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 11 84 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 12 85 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 13 86 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 14 88 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 14 89 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 15 90 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15 91 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 17 92 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 20 93 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 21 94 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21 95 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22 96 5.2. LDP Messages containing LDP MP Status messages . . . . . . 22 97 5.2.1. LDP MP Status sent in LDP notification messages . . . 22 98 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23 99 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24 100 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24 101 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24 102 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24 103 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 104 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25 105 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 106 8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26 107 8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 108 8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 109 8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 110 8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 111 8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 112 8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 113 8.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 114 8.4.4. Receiving a Label Map with MBB status code . . . . . . 31 115 8.4.5. Receiving a Notification with MBB status code . . . . 31 116 8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 117 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 118 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 119 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 120 12. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33 121 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 122 13.1. Normative References . . . . . . . . . . . . . . . . . . . 35 123 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 126 1. Introduction 128 The LDP protocol is described in [RFC5036]. It defines mechanisms 129 for setting up point-to-point (P2P) and multipoint-to-point (MP2P) 130 LSPs in the network. This document describes extensions to LDP for 131 setting up point-to-multipoint (P2MP) and multipoint-to-multipoint 132 (MP2MP) LSPs. These are collectively referred to as multipoint LSPs 133 (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) 134 node to be delivered to a number of leaf (or egress) nodes. A MP2MP 135 LSP allows traffic from multiple ingress nodes to be delivered to 136 multiple egress nodes. Only a single copy of the packet will be sent 137 on any link traversed by the MP LSP (see note at end of 138 Section 2.4.1). This is accomplished without the use of a multicast 139 protocol in the network. There can be several MP LSPs rooted at a 140 given ingress node, each with its own identifier. 142 The solution assumes that the leaf nodes of the MP LSP know the root 143 node and identifier of the MP LSP to which they belong. The 144 mechanisms for the distribution of this information are outside the 145 scope of this document. The specification of how an application can 146 use a MP LSP signaled by LDP is also outside the scope of this 147 document. 149 Interested readers may also wish to peruse the requirements draft 150 [I-D.ietf-mpls-mp-ldp-reqs] and other documents [RFC4875] and 151 [I-D.ietf-l3vpn-2547bis-mcast]. 153 1.1. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 1.2. Terminology 161 The following terminology is taken from [I-D.ietf-mpls-mp-ldp-reqs]. 163 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 165 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 166 LSRs. 168 MP2P LSP: An LSP that has one or more Ingress LSRs and one unique 169 Egress LSR. 171 MP2MP LSP: An LSP that connects a set of nodes, such that traffic 172 sent by any node in the LSP is delivered to all others. 174 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 176 Ingress LSR: An ingress LSR for a particular LSP is an LSR that can 177 send a data packet along the LSP. MP2MP LSPs can have multiple 178 ingress LSRs, P2MP LSPs have just one, and that node is often 179 referred to as the "root node". 181 Egress LSR: An egress LSR for a particular LSP is an LSR that can 182 remove a data packet from that LSP for further processing. P2P 183 and MP2P LSPs have only a single egress node, but P2MP and MP2MP 184 LSPs can have multiple egress nodes. 186 Transit LSR: An LSR that has reachability to the root of the MP LSP 187 via a directly connected upstream LSR and one or more directly 188 connected downstream LSRs. 190 Bud LSR: An LSR that is an egress but also has one or more directly 191 connected downstream LSRs. 193 Leaf node: A Leaf node can be either an Egress or Bud LSR when 194 referred in the context of a P2MP LSP. In the context of a MP2MP 195 LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and 196 can also be a Bud LSR. 198 2. Setting up P2MP LSPs with LDP 200 A P2MP LSP consists of a single root node, zero or more transit nodes 201 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 202 tear-down. Leaf nodes also install forwarding state to deliver the 203 traffic received on a P2MP LSP to wherever it needs to go; how this 204 is done is outside the scope of this document. Transit nodes install 205 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 206 down) toward the root. The root node installs forwarding state to 207 map traffic into the P2MP LSP; how the root node determines which 208 traffic should go over the P2MP LSP is outside the scope of this 209 document. 211 2.1. Support for P2MP LSP setup with LDP 213 Support for the setup of P2MP LSPs is advertised using LDP 214 capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An 215 implementation supporting the P2MP procedures specified in this 216 document MUST implement the procedures for Capability Parameters in 217 Initialization Messages. 219 A new Capability Parameter TLV is defined, the P2MP Capability. 220 Following is the format of the P2MP Capability Parameter. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |1|0| P2MP Capability (TBD IANA) | Length (= 1) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |1| Reserved | 228 +-+-+-+-+-+-+-+-+ 230 The P2MP Capability TLV MUST be supported in the LDP Initialization 231 Message. Advertisement of the P2MP Capability indicates support of 232 the procedures for P2MP LSP setup detailed in this document. If the 233 peer has not advertised the corresponding capability, then no label 234 messages using the P2MP FEC Element should be sent to the peer. 236 2.2. The P2MP FEC Element 238 For the setup of a P2MP LSP with LDP, we define one new protocol 239 entity, the P2MP FEC Element to be used as a FEC Element in the FEC 240 TLV. Note that the P2MP FEC Element does not necessarily identify 241 the traffic that must be mapped to the LSP, so from that point of 242 view, the use of the term FEC is a misnomer. The description of the 243 P2MP FEC Element follows. 245 The P2MP FEC Element consists of the address of the root of the P2MP 246 LSP and an opaque value. The opaque value consists of one or more 247 LDP MP Opaque Value Elements. The opaque value is unique within the 248 context of the root node. The combination of (Root Node Address, 249 Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. 251 The P2MP FEC Element is encoded as follows: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |P2MP Type (TBD)| Address Family | Address Length| 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ~ Root Node Address ~ 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Opaque Length | Opaque Value ... | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 262 ~ ~ 263 | | 264 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Type: The type of the P2MP FEC Element is to be assigned by IANA. 270 Address Family: Two octet quantity containing a value from ADDRESS 271 FAMILY NUMBERS in [RFC3232] that encodes the address family for 272 the Root LSR Address. 274 Address Length: Length of the Root LSR Address in octets. 276 Root Node Address: A host address encoded according to the Address 277 Family field. 279 Opaque Length: The length of the Opaque Value, in octets. 281 Opaque Value: One or more MP Opaque Value elements, uniquely 282 identifying the P2MP LSP in the context of the Root Node. This is 283 described in the next section. 285 If the Address Family is IPv4, the Address Length MUST be 4; if the 286 Address Family is IPv6, the Address Length MUST be 16. No other 287 Address Lengths are defined at present. 289 If the Address Length doesn't match the defined length for the 290 Address Family, the receiver SHOULD abort processing the message 291 containing the FEC Element, and send an "Unknown FEC" Notification 292 message to its LDP peer signaling an error. 294 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 295 be the only FEC Element in the FEC TLV. 297 2.3. The LDP MP Opaque Value Element 299 The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC 300 Elements defined in subsequent sections. It carries information that 301 is meaningful to Ingress LSRs and Leaf LSRs, but need not be 302 interpreted by Transit LSRs. 304 The LDP MP Opaque Value Element is encoded as follows: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type(TBD) | Length | Value ... | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 311 ~ ~ 312 | | 313 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Type: The type of the LDP MP Opaque Value Element is to be assigned 319 by IANA. 321 Length: The length of the Value field, in octets. 323 Value: String of Length octets, to be interpreted as specified by 324 the Type field. 326 2.3.1. The Generic LSP Identifier 328 The generic LSP identifier is a type of Opaque Value Element encoded 329 as follows: 331 Type: 1 (to be assigned by IANA) 332 Length: 4 334 Value: A 32bit integer, unique in the context of the root, as 335 identified by the root's address. 337 This type of Opaque Value Element is recommended when mapping of 338 traffic to LSPs is non-algorithmic, and done by means outside LDP. 340 2.4. Using the P2MP FEC Element 342 This section defines the rules for the processing and propagation of 343 the P2MP FEC Element. The following notation is used in the 344 processing rules: 346 1. P2MP FEC Element : a FEC Element with Root Node Address X 347 and Opaque Value Y. 349 2. P2MP Label Map : a Label Map message with a FEC TLV with 350 a single P2MP FEC Element and Label TLV with label L. 352 3. P2MP Label Withdraw : a Label Withdraw message with a 353 FEC TLV with a single P2MP FEC Element and Label TLV with 354 label L. 356 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 357 Address X and Opaque Value Y. 359 5. The notation L' -> { ..., } on LSR X 360 means that on receiving a packet with label L', X makes n copies 361 of the packet. For copy i of the packet, X swaps L' with Li and 362 sends it out over interface Ii. 364 The procedures below are organized by the role which the node plays 365 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 366 process which is outside the scope of this document. During the 367 course of protocol operation, the root node recognizes its role 368 because it owns the Root Node Address. A transit node is any node 369 (other than the root node) that receives a P2MP Label Map message 370 (i.e., one that has leaf nodes downstream of it). 372 Note that a transit node (and indeed the root node) may also be a 373 leaf node. 375 2.4.1. Label Map 377 The remainder of this section specifies the procedures for 378 originating P2MP Label Map messages and for processing received P2MP 379 label map messages for a particular LSP. The procedures for a 380 particular LSR depend upon the role that LSR plays in the LSP 381 (ingress, transit, or egress). 383 All labels discussed here are downstream-assigned 384 [I-D.ietf-mpls-multicast-encaps] except those which are assigned 385 using the procedures of Section 6. 387 2.4.1.1. Determining one's 'upstream LSR' 389 Each node that is either an Leaf or Transit LSR of MP LSP needs to 390 use the procedures below to select an upstream LSR. A node Z that 391 wants to join a MP LSP determines the LDP peer U which is Z's 392 next-hop on the best path from Z to the root node X. If there is more 393 than one such LDP peer, only one of them is picked. U is Z's 394 "Upstream LSR" for . 396 When there are several candidate upstream LSRs, the LSR MAY select 397 one upstream LSR using the following procedure: 399 1. The candidate upstream LSRs are numbered from lower to higher IP 400 address 402 2. The following hash is performed: H = (Sum Opaque value) modulo N, 403 where N is the number of candidate upstream LSRs 405 3. The selected upstream LSR U is the LSR that has the number H. 407 This allows for load balancing of a set of LSPs among a set of 408 candidate upstream LSRs, while ensuring that on a LAN interface a 409 single upstream LSR is selected. 411 2.4.1.2. Leaf Operation 413 A leaf node Z of P2MP LSP determines its upstream LSR U for 414 as per Section 2.4.1.1, allocates a label L, and sends a P2MP 415 Label Map to U. 417 2.4.1.3. Transit Node operation 419 Suppose a transit node Z receives a P2MP Label Map from LSR 420 T. Z checks whether it already has state for . If not, Z 421 determines its upstream LSR U for as per Section 2.4.1.1. 422 Using this Label Map to update the label forwarding table MUST NOT be 423 done as long as LSR T is equal to LSR U. If LSR U is different from 424 LSR T, Z will allocate a label L', and install state to swap L' with 425 L over interface I associated with LSR T and send a P2MP Label Map 426 to LSR U. 428 If Z already has state for , then Z does not send a Label Map 429 message for P2MP LSP . All that Z needs to do in this case is 430 check that LSR T is not equal to the upstream LSR of and 431 update its forwarding state. Assuming its old forwarding state was 432 L'-> { ..., }, its new forwarding state 433 becomes L'-> { ..., , }. If the LSR T 434 is equal to the installed upstream LSR, the Label Map from LSR T MUST 435 be retained and MUST not update the label forwarding table. 437 2.4.1.4. Root Node Operation 439 Suppose the root node Z receives a P2MP Label Map from LSR 440 T. Z checks whether it already has forwarding state for . If 441 not, Z creates forwarding state to push label L onto the traffic that 442 Z wants to forward over the P2MP LSP (how this traffic is determined 443 is outside the scope of this document). 445 If Z already has forwarding state for , then Z adds "push label 446 L, send over interface I" to the nexthop, where I is the interface 447 associated with LSR T. 449 2.4.2. Label Withdraw 451 The following lists procedures for generating and processing P2MP 452 Label Withdraw messages for nodes that participate in a P2MP LSP. An 453 LSR should apply those procedures that apply to it, based on its role 454 in the P2MP LSP. 456 2.4.2.1. Leaf Operation 458 If a leaf node Z discovers (by means outside the scope of this 459 document) that it has no downstream neighbors in that LSP, and that 460 it has no need to be an egress LSR for that LSP, then it SHOULD send 461 a Label Withdraw to its upstream LSR U for , where L 462 is the label it had previously advertised to U for . 464 2.4.2.2. Transit Node Operation 466 If a transit node Z receives a Label Withdraw message from 467 a node W, it deletes label L from its forwarding state, and sends a 468 Label Release message with label L to W. 470 If deleting L from Z's forwarding state for P2MP LSP results 471 in no state remaining for , then Z propagates the Label 472 Withdraw for , to its upstream T, by sending a Label Withdraw 473 where L1 is the label Z had previously advertised to T for 474 . 476 2.4.2.3. Root Node Operation 478 The procedure when the root node of a P2MP LSP receives a Label 479 Withdraw message are the same as for transit nodes, except that it 480 would not propagate the Label Withdraw upstream (as it has no 481 upstream). 483 2.4.3. Upstream LSR change 485 Suppose that for a given node Z participating in a P2MP LSP , 486 the upstream LSR changes from U to U' as per Section 2.4.1.1. If U' 487 is present in the forwarding table of then it MUST be removed. 488 Z MUST also update its forwarding state by deleting the state for 489 label L, allocating a new label, L', for , and installing the 490 forwarding state for L'. Installing the forwarding state for L' MUST 491 NOT be done before the forwarding state L is removed to avoid 492 microloops. In addition Z MUST send a Label Map to U' and 493 send a Label Withdraw to U. Note, if there was a downstream 494 mapping from U that was not installed in the forwarding due to 495 Section 2.4.1.3 it can now be installed. 497 3. Shared Trees 499 The mechanism described above shows how to build a tree with a single 500 root and multiple leaves, i.e., a P2MP LSP. One can use essentially 501 the same mechanism to build Shared Trees with LDP. A Shared Tree can 502 be used by a group of routers that want to multicast traffic among 503 themselves, i.e., each node is both a root node (when it sources 504 traffic) and a leaf node (when any other member of the group sources 505 traffic). A Shared Tree offers similar functionality to a MP2MP LSP, 506 but the underlying multicasting mechanism uses a P2MP LSP. One 507 example where a Shared Tree is useful is video-conferencing. Another 508 is Virtual Private LAN Service (VPLS) [RFC4664], where for some types 509 of traffic, each device participating in a VPLS must send packets to 510 every other device in that VPLS. 512 One way to build a Shared Tree is to build an LDP P2MP LSP rooted at 513 a common point, the Shared Root (SR), and whose leaves are all the 514 members of the group. Each member of the Shared Tree unicasts 515 traffic to the SR (using, for example, the MP2P LSP created by the 516 unicast LDP FEC advertised by the SR); the SR then splices this 517 traffic into the LDP P2MP LSP. The SR may be (but need not be) a 518 member of the multicast group. 520 A major advantage of this approach is that no further protocol 521 mechanisms beyond the one already described are needed to set up a 522 Shared Tree. Furthermore, a Shared Tree is very efficient in terms 523 of the multicast state in the network, and is reasonably efficient in 524 terms of the bandwidth required to send traffic. 526 A property of this approach is that a sender will receive its own 527 packets as part of the multicast; thus a sender must be prepared to 528 recognize and discard packets that it itself has sent. For a number 529 of applications (for example, VPLS), this requirement is easy to 530 meet. Another consideration is the various techniques that can be 531 used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will 532 be described in a later revision. 534 4. Setting up MP2MP LSPs with LDP 536 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 537 root node, zero or more transit nodes and one or more leaf LSRs 538 acting equally as Ingress or Egress LSR. A leaf node participates in 539 the setup of an MP2MP LSP by establishing both a downstream LSP, 540 which is much like a P2MP LSP from the root, and an upstream LSP 541 which is used to send traffic toward the root and other leaf nodes. 542 Transit nodes support the setup by propagating the upstream and 543 downstream LSP setup toward the root and installing the necessary 544 MPLS forwarding state. The transmission of packets from the root 545 node of a MP2MP LSP to the receivers is identical to that for a P2MP 546 LSP. Traffic from a downstream node follows the upstream LSP toward 547 the root node and branches downward along the downstream LSP as 548 required to reach other leaf nodes. A packet that is received from a 549 downstream node MUST never be forwarded back out to that same node. 550 Mapping traffic to the MP2MP LSP may happen at any leaf node. How 551 that mapping is established is outside the scope of this document. 553 Due to how a MP2MP LSP is built a leaf LSR that is sending packets on 554 the MP2MP LSP does not receive its own packets. There is also no 555 additional mechanism needed on the root or transit LSR to match 556 upstream traffic to the downstream forwarding state. Packets that 557 are forwarded over a MP2MP LSP will not traverse a link more than 558 once, with the possible exception of LAN links (see Section 4.3.1), 559 if the procedures of [I-D.ietf-mpls-upstream-label] are not provided. 561 4.1. Support for MP2MP LSP setup with LDP 563 Support for the setup of MP2MP LSPs is advertised using LDP 564 capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An 565 implementation supporting the MP2MP procedures specified in this 566 document MUST implement the procedures for Capability Parameters in 567 Initialization Messages. 569 A new Capability Parameter TLV is defined, the MP2MP Capability. 570 Following is the format of the MP2MP Capability Parameter. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 |1|0| MP2MP Capability (TBD IANA) | Length (= 1) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |1| Reserved | 578 +-+-+-+-+-+-+-+-+ 580 The MP2MP Capability TLV MUST be supported in the LDP Initialization 581 Message. Advertisement of the MP2MP Capability indicates support of 582 the procedures for MP2MP LSP setup detailed in this document. If the 583 peer has not advertised the corresponding capability, then no label 584 messages using the MP2MP upstream and downstream FEC Elements should 585 be sent to the peer. 587 4.2. The MP2MP downstream and upstream FEC Elements. 589 For the setup of a MP2MP LSP with LDP we define 2 new protocol 590 entities, the MP2MP downstream FEC and upstream FEC Element. Both 591 elements will be used as FEC Elements in the FEC TLV. Note that the 592 MP2MP FEC Elements do not necessarily identify the traffic that must 593 be mapped to the LSP, so from that point of view, the use of the term 594 FEC is a misnomer. The description of the MP2MP FEC Elements follow. 596 The structure, encoding and error handling for the MP2MP downstream 597 and upstream FEC Elements are the same as for the P2MP FEC Element 598 described in Section 2.2. The difference is that two new FEC types 599 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 601 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 602 MUST be the only FEC Element in the FEC TLV. 604 Note, except when using the procedures of 605 [I-D.ietf-mpls-upstream-label], the MPLS labels used are "downstream- 606 assigned" [I-D.ietf-mpls-multicast-encaps], even if they are bound to 607 the "upstream FEC element". 609 4.3. Using the MP2MP FEC Elements 611 This section defines the rules for the processing and propagation of 612 the MP2MP FEC Elements. The following notation is used in the 613 processing rules: 615 1. MP2MP downstream LSP (or simply downstream ): an 616 MP2MP LSP downstream path with root node address X and opaque 617 value Y. 619 2. MP2MP upstream LSP (or simply upstream ): a 620 MP2MP LSP upstream path for downstream node D with root node 621 address X and opaque value Y. 623 3. MP2MP downstream FEC Element : a FEC Element with root 624 node address X and opaque value Y used for a downstream MP2MP 625 LSP. 627 4. MP2MP upstream FEC Element : a FEC Element with root node 628 address X and opaque value Y used for an upstream MP2MP LSP. 630 5. MP2MP-D Label Map : A Label Map message with a FEC TLV 631 with a single MP2MP downstream FEC Element and label TLV 632 with label L. 634 6. MP2MP-U Label Map : A Label Map message with a FEC TLV 635 with a single MP2MP upstream FEC Element and label TLV 636 with label Lu. 638 7. MP2MP-D Label Withdraw : a Label Withdraw message with 639 a FEC TLV with a single MP2MP downstream FEC Element and 640 label TLV with label L. 642 8. MP2MP-U Label Withdraw : a Label Withdraw message with 643 a FEC TLV with a single MP2MP upstream FEC Element and 644 label TLV with label Lu. 646 9. MP2MP-D Label Release : a Label Release message with a 647 FEC TLV with a single MP2MP downstream FEC Element and 648 label TLV with label L. 650 10. MP2MP-U Label Release : a Label Release message with a 651 FEC TLV with a single MP2MP upstream FEC Element and 652 label TLV with label Lu. 654 The procedures below are organized by the role which the node plays 655 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 656 process which is outside the scope of this document. During the 657 course of the protocol operation, the root node recognizes its role 658 because it owns the root node address. A transit node is any node 659 (other then the root node) that receives a MP2MP Label Map message 660 (i.e., one that has leaf nodes downstream of it). 662 Note that a transit node (and indeed the root node) may also be a 663 leaf node and the root node does not have to be an ingress LSR or 664 leaf of the MP2MP LSP. 666 4.3.1. MP2MP Label Map 668 The remainder of this section specifies the procedures for 669 originating MP2MP Label Map messages and for processing received 670 MP2MP label map messages for a particular LSP. The procedures for a 671 particular LSR depend upon the role that LSR plays in the LSP 672 (ingress, transit, or egress). 674 All labels discussed here are downstream-assigned 675 [I-D.ietf-mpls-multicast-encaps] except those which are assigned 676 using the procedures of Section 6. 678 4.3.1.1. Determining one's upstream MP2MP LSR 680 Determining the upstream LDP peer U for a MP2MP LSP follows 681 the procedure for a P2MP LSP described in Section 2.4.1.1. 683 4.3.1.2. Determining one's downstream MP2MP LSR 685 A LDP peer U which receives a MP2MP-D Label Map from a LDP peer D 686 will treat D as downstream MP2MP LSR. 688 4.3.1.3. Installing the upstream path of a MP2MP LSP 690 There are two methods for installing the upstream path of a MP2MP LSP 691 to a downstream neighbor. 693 1. We can install the upstream MP2MP path (to a downstream neighbor) 694 based on receiving a MP2MP-D Label Map from the downstream 695 neighbor. This will install the upstream path on a per hop by 696 hop bases. 698 2. We install the upstream MP2MP path (to a downstream neighbor) 699 based on receiving a MP2MP-U Label Map from the upstream 700 neighbor. An LSR does not need to wait for the MP2MP-U Label Map 701 if it is the root of the MP2MP LSP or already has received an 702 MP2MP-U Label Map from the upstream neighbor. We call this 703 method ordered mode. The typical result of this mode is that the 704 downstream path of the MP2MP is build hop by hop towards the 705 root. Once the root is reached, the root node will trigger a 706 MP2MP-U Label Map to the downstream neighbor(s). 708 For setting up the upstream path of a MP2MP LSP ordered mode MUST be 709 used. Due to ordered mode the upstream path of the MP2MP LSP is 710 installed at the leaf node once the path to the root is completed. 711 The advantage is that when a leaf starts sending immediately after 712 the upstream path is installed, packets are able to reach the root 713 node without being dropped due to an incomplete LSP. Method 1 is not 714 able to guarantee that the upstream path is completed before the leaf 715 starts sending. 717 4.3.1.4. MP2MP leaf node operation 719 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 720 as per Section 4.3.1.1, allocates a label L, and sends a 721 MP2MP-D Label Map to U. 723 Leaf node Z expects an MP2MP-U Label Map from node U in 724 response to the MP2MP-D Label Map it sent to node U. Z checks whether 725 it already has forwarding state for upstream . If not, Z 726 creates forwarding state to push label Lu onto the traffic that Z 727 wants to forward over the MP2MP LSP. How it determines what traffic 728 to forward on this MP2MP LSP is outside the scope of this document. 730 4.3.1.5. MP2MP transit node operation 732 When node Z receives a MP2MP-D Label Map from LSR D 733 associated with interface I, it checks whether it has forwarding 734 state for downstream . If not, Z determines its upstream LSR U 735 for as per Section 4.3.1.1. Using this Label Map to update 736 the label forwarding table MUST NOT be done as long as LSR D is equal 737 to LSR U. If LSR U is different from LSR D, Z will allocate a label 738 L' and install downstream forwarding state to swap label L' with 739 label L over interface I and send a MP2MP-D Label Map to 740 U. 742 If Z already has forwarding state for downstream , all that Z 743 needs to do in this case is check that LSR D is not equal to the 744 upstream LSR of and update its forwarding state. Assuming its 745 old forwarding state was L'-> { ..., }, its 746 new forwarding state becomes L'-> { ..., , 747 }. If the LSR D is equal to the installed upstream LSR, the 748 Label Map from LSR D MUST be retained and MUST not update the label 749 forwarding table. 751 Node Z checks if upstream LSR U already assigned a label Lu to . If not, transit node Z waits until it receives a MP2MP-U Label 753 Map from LSR U associated with interface Iu. See 754 Section 4.3.1.3. Once the MP2MP-U Label Map for Lu over interface Iu 755 is received from LSR U, node Z checks whether it already has 756 forwarding state upstream . If it does, then no further 757 action needs to happen. If it does not, it allocates a label Lu' and 758 creates a new label swap for Lu' with Label Lu over interface Iu. In 759 addition, it also adds the label swap(s) from the forwarding state 760 downstream , omitting the swap on interface I for node D. The 761 swap on interface I for node D is omitted to prevent packet 762 originated by D to be forwarded back to D. 764 Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2, 765 and sends a MP2MP-U Label Map to node D. 767 4.3.1.6. MP2MP root node operation 769 4.3.1.6.1. Root node is also a leaf 771 Suppose root/leaf node Z receives a MP2MP-D Label Map from 772 node D associated with interface I. Z checks whether it already has 773 forwarding state downstream . If not, Z creates forwarding 774 state for downstream to push label L on traffic that Z wants to 775 forward down the MP2MP LSP. How it determines what traffic to 776 forward on this MP2MP LSP is outside the scope of this document. If 777 Z already has forwarding state for downstream , then Z will add 778 the label push for L over interface I to it. 780 Node Z checks if it has forwarding state for upstream If 781 not, Z allocates a label Lu' and creates upstream forwarding state to 782 push Lu' with the label push(s) from the forwarding state downstream 783 , except the push on interface I for node D. This allows 784 upstream traffic to go down the MP2MP to other node(s), except the 785 node from which the traffic was received. Node Z determines the 786 downstream MP2MP LSR as per section Section 4.3.1.2, and sends a 787 MP2MP-U Label Map to node D. Since Z is the root of the 788 tree Z will not send a MP2MP-D Label Map and will not receive a 789 MP2MP-U Label Map. 791 4.3.1.6.2. Root node is not a leaf 793 Suppose the root node Z receives a MP2MP-D Label Map from 794 node D associated with interface I. Z checks whether it already has 795 forwarding state for downstream . If not, Z creates downstream 796 forwarding state and installs a outgoing label L over interface I. If 797 Z already has forwarding state for downstream , then Z will add 798 label L over interface I to the existing state. 800 Node Z checks if it has forwarding state for upstream . If 801 not, Z allocates a label Lu' and creates forwarding state to swap Lu' 802 with the label swap(s) from the forwarding state downstream , 803 except the swap for node D. This allows upstream traffic to go down 804 the MP2MP to other node(s), except the node is was received from. 805 Root node Z determines the downstream MP2MP LSR D as per 806 Section 4.3.1.2, and sends a MP2MP-U Label Map to it. 807 Since Z is the root of the tree Z will not send a MP2MP-D Label Map 808 and will not receive a MP2MP-U Label Map. 810 4.3.2. MP2MP Label Withdraw 812 The following lists procedures for generating and processing MP2MP 813 Label Withdraw messages for nodes that participate in a MP2MP LSP. 814 An LSR should apply those procedures that apply to it, based on its 815 role in the MP2MP LSP. 817 4.3.2.1. MP2MP leaf operation 819 If a leaf node Z discovers (by means outside the scope of this 820 document) that it has no downstream neighbors in that LSP, and that 821 it has no need to be an egress LSR for that LSP, then it SHOULD send 822 a MP2MP-D Label Withdraw to its upstream LSR U for , 823 where L is the label it had previously advertised to U for . 824 Leaf node Z will also send a unsolicited label release to 825 U to indicate that the upstream path is no longer used and that Label 826 Lu can be removed. 828 Leaf node Z expects the upstream router U to respond by sending a 829 downstream label release for L. 831 4.3.2.2. MP2MP transit node operation 833 If a transit node Z receives a MP2MP-D Label Withdraw message from node D, it deletes label L from its forwarding state 835 downstream and from all its upstream states for . Node 836 Z sends a MP2MP-D Label Release message with label L to D. Since node 837 D is no longer part of the downstream forwarding state, Z cleans up 838 the forwarding state upstream . There is no need to send an 839 MP2MP-U Label Withdraw to D because node D already removed 840 Lu and send a label release for Lu to Z. 842 If deleting L from Z's forwarding state for downstream results 843 in no state remaining for , then Z propagates the MP2MP-D Label 844 Withdraw to its upstream node U for and will also 845 send a unsolicited MP2MP-U Label Release to U to indicate 846 that the upstream path is no longer used and that Label Lu can be 847 removed. 849 4.3.2.3. MP2MP root node operation 851 The procedure when the root node of a MP2MP LSP receives a MP2MP-D 852 Label Withdraw message is the same as for transit nodes, except that 853 the root node would not propagate the Label Withdraw upstream (as it 854 has no upstream). 856 4.3.3. MP2MP Upstream LSR change 858 The procedure for changing the upstream LSR is the same as documented 859 in Section 2.4.3, except it is applied to MP2MP FECs, using the 860 procedures described in Section 4.3.1 through Section 4.3.2.3. 862 5. The LDP MP Status TLV 864 An LDP MP capable router MAY use an LDP MP Status TLV to indicate 865 additional status for a MP LSP to its remote peers. This includes 866 signaling to peers that are either upstream or downstream of the LDP 867 MP capable router. The value of the LDP MP status TLV will remain 868 opaque to LDP and MAY encode one or more status elements. 870 The LDP MP Status TLV is encoded as follows: 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 |1|0| LDP MP Status Type(TBD) | Length | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Value | 878 ~ ~ 879 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. 885 Length: Length of the LDP MP Status Value in octets. 887 Value: One or more LDP MP Status Value elements. 889 5.1. The LDP MP Status Value Element 891 The LDP MP Status Value Element that is included in the LDP MP Status 892 TLV Value has the following encoding. 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Type(TBD) | Length | Value ... | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 899 ~ ~ 900 | | 901 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 Type: The type of the LDP MP Status Value Element is to be assigned 907 by IANA. 909 Length: The length of the Value field, in octets. 911 Value: String of Length octets, to be interpreted as specified by 912 the Type field. 914 5.2. LDP Messages containing LDP MP Status messages 916 The LDP MP status message may appear either in a label mapping 917 message or a LDP notification message. 919 5.2.1. LDP MP Status sent in LDP notification messages 921 An LDP MP status TLV sent in a notification message must be 922 accompanied with a Status TLV. The general format of the 923 Notification Message with an LDP MP status TLV is: 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 |0| Notification (0x0001) | Message Length | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Message ID | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Status TLV | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | LDP MP Status TLV | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Optional LDP MP FEC TLV | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Optional Label TLV | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 The Status TLV status code is used to indicate that LDP MP status TLV 942 and an additional information follows in the Notification message's 943 "optional parameter" section. Depending on the actual contents of 944 the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may 945 also be present to provide context to the LDP MP Status TLV. (NOTE: 946 Status Code is pending IANA assignment). 948 Since the notification does not refer to any particular message, the 949 Message Id and Message Type fields are set to 0. 951 5.2.2. LDP MP Status TLV in Label Mapping Message 953 An example of the Label Mapping Message defined in RFC3036 is shown 954 below to illustrate the message with an Optional LDP MP Status TLV 955 present. 957 0 1 2 3 958 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 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 |0| Label Mapping (0x0400) | Message Length | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Message ID | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | FEC TLV | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Label TLV | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Optional LDP MP Status TLV | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Additional Optional Parameters | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 6. Upstream label allocation on a LAN 975 On a LAN, the procedures so far discussed would require the upstream 976 LSR to send a copy of the packet to each receiver individually. If 977 there is more then one receiver on the LAN we don't take full benefit 978 of the multi-access capability of the network. We may optimize the 979 bandwidth consumption on the LAN and replication overhead on the 980 upstream LSR by using upstream label allocation 981 [I-D.ietf-mpls-upstream-label]. Procedures on how to distribute 982 upstream labels using LDP is documented in 983 [I-D.ietf-mpls-ldp-upstream]. 985 6.1. LDP Multipoint-to-Multipoint on a LAN 987 The procedure to allocate a context label on a LAN is defined in 988 [I-D.ietf-mpls-upstream-label]. That procedure results in each LSR 989 on a given LAN having a context label which, on that LAN, can be used 990 to identify itself uniquely. Each LSR advertises its context label 991 as an upstream-assigned label, following the procedures of 992 [I-D.ietf-mpls-ldp-upstream]. Any LSR for which the LAN is a 993 downstream link on some P2MP or MP2MP LSP will allocate an upstream- 994 assigned label identifying that LSP. When the LSR forwards a packet 995 downstream on one of those LSPs, the packet's top label must be the 996 LSR's context label, and the packet's second label is the label 997 identifying the LSP. We will call the top label the "upstream LSR 998 label" and the second label the "LSP label". 1000 6.1.1. MP2MP downstream forwarding 1002 The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so 1003 we will use the same procedures as defined in 1004 [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is 1005 send to the upstream LSR. The label mapping that is received from 1006 the upstream LSR contains the LSP label for the MP2MP FEC and the 1007 upstream LSR context label. The MP2MP downstream path (corresponding 1008 to the LSP label) will be installed the context specific forwarding 1009 table corresponding to the upstream LSR label. Packets sent by the 1010 upstream router can be forwarded downstream using this forwarding 1011 state based on a two label lookup. 1013 6.1.2. MP2MP upstream forwarding 1015 A MP2MP LSP also has an upstream forwarding path. Upstream packets 1016 need to be forwarded in the direction of the root and downstream on 1017 any node on the LAN that has a downstream interface for the LSP. For 1018 a given MP2MP LSP on a given LAN, exactly one LSR is considered to be 1019 the upstream LSR. If an LSR on the LAN receives a packet from one of 1020 its downstream interfaces for the LSP, and if it needs to forward the 1021 packet onto the LAN, it ensures that the packet's top label is the 1022 context label of the upstream LSR, and that its second label is the 1023 LSP label that was assigned by the upstream LSR. 1025 Other LSRs receiving the packet will not be able to tell whether the 1026 packet really came from the upstream router, but that makes no 1027 difference in the processing of the packet. The upstream LSR will 1028 see its own upstream LSR in the label, and this will enable it to 1029 determine that the packet is traveling upstream. 1031 7. Root node redundancy 1033 The root node is a single point of failure for an MP LSP, whether 1034 this is P2MP or MP2MP. The problem is particularly severe for MP2MP 1035 LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same 1036 root node to set up the MP2MP LSP, because otherwise the traffic 1037 sourced by some leafs is not received by others. Because the root 1038 node is the single point of failure for an MP LSP, we need a fast and 1039 efficient mechanism to recover from a root node failure. 1041 An MP LSP is uniquely identified in the network by the opaque value 1042 and the root node address. It is likely that the root node for an MP 1043 LSP is defined statically. The root node address may be configured 1044 on each leaf statically or learned using a dynamic protocol. How 1045 leafs learn about the root node is out of the scope of this document. 1047 Suppose that for the same opaque value we define two (or more) root 1048 node addresses and we build a tree to each root using the same opaque 1049 value. Effectively these will be treated as different MP LSPs in the 1050 network. Once the trees are built, the procedures differ for P2MP 1051 and MP2MP LSPs. The different procedures are explained in the 1052 sections below. 1054 7.1. Root node redundancy - procedures for P2MP LSPs 1056 Since all leafs have set up P2MP LSPs to all the roots, they are 1057 prepared to receive packets on either one of these LSPs. However, 1058 only one of the roots should be forwarding traffic at any given time, 1059 for the following reasons: 1) to achieve bandwidth savings in the 1060 network and 2) to ensure that the receiving leafs don't receive 1061 duplicate packets (since one cannot assume that the receiving leafs 1062 are able to discard duplicates). How the roots determine which one 1063 is the active sender is outside the scope of this document. 1065 7.2. Root node redundancy - procedures for MP2MP LSPs 1067 Since all leafs have set up an MP2MP LSP to each one of the root 1068 nodes for this opaque value, a sending leaf may pick either of the 1069 two (or more) MP2MP LSPs to forward a packet on. The leaf nodes 1070 receive the packet on one of the MP2MP LSPs. The client of the MP2MP 1071 LSP does not care on which MP2MP LSP the packet is received, as long 1072 as they are for the same opaque value. The sending leaf MUST only 1073 forward a packet on one MP2MP LSP at a given point in time. The 1074 receiving leafs are unable to discard duplicate packets because they 1075 accept on all LSPs. Using all the available MP2MP LSPs we can 1076 implement redundancy using the following procedures. 1078 A sending leaf selects a single root node out of the available roots 1079 for a given opaque value. A good strategy MAY be to look at the 1080 unicast routing table and select a root that is closest in terms of 1081 the unicast metric. As soon as the root address of the active root 1082 disappears from the unicast routing table (or becomes less 1083 attractive) due to root node or link failure, the leaf can select a 1084 new best root address and start forwarding to it directly. If 1085 multiple root nodes have the same unicast metric, the highest root 1086 node addresses MAY be selected, or per session load balancing MAY be 1087 done over the root nodes. 1089 All leafs participating in a MP2MP LSP MUST join to all the available 1090 root nodes for a given opaque value. Since the sending leaf may pick 1091 any MP2MP LSP, it must be prepared to receive on it. 1093 The advantage of pre-building multiple MP2MP LSPs for a single opaque 1094 value is that convergence from a root node failure happens as fast as 1095 the unicast routing protocol is able to notify. There is no need for 1096 an additional protocol to advertise to the leaf nodes which root node 1097 is the active root. The root selection is a local leaf policy that 1098 does not need to be coordinated with other leafs. The disadvantage 1099 of pre-building multiple MP2MP LSPs is that more label resources are 1100 used, depending on how many root nodes are defined. 1102 8. Make Before Break (MBB) 1104 An LSR selects as its upstream LSR for a MP LSP the LSR that is its 1105 next hop to the root of the LSP. When the best path to reach the 1106 root changes the LSR must choose a new upstream LSR. Sections 1107 Section 2.4.3 and Section 4.3.3 describe these procedures. 1109 When the best path to the root changes the LSP may be broken 1110 temporarily resulting in packet loss until the LSP "reconverges" to a 1111 new upstream LSR. The goal of MBB when this happens is to keep the 1112 duration of packet loss as short as possible. In addition, there are 1113 scenarios where the best path from the LSR to the root changes but 1114 the LSP continues to forward packets to the prevous next hop to the 1115 root. That may occur when a link comes up or routing metrics change. 1116 In such a case a new LSP should be established before the old LSP is 1117 removed to limit the duration of packet loss. The procedures 1118 described below deal with both scenarios in a way that an LSR does 1119 not need to know which of the events described above caused its 1120 upstream router for an MBB LSP to change. 1122 This MBB procedures are an optional extension to the MP LSP building 1123 procedures described in this draft. 1125 8.1. MBB overview 1127 The MBB procedues use additional LDP signaling. 1129 Suppose some event causes a downstream LSR-D to select a new upstream 1130 LSR-U for FEC-A. The new LSR-U may already be forwarding packets for 1131 FEC-A; that is, to downstream LSR's other than LSR-D. After LSR-U 1132 receives a label for FEC-A from LSR-D, it will notify LSR-D when it 1133 knows that the LSP for FEC-A has been established from the root to 1134 itself. When LSR-D receives this MBB notification it will change its 1135 next hop for the LSP root to LSR-U. 1137 The assumption is that if LSR-U has received an MBB notification from 1138 its upstream router for the FEC-A LSP and has installed forwarding 1139 state the LSP it is capable of forwarding packets on the LSP. At 1140 that point LSR-U should signal LSR-D by means of an MBB notification 1141 that it has become part of the tree identified by FEC-A and that 1142 LSR-D should initiate its switchover to the LSP. 1144 At LSR-U the LSP for FEC-A may be in 1 of 3 states. 1146 1. There is no state for FEC-A. 1148 2. State for FEC-A exists and LSR-U is waiting for MBB notification 1149 that the LSP from the root to it exists. 1151 3. State for FEC-A exists and the MBB notification has been 1152 received. 1154 After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U 1155 MUST NOT reply with an MBB notification to LSR-D until its state for 1156 the LSP is state #3 above. If the state of the LSP at LSR-U is state 1157 #1 or #2, LSR-U should remember receipt of the Label Mapping message 1158 from LSR-D while waiting for an MBB notification from its upstream 1159 LSR for the LSP. When LSR-U receives the MBB notification from its 1160 upstream LSR it transitions to LSP state #3 and sends an MBB 1161 notification to LSR-D. 1163 8.2. The MBB Status code 1165 As noted in Section 8.1, the procedures to establish an MBB MP LSP 1166 are different from those to establish normal MP LSPs. 1168 When a downstream LSR sends a Label Mapping message for MP LSP to its 1169 upstream LSR it MAY include an LDP MP Status TLV that carries a MBB 1170 Status Code to indicate MBB procedures apply to the LSP. This new 1171 MBB Status Code MAY also appear in an LDP Notification message used 1172 by an upstream LSR to signal LSP state #3 to the downstream LSR; that 1173 is, that the upstream LSR's state for the LSP exists and that it has 1174 received notification from its upstream LSR that the LSP is in state 1175 #3. 1177 The MBB Status is a type of the LDP MP Status Value Element as 1178 described in Section 5.1. It is encoded as follows: 1180 0 1 2 3 1181 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 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | MBB Type = 1 | Length = 1 | Status code | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 MBB Type: Type 1 (to be assigned by IANA) 1188 Length: 1 1190 Status code: 1 = MBB request 1192 2 = MBB ack 1194 8.3. The MBB capability 1196 An LSR MAY advertise that it is capable of handling MBB LSPs using 1197 the capability advertisement as defined in 1198 [I-D.ietf-mpls-ldp-capabilities]. The LDP MP MBB capability has the 1199 following format: 1201 0 1 2 3 1202 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 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 |1|0| LDP MP MBB Capability | Length = 1 | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 |1| Reserved | 1207 +-+-+-+-+-+-+-+-+ 1209 Note: LDP MP MBB Capability (Pending IANA assignment) 1211 0 1 2 3 1212 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 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 |1|0| LDP MP MBB Capability | Length = 1 | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 |1| Reserved | 1217 +-+-+-+-+-+-+-+-+ 1219 If an LSR has not advertised that it is MBB capable, its LDP peers 1220 MUST NOT send it messages which include MBB parameters. If an LSR 1221 receives a Label Mapping message with a MBB parameter from downstream 1222 LSR-D and its upstream LSR-U has not advertised that it is MBB 1223 capable, the LSR MUST send an MBB notification immediatly to LSR-U 1224 (see Section 8.4). If this happens an MBB MP LSP will not be 1225 established, but normal a MP LSP will be the result. 1227 8.4. The MBB procedures 1229 8.4.1. Terminology 1231 1. MBB LSP : A P2MP or MP2MP Make Before Break (MBB) LSP entry 1232 with Root Node Address X and Opaque Value Y. 1234 2. A(N, L): An Accepting element that consists of an upstream 1235 Neighbor N and Local label L. This LSR assigned label L to 1236 neighbor N for a specific MBB LSP. For an active element the 1237 corresponding Label is stored in the label forwarding database. 1239 3. iA(N, L): An inactive Accepting element that consists of an 1240 upstream neighbor N and local Label L. This LSR assigned label L 1241 to neighbor N for a specific MBB LSP. For an inactive element 1242 the corresponding Label is not stored in the label forwarding 1243 database. 1245 4. F(N, L): A Forwarding state that consists of downstream Neighbor 1246 N and Label L. This LSR is sending label packets with label L to 1247 neighbor N for a specific FEC. 1249 5. F'(N, L): A Forwarding state that has been marked for sending a 1250 MBB Notification message to Neighbor N with Label L. 1252 6. MBB Notification : A LDP notification message with a MP 1253 LSP , Label L and MBB Status code 2. 1255 7. MBB Label Map : A P2MP Label Map or MP2MP Label Map 1256 downstream with a FEC element , Label L and MBB Status code 1257 1. 1259 8.4.2. Accepting elements 1261 An accepting element represents a specific label value L that has 1262 been advertised to a neighbor N for a MBB LSP and is a 1263 candidate for accepting labels switched packets on. An LSR can have 1264 two accepting elements for a specific MBB LSP LSP, only one of 1265 them MUST be active. An active element is the element for which the 1266 label value has been installed in the label forwarding database. An 1267 inactive accepting element is created after a new upstream LSR is 1268 chosen and is pending to replace the active element in the label 1269 forwarding database. Inactive elements only exist temporarily while 1270 switching to a new upstream LSR. Once the switch has been completed 1271 only one active element remains. During network convergence it is 1272 possible that an inactive accepting element is created while an other 1273 inactive accepting element is pending. If that happens the older 1274 inactive accepting element MUST be replaced with an newer inactive 1275 element. If an accepting element is removed a Label Withdraw has to 1276 be send for label L to neighbor N for . 1278 8.4.3. Procedures for upstream LSR change 1280 Suppose a node Z has a MBB LSP with an active accepting 1281 element A(N1, L1). Due to a routing change it detects a new best 1282 path for root X and selects a new upstream LSR N2. Node Z allocates 1283 a new local label L2 and creates an inactive accepting element iA(N2, 1284 L2). Node Z sends MBB Label Map to N2 and waits for the 1285 new upstream LSR N2 to respond with a MBB Notification for . During this transition phase there are two accepting elements, 1287 the element A(N1, L1) still accepting packets from N1 over label L1 1288 and the new inactive element iA(N2, L2). 1290 While waiting for the MBB Notification from upstream LSR N2, it is 1291 possible that an other transition occurs due to a routing change. 1292 Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) 1293 is created and the old inactive element iA(N2, L2) MUST be removed. 1294 A label withdraw MUST be sent to N2 for from N2 will be ignored because the 1296 inactive element is removed. 1298 It is possible that the MBB Notification from upstream LSR is never 1299 received due to link or node failure. To prevent waiting 1300 indefinitely for the MBB Notification a timeout SHOULD be applied. 1301 As soon as the timer expires, the procedures in Section 8.4.5 are 1302 applied as if a MBB Notification was received for the inactive 1303 element. 1305 8.4.4. Receiving a Label Map with MBB status code 1307 Suppose node Z has state for a MBB LSP and receives a MBB 1308 Label Map from N2. A new forwarding state F(N2, L2) will 1309 be added to the MP LSP if it did not already exist. If this MBB LSP 1310 has an active accepting element or node Z is the root of the MBB LSP 1311 a MBB notification is send to node N2. If node Z has an 1312 inactive accepting element it marks the Forwarding state as . 1315 8.4.5. Receiving a Notification with MBB status code 1317 Suppose node Z receives a MBB Notification from N. If node 1318 Z has state for MBB LSP and an inactive accepting element 1319 iA(N, L) that matches with N and L, we activate this accepting 1320 element and install label L in the label forwarding database. If an 1321 other active accepting was present it will be removed from the label 1322 forwarding database. 1324 If this MBB LSP also has Forwarding states marked for sending 1325 MBB Notifications, like , MBB Notifications are 1326 send to these downstream LSRs. If node Z receives a MBB Notification 1327 for an accepting element that is not inactive or does not match the 1328 Label value and Neighbor address, the MBB notification is ignored. 1330 8.4.6. Node operation for MP2MP LSPs 1332 The procedures described above apply to the downstream path of a 1333 MP2MP LSP. The upstream path of the MP2MP is setup as normal without 1334 including a MBB Status code. If the MBB procedures apply to a MP2MP 1335 downstream FEC element, the upstream path to a node N is only 1336 installed in the label forwarding database if node N is part of the 1337 active accepting element. If node N is part of an inactive accepting 1338 element, the upstream path is installed when this inactive accepting 1339 element is activated. 1341 9. Security Considerations 1343 The same security considerations apply as for the base LDP 1344 specification, as described in [RFC5036]. 1346 10. IANA considerations 1348 This document creates a new name space (the LDP MP Opaque Value 1349 Element type) that is to be managed by IANA, and the allocation of 1350 the value 1 for the type of Generic LSP Identifier. 1352 This document requires allocation of three new LDP FEC Element types: 1354 1. the P2MP FEC type - requested value 0x06 1356 2. the MP2MP-up FEC type - requested value 0x07 1358 3. the MP2MP-down FEC type - requested value 0x08 1360 This document requires the assignment of three new code points for 1361 three new Capability Parameter TLVs, corresponding to the 1362 advertisement of the P2MP, MP2MP and MBB capabilities. The values 1363 requested are: 1365 P2MP Capability Parameter - requested value 0x0508 1367 MP2MP Capability Parameter - requested value 0x0509 1369 MBB Capability Parameter - requested value 0x050A 1371 This document requires the assignment of a LDP Status Code to 1372 indicate a LDP MP Status TLV is following in the Notification 1373 message. The value requested from the LDP Status Code Name Space: 1375 LDP MP status - requested value 0x00000040 1377 This document requires the assigment of a new code point for a LDP MP 1378 Status TLV. The value requested from the LDP TLV Type Name Space: 1380 LDP MP Status TLV Type - requested value 0x096F 1382 This document creates a new name space (the LDP MP Status Value 1383 Element type) that is to be managed by IANA, and the allocation of 1384 the value 1 for the type of MBB Status. 1386 11. Acknowledgments 1388 The authors would like to thank the following individuals for their 1389 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 1390 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, 1391 George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas 1392 Morin. 1394 12. Contributing authors 1396 Below is a list of the contributing authors in alphabetical order: 1398 Shane Amante 1399 Level 3 Communications, LLC 1400 1025 Eldorado Blvd 1401 Broomfield, CO 80021 1402 US 1403 Email: Shane.Amante@Level3.com 1405 Luyuan Fang 1406 Cisco Systems 1407 300 Beaver Brook Road 1408 Boxborough, MA 01719 1409 US 1410 Email: lufang@cisco.com 1412 Hitoshi Fukuda 1413 NTT Communications Corporation 1414 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1415 Tokyo 100-8019, 1416 Japan 1417 Email: hitoshi.fukuda@ntt.com 1419 Yuji Kamite 1420 NTT Communications Corporation 1421 Tokyo Opera City Tower 1422 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1423 Tokyo 163-1421, 1424 Japan 1425 Email: y.kamite@ntt.com 1426 Kireeti Kompella 1427 Juniper Networks 1428 1194 N. Mathilda Ave. 1429 Sunnyvale, CA 94089 1430 US 1431 Email: kireeti@juniper.net 1433 Ina Minei 1434 Juniper Networks 1435 1194 N. Mathilda Ave. 1436 Sunnyvale, CA 94089 1437 US 1438 Email: ina@juniper.net 1440 Jean-Louis Le Roux 1441 France Telecom 1442 2, avenue Pierre-Marzin 1443 Lannion, Cedex 22307 1444 France 1445 Email: jeanlouis.leroux@francetelecom.com 1447 Bob Thomas 1448 Cisco Systems, Inc. 1449 300 Beaver Brook Road 1450 Boxborough, MA, 01719 1451 E-mail: bobthomas@alum.mit.edu 1453 Lei Wang 1454 Telenor 1455 Snaroyveien 30 1456 Fornebu 1331 1457 Norway 1458 Email: lei.wang@telenor.com 1460 IJsbrand Wijnands 1461 Cisco Systems, Inc. 1462 De kleetlaan 6a 1463 1831 Diegem 1464 Belgium 1465 E-mail: ice@cisco.com 1467 13. References 1468 13.1. Normative References 1470 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1471 Specification", RFC 5036, October 2007. 1473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1474 Requirement Levels", BCP 14, RFC 2119, March 1997. 1476 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1477 an On-line Database", RFC 3232, January 2002. 1479 [I-D.ietf-mpls-upstream-label] 1480 Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1481 Label Assignment and Context-Specific Label Space", 1482 draft-ietf-mpls-upstream-label-05 (work in progress), 1483 April 2008. 1485 [I-D.ietf-mpls-ldp-upstream] 1486 Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment 1487 for LDP", draft-ietf-mpls-ldp-upstream-02 (work in 1488 progress), November 2007. 1490 [I-D.ietf-mpls-ldp-capabilities] 1491 Thomas, B., "LDP Capabilities", 1492 draft-ietf-mpls-ldp-capabilities-02 (work in progress), 1493 March 2008. 1495 13.2. Informative References 1497 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1498 Private Networks (L2VPNs)", RFC 4664, September 2006. 1500 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1501 "Extensions to Resource Reservation Protocol - Traffic 1502 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1503 Switched Paths (LSPs)", RFC 4875, May 2007. 1505 [I-D.ietf-mpls-mp-ldp-reqs] 1506 Roux, J., "Requirements for Point-To-Multipoint Extensions 1507 to the Label Distribution Protocol", 1508 draft-ietf-mpls-mp-ldp-reqs-04 (work in progress), 1509 February 2008. 1511 [I-D.ietf-l3vpn-2547bis-mcast] 1512 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 1513 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 1514 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work 1515 in progress), January 2008. 1517 [I-D.ietf-mpls-multicast-encaps] 1518 Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 1519 Multicast Encapsulations", 1520 draft-ietf-mpls-multicast-encaps-09 (work in progress), 1521 May 2008. 1523 Authors' Addresses 1525 Ina Minei 1526 Juniper Networks 1527 1194 N. Mathilda Ave. 1528 Sunnyvale, CA 94089 1529 US 1531 Email: ina@juniper.net 1533 Kireeti Kompella 1534 Juniper Networks 1535 1194 N. Mathilda Ave. 1536 Sunnyvale, CA 94089 1537 US 1539 Email: kireeti@juniper.net 1541 IJsbrand Wijnands 1542 Cisco Systems, Inc. 1543 De kleetlaan 6a 1544 Diegem 1831 1545 Belgium 1547 Email: ice@cisco.com 1549 Bob Thomas 1550 Cisco Systems, Inc. 1551 300 Beaver Brook Road 1552 Boxborough 01719 1553 US 1555 Email: bobthomas@alum.mit.edu