idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 -- 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 (February 17, 2011) is 4809 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) == Unused Reference: 'RFC4664' is defined on line 1596, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mp-ldp-reqs-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Minei, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track IJ. Wijnands, Ed. 5 Expires: August 21, 2011 Cisco Systems, Inc. 6 K. Kompella 7 Juniper Networks 8 B. Thomas 9 Cisco Systems, Inc. 10 February 17, 2011 12 Label Distribution Protocol Extensions for Point-to-Multipoint and 13 Multipoint-to-Multipoint Label Switched Paths 14 draft-ietf-mpls-ldp-p2mp-12 16 Abstract 18 This document describes extensions to the Label Distribution Protocol 19 (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- 20 multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol 21 Label Switching (MPLS) networks. These extensions are also referred 22 to as Multicast LDP (mLDP). mLDP constructs the P2MP or MP2MP LSPs 23 without interacting with or relying upon any other multicast tree 24 construction protocol. Protocol elements and procedures for this 25 solution are described for building such LSPs in a receiver-initiated 26 manner. There can be various applications for P2MP/MP2MP LSPs, for 27 example IP multicast or support for multicast in BGP/MPLS L3VPNs. 28 Specification of how such applications can use a LDP signaled P2MP/ 29 MP2MP LSPs is outside the scope of this document. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on August 21, 2011. 54 Copyright Notice 56 Copyright (c) 2011 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.1. Conventions used in this document . . . . . . . . . . . . 4 85 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 86 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 5 87 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 5 88 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6 89 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 8 90 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 9 91 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 10 92 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 10 93 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 12 94 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 13 95 3. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 13 96 3.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 14 97 3.2. The MP2MP downstream and upstream FEC Elements. . . . . . 15 98 3.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15 99 3.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 16 100 3.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 20 101 3.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 21 102 4. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 21 103 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21 104 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22 105 5.2. LDP Messages containing LDP MP Status messages . . . . . . 23 106 5.2.1. LDP MP Status sent in LDP notification messages . . . 23 107 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23 108 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24 109 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24 110 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24 111 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 25 112 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 113 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 26 114 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 115 8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 27 116 8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 117 8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 118 8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 29 119 8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 120 8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 121 8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 122 8.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 123 8.4.4. Receiving a Label Map with MBB status code . . . . . . 31 124 8.4.5. Receiving a Notification with MBB status code . . . . 31 125 8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 32 126 9. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 32 127 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 128 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 129 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 130 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 34 131 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 132 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 133 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 136 1. Introduction 138 The LDP protocol is described in [RFC5036]. It defines mechanisms 139 for setting up point-to-point (P2P) and multipoint-to-point (MP2P) 140 LSPs in the network. This document describes extensions to LDP for 141 setting up point-to-multipoint (P2MP) and multipoint-to-multipoint 142 (MP2MP) LSPs. These are collectively referred to as multipoint LSPs 143 (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) 144 node to be delivered to a number of leaf (or egress) nodes. A MP2MP 145 LSP allows traffic from multiple ingress nodes to be delivered to 146 multiple egress nodes. Only a single copy of the packet will be sent 147 on any link traversed by the MP LSP (see note at end of 148 Section 2.4.1). This is accomplished without the use of a multicast 149 protocol in the network. There can be several MP LSPs rooted at a 150 given ingress node, each with its own identifier. 152 The solution assumes that the leaf nodes of the MP LSP know the root 153 node and identifier of the MP LSP to which they belong. The 154 mechanisms for the distribution of this information are outside the 155 scope of this document. The specification of how an application can 156 use a MP LSP signaled by LDP is also outside the scope of this 157 document. 159 Related documents that may be of interest include 160 [I-D.ietf-mpls-mp-ldp-reqs], [I-D.ietf-l3vpn-2547bis-mcast] and 161 [RFC4875]. 163 1.1. Conventions used in this document 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 1.2. Terminology 171 Some of the following terminology is taken from 172 [I-D.ietf-mpls-mp-ldp-reqs]. 174 mLDP: Multicast extensions for LDP. 176 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 178 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 179 LSRs. 181 MP2P LSP: An LSP that has one or more Ingress LSRs and one unique 182 Egress LSR. 184 MP2MP LSP: An LSP that connects a set of nodes, such that traffic 185 sent by any node in the LSP is delivered to all others. 187 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 189 Ingress LSR: An ingress LSR for a particular LSP is an LSR that can 190 send a data packet along the LSP. MP2MP LSPs can have multiple 191 ingress LSRs, P2MP LSPs have just one, and that node is often 192 referred to as the "root node". 194 Egress LSR: An egress LSR for a particular LSP is an LSR that can 195 remove a data packet from that LSP for further processing. P2P 196 and MP2P LSPs have only a single egress node, but P2MP and MP2MP 197 LSPs can have multiple egress nodes. 199 Transit LSR: An LSR that has reachability to the root of the MP LSP 200 via a directly connected upstream LSR and one or more directly 201 connected downstream LSRs. 203 Bud LSR: An LSR that is an egress but also has one or more directly 204 connected downstream LSRs. 206 Leaf node: A Leaf node can be either an Egress or Bud LSR when 207 referred in the context of a P2MP LSP. In the context of a MP2MP 208 LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and 209 can also be a Bud LSR. 211 2. Setting up P2MP LSPs with LDP 213 A P2MP LSP consists of a single root node, zero or more transit nodes 214 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 215 tear-down. Leaf nodes also install forwarding state to deliver the 216 traffic received on a P2MP LSP to wherever it needs to go; how this 217 is done is outside the scope of this document. Transit nodes install 218 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 219 down) toward the root. The root node installs forwarding state to 220 map traffic into the P2MP LSP; how the root node determines which 221 traffic should go over the P2MP LSP is outside the scope of this 222 document. 224 2.1. Support for P2MP LSP setup with LDP 226 Support for the setup of P2MP LSPs is advertised using LDP 227 capabilities as defined in [RFC5561]. An implementation supporting 228 the P2MP procedures specified in this document MUST implement the 229 procedures for Capability Parameters in Initialization Messages. 231 A new Capability Parameter TLV is defined, the P2MP Capability. 232 Following is the format of the P2MP Capability Parameter. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |1|0| P2MP Capability (TBD IANA)| Length (= 1) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |1| Reserved | 240 +-+-+-+-+-+-+-+-+ 242 The P2MP Capability TLV MUST be supported in the LDP Initialization 243 Message. Advertisement of the P2MP Capability indicates support of 244 the procedures for P2MP LSP setup detailed in this document. If the 245 peer has not advertised the corresponding capability, then label 246 messages using the P2MP FEC Element SHOULD NOT be sent to the peer. 248 2.2. The P2MP FEC Element 250 For the setup of a P2MP LSP with LDP, we define one new protocol 251 entity, the P2MP FEC Element to be used as a FEC Element in the FEC 252 TLV. Note that the P2MP FEC Element does not necessarily identify 253 the traffic that must be mapped to the LSP, so from that point of 254 view, the use of the term FEC is a misnomer. The description of the 255 P2MP FEC Element follows. 257 The P2MP FEC Element consists of the address of the root of the P2MP 258 LSP and an opaque value. The opaque value consists of one or more 259 LDP MP Opaque Value Elements. The opaque value is unique within the 260 context of the root node. The combination of (Root Node Address, 261 Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. 263 The P2MP FEC Element is encoded as follows: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 |P2MP Type (TBD)| Address Family | Address Length| 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 ~ Root Node Address ~ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Opaque Length | Opaque Value ... | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 274 ~ ~ 275 | | 276 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Type: The type of the P2MP FEC Element is to be assigned by IANA. 282 Address Family: Two octet quantity containing a value from IANA's 283 "Address Family Numbers" registry that encodes the address family 284 for the Root LSR Address. 286 Address Length: Length of the Root LSR Address in octets. 288 Root Node Address: A host address encoded according to the Address 289 Family field. 291 Opaque Length: The length of the Opaque Value, in octets. 293 Opaque Value: One or more MP Opaque Value elements, uniquely 294 identifying the P2MP LSP in the context of the Root Node. This is 295 described in the next section. 297 If the Address Family is IPv4, the Address Length MUST be 4; if the 298 Address Family is IPv6, the Address Length MUST be 16. No other 299 Address Lengths are defined at present. 301 If the Address Length doesn't match the defined length for the 302 Address Family, the receiver SHOULD abort processing the message 303 containing the FEC Element, and send an "Unknown FEC" Notification 304 message to its LDP peer signaling an error. 306 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 307 be the only FEC Element in the FEC TLV. 309 2.3. The LDP MP Opaque Value Element 311 The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC 312 Elements defined in subsequent sections. It carries information that 313 is meaningful to Ingress LSRs and Leaf LSRs, but need not be 314 interpreted by Transit LSRs. 316 The LDP MP Opaque Value Element basic type is encoded as follows: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type < 255 | Length | Value ... | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 323 ~ ~ 324 | | 325 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Type: The Type of the LDP MP Opaque Value Element basic type is to 330 be assigned by IANA. 332 Length: The length of the Value field, in octets. 334 Value: String of Length octets, to be interpreted as specified by 335 the Type field. 337 The LDP MP Opaque Value Element extended type is encoded as follows: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type = 255 | Extended Type | Length (high) | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 344 | Length (low) | Value | 345 +-+-+-+-+-+-+-+-+ | 346 ~ ~ 347 | | 348 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Type: Type = 255. 354 Extended Type: The Extended Type of the LDP MP Opaque Value Element 355 extended type is to be assigned by IANA. 357 Length: The length of the Value field, in octets. 359 Value: String of Length octets, to be interpreted as specified by 360 the Type field. 362 2.3.1. The Generic LSP Identifier 364 The generic LSP identifier is a type of Opaque Value Element basic 365 type encoded as follows: 367 Type: 1 (to be assigned by IANA) 369 Length: 4 371 Value: A 32bit integer, unique in the context of the root, as 372 identified by the root's address. 374 This type of Opaque Value Element is recommended when mapping of 375 traffic to LSPs is non-algorithmic, and done by means outside LDP. 377 2.4. Using the P2MP FEC Element 379 This section defines the rules for the processing and propagation of 380 the P2MP FEC Element. The following notation is used in the 381 processing rules: 383 1. P2MP FEC Element : a FEC Element with Root Node Address X 384 and Opaque Value Y. 386 2. P2MP Label Map : a Label Map message with a FEC TLV with 387 a single P2MP FEC Element and Label TLV with label L. 388 Label L MUST be allocated from the per-platform label space (see 389 [RFC3031] section 3.14) of the LSR sending the Label Map Message. 391 3. P2MP Label Withdraw : a Label Withdraw message with a 392 FEC TLV with a single P2MP FEC Element and Label TLV with 393 label L. 395 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 396 Address X and Opaque Value Y. 398 5. The notation L' -> { ..., } on LSR X 399 means that on receiving a packet with label L', X makes n copies 400 of the packet. For copy i of the packet, X swaps L' with Li and 401 sends it out over interface Ii. 403 The procedures below are organized by the role which the node plays 404 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 405 process which is outside the scope of this document. During the 406 course of protocol operation, the root node recognizes its role 407 because it owns the Root Node Address. A transit node is any node 408 (other than the root node) that receives a P2MP Label Map message 409 (i.e., one that has leaf nodes downstream of it). 411 Note that a transit node (and indeed the root node) may also be a 412 leaf node. 414 2.4.1. Label Map 416 The remainder of this section specifies the procedures for 417 originating P2MP Label Map messages and for processing received P2MP 418 label map messages for a particular LSP. The procedures for a 419 particular LSR depend upon the role that LSR plays in the LSP 420 (ingress, transit, or egress). 422 All labels discussed here are downstream-assigned [RFC5332] except 423 those which are assigned using the procedures of Section 6. 425 2.4.1.1. Determining one's 'upstream LSR' 427 Each node that is either an Leaf or Transit LSR of MP LSP needs to 428 use the procedures below to select an upstream LSR. A node Z that 429 wants to join a MP LSP determines the LDP peer U which is Z's 430 next-hop on the best path from Z to the root node X. If there is more 431 than one such LDP peer, only one of them is picked. U is Z's 432 "Upstream LSR" for . 434 When there are several candidate upstream LSRs, the LSR MAY select 435 one upstream LSR. The algorithm used for the LSR selection is a 436 local matter. If the LSR selection is done over a LAN interface and 437 the Section 6 procedures are applied, the following procedure SHOULD 438 be applied to ensure that the same upstream LSR is elected among a 439 set of candidate receivers on that LAN. 441 1. The candidate upstream LSRs are numbered from lower to higher IP 442 address 444 2. The following hash is performed: H = (CRC32(Opaque value)) modulo 445 N, where N is the number of upstream LSRs. 447 3. The selected upstream LSR U is the LSR that has the number H. 449 This procedure will ensure that there is a single forwarder over the 450 LAN for a particular LSP. 452 2.4.1.2. Determining the forwarding interface to an LSR 454 Suppose LSR U receives a MP Label Map message from a downstream LSR 455 D, specifying label L. Suppose further that U is connected to D over 456 several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If U 457 needs to transmit to D a data packet whose top label is L, U is free 458 to transmit the packet on any of those interfaces. The algorithm it 459 uses to choose a particular interface and next-hop for a particular 460 such packet is a local matter. For completeness the following 461 procedure MAY be used. LSR U may do a lookup in the unicast routing 462 table to find the best interface and next-hop to reach LSR D. If the 463 next-hop and interface are also advertised by LSR D via the LDP 464 session it can be used to transmit the packet to LSR D. 466 2.4.1.3. Leaf Operation 468 A leaf node Z of P2MP LSP determines its upstream LSR U for 469 as per Section 2.4.1.1, allocates a label L, and sends a P2MP 470 Label Map to U. 472 2.4.1.4. Transit Node operation 474 Suppose a transit node Z receives a P2MP Label Map from LSR 475 T. Z checks whether it already has state for . If not, Z 476 determines its upstream LSR U for as per Section 2.4.1.1. 477 Using this Label Map to update the label forwarding table MUST NOT be 478 done as long as LSR T is equal to LSR U. If LSR U is different from 479 LSR T, Z will allocate a label L', and install state to swap L' with 480 L over interface I associated with LSR T and send a P2MP Label Map 481 to LSR U. Interface I is determind via the procedures in 482 Section 2.4.1.2. 484 If Z already has state for , then Z does not send a Label Map 485 message for P2MP LSP . All that Z needs to do in this case is 486 check that LSR T is not equal to the upstream LSR of and 487 update its forwarding state. Assuming its old forwarding state was 488 L'-> { ..., }, its new forwarding state 489 becomes L'-> { ..., , }. If the LSR T 490 is equal to the installed upstream LSR, the Label Map from LSR T MUST 491 be retained and MUST NOT update the label forwarding table. 493 2.4.1.5. Root Node Operation 495 Suppose the root node Z receives a P2MP Label Map from LSR 496 T. Z checks whether it already has forwarding state for . If 497 not, Z creates forwarding state to push label L onto the traffic that 498 Z wants to forward over the P2MP LSP (how this traffic is determined 499 is outside the scope of this document). 501 If Z already has forwarding state for , then Z adds "push label 502 L, send over interface I" to the nexthop, where I is the interface 503 associated with LSR T and determined via the procedures in 504 Section 2.4.1.2. 506 2.4.2. Label Withdraw 508 The following section lists procedures for generating and processing 509 P2MP Label Withdraw messages for nodes that participate in a P2MP 510 LSP. An LSR should apply those procedures that apply to it, based on 511 its role in the P2MP LSP. 513 2.4.2.1. Leaf Operation 515 If a leaf node Z discovers (by means outside the scope of this 516 document) that it has no downstream neighbors in that LSP, and that 517 it has no need to be an egress LSR for that LSP, then it SHOULD send 518 a Label Withdraw to its upstream LSR U for , where L 519 is the label it had previously advertised to U for . 521 2.4.2.2. Transit Node Operation 523 If a transit node Z receives a Label Withdraw message from 524 a node W, it deletes label L from its forwarding state, and sends a 525 Label Release message with label L to W. 527 If deleting L from Z's forwarding state for P2MP LSP results 528 in no state remaining for , then Z propagates the Label 529 Withdraw for , to its upstream T, by sending a Label Withdraw 530 where L1 is the label Z had previously advertised to T for 531 . 533 2.4.2.3. Root Node Operation 535 The procedure when the root node of a P2MP LSP receives a Label 536 Withdraw message are the same as for transit nodes, except that it 537 would not propagate the Label Withdraw upstream (as it has no 538 upstream). 540 2.4.3. Upstream LSR change 542 Suppose that for a given node Z participating in a P2MP LSP , 543 the upstream LSR changes from U to U' as per Section 2.4.1.1. Z MUST 544 update its forwarding state as follows. It allocates a new label, 545 L', for . The forwarding state for L' is copied from the 546 forwarding state for L, with one exception: if U' was present in the 547 forwarding state of L, it MUST NOT be installed in the forwarding 548 state of L'. Then the forwarding state for L is deleted and the 549 forwarding state for L' is installed. In addition Z MUST send a 550 Label Map to U' and send a Label Withdraw to U. 551 Note, if there was a downstream mapping from U that was not installed 552 in the forwarding due to Section 2.4.1.4 it can now be installed. 554 While changing the upstream LSR the following must be taken into 555 consideration. If L' is added before L is removed, there is a 556 potential risk of packet duplication, and/or the creation of a 557 transient dataplane forwarding loop. If L is removed before L' is 558 added, packet loss may result. 560 3. Setting up MP2MP LSPs with LDP 562 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 563 root node, zero or more transit nodes and one or more leaf LSRs 564 acting equally as Ingress or Egress LSR. A leaf node participates in 565 the setup of an MP2MP LSP by establishing both a downstream LSP, 566 which is much like a P2MP LSP from the root, and an upstream LSP 567 which is used to send traffic toward the root and other leaf nodes. 568 Transit nodes support the setup by propagating the upstream and 569 downstream LSP setup toward the root and installing the necessary 570 MPLS forwarding state. The transmission of packets from the root 571 node of a MP2MP LSP to the receivers is identical to that for a P2MP 572 LSP. Traffic from a downstream node follows the upstream LSP toward 573 the root node and branches downward along the downstream LSP as 574 required to reach other leaf nodes. A packet that is received from a 575 downstream node MUST never be forwarded back out to that same node. 576 Mapping traffic to the MP2MP LSP may happen at any leaf node. How 577 that mapping is established is outside the scope of this document. 579 Due to how a MP2MP LSP is built a leaf LSR that is sending packets on 580 the MP2MP LSP does not receive its own packets. There is also no 581 additional mechanism needed on the root or transit LSR to match 582 upstream traffic to the downstream forwarding state. Packets that 583 are forwarded over a MP2MP LSP will not traverse a link more than 584 once, with the possible exception of LAN links (see Section 3.3.1), 585 if the procedures of [RFC5331] are not provided. 587 3.1. Support for MP2MP LSP setup with LDP 589 Support for the setup of MP2MP LSPs is advertised using LDP 590 capabilities as defined in [RFC5561]. An implementation supporting 591 the MP2MP procedures specified in this document MUST implement the 592 procedures for Capability Parameters in Initialization Messages. 594 A new Capability Parameter TLV is defined, the MP2MP Capability. 595 Following is the format of the MP2MP Capability Parameter. 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 |1|0| MP2MP Capability TBD IANA | Length (= 1) | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 |1| Reserved | 603 +-+-+-+-+-+-+-+-+ 605 The MP2MP Capability TLV MUST be supported in the LDP Initialization 606 Message. Advertisement of the MP2MP Capability indicates support of 607 the procedures for MP2MP LSP setup detailed in this document. If the 608 peer has not advertised the corresponding capability, then label 609 messages using the MP2MP upstream and downstream FEC Elements SHOULD 610 NOT be sent to the peer. 612 3.2. The MP2MP downstream and upstream FEC Elements. 614 For the setup of a MP2MP LSP with LDP we define 2 new protocol 615 entities, the MP2MP downstream FEC and upstream FEC Element. Both 616 elements will be used as FEC Elements in the FEC TLV. Note that the 617 MP2MP FEC Elements do not necessarily identify the traffic that must 618 be mapped to the LSP, so from that point of view, the use of the term 619 FEC is a misnomer. The description of the MP2MP FEC Elements follow. 621 The structure, encoding and error handling for the MP2MP downstream 622 and upstream FEC Elements are the same as for the P2MP FEC Element 623 described in Section 2.2. The difference is that two new FEC types 624 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 626 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 627 MUST be the only FEC Element in the FEC TLV. 629 Note, except when using the procedures of [RFC5331], the MPLS labels 630 used are "downstream-assigned" [RFC5332], even if they are bound to 631 the "upstream FEC element". 633 3.3. Using the MP2MP FEC Elements 635 This section defines the rules for the processing and propagation of 636 the MP2MP FEC Elements. The following notation is used in the 637 processing rules: 639 1. MP2MP downstream LSP (or simply downstream ): an 640 MP2MP LSP downstream path with root node address X and opaque 641 value Y. 643 2. MP2MP upstream LSP (or simply upstream ): a 644 MP2MP LSP upstream path for downstream node D with root node 645 address X and opaque value Y. 647 3. MP2MP downstream FEC Element : a FEC Element with root 648 node address X and opaque value Y used for a downstream MP2MP 649 LSP. 651 4. MP2MP upstream FEC Element : a FEC Element with root node 652 address X and opaque value Y used for an upstream MP2MP LSP. 654 5. MP2MP-D Label Map : A Label Map message with a FEC TLV 655 with a single MP2MP downstream FEC Element and label TLV 656 with label L. Label L MUST be allocated from the per-platform 657 label space (see [RFC3031] section 3.14) of the LSR sending the 658 Label Map Message. 660 6. MP2MP-U Label Map : A Label Map message with a FEC TLV 661 with a single MP2MP upstream FEC Element and label TLV 662 with label Lu. Label Lu MUST be allocated from the per-platform 663 label space (see [RFC3031] section 3.14) of the LSR sending the 664 Label Map Message. 666 7. MP2MP-D Label Withdraw : a Label Withdraw message with 667 a FEC TLV with a single MP2MP downstream FEC Element and 668 label TLV with label L. 670 8. MP2MP-U Label Withdraw : a Label Withdraw message with 671 a FEC TLV with a single MP2MP upstream FEC Element and 672 label TLV with label Lu. 674 9. MP2MP-D Label Release : a Label Release message with a 675 FEC TLV with a single MP2MP downstream FEC Element and 676 label TLV with label L. 678 10. MP2MP-U Label Release : a Label Release message with a 679 FEC TLV with a single MP2MP upstream FEC Element and 680 label TLV with label Lu. 682 The procedures below are organized by the role which the node plays 683 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 684 process which is outside the scope of this document. During the 685 course of the protocol operation, the root node recognizes its role 686 because it owns the root node address. A transit node is any node 687 (other then the root node) that receives a MP2MP Label Map message 688 (i.e., one that has leaf nodes downstream of it). 690 Note that a transit node (and indeed the root node) may also be a 691 leaf node and the root node does not have to be an ingress LSR or 692 leaf of the MP2MP LSP. 694 3.3.1. MP2MP Label Map 696 The remainder of this section specifies the procedures for 697 originating MP2MP Label Map messages and for processing received 698 MP2MP label map messages for a particular LSP. The procedures for a 699 particular LSR depend upon the role that LSR plays in the LSP 700 (ingress, transit, or egress). 702 All labels discussed here are downstream-assigned [RFC5332] except 703 those which are assigned using the procedures of Section 6. 705 3.3.1.1. Determining one's upstream MP2MP LSR 707 Determining the upstream LDP peer U for a MP2MP LSP follows 708 the procedure for a P2MP LSP described in Section 2.4.1.1. 710 3.3.1.2. Determining one's downstream MP2MP LSR 712 A LDP peer U which receives a MP2MP-D Label Map from a LDP peer D 713 will treat D as downstream MP2MP LSR. 715 3.3.1.3. Installing the upstream path of a MP2MP LSP 717 There are two methods for installing the upstream path of a MP2MP LSP 718 to a downstream neighbor. 720 1. We can install the upstream MP2MP path (to a downstream neighbor) 721 based on receiving a MP2MP-D Label Map from the downstream 722 neighbor. This will install the upstream path on a per hop by 723 hop basis. 725 2. We install the upstream MP2MP path (to a downstream neighbor) 726 based on receiving a MP2MP-U Label Map from the upstream 727 neighbor. An LSR does not need to wait for the MP2MP-U Label Map 728 if it is the root of the MP2MP LSP or already has received an 729 MP2MP-U Label Map from the upstream neighbor. We call this 730 method ordered mode. The typical result of this mode is that the 731 downstream path of the MP2MP is built hop by hop towards the 732 root. Once the root is reached, the root node will trigger a 733 MP2MP-U Label Map to the downstream neighbor(s). 735 For setting up the upstream path of a MP2MP LSP ordered mode MUST be 736 used. Due to ordered mode the upstream path of the MP2MP LSP is 737 installed at the leaf node once the path to the root is completed. 738 The advantage is that when a leaf starts sending immediately after 739 the upstream path is installed, packets are able to reach the root 740 node without being dropped due to an incomplete LSP. Method 1 is not 741 able to guarantee that the upstream path is completed before the leaf 742 starts sending. 744 3.3.1.4. MP2MP leaf node operation 746 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 747 as per Section 3.3.1.1, allocates a label L, and sends a 748 MP2MP-D Label Map to U. 750 Leaf node Z expects an MP2MP-U Label Map from node U in 751 response to the MP2MP-D Label Map it sent to node U. Z checks whether 752 it already has forwarding state for upstream . If not, Z 753 creates forwarding state to push label Lu onto the traffic that Z 754 wants to forward over the MP2MP LSP. How it determines what traffic 755 to forward on this MP2MP LSP is outside the scope of this document. 757 3.3.1.5. MP2MP transit node operation 759 Suppose node Z receives a MP2MP-D Label Map from LSR D. Z 760 checks whether it has forwarding state for downstream . If 761 not, Z determines its upstream LSR U for as per 762 Section 3.3.1.1. Using this Label Map to update the label forwarding 763 table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U 764 is different from LSR D, Z will allocate a label L' and install 765 downstream forwarding state to swap label L' with label L over 766 interface I associated with LSR D and send a MP2MP-D Label Map to U. Interface I is determined via the procedures in 768 Section 2.4.1.2. 770 If Z already has forwarding state for downstream , all that Z 771 needs to do in this case is check that LSR D is not equal to the 772 upstream LSR of and update its forwarding state. Assuming its 773 old forwarding state was L'-> { ..., }, its 774 new forwarding state becomes L'-> { ..., , 775 }. If the LSR D is equal to the installed upstream LSR, the 776 Label Map from LSR D MUST be retained and MUST NOT update the label 777 forwarding table. 779 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 781 Map from LSR U. See Section 3.3.1.3. Once the MP2MP-U 782 Label Map is received from LSR U, node Z checks whether it already 783 has forwarding state upstream . If it does, then no further 784 action needs to happen. If it does not, it allocates a label Lu' and 785 creates a new label swap for Lu' with Label Lu over interface Iu. 786 Interface Iu is determined via the procedures in Section 2.4.1.2. In 787 addition, it also adds the label swap(s) from the forwarding state 788 downstream , omitting the swap on interface I for node D. The 789 swap on interface I for node D is omitted to prevent packet 790 originated by D to be forwarded back to D. 792 Node Z determines the downstream MP2MP LSR as per Section 3.3.1.2, 793 and sends a MP2MP-U Label Map to node D. 795 3.3.1.6. MP2MP root node operation 797 3.3.1.6.1. Root node is also a leaf 799 Suppose root/leaf node Z receives a MP2MP-D Label Map from 800 node D. Z checks whether it already has forwarding state downstream 801 . If not, Z creates forwarding state for downstream to push 802 label L on traffic that Z wants to forward down the MP2MP LSP. How 803 it determines what traffic to forward on this MP2MP LSP is outside 804 the scope of this document. If Z already has forwarding state for 805 downstream , then Z will add the label push for L over 806 interface I to it. Interface I is determined via the procedures in 807 Section 2.4.1.2. 809 Node Z checks if it has forwarding state for upstream If 810 not, Z allocates a label Lu' and creates upstream forwarding state to 811 swap Lu' with the label swap(s) from the forwarding state downstream 812 , except the swap on interface I for node D. This allows 813 upstream traffic to go down the MP2MP to other node(s), except the 814 node from which the traffic was received. Node Z determines the 815 downstream MP2MP LSR as per section Section 3.3.1.2, and sends a 816 MP2MP-U Label Map to node D. Since Z is the root of the 817 tree Z will not send a MP2MP-D Label Map and will not receive a 818 MP2MP-U Label Map. 820 3.3.1.6.2. Root node is not a leaf 822 Suppose the root node Z receives a MP2MP-D Label Map from 823 node D. Z checks whether it already has forwarding state for 824 downstream . If not, Z creates downstream forwarding state and 825 installs a outgoing label L over interface I. Interface I is 826 determined via the procedures in Section 2.4.1.2. If Z already has 827 forwarding state for downstream , then Z will add label L over 828 interface I to the existing state. 830 Node Z checks if it has forwarding state for upstream . If 831 not, Z allocates a label Lu' and creates forwarding state to swap Lu' 832 with the label swap(s) from the forwarding state downstream , 833 except the swap for node D. This allows upstream traffic to go down 834 the MP2MP to other node(s), except the node is was received from. 835 Root node Z determines the downstream MP2MP LSR D as per 836 Section 3.3.1.2, and sends a MP2MP-U Label Map to it. 837 Since Z is the root of the tree Z will not send a MP2MP-D Label Map 838 and will not receive a MP2MP-U Label Map. 840 3.3.2. MP2MP Label Withdraw 842 The following section lists procedures for generating and processing 843 MP2MP Label Withdraw messages for nodes that participate in a MP2MP 844 LSP. An LSR should apply those procedures that apply to it, based on 845 its role in the MP2MP LSP. 847 3.3.2.1. MP2MP leaf operation 849 If a leaf node Z discovers (by means outside the scope of this 850 document) that it has no downstream neighbors in that LSP, and that 851 it has no need to be an egress LSR for that LSP, then it SHOULD send 852 a MP2MP-D Label Withdraw to its upstream LSR U for , 853 where L is the label it had previously advertised to U for . 854 Leaf node Z will also send a unsolicited label release to 855 U to indicate that the upstream path is no longer used and that Label 856 Lu can be removed. 858 Leaf node Z expects the upstream router U to respond by sending a 859 downstream label release for L. 861 3.3.2.2. MP2MP transit node operation 863 If a transit node Z receives a MP2MP-D Label Withdraw message from node D, it deletes label L from its forwarding state 865 downstream and from all its upstream states for . Node 866 Z sends a MP2MP-D Label Release message with label L to D. Since node 867 D is no longer part of the downstream forwarding state, Z cleans up 868 the forwarding state upstream . There is no need to send an 869 MP2MP-U Label Withdraw to D because node D already removed 870 Lu and send a label release for Lu to Z. 872 If deleting L from Z's forwarding state for downstream results 873 in no state remaining for , then Z propagates the MP2MP-D Label 874 Withdraw to its upstream node U for and will also 875 send a unsolicited MP2MP-U Label Release to U to indicate 876 that the upstream path is no longer used and that Label Lu can be 877 removed. 879 3.3.2.3. MP2MP root node operation 881 The procedure when the root node of a MP2MP LSP receives a MP2MP-D 882 Label Withdraw message is the same as for transit nodes, except that 883 the root node would not propagate the Label Withdraw upstream (as it 884 has no upstream). 886 3.3.3. MP2MP Upstream LSR change 888 The procedure for changing the upstream LSR is the same as documented 889 in Section 2.4.3, except it is applied to MP2MP FECs, using the 890 procedures described in Section 3.3.1 through Section 3.3.2.3. 892 4. Micro-loops in MP LSPs 894 Micro-loops created by the unicast routing protocol during 895 convergence may also effect mLDP MP LSPs. Since the tree building 896 logic in mLDP is based on unicast routing, a unicast routing loop may 897 also result in a micro-loop in the MP LSPs. Micro-loops that involve 898 2 directly connected routers don't create a loop in mLDP. mLDP is 899 able to prevent this inconsistency by never allowing an upstream LDP 900 neighbor to be added as a downstream LDP neighbor into the Label 901 Forwarding Table (LFT) for the same FEC. Micro-loops that involve 902 more than 2 LSRs are not prevented. 904 Micro-loops that involve more than 2 LSRs may create a micro-loop in 905 the downstream path of either a MP2MP LSP or P2MP LSP and the 906 upstream path of the MP2MP LSP. The loops are transient and will 907 disappear as soon as the unicast routing protocol converges. Micro- 908 loops that occur in the upstream path of a MP2MP LSP may be detected 909 by including LDP path vector in the MP2MP-U Label Map messages. 910 These procedures are currently under investigation and are subjected 911 to further study. 913 5. The LDP MP Status TLV 915 An LDP MP capable router MAY use an LDP MP Status TLV to indicate 916 additional status for a MP LSP to its remote peers. This includes 917 signaling to peers that are either upstream or downstream of the LDP 918 MP capable router. The value of the LDP MP status TLV will remain 919 opaque to LDP and MAY encode one or more status elements. 921 The LDP MP Status TLV is encoded as follows: 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 |1|0| LDP MP Status Type(TBD) | Length | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Value | 929 ~ ~ 930 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. 936 Length: Length of the LDP MP Status Value in octets. 938 Value: One or more LDP MP Status Value elements. 940 5.1. The LDP MP Status Value Element 942 The LDP MP Status Value Element that is included in the LDP MP Status 943 TLV Value has the following encoding. 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Type(TBD) | Length | Value ... | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 950 ~ ~ 951 | | 952 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Type: The type of the LDP MP Status Value Element is to be assigned 958 by IANA. 960 Length: The length of the Value field, in octets. 962 Value: String of Length octets, to be interpreted as specified by 963 the Type field. 965 5.2. LDP Messages containing LDP MP Status messages 967 The LDP MP status message may appear either in a label mapping 968 message or a LDP notification message. 970 5.2.1. LDP MP Status sent in LDP notification messages 972 An LDP MP status TLV sent in a notification message must be 973 accompanied with a Status TLV. The general format of the 974 Notification Message with an LDP MP status TLV is: 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 |0| Notification (0x0001) | Message Length | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Message ID | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Status TLV | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | LDP MP Status TLV | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Optional LDP MP FEC TLV | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Optional Label TLV | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 The Status TLV status code is used to indicate that LDP MP status TLV 993 and any additional information follows in the Notification message's 994 "optional parameter" section. Depending on the actual contents of 995 the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may 996 also be present to provide context to the LDP MP Status TLV. (NOTE: 997 Status Code is pending IANA assignment). 999 Since the notification does not refer to any particular message, the 1000 Message Id and Message Type fields are set to 0. 1002 5.2.2. LDP MP Status TLV in Label Mapping Message 1004 An example of the Label Mapping Message defined in RFC3036 is shown 1005 below to illustrate the message with an Optional LDP MP Status TLV 1006 present. 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 |0| Label Mapping (0x0400) | Message Length | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Message ID | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | FEC TLV | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Label TLV | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Optional LDP MP Status TLV | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Additional Optional Parameters | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 6. Upstream label allocation on a LAN 1026 On a LAN, the procedures so far discussed would require the upstream 1027 LSR to send a copy of the packet to each receiver individually. If 1028 there is more than one receiver on the LAN we don't take full benefit 1029 of the multi-access capability of the network. We may optimize the 1030 bandwidth consumption on the LAN and replication overhead on the 1031 upstream LSR by using upstream label allocation [RFC5331]. 1032 Procedures on how to distribute upstream labels using LDP is 1033 documented in [I-D.ietf-mpls-ldp-upstream]. 1035 6.1. LDP Multipoint-to-Multipoint on a LAN 1037 The procedure to allocate a context label on a LAN is defined in 1038 [RFC5331]. That procedure results in each LSR on a given LAN having 1039 a context label which, on that LAN, can be used to identify itself 1040 uniquely. Each LSR advertises its context label as an upstream- 1041 assigned label, following the procedures of 1042 [I-D.ietf-mpls-ldp-upstream]. Any LSR for which the LAN is a 1043 downstream link on some P2MP or MP2MP LSP will allocate an upstream- 1044 assigned label identifying that LSP. When the LSR forwards a packet 1045 downstream on one of those LSPs, the packet's top label must be the 1046 LSR's context label, and the packet's second label is the label 1047 identifying the LSP. We will call the top label the "upstream LSR 1048 label" and the second label the "LSP label". 1050 6.1.1. MP2MP downstream forwarding 1052 The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so 1053 we will use the same procedures as defined in 1055 [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is 1056 sent to the upstream LSR. The label mapping that is received from 1057 the upstream LSR contains the LSP label for the MP2MP FEC and the 1058 upstream LSR context label. The MP2MP downstream path (corresponding 1059 to the LSP label) will be installed in the context specific 1060 forwarding table corresponding to the upstream LSR label. Packets 1061 sent by the upstream router can be forwarded downstream using this 1062 forwarding state based on a two label lookup. 1064 6.1.2. MP2MP upstream forwarding 1066 A MP2MP LSP also has an upstream forwarding path. Upstream packets 1067 need to be forwarded in the direction of the root and downstream on 1068 any node on the LAN that has a downstream interface for the LSP. For 1069 a given MP2MP LSP on a given LAN, exactly one LSR is considered to be 1070 the upstream LSR. If an LSR on the LAN receives a packet from one of 1071 its downstream interfaces for the LSP, and if it needs to forward the 1072 packet onto the LAN, it ensures that the packet's top label is the 1073 context label of the upstream LSR, and that its second label is the 1074 LSP label that was assigned by the upstream LSR. 1076 Other LSRs receiving the packet will not be able to tell whether the 1077 packet really came from the upstream router, but that makes no 1078 difference in the processing of the packet. The upstream LSR will 1079 see its own upstream LSR in the label, and this will enable it to 1080 determine that the packet is traveling upstream. 1082 7. Root node redundancy 1084 The root node is a single point of failure for an MP LSP, whether 1085 this is P2MP or MP2MP. The problem is particularly severe for MP2MP 1086 LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same 1087 root node to set up the MP2MP LSP, because otherwise the traffic 1088 sourced by some leafs is not received by others. Because the root 1089 node is the single point of failure for an MP LSP, we need a fast and 1090 efficient mechanism to recover from a root node failure. 1092 An MP LSP is uniquely identified in the network by the opaque value 1093 and the root node address. It is likely that the root node for an MP 1094 LSP is defined statically. The root node address may be configured 1095 on each leaf statically or learned using a dynamic protocol. How 1096 leafs learn about the root node is out of the scope of this document. 1098 Suppose that for the same opaque value we define two (or more) root 1099 node addresses and we build a tree to each root using the same opaque 1100 value. Effectively these will be treated as different MP LSPs in the 1101 network. Once the trees are built, the procedures differ for P2MP 1102 and MP2MP LSPs. The different procedures are explained in the 1103 sections below. 1105 7.1. Root node redundancy - procedures for P2MP LSPs 1107 Since all leafs have set up P2MP LSPs to all the roots, they are 1108 prepared to receive packets on either one of these LSPs. However, 1109 only one of the roots should be forwarding traffic at any given time, 1110 for the following reasons: 1) to achieve bandwidth savings in the 1111 network and 2) to ensure that the receiving leafs don't receive 1112 duplicate packets (since one cannot assume that the receiving leafs 1113 are able to discard duplicates). How the roots determine which one 1114 is the active sender is outside the scope of this document. 1116 7.2. Root node redundancy - procedures for MP2MP LSPs 1118 Since all leafs have set up an MP2MP LSP to each one of the root 1119 nodes for this opaque value, a sending leaf may pick either of the 1120 two (or more) MP2MP LSPs to forward a packet on. The leaf nodes 1121 receive the packet on one of the MP2MP LSPs. The client of the MP2MP 1122 LSP does not care on which MP2MP LSP the packet is received, as long 1123 as they are for the same opaque value. The sending leaf MUST only 1124 forward a packet on one MP2MP LSP at a given point in time. The 1125 receiving leafs are unable to discard duplicate packets because they 1126 accept on all LSPs. Using all the available MP2MP LSPs we can 1127 implement redundancy using the following procedures. 1129 A sending leaf selects a single root node out of the available roots 1130 for a given opaque value. A good strategy MAY be to look at the 1131 unicast routing table and select a root that is closest in terms of 1132 the unicast metric. As soon as the root address of the active root 1133 disappears from the unicast routing table (or becomes less 1134 attractive) due to root node or link failure, the leaf can select a 1135 new best root address and start forwarding to it directly. If 1136 multiple root nodes have the same unicast metric, the highest root 1137 node addresses MAY be selected, or per session load balancing MAY be 1138 done over the root nodes. 1140 All leafs participating in a MP2MP LSP MUST join to all the available 1141 root nodes for a given opaque value. Since the sending leaf may pick 1142 any MP2MP LSP, it must be prepared to receive on it. 1144 The advantage of pre-building multiple MP2MP LSPs for a single opaque 1145 value is that convergence from a root node failure happens as fast as 1146 the unicast routing protocol is able to notify. There is no need for 1147 an additional protocol to advertise to the leaf nodes which root node 1148 is the active root. The root selection is a local leaf policy that 1149 does not need to be coordinated with other leafs. The disadvantage 1150 of pre-building multiple MP2MP LSPs is that more label resources are 1151 used, depending on how many root nodes are defined. 1153 8. Make Before Break (MBB) 1155 An LSR selects as its upstream LSR for a MP LSP the LSR that is its 1156 next hop to the root of the LSP. When the best path to reach the 1157 root changes the LSR must choose a new upstream LSR. Sections 1158 Section 2.4.3 and Section 3.3.3 describe these procedures. 1160 When the best path to the root changes the LSP may be broken 1161 temporarily resulting in packet loss until the LSP "reconverges" to a 1162 new upstream LSR. The goal of MBB when this happens is to keep the 1163 duration of packet loss as short as possible. In addition, there are 1164 scenarios where the best path from the LSR to the root changes but 1165 the LSP continues to forward packets to the prevous next hop to the 1166 root. That may occur when a link comes up or routing metrics change. 1167 In such a case a new LSP should be established before the old LSP is 1168 removed to limit the duration of packet loss. The procedures 1169 described below deal with both scenarios in a way that an LSR does 1170 not need to know which of the events described above caused its 1171 upstream router for an MBB LSP to change. 1173 The MBB procedures are an optional extension to the MP LSP building 1174 procedures described in this draft. The procedures in this section 1175 offer a make-before-break behavior, except in cases where the new 1176 path is part of a transient routing loop involving more than 2 LSRs 1177 (also see Section 4). 1179 8.1. MBB overview 1181 The MBB procedures use additional LDP signaling. 1183 Suppose some event causes a downstream LSR-D to select a new upstream 1184 LSR-U for FEC-A. The new LSR-U may already be forwarding packets for 1185 FEC-A; that is, to downstream LSRs other than LSR-D. After LSR-U 1186 receives a label for FEC-A from LSR-D, it will notify LSR-D when it 1187 knows that the LSP for FEC-A has been established from the root to 1188 itself. When LSR-D receives this MBB notification it will change its 1189 next hop for the LSP root to LSR-U. 1191 The assumption is that if LSR-U has received an MBB notification from 1192 its upstream router for the FEC-A LSP and has installed forwarding 1193 state the LSP it is capable of forwarding packets on the LSP. At 1194 that point LSR-U should signal LSR-D by means of an MBB notification 1195 that it has become part of the tree identified by FEC-A and that 1196 LSR-D should initiate its switchover to the LSP. 1198 At LSR-U the LSP for FEC-A may be in 1 of 3 states. 1200 1. There is no state for FEC-A. 1202 2. State for FEC-A exists and LSR-U is waiting for MBB notification 1203 that the LSP from the root to it exists. 1205 3. State for FEC-A exists and the MBB notification has been received 1206 or it is the Root node for FEC-A. 1208 After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U 1209 MUST NOT reply with an MBB notification to LSR-D until its state for 1210 the LSP is state #3 above. If the state of the LSP at LSR-U is state 1211 #1 or #2, LSR-U should remember receipt of the Label Mapping message 1212 from LSR-D while waiting for an MBB notification from its upstream 1213 LSR for the LSP. When LSR-U receives the MBB notification from LSR-U 1214 it transitions to LSP state #3 and sends an MBB notification to 1215 LSR-D. 1217 8.2. The MBB Status code 1219 As noted in Section 8.1, the procedures to establish an MBB MP LSP 1220 are different from those to establish normal MP LSPs. 1222 When a downstream LSR sends a Label Mapping message for MP LSP to its 1223 upstream LSR it MAY include an LDP MP Status TLV that carries a MBB 1224 Status Code to indicate MBB procedures apply to the LSP. This new 1225 MBB Status Code MAY also appear in an LDP Notification message used 1226 by an upstream LSR to signal LSP state #3 to the downstream LSR; that 1227 is, that the upstream LSRs state for the LSP exists and that it has 1228 received notification from its upstream LSR that the LSP is in state 1229 #3. 1231 The MBB Status is a type of the LDP MP Status Value Element as 1232 described in Section 5.1. It is encoded as follows: 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | MBB Type = 1 | Length = 1 | Status code | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 MBB Type: Type 1 (to be assigned by IANA) 1242 Length: 1 1244 Status code: 1 = MBB request 1246 2 = MBB ack 1248 8.3. The MBB capability 1250 An LSR MAY advertise that it is capable of handling MBB LSPs using 1251 the capability advertisement as defined in [RFC5561]. The LDP MP MBB 1252 capability has the following format: 1254 0 1 2 3 1255 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 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 |1|0| LDP MP MBB Capability | Length = 1 | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 |1| Reserved | 1260 +-+-+-+-+-+-+-+-+ 1262 Note: LDP MP MBB Capability (Pending IANA assignment) 1264 If an LSR has not advertised that it is MBB capable, its LDP peers 1265 MUST NOT send it messages which include MBB parameters. If an LSR 1266 receives a Label Mapping message with a MBB parameter from downstream 1267 LSR-D and its upstream LSR-U has not advertised that it is MBB 1268 capable, the LSR MUST send an MBB notification immediatly to LSR-U 1269 (see Section 8.4). If this happens an MBB MP LSP will not be 1270 established, but normal a MP LSP will be the result. 1272 8.4. The MBB procedures 1274 8.4.1. Terminology 1276 1. MBB LSP : A P2MP or MP2MP Make Before Break (MBB) LSP entry 1277 with Root Node Address X and Opaque Value Y. 1279 2. A(N, L): An Accepting element that consists of an upstream 1280 Neighbor N and Local label L. This LSR assigned label L to 1281 neighbor N for a specific MBB LSP. For an active element the 1282 corresponding Label is stored in the label forwarding database. 1284 3. iA(N, L): An inactive Accepting element that consists of an 1285 upstream neighbor N and local Label L. This LSR assigned label L 1286 to neighbor N for a specific MBB LSP. For an inactive element 1287 the corresponding Label is not stored in the label forwarding 1288 database. 1290 4. F(N, L): A Forwarding state that consists of downstream Neighbor 1291 N and Label L. This LSR is sending label packets with label L to 1292 neighbor N for a specific FEC. 1294 5. F'(N, L): A Forwarding state that has been marked for sending a 1295 MBB Notification message to Neighbor N with Label L. 1297 6. MBB Notification : A LDP notification message with a MP 1298 LSP , Label L and MBB Status code 2. 1300 7. MBB Label Map : A P2MP Label Map or MP2MP Label Map 1301 downstream with a FEC element , Label L and MBB Status code 1302 1. 1304 8.4.2. Accepting elements 1306 An accepting element represents a specific label value L that has 1307 been advertised to a neighbor N for a MBB LSP and is a 1308 candidate for accepting labels switched packets on. An LSR can have 1309 two accepting elements for a specific MBB LSP LSP, only one of 1310 them MUST be active. An active element is the element for which the 1311 label value has been installed in the label forwarding database. An 1312 inactive accepting element is created after a new upstream LSR is 1313 chosen and is pending to replace the active element in the label 1314 forwarding database. Inactive elements only exist temporarily while 1315 switching to a new upstream LSR. Once the switch has been completed 1316 only one active element remains. During network convergence it is 1317 possible that an inactive accepting element is created while an other 1318 inactive accepting element is pending. If that happens the older 1319 inactive accepting element MUST be replaced with an newer inactive 1320 element. If an accepting element is removed a Label Withdraw has to 1321 be send for label L to neighbor N for . 1323 8.4.3. Procedures for upstream LSR change 1325 Suppose a node Z has a MBB LSP with an active accepting 1326 element A(N1, L1). Due to a routing change it detects a new best 1327 path for root X and selects a new upstream LSR N2. Node Z allocates 1328 a new local label L2 and creates an inactive accepting element iA(N2, 1329 L2). Node Z sends MBB Label Map to N2 and waits for the 1330 new upstream LSR N2 to respond with a MBB Notification for . During this transition phase there are two accepting elements, 1332 the element A(N1, L1) still accepting packets from N1 over label L1 1333 and the new inactive element iA(N2, L2). 1335 While waiting for the MBB Notification from upstream LSR N2, it is 1336 possible that another transition occurs due to a routing change. 1337 Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) 1338 is created and the old inactive element iA(N2, L2) MUST be removed. 1339 A label withdraw MUST be sent to N2 for from N2 will be ignored because the 1341 inactive element is removed. 1343 It is possible that the MBB Notification from upstream LSR is never 1344 received due to link or node failure. To prevent waiting 1345 indefinitely for the MBB Notification a timeout SHOULD be applied. 1346 As soon as the timer expires, the procedures in Section 8.4.5 are 1347 applied as if a MBB Notification was received for the inactive 1348 element. If a downstream LSR detects that the old upstream LSR went 1349 down while waiting for the MBB Notification from the new upstream 1350 LSR, the downstream LSR can immediately proceed without waiting for 1351 the timer to expire. 1353 8.4.4. Receiving a Label Map with MBB status code 1355 Suppose node Z has state for a MBB LSP and receives a MBB 1356 Label Map from N2. A new forwarding state F(N2, L2) will 1357 be added to the MP LSP if it did not already exist. If this MBB LSP 1358 has an active accepting element or node Z is the root of the MBB LSP 1359 a MBB notification is sent to node N2. If node Z has an 1360 inactive accepting element it marks the Forwarding state as . If router Z upstream LSR for happens to be N2, 1362 then Z MUST NOT send an MBB notification to N2 at once. Sending the 1363 MBB notification to N2 must be done only after Z upstream for 1364 stops being N2. 1366 8.4.5. Receiving a Notification with MBB status code 1368 Suppose node Z receives a MBB Notification from N. If node 1369 Z has state for MBB LSP and an inactive accepting element 1370 iA(N, L) that matches with N and L, we activate this accepting 1371 element and install label L in the label forwarding database. If an 1372 other active accepting was present it will be removed from the label 1373 forwarding database. 1375 If this MBB LSP also has Forwarding states marked for sending 1376 MBB Notifications, like , MBB Notifications are 1377 sent to these downstream LSRs. If node Z receives a MBB Notification 1378 for an accepting element that is not inactive or does not match the 1379 Label value and Neighbor address, the MBB notification is ignored. 1381 8.4.6. Node operation for MP2MP LSPs 1383 The procedures described above apply to the downstream path of a 1384 MP2MP LSP. The upstream path of the MP2MP is setup as normal without 1385 including a MBB Status code. If the MBB procedures apply to a MP2MP 1386 downstream FEC element, the upstream path to a node N is only 1387 installed in the label forwarding database if node N is part of the 1388 active accepting element. If node N is part of an inactive accepting 1389 element, the upstream path is installed when this inactive accepting 1390 element is activated. 1392 9. Typed Wildcard for mLDP FEC Element 1394 The format of the mLDP FEC Typed Wildcard FEC is as follows: 1396 0 1 2 3 1397 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 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | Typed Wcard | Type = mLDP | Len = 2 | AFI ~ 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 ~ | 1402 +-+-+-+-+-+-+-+-+ 1404 Type Wcard: As specified in [RFC5918] 1406 Type: mLDP FEC Element Type as documented in this draft. 1408 Len: Len FEC Type Info, two octets (=0x02). 1410 AFI: Address Family, two octet quantity containing a value from 1411 IANA's "Address Family Numbers" registry. 1413 10. Security Considerations 1415 The same security considerations apply as for the base LDP 1416 specification, as described in [RFC5036]. 1418 11. IANA Considerations 1420 This document creates three new registries to be managed by IANA. 1422 1. "LDP MP Opaque Value Element basic type" 1424 The range is 0-255, with the following values allocated in this 1425 document: 1427 1: Generic LSP identifier 1429 255: Extended Type field is present in the following two bytes 1431 The allocation policy for this space is 'Standards Action with 1432 Early Allocation' 1434 2. "LDP MP Opaque Value Element extended type" 1436 The range is 0-65335, with the following allocation policies: 1438 0-32767: Standards Action with Early Allocation 1440 32768-65535: First Come, First Served 1442 3. "LDP MP Status Value Element type" 1444 The range is 0-255, with the following value allocated in this 1445 document: 1447 1: MBB Status 1449 The allocation policy for this space is 'Standards Action with 1450 Early Allocation' 1452 This document requires allocation of three new code points from the 1453 IANA managed LDP registry "Forwarding Equivalence Class (FEC) Type 1454 Name Space". The values are: 1456 P2MP FEC type - requested value 0x06 1458 MP2MP-up FEC type - requested value 0x07 1460 MP2MP-down FEC type - requested value 0x08 1462 This document requires the assignment of three new code points for 1463 three new Capability Parameter TLVs from the IANA managed LDP 1464 registry "TLV Type Name Space", corresponding to the advertisement of 1465 the P2MP, MP2MP and MBB capabilities. The values requested are: 1467 P2MP Capability Parameter - requested value 0x0508 1468 MP2MP Capability Parameter - requested value 0x0509 1470 MBB Capability Parameter - requested value 0x050A 1472 This document requires the assignment of a LDP Status Code to 1473 indicate a LDP MP Status TLV is following in the Notification 1474 message. The value requested from the IANA managed LDP registry "LDP 1475 Status Code Name Space" is: 1477 LDP MP status - requested value 0x00000040 1479 This document requires the assigment of a new code point for a LDP MP 1480 Status TLV. The value requested from the IANA managed LDP registry 1481 "LDP TLV Type Name Space" is: 1483 LDP MP Status TLV Type - requested value 0x096F 1485 12. Acknowledgments 1487 The authors would like to thank the following individuals for their 1488 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 1489 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, 1490 George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel, Thomas Morin 1491 and Ben Niven-Jenkins. 1493 13. Contributing authors 1495 Below is a list of the contributing authors in alphabetical order: 1497 Shane Amante 1498 Level 3 Communications, LLC 1499 1025 Eldorado Blvd 1500 Broomfield, CO 80021 1501 US 1502 Email: Shane.Amante@Level3.com 1504 Luyuan Fang 1505 Cisco Systems 1506 300 Beaver Brook Road 1507 Boxborough, MA 01719 1508 US 1509 Email: lufang@cisco.com 1510 Hitoshi Fukuda 1511 NTT Communications Corporation 1512 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1513 Tokyo 100-8019, 1514 Japan 1515 Email: hitoshi.fukuda@ntt.com 1517 Yuji Kamite 1518 NTT Communications Corporation 1519 Tokyo Opera City Tower 1520 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1521 Tokyo 163-1421, 1522 Japan 1523 Email: y.kamite@ntt.com 1525 Kireeti Kompella 1526 Juniper Networks 1527 1194 N. Mathilda Ave. 1528 Sunnyvale, CA 94089 1529 US 1530 Email: kireeti@juniper.net 1532 Ina Minei 1533 Juniper Networks 1534 1194 N. Mathilda Ave. 1535 Sunnyvale, CA 94089 1536 US 1537 Email: ina@juniper.net 1539 Jean-Louis Le Roux 1540 France Telecom 1541 2, avenue Pierre-Marzin 1542 Lannion, Cedex 22307 1543 France 1544 Email: jeanlouis.leroux@francetelecom.com 1546 Bob Thomas 1547 Cisco Systems, Inc. 1548 300 Beaver Brook Road 1549 Boxborough, MA, 01719 1550 E-mail: bobthomas@alum.mit.edu 1551 Lei Wang 1552 Telenor 1553 Snaroyveien 30 1554 Fornebu 1331 1555 Norway 1556 Email: lei.wang@telenor.com 1558 IJsbrand Wijnands 1559 Cisco Systems, Inc. 1560 De kleetlaan 6a 1561 1831 Diegem 1562 Belgium 1563 E-mail: ice@cisco.com 1565 14. References 1567 14.1. Normative References 1569 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1570 Specification", RFC 5036, October 2007. 1572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1573 Requirement Levels", BCP 14, RFC 2119, March 1997. 1575 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1576 Label Switching Architecture", RFC 3031, January 2001. 1578 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1579 Label Assignment and Context-Specific Label Space", 1580 RFC 5331, August 2008. 1582 [I-D.ietf-mpls-ldp-upstream] 1583 Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment 1584 for LDP", draft-ietf-mpls-ldp-upstream-10 (work in 1585 progress), February 2011. 1587 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 1588 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 1590 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 1591 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 1592 (FEC)", RFC 5918, August 2010. 1594 14.2. Informative References 1596 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1597 Private Networks (L2VPNs)", RFC 4664, September 2006. 1599 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1600 "Extensions to Resource Reservation Protocol - Traffic 1601 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1602 Switched Paths (LSPs)", RFC 4875, May 2007. 1604 [I-D.ietf-mpls-mp-ldp-reqs] 1605 Morin, T., "Requirements for Point-To-Multipoint 1606 Extensions to the Label Distribution Protocol", 1607 draft-ietf-mpls-mp-ldp-reqs-06 (work in progress), 1608 December 2010. 1610 [I-D.ietf-l3vpn-2547bis-mcast] 1611 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 1612 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 1613 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work 1614 in progress), January 2010. 1616 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 1617 Multicast Encapsulations", RFC 5332, August 2008. 1619 Authors' Addresses 1621 Ina Minei (editor) 1622 Juniper Networks 1623 1194 N. Mathilda Ave. 1624 Sunnyvale, CA 94089 1625 US 1627 Email: ina@juniper.net 1629 IJsbrand Wijnands (editor) 1630 Cisco Systems, Inc. 1631 De kleetlaan 6a 1632 Diegem 1831 1633 Belgium 1635 Email: ice@cisco.com 1636 Kireeti Kompella 1637 Juniper Networks 1638 1194 N. Mathilda Ave. 1639 Sunnyvale, CA 94089 1640 US 1642 Email: kireeti@juniper.net 1644 Bob Thomas 1645 Cisco Systems, Inc. 1646 300 Beaver Brook Road 1647 Boxborough 01719 1648 US 1650 Email: bobthomas@alum.mit.edu