idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-06.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 (April 20, 2009) is 5485 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: October 22, 2009 I. Wijnands (Editor) 6 B. Thomas 7 Cisco Systems, Inc. 8 April 20, 2009 10 Label Distribution Protocol Extensions for Point-to-Multipoint and 11 Multipoint-to-Multipoint Label Switched Paths 12 draft-ietf-mpls-ldp-p2mp-06 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 October 22, 2009. 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. LDP constructs the P2MP or MP2MP 63 LSPs without interacting with or relying upon any other multicast 64 tree construction protocol. Protocol elements and procedures for 65 this solution are described for building such LSPs in a receiver- 66 initiated manner. There can be various applications for P2MP/MP2MP 67 LSPs, for example IP multicast or support for multicast in BGP/MPLS 68 L3VPNs. Specification of how such applications can use a LDP 69 signaled P2MP/MP2MP LSP is outside the scope of this document. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.1. Conventions used in this document . . . . . . . . . . . . 5 75 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6 77 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 7 78 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7 79 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9 80 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 9 81 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 10 82 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 11 83 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 12 84 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 13 85 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 14 87 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 14 88 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 15 89 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15 90 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 17 91 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 20 92 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 21 93 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21 94 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22 95 5.2. LDP Messages containing LDP MP Status messages . . . . . . 22 96 5.2.1. LDP MP Status sent in LDP notification messages . . . 22 97 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23 98 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24 99 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24 100 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24 101 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24 102 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 103 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25 104 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 105 8. MP2MP micro loop prevention . . . . . . . . . . . . . . . . . 26 106 8.1. MP2MP upstream path . . . . . . . . . . . . . . . . . . . 27 107 8.2. MP2MP micro loop prevention procedures . . . . . . . . . . 27 108 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 27 109 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28 110 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29 111 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 29 112 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30 113 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30 114 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31 115 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 31 116 9.4.4. Receiving a Label Map with MBB status code . . . . . . 32 117 9.4.5. Receiving a Notification with MBB status code . . . . 32 118 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 32 120 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 121 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33 122 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 123 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 34 124 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 125 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 126 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 129 1. Introduction 131 The LDP protocol is described in [RFC5036]. It defines mechanisms 132 for setting up point-to-point (P2P) and multipoint-to-point (MP2P) 133 LSPs in the network. This document describes extensions to LDP for 134 setting up point-to-multipoint (P2MP) and multipoint-to-multipoint 135 (MP2MP) LSPs. These are collectively referred to as multipoint LSPs 136 (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) 137 node to be delivered to a number of leaf (or egress) nodes. A MP2MP 138 LSP allows traffic from multiple ingress nodes to be delivered to 139 multiple egress nodes. Only a single copy of the packet will be sent 140 on any link traversed by the MP LSP (see note at end of 141 Section 2.4.1). This is accomplished without the use of a multicast 142 protocol in the network. There can be several MP LSPs rooted at a 143 given ingress node, each with its own identifier. 145 The solution assumes that the leaf nodes of the MP LSP know the root 146 node and identifier of the MP LSP to which they belong. The 147 mechanisms for the distribution of this information are outside the 148 scope of this document. The specification of how an application can 149 use a MP LSP signaled by LDP is also outside the scope of this 150 document. 152 Interested readers may also wish to peruse the requirements draft 153 [I-D.ietf-mpls-mp-ldp-reqs] and other documents [RFC4875] and 154 [I-D.ietf-l3vpn-2547bis-mcast]. 156 1.1. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 1.2. Terminology 164 The following terminology is taken from [I-D.ietf-mpls-mp-ldp-reqs]. 166 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 168 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 169 LSRs. 171 MP2P LSP: An LSP that has one or more Ingress LSRs and one unique 172 Egress LSR. 174 MP2MP LSP: An LSP that connects a set of nodes, such that traffic 175 sent by any node in the LSP is delivered to all others. 177 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 179 Ingress LSR: An ingress LSR for a particular LSP is an LSR that can 180 send a data packet along the LSP. MP2MP LSPs can have multiple 181 ingress LSRs, P2MP LSPs have just one, and that node is often 182 referred to as the "root node". 184 Egress LSR: An egress LSR for a particular LSP is an LSR that can 185 remove a data packet from that LSP for further processing. P2P 186 and MP2P LSPs have only a single egress node, but P2MP and MP2MP 187 LSPs can have multiple egress nodes. 189 Transit LSR: An LSR that has reachability to the root of the MP LSP 190 via a directly connected upstream LSR and one or more directly 191 connected downstream LSRs. 193 Bud LSR: An LSR that is an egress but also has one or more directly 194 connected downstream LSRs. 196 Leaf node: A Leaf node can be either an Egress or Bud LSR when 197 referred in the context of a P2MP LSP. In the context of a MP2MP 198 LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and 199 can also be a Bud LSR. 201 2. Setting up P2MP LSPs with LDP 203 A P2MP LSP consists of a single root node, zero or more transit nodes 204 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 205 tear-down. Leaf nodes also install forwarding state to deliver the 206 traffic received on a P2MP LSP to wherever it needs to go; how this 207 is done is outside the scope of this document. Transit nodes install 208 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 209 down) toward the root. The root node installs forwarding state to 210 map traffic into the P2MP LSP; how the root node determines which 211 traffic should go over the P2MP LSP is outside the scope of this 212 document. 214 2.1. Support for P2MP LSP setup with LDP 216 Support for the setup of P2MP LSPs is advertised using LDP 217 capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An 218 implementation supporting the P2MP procedures specified in this 219 document MUST implement the procedures for Capability Parameters in 220 Initialization Messages. 222 A new Capability Parameter TLV is defined, the P2MP Capability. 223 Following is the format of the P2MP Capability Parameter. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |1|0| P2MP Capability (TBD IANA) | Length (= 1) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |1| Reserved | 231 +-+-+-+-+-+-+-+-+ 233 The P2MP Capability TLV MUST be supported in the LDP Initialization 234 Message. Advertisement of the P2MP Capability indicates support of 235 the procedures for P2MP LSP setup detailed in this document. If the 236 peer has not advertised the corresponding capability, then no label 237 messages using the P2MP FEC Element should be sent to the peer. 239 2.2. The P2MP FEC Element 241 For the setup of a P2MP LSP with LDP, we define one new protocol 242 entity, the P2MP FEC Element to be used as a FEC Element in the FEC 243 TLV. Note that the P2MP FEC Element does not necessarily identify 244 the traffic that must be mapped to the LSP, so from that point of 245 view, the use of the term FEC is a misnomer. The description of the 246 P2MP FEC Element follows. 248 The P2MP FEC Element consists of the address of the root of the P2MP 249 LSP and an opaque value. The opaque value consists of one or more 250 LDP MP Opaque Value Elements. The opaque value is unique within the 251 context of the root node. The combination of (Root Node Address, 252 Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. 254 The P2MP FEC Element is encoded as follows: 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |P2MP Type (TBD)| Address Family | Address Length| 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 ~ Root Node Address ~ 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Opaque Length | Opaque Value ... | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 265 ~ ~ 266 | | 267 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Type: The type of the P2MP FEC Element is to be assigned by IANA. 273 Address Family: Two octet quantity containing a value from ADDRESS 274 FAMILY NUMBERS in [RFC3232] that encodes the address family for 275 the Root LSR Address. 277 Address Length: Length of the Root LSR Address in octets. 279 Root Node Address: A host address encoded according to the Address 280 Family field. 282 Opaque Length: The length of the Opaque Value, in octets. 284 Opaque Value: One or more MP Opaque Value elements, uniquely 285 identifying the P2MP LSP in the context of the Root Node. This is 286 described in the next section. 288 If the Address Family is IPv4, the Address Length MUST be 4; if the 289 Address Family is IPv6, the Address Length MUST be 16. No other 290 Address Lengths are defined at present. 292 If the Address Length doesn't match the defined length for the 293 Address Family, the receiver SHOULD abort processing the message 294 containing the FEC Element, and send an "Unknown FEC" Notification 295 message to its LDP peer signaling an error. 297 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 298 be the only FEC Element in the FEC TLV. 300 2.3. The LDP MP Opaque Value Element 302 The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC 303 Elements defined in subsequent sections. It carries information that 304 is meaningful to Ingress LSRs and Leaf LSRs, but need not be 305 interpreted by Transit LSRs. 307 The LDP MP Opaque Value Element is encoded as follows: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type(TBD) | Length | Value ... | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 314 ~ ~ 315 | | 316 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Type: The type of the LDP MP Opaque Value Element is to be assigned 322 by IANA. 324 Length: The length of the Value field, in octets. 326 Value: String of Length octets, to be interpreted as specified by 327 the Type field. 329 2.3.1. The Generic LSP Identifier 331 The generic LSP identifier is a type of Opaque Value Element encoded 332 as follows: 334 Type: 1 (to be assigned by IANA) 335 Length: 4 337 Value: A 32bit integer, unique in the context of the root, as 338 identified by the root's address. 340 This type of Opaque Value Element is recommended when mapping of 341 traffic to LSPs is non-algorithmic, and done by means outside LDP. 343 2.4. Using the P2MP FEC Element 345 This section defines the rules for the processing and propagation of 346 the P2MP FEC Element. The following notation is used in the 347 processing rules: 349 1. P2MP FEC Element : a FEC Element with Root Node Address X 350 and Opaque Value Y. 352 2. P2MP Label Map : a Label Map message with a FEC TLV with 353 a single P2MP FEC Element and Label TLV with label L. 355 3. P2MP Label Withdraw : a Label Withdraw message with a 356 FEC TLV with a single P2MP FEC Element and Label TLV with 357 label L. 359 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 360 Address X and Opaque Value Y. 362 5. The notation L' -> { ..., } on LSR X 363 means that on receiving a packet with label L', X makes n copies 364 of the packet. For copy i of the packet, X swaps L' with Li and 365 sends it out over interface Ii. 367 The procedures below are organized by the role which the node plays 368 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 369 process which is outside the scope of this document. During the 370 course of protocol operation, the root node recognizes its role 371 because it owns the Root Node Address. A transit node is any node 372 (other than the root node) that receives a P2MP Label Map message 373 (i.e., one that has leaf nodes downstream of it). 375 Note that a transit node (and indeed the root node) may also be a 376 leaf node. 378 2.4.1. Label Map 380 The remainder of this section specifies the procedures for 381 originating P2MP Label Map messages and for processing received P2MP 382 label map messages for a particular LSP. The procedures for a 383 particular LSR depend upon the role that LSR plays in the LSP 384 (ingress, transit, or egress). 386 All labels discussed here are downstream-assigned 387 [I-D.ietf-mpls-multicast-encaps] except those which are assigned 388 using the procedures of Section 6. 390 2.4.1.1. Determining one's 'upstream LSR' 392 Each node that is either an Leaf or Transit LSR of MP LSP needs to 393 use the procedures below to select an upstream LSR. A node Z that 394 wants to join a MP LSP determines the LDP peer U which is Z's 395 next-hop on the best path from Z to the root node X. If there is more 396 than one such LDP peer, only one of them is picked. U is Z's 397 "Upstream LSR" for . 399 When there are several candidate upstream LSRs, the LSR MAY select 400 one upstream LSR using the following procedure: 402 1. The candidate upstream LSRs are numbered from lower to higher IP 403 address 405 2. The following hash is performed: H = (Sum Opaque value) modulo N, 406 where N is the number of candidate upstream LSRs 408 3. The selected upstream LSR U is the LSR that has the number H. 410 This allows for load balancing of a set of LSPs among a set of 411 candidate upstream LSRs, while ensuring that on a LAN interface a 412 single upstream LSR is selected. 414 2.4.1.2. Leaf Operation 416 A leaf node Z of P2MP LSP determines its upstream LSR U for 417 as per Section 2.4.1.1, allocates a label L, and sends a P2MP 418 Label Map to U. 420 2.4.1.3. Transit Node operation 422 Suppose a transit node Z receives a P2MP Label Map from LSR 423 T. Z checks whether it already has state for . If not, Z 424 determines its upstream LSR U for as per Section 2.4.1.1. 425 Using this Label Map to update the label forwarding table MUST NOT be 426 done as long as LSR T is equal to LSR U. If LSR U is different from 427 LSR T, Z will allocate a label L', and install state to swap L' with 428 L over interface I associated with LSR T and send a P2MP Label Map 429 to LSR U. 431 If Z already has state for , then Z does not send a Label Map 432 message for P2MP LSP . All that Z needs to do in this case is 433 check that LSR T is not equal to the upstream LSR of and 434 update its forwarding state. Assuming its old forwarding state was 435 L'-> { ..., }, its new forwarding state 436 becomes L'-> { ..., , }. If the LSR T 437 is equal to the installed upstream LSR, the Label Map from LSR T MUST 438 be retained and MUST not update the label forwarding table. 440 2.4.1.4. Root Node Operation 442 Suppose the root node Z receives a P2MP Label Map from LSR 443 T. Z checks whether it already has forwarding state for . If 444 not, Z creates forwarding state to push label L onto the traffic that 445 Z wants to forward over the P2MP LSP (how this traffic is determined 446 is outside the scope of this document). 448 If Z already has forwarding state for , then Z adds "push label 449 L, send over interface I" to the nexthop, where I is the interface 450 associated with LSR T. 452 2.4.2. Label Withdraw 454 The following lists procedures for generating and processing P2MP 455 Label Withdraw messages for nodes that participate in a P2MP LSP. An 456 LSR should apply those procedures that apply to it, based on its role 457 in the P2MP LSP. 459 2.4.2.1. Leaf Operation 461 If a leaf node Z discovers (by means outside the scope of this 462 document) that it has no downstream neighbors in that LSP, and that 463 it has no need to be an egress LSR for that LSP, then it SHOULD send 464 a Label Withdraw to its upstream LSR U for , where L 465 is the label it had previously advertised to U for . 467 2.4.2.2. Transit Node Operation 469 If a transit node Z receives a Label Withdraw message from 470 a node W, it deletes label L from its forwarding state, and sends a 471 Label Release message with label L to W. 473 If deleting L from Z's forwarding state for P2MP LSP results 474 in no state remaining for , then Z propagates the Label 475 Withdraw for , to its upstream T, by sending a Label Withdraw 476 where L1 is the label Z had previously advertised to T for 477 . 479 2.4.2.3. Root Node Operation 481 The procedure when the root node of a P2MP LSP receives a Label 482 Withdraw message are the same as for transit nodes, except that it 483 would not propagate the Label Withdraw upstream (as it has no 484 upstream). 486 2.4.3. Upstream LSR change 488 Suppose that for a given node Z participating in a P2MP LSP , 489 the upstream LSR changes from U to U' as per Section 2.4.1.1. If U' 490 is present in the forwarding table of then it MUST be removed. 491 Z MUST also update its forwarding state by deleting the state for 492 label L, allocating a new label, L', for , and installing the 493 forwarding state for L'. Installing the forwarding state for L' MUST 494 NOT be done before the forwarding state L is removed to avoid 495 microloops. In addition Z MUST send a Label Map to U' and 496 send a Label Withdraw to U. Note, if there was a downstream 497 mapping from U that was not installed in the forwarding due to 498 Section 2.4.1.3 it can now be installed. 500 3. Shared Trees 502 The mechanism described above shows how to build a tree with a single 503 root and multiple leaves, i.e., a P2MP LSP. One can use essentially 504 the same mechanism to build Shared Trees with LDP. A Shared Tree can 505 be used by a group of routers that want to multicast traffic among 506 themselves, i.e., each node is both a root node (when it sources 507 traffic) and a leaf node (when any other member of the group sources 508 traffic). A Shared Tree offers similar functionality to a MP2MP LSP, 509 but the underlying multicasting mechanism uses a P2MP LSP. One 510 example where a Shared Tree is useful is video-conferencing. Another 511 is Virtual Private LAN Service (VPLS) [RFC4664], where for some types 512 of traffic, each device participating in a VPLS must send packets to 513 every other device in that VPLS. 515 One way to build a Shared Tree is to build an LDP P2MP LSP rooted at 516 a common point, the Shared Root (SR), and whose leaves are all the 517 members of the group. Each member of the Shared Tree unicasts 518 traffic to the SR (using, for example, the MP2P LSP created by the 519 unicast LDP FEC advertised by the SR); the SR then splices this 520 traffic into the LDP P2MP LSP. The SR may be (but need not be) a 521 member of the multicast group. 523 A major advantage of this approach is that no further protocol 524 mechanisms beyond the one already described are needed to set up a 525 Shared Tree. Furthermore, a Shared Tree is very efficient in terms 526 of the multicast state in the network, and is reasonably efficient in 527 terms of the bandwidth required to send traffic. 529 A property of this approach is that a sender will receive its own 530 packets as part of the multicast; thus a sender must be prepared to 531 recognize and discard packets that it itself has sent. For a number 532 of applications (for example, VPLS), this requirement is easy to 533 meet. Another consideration is the various techniques that can be 534 used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will 535 be described in a later revision. 537 4. Setting up MP2MP LSPs with LDP 539 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 540 root node, zero or more transit nodes and one or more leaf LSRs 541 acting equally as Ingress or Egress LSR. A leaf node participates in 542 the setup of an MP2MP LSP by establishing both a downstream LSP, 543 which is much like a P2MP LSP from the root, and an upstream LSP 544 which is used to send traffic toward the root and other leaf nodes. 545 Transit nodes support the setup by propagating the upstream and 546 downstream LSP setup toward the root and installing the necessary 547 MPLS forwarding state. The transmission of packets from the root 548 node of a MP2MP LSP to the receivers is identical to that for a P2MP 549 LSP. Traffic from a downstream node follows the upstream LSP toward 550 the root node and branches downward along the downstream LSP as 551 required to reach other leaf nodes. A packet that is received from a 552 downstream node MUST never be forwarded back out to that same node. 553 Mapping traffic to the MP2MP LSP may happen at any leaf node. How 554 that mapping is established is outside the scope of this document. 556 Due to how a MP2MP LSP is built a leaf LSR that is sending packets on 557 the MP2MP LSP does not receive its own packets. There is also no 558 additional mechanism needed on the root or transit LSR to match 559 upstream traffic to the downstream forwarding state. Packets that 560 are forwarded over a MP2MP LSP will not traverse a link more than 561 once, with the possible exception of LAN links (see Section 4.3.1), 562 if the procedures of [I-D.ietf-mpls-upstream-label] are not provided. 564 4.1. Support for MP2MP LSP setup with LDP 566 Support for the setup of MP2MP LSPs is advertised using LDP 567 capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An 568 implementation supporting the MP2MP procedures specified in this 569 document MUST implement the procedures for Capability Parameters in 570 Initialization Messages. 572 A new Capability Parameter TLV is defined, the MP2MP Capability. 573 Following is the format of the MP2MP Capability Parameter. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |1|0| MP2MP Capability (TBD IANA) | Length (= 1) | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 |1| Reserved | 581 +-+-+-+-+-+-+-+-+ 583 The MP2MP Capability TLV MUST be supported in the LDP Initialization 584 Message. Advertisement of the MP2MP Capability indicates support of 585 the procedures for MP2MP LSP setup detailed in this document. If the 586 peer has not advertised the corresponding capability, then no label 587 messages using the MP2MP upstream and downstream FEC Elements should 588 be sent to the peer. 590 4.2. The MP2MP downstream and upstream FEC Elements. 592 For the setup of a MP2MP LSP with LDP we define 2 new protocol 593 entities, the MP2MP downstream FEC and upstream FEC Element. Both 594 elements will be used as FEC Elements in the FEC TLV. Note that the 595 MP2MP FEC Elements do not necessarily identify the traffic that must 596 be mapped to the LSP, so from that point of view, the use of the term 597 FEC is a misnomer. The description of the MP2MP FEC Elements follow. 599 The structure, encoding and error handling for the MP2MP downstream 600 and upstream FEC Elements are the same as for the P2MP FEC Element 601 described in Section 2.2. The difference is that two new FEC types 602 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 604 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 605 MUST be the only FEC Element in the FEC TLV. 607 Note, except when using the procedures of 608 [I-D.ietf-mpls-upstream-label], the MPLS labels used are "downstream- 609 assigned" [I-D.ietf-mpls-multicast-encaps], even if they are bound to 610 the "upstream FEC element". 612 4.3. Using the MP2MP FEC Elements 614 This section defines the rules for the processing and propagation of 615 the MP2MP FEC Elements. The following notation is used in the 616 processing rules: 618 1. MP2MP downstream LSP (or simply downstream ): an 619 MP2MP LSP downstream path with root node address X and opaque 620 value Y. 622 2. MP2MP upstream LSP (or simply upstream ): a 623 MP2MP LSP upstream path for downstream node D with root node 624 address X and opaque value Y. 626 3. MP2MP downstream FEC Element : a FEC Element with root 627 node address X and opaque value Y used for a downstream MP2MP 628 LSP. 630 4. MP2MP upstream FEC Element : a FEC Element with root node 631 address X and opaque value Y used for an upstream MP2MP LSP. 633 5. MP2MP-D Label Map : A Label Map message with a FEC TLV 634 with a single MP2MP downstream FEC Element and label TLV 635 with label L. 637 6. MP2MP-U Label Map : A Label Map message with a FEC TLV 638 with a single MP2MP upstream FEC Element and label TLV 639 with label Lu. 641 7. MP2MP-D Label Withdraw : a Label Withdraw message with 642 a FEC TLV with a single MP2MP downstream FEC Element and 643 label TLV with label L. 645 8. MP2MP-U Label Withdraw : a Label Withdraw message with 646 a FEC TLV with a single MP2MP upstream FEC Element and 647 label TLV with label Lu. 649 9. MP2MP-D Label Release : a Label Release message with a 650 FEC TLV with a single MP2MP downstream FEC Element and 651 label TLV with label L. 653 10. MP2MP-U Label Release : a Label Release message with a 654 FEC TLV with a single MP2MP upstream FEC Element and 655 label TLV with label Lu. 657 The procedures below are organized by the role which the node plays 658 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 659 process which is outside the scope of this document. During the 660 course of the protocol operation, the root node recognizes its role 661 because it owns the root node address. A transit node is any node 662 (other then the root node) that receives a MP2MP Label Map message 663 (i.e., one that has leaf nodes downstream of it). 665 Note that a transit node (and indeed the root node) may also be a 666 leaf node and the root node does not have to be an ingress LSR or 667 leaf of the MP2MP LSP. 669 4.3.1. MP2MP Label Map 671 The remainder of this section specifies the procedures for 672 originating MP2MP Label Map messages and for processing received 673 MP2MP label map messages for a particular LSP. The procedures for a 674 particular LSR depend upon the role that LSR plays in the LSP 675 (ingress, transit, or egress). 677 All labels discussed here are downstream-assigned 678 [I-D.ietf-mpls-multicast-encaps] except those which are assigned 679 using the procedures of Section 6. 681 4.3.1.1. Determining one's upstream MP2MP LSR 683 Determining the upstream LDP peer U for a MP2MP LSP follows 684 the procedure for a P2MP LSP described in Section 2.4.1.1. 686 4.3.1.2. Determining one's downstream MP2MP LSR 688 A LDP peer U which receives a MP2MP-D Label Map from a LDP peer D 689 will treat D as downstream MP2MP LSR. 691 4.3.1.3. Installing the upstream path of a MP2MP LSP 693 There are two methods for installing the upstream path of a MP2MP LSP 694 to a downstream neighbor. 696 1. We can install the upstream MP2MP path (to a downstream neighbor) 697 based on receiving a MP2MP-D Label Map from the downstream 698 neighbor. This will install the upstream path on a per hop by 699 hop bases. 701 2. We install the upstream MP2MP path (to a downstream neighbor) 702 based on receiving a MP2MP-U Label Map from the upstream 703 neighbor. An LSR does not need to wait for the MP2MP-U Label Map 704 if it is the root of the MP2MP LSP or already has received an 705 MP2MP-U Label Map from the upstream neighbor. We call this 706 method ordered mode. The typical result of this mode is that the 707 downstream path of the MP2MP is build hop by hop towards the 708 root. Once the root is reached, the root node will trigger a 709 MP2MP-U Label Map to the downstream neighbor(s). 711 For setting up the upstream path of a MP2MP LSP ordered mode MUST be 712 used. Due to ordered mode the upstream path of the MP2MP LSP is 713 installed at the leaf node once the path to the root is completed. 714 The advantage is that when a leaf starts sending immediately after 715 the upstream path is installed, packets are able to reach the root 716 node without being dropped due to an incomplete LSP. Method 1 is not 717 able to guarantee that the upstream path is completed before the leaf 718 starts sending. 720 4.3.1.4. MP2MP leaf node operation 722 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 723 as per Section 4.3.1.1, allocates a label L, and sends a 724 MP2MP-D Label Map to U. 726 Leaf node Z expects an MP2MP-U Label Map from node U in 727 response to the MP2MP-D Label Map it sent to node U. Z checks whether 728 it already has forwarding state for upstream . If not, Z 729 creates forwarding state to push label Lu onto the traffic that Z 730 wants to forward over the MP2MP LSP. How it determines what traffic 731 to forward on this MP2MP LSP is outside the scope of this document. 733 4.3.1.5. MP2MP transit node operation 735 When node Z receives a MP2MP-D Label Map from LSR D 736 associated with interface I, it checks whether it has forwarding 737 state for downstream . If not, Z determines its upstream LSR U 738 for as per Section 4.3.1.1. Using this Label Map to update 739 the label forwarding table MUST NOT be done as long as LSR D is equal 740 to LSR U. If LSR U is different from LSR D, Z will allocate a label 741 L' and install downstream forwarding state to swap label L' with 742 label L over interface I and send a MP2MP-D Label Map to 743 U. 745 If Z already has forwarding state for downstream , all that Z 746 needs to do in this case is check that LSR D is not equal to the 747 upstream LSR of and update its forwarding state. Assuming its 748 old forwarding state was L'-> { ..., }, its 749 new forwarding state becomes L'-> { ..., , 750 }. If the LSR D is equal to the installed upstream LSR, the 751 Label Map from LSR D MUST be retained and MUST not update the label 752 forwarding table. 754 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 756 Map from LSR U associated with interface Iu. See 757 Section 4.3.1.3. Once the MP2MP-U Label Map for Lu over interface Iu 758 is received from LSR U, node Z checks whether it already has 759 forwarding state upstream . If it does, then no further 760 action needs to happen. If it does not, it allocates a label Lu' and 761 creates a new label swap for Lu' with Label Lu over interface Iu. In 762 addition, it also adds the label swap(s) from the forwarding state 763 downstream , omitting the swap on interface I for node D. The 764 swap on interface I for node D is omitted to prevent packet 765 originated by D to be forwarded back to D. 767 Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2, 768 and sends a MP2MP-U Label Map to node D. 770 4.3.1.6. MP2MP root node operation 772 4.3.1.6.1. Root node is also a leaf 774 Suppose root/leaf node Z receives a MP2MP-D Label Map from 775 node D associated with interface I. Z checks whether it already has 776 forwarding state downstream . If not, Z creates forwarding 777 state for downstream to push label L on traffic that Z wants to 778 forward down the MP2MP LSP. How it determines what traffic to 779 forward on this MP2MP LSP is outside the scope of this document. If 780 Z already has forwarding state for downstream , then Z will add 781 the label push for L over interface I to it. 783 Node Z checks if it has forwarding state for upstream If 784 not, Z allocates a label Lu' and creates upstream forwarding state to 785 push Lu' with the label push(s) from the forwarding state downstream 786 , except the push on interface I for node D. This allows 787 upstream traffic to go down the MP2MP to other node(s), except the 788 node from which the traffic was received. Node Z determines the 789 downstream MP2MP LSR as per section Section 4.3.1.2, and sends a 790 MP2MP-U Label Map to node D. Since Z is the root of the 791 tree Z will not send a MP2MP-D Label Map and will not receive a 792 MP2MP-U Label Map. 794 4.3.1.6.2. Root node is not a leaf 796 Suppose the root node Z receives a MP2MP-D Label Map from 797 node D associated with interface I. Z checks whether it already has 798 forwarding state for downstream . If not, Z creates downstream 799 forwarding state and installs a outgoing label L over interface I. If 800 Z already has forwarding state for downstream , then Z will add 801 label L over interface I to the existing state. 803 Node Z checks if it has forwarding state for upstream . If 804 not, Z allocates a label Lu' and creates forwarding state to swap Lu' 805 with the label swap(s) from the forwarding state downstream , 806 except the swap for node D. This allows upstream traffic to go down 807 the MP2MP to other node(s), except the node is was received from. 808 Root node Z determines the downstream MP2MP LSR D as per 809 Section 4.3.1.2, and sends a MP2MP-U Label Map to it. 810 Since Z is the root of the tree Z will not send a MP2MP-D Label Map 811 and will not receive a MP2MP-U Label Map. 813 4.3.2. MP2MP Label Withdraw 815 The following lists procedures for generating and processing MP2MP 816 Label Withdraw messages for nodes that participate in a MP2MP LSP. 817 An LSR should apply those procedures that apply to it, based on its 818 role in the MP2MP LSP. 820 4.3.2.1. MP2MP leaf operation 822 If a leaf node Z discovers (by means outside the scope of this 823 document) that it has no downstream neighbors in that LSP, and that 824 it has no need to be an egress LSR for that LSP, then it SHOULD send 825 a MP2MP-D Label Withdraw to its upstream LSR U for , 826 where L is the label it had previously advertised to U for . 827 Leaf node Z will also send a unsolicited label release to 828 U to indicate that the upstream path is no longer used and that Label 829 Lu can be removed. 831 Leaf node Z expects the upstream router U to respond by sending a 832 downstream label release for L. 834 4.3.2.2. MP2MP transit node operation 836 If a transit node Z receives a MP2MP-D Label Withdraw message from node D, it deletes label L from its forwarding state 838 downstream and from all its upstream states for . Node 839 Z sends a MP2MP-D Label Release message with label L to D. Since node 840 D is no longer part of the downstream forwarding state, Z cleans up 841 the forwarding state upstream . There is no need to send an 842 MP2MP-U Label Withdraw to D because node D already removed 843 Lu and send a label release for Lu to Z. 845 If deleting L from Z's forwarding state for downstream results 846 in no state remaining for , then Z propagates the MP2MP-D Label 847 Withdraw to its upstream node U for and will also 848 send a unsolicited MP2MP-U Label Release to U to indicate 849 that the upstream path is no longer used and that Label Lu can be 850 removed. 852 4.3.2.3. MP2MP root node operation 854 The procedure when the root node of a MP2MP LSP receives a MP2MP-D 855 Label Withdraw message is the same as for transit nodes, except that 856 the root node would not propagate the Label Withdraw upstream (as it 857 has no upstream). 859 4.3.3. MP2MP Upstream LSR change 861 The procedure for changing the upstream LSR is the same as documented 862 in Section 2.4.3, except it is applied to MP2MP FECs, using the 863 procedures described in Section 4.3.1 through Section 4.3.2.3. 865 5. The LDP MP Status TLV 867 An LDP MP capable router MAY use an LDP MP Status TLV to indicate 868 additional status for a MP LSP to its remote peers. This includes 869 signaling to peers that are either upstream or downstream of the LDP 870 MP capable router. The value of the LDP MP status TLV will remain 871 opaque to LDP and MAY encode one or more status elements. 873 The LDP MP Status TLV is encoded as follows: 875 0 1 2 3 876 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 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 |1|0| LDP MP Status Type(TBD) | Length | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Value | 881 ~ ~ 882 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. 888 Length: Length of the LDP MP Status Value in octets. 890 Value: One or more LDP MP Status Value elements. 892 5.1. The LDP MP Status Value Element 894 The LDP MP Status Value Element that is included in the LDP MP Status 895 TLV Value has the following encoding. 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Type(TBD) | Length | Value ... | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 902 ~ ~ 903 | | 904 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Type: The type of the LDP MP Status Value Element is to be assigned 910 by IANA. 912 Length: The length of the Value field, in octets. 914 Value: String of Length octets, to be interpreted as specified by 915 the Type field. 917 5.2. LDP Messages containing LDP MP Status messages 919 The LDP MP status message may appear either in a label mapping 920 message or a LDP notification message. 922 5.2.1. LDP MP Status sent in LDP notification messages 924 An LDP MP status TLV sent in a notification message must be 925 accompanied with a Status TLV. The general format of the 926 Notification Message with an LDP MP status TLV is: 928 0 1 2 3 929 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 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 |0| Notification (0x0001) | Message Length | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Message ID | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Status TLV | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | LDP MP Status TLV | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Optional LDP MP FEC TLV | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Optional Label TLV | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 The Status TLV status code is used to indicate that LDP MP status TLV 945 and an additional information follows in the Notification message's 946 "optional parameter" section. Depending on the actual contents of 947 the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may 948 also be present to provide context to the LDP MP Status TLV. (NOTE: 949 Status Code is pending IANA assignment). 951 Since the notification does not refer to any particular message, the 952 Message Id and Message Type fields are set to 0. 954 5.2.2. LDP MP Status TLV in Label Mapping Message 956 An example of the Label Mapping Message defined in RFC3036 is shown 957 below to illustrate the message with an Optional LDP MP Status TLV 958 present. 960 0 1 2 3 961 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 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 |0| Label Mapping (0x0400) | Message Length | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Message ID | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | FEC TLV | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Label TLV | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Optional LDP MP Status TLV | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Additional Optional Parameters | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 6. Upstream label allocation on a LAN 978 On a LAN, the procedures so far discussed would require the upstream 979 LSR to send a copy of the packet to each receiver individually. If 980 there is more then one receiver on the LAN we don't take full benefit 981 of the multi-access capability of the network. We may optimize the 982 bandwidth consumption on the LAN and replication overhead on the 983 upstream LSR by using upstream label allocation 984 [I-D.ietf-mpls-upstream-label]. Procedures on how to distribute 985 upstream labels using LDP is documented in 986 [I-D.ietf-mpls-ldp-upstream]. 988 6.1. LDP Multipoint-to-Multipoint on a LAN 990 The procedure to allocate a context label on a LAN is defined in 991 [I-D.ietf-mpls-upstream-label]. That procedure results in each LSR 992 on a given LAN having a context label which, on that LAN, can be used 993 to identify itself uniquely. Each LSR advertises its context label 994 as an upstream-assigned label, following the procedures of 995 [I-D.ietf-mpls-ldp-upstream]. Any LSR for which the LAN is a 996 downstream link on some P2MP or MP2MP LSP will allocate an upstream- 997 assigned label identifying that LSP. When the LSR forwards a packet 998 downstream on one of those LSPs, the packet's top label must be the 999 LSR's context label, and the packet's second label is the label 1000 identifying the LSP. We will call the top label the "upstream LSR 1001 label" and the second label the "LSP label". 1003 6.1.1. MP2MP downstream forwarding 1005 The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so 1006 we will use the same procedures as defined in 1007 [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is 1008 send to the upstream LSR. The label mapping that is received from 1009 the upstream LSR contains the LSP label for the MP2MP FEC and the 1010 upstream LSR context label. The MP2MP downstream path (corresponding 1011 to the LSP label) will be installed the context specific forwarding 1012 table corresponding to the upstream LSR label. Packets sent by the 1013 upstream router can be forwarded downstream using this forwarding 1014 state based on a two label lookup. 1016 6.1.2. MP2MP upstream forwarding 1018 A MP2MP LSP also has an upstream forwarding path. Upstream packets 1019 need to be forwarded in the direction of the root and downstream on 1020 any node on the LAN that has a downstream interface for the LSP. For 1021 a given MP2MP LSP on a given LAN, exactly one LSR is considered to be 1022 the upstream LSR. If an LSR on the LAN receives a packet from one of 1023 its downstream interfaces for the LSP, and if it needs to forward the 1024 packet onto the LAN, it ensures that the packet's top label is the 1025 context label of the upstream LSR, and that its second label is the 1026 LSP label that was assigned by the upstream LSR. 1028 Other LSRs receiving the packet will not be able to tell whether the 1029 packet really came from the upstream router, but that makes no 1030 difference in the processing of the packet. The upstream LSR will 1031 see its own upstream LSR in the label, and this will enable it to 1032 determine that the packet is traveling upstream. 1034 7. Root node redundancy 1036 The root node is a single point of failure for an MP LSP, whether 1037 this is P2MP or MP2MP. The problem is particularly severe for MP2MP 1038 LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same 1039 root node to set up the MP2MP LSP, because otherwise the traffic 1040 sourced by some leafs is not received by others. Because the root 1041 node is the single point of failure for an MP LSP, we need a fast and 1042 efficient mechanism to recover from a root node failure. 1044 An MP LSP is uniquely identified in the network by the opaque value 1045 and the root node address. It is likely that the root node for an MP 1046 LSP is defined statically. The root node address may be configured 1047 on each leaf statically or learned using a dynamic protocol. How 1048 leafs learn about the root node is out of the scope of this document. 1050 Suppose that for the same opaque value we define two (or more) root 1051 node addresses and we build a tree to each root using the same opaque 1052 value. Effectively these will be treated as different MP LSPs in the 1053 network. Once the trees are built, the procedures differ for P2MP 1054 and MP2MP LSPs. The different procedures are explained in the 1055 sections below. 1057 7.1. Root node redundancy - procedures for P2MP LSPs 1059 Since all leafs have set up P2MP LSPs to all the roots, they are 1060 prepared to receive packets on either one of these LSPs. However, 1061 only one of the roots should be forwarding traffic at any given time, 1062 for the following reasons: 1) to achieve bandwidth savings in the 1063 network and 2) to ensure that the receiving leafs don't receive 1064 duplicate packets (since one cannot assume that the receiving leafs 1065 are able to discard duplicates). How the roots determine which one 1066 is the active sender is outside the scope of this document. 1068 7.2. Root node redundancy - procedures for MP2MP LSPs 1070 Since all leafs have set up an MP2MP LSP to each one of the root 1071 nodes for this opaque value, a sending leaf may pick either of the 1072 two (or more) MP2MP LSPs to forward a packet on. The leaf nodes 1073 receive the packet on one of the MP2MP LSPs. The client of the MP2MP 1074 LSP does not care on which MP2MP LSP the packet is received, as long 1075 as they are for the same opaque value. The sending leaf MUST only 1076 forward a packet on one MP2MP LSP at a given point in time. The 1077 receiving leafs are unable to discard duplicate packets because they 1078 accept on all LSPs. Using all the available MP2MP LSPs we can 1079 implement redundancy using the following procedures. 1081 A sending leaf selects a single root node out of the available roots 1082 for a given opaque value. A good strategy MAY be to look at the 1083 unicast routing table and select a root that is closest in terms of 1084 the unicast metric. As soon as the root address of the active root 1085 disappears from the unicast routing table (or becomes less 1086 attractive) due to root node or link failure, the leaf can select a 1087 new best root address and start forwarding to it directly. If 1088 multiple root nodes have the same unicast metric, the highest root 1089 node addresses MAY be selected, or per session load balancing MAY be 1090 done over the root nodes. 1092 All leafs participating in a MP2MP LSP MUST join to all the available 1093 root nodes for a given opaque value. Since the sending leaf may pick 1094 any MP2MP LSP, it must be prepared to receive on it. 1096 The advantage of pre-building multiple MP2MP LSPs for a single opaque 1097 value is that convergence from a root node failure happens as fast as 1098 the unicast routing protocol is able to notify. There is no need for 1099 an additional protocol to advertise to the leaf nodes which root node 1100 is the active root. The root selection is a local leaf policy that 1101 does not need to be coordinated with other leafs. The disadvantage 1102 of pre-building multiple MP2MP LSPs is that more label resources are 1103 used, depending on how many root nodes are defined. 1105 8. MP2MP micro loop prevention 1107 A MP LSP is built hop by hop following the best path to reach the 1108 root of the LSP. If the routing protocol used to calculate the best 1109 path is subjected to micro-loops, the MP LSP may contain a micro 1110 loop. Both P2MP and MP2MP LSPs may end up containing a micro-loop. 1111 However, there is a difference between loops in P2MP and MP2MP LSP. 1112 In a P2MP LSP, once a loop s formed, no new packet can enter it, but 1113 in a MP2MP LSP, packets may continue to enter the loop. This makes a 1114 loop in MP2MP LSP worse compared to loop in P2MP LSP. If the routing 1115 protocol is not subjected to micro-loops, the MP LSP will not end up 1116 in a micro-loop and no additional procedures are necessary. The 1117 following section describes procedures that MAY be applied to prevent 1118 micro-loops in MP2MP LSPs in case the routing protocol is not able to 1119 guarantee a loop-free best path selection. 1121 8.1. MP2MP upstream path 1123 A MP2MP LSP has multiple injection points, there is one injection 1124 point from the root down the LSP towards the leafs, which is the same 1125 as a P2MP LSP. Other injection point(s) are from each leaf towards 1126 the root of the LSP. These procedures solve micro-loops which are 1127 the result of injecting packets from the leaf towards the root. It 1128 does not solve micro-loops which are the result of injecting packets 1129 from the root. This makes the MP2MP LSP as good as P2MP LSPs. 1131 8.2. MP2MP micro loop prevention procedures 1133 Based on the procedures defined in Section 4.3.1.3 ordered mode is 1134 used to build the upstream path from the root down to the leaves. 1135 The MP2MP-U Label Map will add a path vector TLV [RFC5036] as 1136 optional parameter to the MP2MP-U Label Map message. Each LSR will 1137 add its own router ID to the path list TLV before sending the MP2MP-U 1138 Label Map to the downstream LSRs. Suppose node Z receives 1139 a MP2MP-U Label Map from LSR D with Label Lu. If node Z finds its 1140 own router ID in the path vector list it will complete the procedures 1141 for MP2MP LSP's defined in this draft with the following exception, 1142 the Label Forwarding Database for the MP2MP upstream with 1143 Lu is not installed, but is retained. By not installing Label Lu the 1144 loop is prevented. If node Z receives a MP2MP-U Label Map that 1145 updates the path vector list such that it does not include its own 1146 router ID, Label Lu can be safely installed into forwarding. 1148 9. Make Before Break (MBB) 1150 An LSR selects as its upstream LSR for a MP LSP the LSR that is its 1151 next hop to the root of the LSP. When the best path to reach the 1152 root changes the LSR must choose a new upstream LSR. Sections 1153 Section 2.4.3 and Section 4.3.3 describe these procedures. 1155 When the best path to the root changes the LSP may be broken 1156 temporarily resulting in packet loss until the LSP "reconverges" to a 1157 new upstream LSR. The goal of MBB when this happens is to keep the 1158 duration of packet loss as short as possible. In addition, there are 1159 scenarios where the best path from the LSR to the root changes but 1160 the LSP continues to forward packets to the prevous next hop to the 1161 root. That may occur when a link comes up or routing metrics change. 1163 In such a case a new LSP should be established before the old LSP is 1164 removed to limit the duration of packet loss. The procedures 1165 described below deal with both scenarios in a way that an LSR does 1166 not need to know which of the events described above caused its 1167 upstream router for an MBB LSP to change. 1169 This MBB procedures are an optional extension to the MP LSP building 1170 procedures described in this draft. 1172 9.1. MBB overview 1174 The MBB procedues use additional LDP signaling. 1176 Suppose some event causes a downstream LSR-D to select a new upstream 1177 LSR-U for FEC-A. The new LSR-U may already be forwarding packets for 1178 FEC-A; that is, to downstream LSR's other than LSR-D. After LSR-U 1179 receives a label for FEC-A from LSR-D, it will notify LSR-D when it 1180 knows that the LSP for FEC-A has been established from the root to 1181 itself. When LSR-D receives this MBB notification it will change its 1182 next hop for the LSP root to LSR-U. 1184 The assumption is that if LSR-U has received an MBB notification from 1185 its upstream router for the FEC-A LSP and has installed forwarding 1186 state the LSP it is capable of forwarding packets on the LSP. At 1187 that point LSR-U should signal LSR-D by means of an MBB notification 1188 that it has become part of the tree identified by FEC-A and that 1189 LSR-D should initiate its switchover to the LSP. 1191 At LSR-U the LSP for FEC-A may be in 1 of 3 states. 1193 1. There is no state for FEC-A. 1195 2. State for FEC-A exists and LSR-U is waiting for MBB notification 1196 that the LSP from the root to it exists. 1198 3. State for FEC-A exists and the MBB notification has been 1199 received. 1201 After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U 1202 MUST NOT reply with an MBB notification to LSR-D until its state for 1203 the LSP is state #3 above. If the state of the LSP at LSR-U is state 1204 #1 or #2, LSR-U should remember receipt of the Label Mapping message 1205 from LSR-D while waiting for an MBB notification from its upstream 1206 LSR for the LSP. When LSR-U receives the MBB notification from its 1207 upstream LSR it transitions to LSP state #3 and sends an MBB 1208 notification to LSR-D. 1210 9.2. The MBB Status code 1212 As noted in Section 9.1, the procedures to establish an MBB MP LSP 1213 are different from those to establish normal MP LSPs. 1215 When a downstream LSR sends a Label Mapping message for MP LSP to its 1216 upstream LSR it MAY include an LDP MP Status TLV that carries a MBB 1217 Status Code to indicate MBB procedures apply to the LSP. This new 1218 MBB Status Code MAY also appear in an LDP Notification message used 1219 by an upstream LSR to signal LSP state #3 to the downstream LSR; that 1220 is, that the upstream LSR's state for the LSP exists and that it has 1221 received notification from its upstream LSR that the LSP is in state 1222 #3. 1224 The MBB Status is a type of the LDP MP Status Value Element as 1225 described in Section 5.1. It is encoded as follows: 1227 0 1 2 3 1228 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 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | MBB Type = 1 | Length = 1 | Status code | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 MBB Type: Type 1 (to be assigned by IANA) 1235 Length: 1 1237 Status code: 1 = MBB request 1239 2 = MBB ack 1241 9.3. The MBB capability 1243 An LSR MAY advertise that it is capable of handling MBB LSPs using 1244 the capability advertisement as defined in 1245 [I-D.ietf-mpls-ldp-capabilities]. The LDP MP MBB capability has the 1246 following format: 1248 0 1 2 3 1249 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 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 |1|0| LDP MP MBB Capability | Length = 1 | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 |1| Reserved | 1254 +-+-+-+-+-+-+-+-+ 1256 Note: LDP MP MBB Capability (Pending IANA assignment) 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 |1|0| LDP MP MBB Capability | Length = 1 | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 |1| Reserved | 1264 +-+-+-+-+-+-+-+-+ 1266 If an LSR has not advertised that it is MBB capable, its LDP peers 1267 MUST NOT send it messages which include MBB parameters. If an LSR 1268 receives a Label Mapping message with a MBB parameter from downstream 1269 LSR-D and its upstream LSR-U has not advertised that it is MBB 1270 capable, the LSR MUST send an MBB notification immediatly to LSR-U 1271 (see Section 9.4). If this happens an MBB MP LSP will not be 1272 established, but normal a MP LSP will be the result. 1274 9.4. The MBB procedures 1276 9.4.1. Terminology 1278 1. MBB LSP : A P2MP or MP2MP Make Before Break (MBB) LSP entry 1279 with Root Node Address X and Opaque Value Y. 1281 2. A(N, L): An Accepting element that consists of an upstream 1282 Neighbor N and Local label L. This LSR assigned label L to 1283 neighbor N for a specific MBB LSP. For an active element the 1284 corresponding Label is stored in the label forwarding database. 1286 3. iA(N, L): An inactive Accepting element that consists of an 1287 upstream neighbor N and local Label L. This LSR assigned label L 1288 to neighbor N for a specific MBB LSP. For an inactive element 1289 the corresponding Label is not stored in the label forwarding 1290 database. 1292 4. F(N, L): A Forwarding state that consists of downstream Neighbor 1293 N and Label L. This LSR is sending label packets with label L to 1294 neighbor N for a specific FEC. 1296 5. F'(N, L): A Forwarding state that has been marked for sending a 1297 MBB Notification message to Neighbor N with Label L. 1299 6. MBB Notification : A LDP notification message with a MP 1300 LSP , Label L and MBB Status code 2. 1302 7. MBB Label Map : A P2MP Label Map or MP2MP Label Map 1303 downstream with a FEC element , Label L and MBB Status code 1304 1. 1306 9.4.2. Accepting elements 1308 An accepting element represents a specific label value L that has 1309 been advertised to a neighbor N for a MBB LSP and is a 1310 candidate for accepting labels switched packets on. An LSR can have 1311 two accepting elements for a specific MBB LSP LSP, only one of 1312 them MUST be active. An active element is the element for which the 1313 label value has been installed in the label forwarding database. An 1314 inactive accepting element is created after a new upstream LSR is 1315 chosen and is pending to replace the active element in the label 1316 forwarding database. Inactive elements only exist temporarily while 1317 switching to a new upstream LSR. Once the switch has been completed 1318 only one active element remains. During network convergence it is 1319 possible that an inactive accepting element is created while an other 1320 inactive accepting element is pending. If that happens the older 1321 inactive accepting element MUST be replaced with an newer inactive 1322 element. If an accepting element is removed a Label Withdraw has to 1323 be send for label L to neighbor N for . 1325 9.4.3. Procedures for upstream LSR change 1327 Suppose a node Z has a MBB LSP with an active accepting 1328 element A(N1, L1). Due to a routing change it detects a new best 1329 path for root X and selects a new upstream LSR N2. Node Z allocates 1330 a new local label L2 and creates an inactive accepting element iA(N2, 1331 L2). Node Z sends MBB Label Map to N2 and waits for the 1332 new upstream LSR N2 to respond with a MBB Notification for . During this transition phase there are two accepting elements, 1334 the element A(N1, L1) still accepting packets from N1 over label L1 1335 and the new inactive element iA(N2, L2). 1337 While waiting for the MBB Notification from upstream LSR N2, it is 1338 possible that an other transition occurs due to a routing change. 1339 Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) 1340 is created and the old inactive element iA(N2, L2) MUST be removed. 1341 A label withdraw MUST be sent to N2 for from N2 will be ignored because the 1343 inactive element is removed. 1345 It is possible that the MBB Notification from upstream LSR is never 1346 received due to link or node failure. To prevent waiting 1347 indefinitely for the MBB Notification a timeout SHOULD be applied. 1348 As soon as the timer expires, the procedures in Section 9.4.5 are 1349 applied as if a MBB Notification was received for the inactive 1350 element. 1352 9.4.4. Receiving a Label Map with MBB status code 1354 Suppose node Z has state for a MBB LSP and receives a MBB 1355 Label Map from N2. A new forwarding state F(N2, L2) will 1356 be added to the MP LSP if it did not already exist. If this MBB LSP 1357 has an active accepting element or node Z is the root of the MBB LSP 1358 a MBB notification is send to node N2. If node Z has an 1359 inactive accepting element it marks the Forwarding state as . 1362 9.4.5. Receiving a Notification with MBB status code 1364 Suppose node Z receives a MBB Notification from N. If node 1365 Z has state for MBB LSP and an inactive accepting element 1366 iA(N, L) that matches with N and L, we activate this accepting 1367 element and install label L in the label forwarding database. If an 1368 other active accepting was present it will be removed from the label 1369 forwarding database. 1371 If this MBB LSP also has Forwarding states marked for sending 1372 MBB Notifications, like , MBB Notifications are 1373 send to these downstream LSRs. If node Z receives a MBB Notification 1374 for an accepting element that is not inactive or does not match the 1375 Label value and Neighbor address, the MBB notification is ignored. 1377 9.4.6. Node operation for MP2MP LSPs 1379 The procedures described above apply to the downstream path of a 1380 MP2MP LSP. The upstream path of the MP2MP is setup as normal without 1381 including a MBB Status code. If the MBB procedures apply to a MP2MP 1382 downstream FEC element, the upstream path to a node N is only 1383 installed in the label forwarding database if node N is part of the 1384 active accepting element. If node N is part of an inactive accepting 1385 element, the upstream path is installed when this inactive accepting 1386 element is activated. 1388 10. Security Considerations 1390 The same security considerations apply as for the base LDP 1391 specification, as described in [RFC5036]. 1393 11. IANA considerations 1395 This document creates a new name space (the LDP MP Opaque Value 1396 Element type) that is to be managed by IANA, and the allocation of 1397 the value 1 for the type of Generic LSP Identifier. 1399 This document requires allocation of three new LDP FEC Element types: 1401 1. the P2MP FEC type - requested value 0x06 1403 2. the MP2MP-up FEC type - requested value 0x07 1405 3. the MP2MP-down FEC type - requested value 0x08 1407 This document requires the assignment of three new code points for 1408 three new Capability Parameter TLVs, corresponding to the 1409 advertisement of the P2MP, MP2MP and MBB capabilities. The values 1410 requested are: 1412 P2MP Capability Parameter - requested value 0x0508 1414 MP2MP Capability Parameter - requested value 0x0509 1416 MBB Capability Parameter - requested value 0x050A 1418 This document requires the assignment of a LDP Status TLV code to 1419 indicate a LDP MP Status TLV is following in the Notification 1420 message. The value requested is: 1422 LDP MP status - requested value 0x0000002D 1424 This document requires the assigment of a new code point for a LDP MP 1425 Status TLV. The value requested is: 1427 LDP MP Status TLV Type - requested value 0x096D 1429 This document creates a new name space (the LDP MP Status Value 1430 Element type) that is to be managed by IANA, and the allocation of 1431 the value 1 for the type of MBB Status. 1433 12. Acknowledgments 1435 The authors would like to thank the following individuals for their 1436 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 1437 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, 1438 George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas 1439 Morin. 1441 13. Contributing authors 1443 Below is a list of the contributing authors in alphabetical order: 1445 Shane Amante 1446 Level 3 Communications, LLC 1447 1025 Eldorado Blvd 1448 Broomfield, CO 80021 1449 US 1450 Email: Shane.Amante@Level3.com 1452 Luyuan Fang 1453 Cisco Systems 1454 300 Beaver Brook Road 1455 Boxborough, MA 01719 1456 US 1457 Email: lufang@cisco.com 1459 Hitoshi Fukuda 1460 NTT Communications Corporation 1461 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1462 Tokyo 100-8019, 1463 Japan 1464 Email: hitoshi.fukuda@ntt.com 1466 Yuji Kamite 1467 NTT Communications Corporation 1468 Tokyo Opera City Tower 1469 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1470 Tokyo 163-1421, 1471 Japan 1472 Email: y.kamite@ntt.com 1474 Kireeti Kompella 1475 Juniper Networks 1476 1194 N. Mathilda Ave. 1477 Sunnyvale, CA 94089 1478 US 1479 Email: kireeti@juniper.net 1480 Ina Minei 1481 Juniper Networks 1482 1194 N. Mathilda Ave. 1483 Sunnyvale, CA 94089 1484 US 1485 Email: ina@juniper.net 1487 Jean-Louis Le Roux 1488 France Telecom 1489 2, avenue Pierre-Marzin 1490 Lannion, Cedex 22307 1491 France 1492 Email: jeanlouis.leroux@francetelecom.com 1494 Bob Thomas 1495 Cisco Systems, Inc. 1496 300 Beaver Brook Road 1497 Boxborough, MA, 01719 1498 E-mail: bobthomas@alum.mit.edu 1500 Lei Wang 1501 Telenor 1502 Snaroyveien 30 1503 Fornebu 1331 1504 Norway 1505 Email: lei.wang@telenor.com 1507 IJsbrand Wijnands 1508 Cisco Systems, Inc. 1509 De kleetlaan 6a 1510 1831 Diegem 1511 Belgium 1512 E-mail: ice@cisco.com 1514 14. References 1516 14.1. Normative References 1518 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1519 Specification", RFC 5036, October 2007. 1521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1522 Requirement Levels", BCP 14, RFC 2119, March 1997. 1524 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1525 an On-line Database", RFC 3232, January 2002. 1527 [I-D.ietf-mpls-upstream-label] 1528 Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1529 Label Assignment and Context-Specific Label Space", 1530 draft-ietf-mpls-upstream-label-05 (work in progress), 1531 April 2008. 1533 [I-D.ietf-mpls-ldp-upstream] 1534 Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment 1535 for LDP", draft-ietf-mpls-ldp-upstream-02 (work in 1536 progress), November 2007. 1538 [I-D.ietf-mpls-ldp-capabilities] 1539 Thomas, B., "LDP Capabilities", 1540 draft-ietf-mpls-ldp-capabilities-02 (work in progress), 1541 March 2008. 1543 14.2. Informative References 1545 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1546 Private Networks (L2VPNs)", RFC 4664, September 2006. 1548 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1549 "Extensions to Resource Reservation Protocol - Traffic 1550 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1551 Switched Paths (LSPs)", RFC 4875, May 2007. 1553 [I-D.ietf-mpls-mp-ldp-reqs] 1554 Roux, J., "Requirements for Point-To-Multipoint Extensions 1555 to the Label Distribution Protocol", 1556 draft-ietf-mpls-mp-ldp-reqs-04 (work in progress), 1557 February 2008. 1559 [I-D.ietf-l3vpn-2547bis-mcast] 1560 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 1561 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 1562 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work 1563 in progress), January 2008. 1565 [I-D.ietf-mpls-multicast-encaps] 1566 Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 1567 Multicast Encapsulations", 1568 draft-ietf-mpls-multicast-encaps-09 (work in progress), 1569 May 2008. 1571 Authors' Addresses 1573 Ina Minei 1574 Juniper Networks 1575 1194 N. Mathilda Ave. 1576 Sunnyvale, CA 94089 1577 US 1579 Email: ina@juniper.net 1581 Kireeti Kompella 1582 Juniper Networks 1583 1194 N. Mathilda Ave. 1584 Sunnyvale, CA 94089 1585 US 1587 Email: kireeti@juniper.net 1589 IJsbrand Wijnands 1590 Cisco Systems, Inc. 1591 De kleetlaan 6a 1592 Diegem 1831 1593 Belgium 1595 Email: ice@cisco.com 1597 Bob Thomas 1598 Cisco Systems, Inc. 1599 300 Beaver Brook Road 1600 Boxborough 01719 1601 US 1603 Email: bobthomas@alum.mit.edu