idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (August 4, 2011) is 4642 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: 'ITU.V42.1994' is defined on line 1627, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.V42.1994' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mp-ldp-reqs-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: February 5, 2012 Cisco Systems, Inc. 6 K. Kompella 7 Juniper Networks 8 B. Thomas 9 August 4, 2011 11 Label Distribution Protocol Extensions for Point-to-Multipoint and 12 Multipoint-to-Multipoint Label Switched Paths 13 draft-ietf-mpls-ldp-p2mp-15 15 Abstract 17 This document describes extensions to the Label Distribution Protocol 18 for the setup of Point-to-Multipoint and Multipoint-to-Multipoint 19 Label Switched Paths in Multi-Protocol Label Switching networks. 20 These extensions are also referred to as Multipoint LDP. Multipoint 21 LDP constructs the P2MP or MP2MP Label Switched Paths without 22 interacting with or relying upon any other multicast tree 23 construction protocol. Protocol elements and procedures for this 24 solution are described for building such Label Switched Paths in a 25 receiver-initiated manner. There can be various applications for 26 Multipoint Label Switched Paths, for example IP multicast or support 27 for multicast in BGP/MPLS L3VPNs. Specification of how such 28 applications can use a LDP signaled Multipoint Label Switched Path is 29 outside the scope of this document. 31 Status of this Memo 33 This Internet-Draft is submitted 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). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 5, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.1. Conventions used in this document . . . . . . . . . . . . 5 78 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 79 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6 80 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 7 81 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7 82 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9 83 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 10 84 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 11 85 2.4.1. Label Mapping . . . . . . . . . . . . . . . . . . . . 11 86 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 13 87 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 14 88 3. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 15 89 3.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 15 90 3.2. The MP2MP downstream and upstream FEC Elements. . . . . . 16 91 3.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 16 92 3.3.1. MP2MP Label Mapping . . . . . . . . . . . . . . . . . 18 93 3.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 21 94 3.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 22 95 4. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 22 96 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 22 97 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 23 98 5.2. LDP Messages containing LDP MP Status messages . . . . . . 24 99 5.2.1. LDP MP Status sent in LDP notification messages . . . 24 100 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 24 101 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 25 102 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 25 103 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 26 104 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 26 105 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 26 106 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 27 107 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 27 108 8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 28 109 8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28 110 8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29 111 8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 30 112 8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30 113 8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30 114 8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31 115 8.4.3. Procedures for upstream LSR change . . . . . . . . . . 31 116 8.4.4. Receiving a Label Mapping with MBB status code . . . . 32 117 8.4.5. Receiving a Notification with MBB status code . . . . 32 118 8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 33 119 9. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 33 120 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 121 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 122 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 123 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 35 124 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 125 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 126 14.2. Informative References . . . . . . . . . . . . . . . . . . 38 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 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 to a LDP neighbor 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 Related documents that may be of interest include 153 [I-D.ietf-mpls-mp-ldp-reqs], [I-D.ietf-l3vpn-2547bis-mcast] and 154 [RFC4875]. 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 Some of the following terminology is taken from 165 [I-D.ietf-mpls-mp-ldp-reqs]. 167 mLDP: Multipoint extensions for LDP. 169 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 171 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 172 LSRs. 174 MP2P LSP: An LSP that has one or more Ingress LSRs and one unique 175 Egress LSR. 177 MP2MP LSP: An LSP with a distinguished root node that connects a set 178 of nodes, such that traffic sent by any node in the LSP is 179 delivered to all others. 181 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 183 Ingress LSR: An ingress LSR for a particular LSP is an LSR that can 184 send a data packet along the LSP. MP2MP LSPs can have multiple 185 ingress LSRs, P2MP LSPs have just one, and that node is often 186 referred to as the "root node". 188 Egress LSR: An egress LSR for a particular LSP is an LSR that can 189 remove a data packet from that LSP for further processing. P2P 190 and MP2P LSPs have only a single egress node, but P2MP and MP2MP 191 LSPs can have multiple egress nodes. 193 Transit LSR: An LSR that has reachability to the root of the MP LSP 194 via a directly connected upstream LSR and one or more directly 195 connected downstream LSRs. 197 Bud LSR: An LSR that is an egress but also has one or more directly 198 connected downstream LSRs. 200 Leaf node: A Leaf node can be either an Egress or Bud LSR when 201 referred in the context of a P2MP LSP. In the context of a MP2MP 202 LSP, a leaf is both Ingress and Egress for the same MP2MP LSP and 203 can also be a Bud LSR. 205 CRC32: This contains a Cyclic Redundancy Check value of the 206 uncompressed data in network byte order computed according to 207 CRC-32 algorithm used in the ISO 3309 standard and in section 208 8.1.1.6.2 of ITU-T recommendation V.42. 210 2. Setting up P2MP LSPs with LDP 212 A P2MP LSP consists of a single root node, zero or more transit nodes 213 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 214 tear-down. Leaf nodes also install forwarding state to deliver the 215 traffic received on a P2MP LSP to wherever it needs to go; how this 216 is done is outside the scope of this document. Transit nodes install 217 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 218 down) toward the root. The root node installs forwarding state to 219 map traffic into the P2MP LSP; how the root node determines which 220 traffic should go over the P2MP LSP is outside the scope of this 221 document. 223 2.1. Support for P2MP LSP setup with LDP 225 Support for the setup of P2MP LSPs is advertised using LDP 226 capabilities as defined in [RFC5561]. An implementation supporting 227 the P2MP procedures specified in this document MUST implement the 228 procedures for Capability Parameters in Initialization Messages. 230 A new Capability Parameter TLV is defined, the P2MP Capability. 231 Following is the format of the P2MP Capability Parameter. 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |1|0| P2MP Capability (TBD IANA)| Length (= 1) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 |S| Reserved | 239 +-+-+-+-+-+-+-+-+ 241 S: As specified in [RFC5561] 243 The P2MP Capability TLV MUST be advertised in the LDP Initialization 244 Message. Advertisement of the P2MP Capability indicates support of 245 the procedures for P2MP LSP setup detailed in this document. If the 246 peer has not advertised the corresponding capability, then label 247 messages using the P2MP FEC Element SHOULD NOT be sent to the peer. 249 2.2. The P2MP FEC Element 251 For the setup of a P2MP LSP with LDP, we define one new protocol 252 entity, the P2MP FEC Element to be used as a FEC Element in the FEC 253 TLV. Note that the P2MP FEC Element does not necessarily identify 254 the traffic that must be mapped to the LSP, so from that point of 255 view, the use of the term FEC is a misnomer. The description of the 256 P2MP FEC Element follows. 258 The P2MP FEC Element consists of the address of the root of the P2MP 259 LSP and an opaque value. The opaque value consists of one or more 260 LDP MP Opaque Value Elements. The opaque value is unique within the 261 context of the root node. The combination of (Root Node Address 262 type, Root Node Address, Opaque Value) uniquely identifies a P2MP LSP 263 within the MPLS network. 265 The P2MP FEC Element is encoded as follows: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |P2MP Type (TBD)| Address Family | Address Length| 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 ~ Root Node Address ~ 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Opaque Length | Opaque Value ... | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 276 ~ ~ 277 | | 278 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Type: The type of the P2MP FEC Element is to be assigned by IANA. 284 Address Family: Two octet quantity containing a value from IANA's 285 "Address Family Numbers" registry that encodes the address family 286 for the Root LSR Address. 288 Address Length: Length of the Root LSR Address in octets. 290 Root Node Address: A host address encoded according to the Address 291 Family field. 293 Opaque Length: The length of the Opaque Value, in octets. 295 Opaque Value: One or more MP Opaque Value elements, uniquely 296 identifying the P2MP LSP in the context of the Root Node. This is 297 described in the next section. 299 If the Address Family is IPv4, the Address Length MUST be 4; if the 300 Address Family is IPv6, the Address Length MUST be 16. No other 301 Address Lengths are defined at present. 303 If the Address Length doesn't match the defined length for the 304 Address Family, the receiver SHOULD abort processing the message 305 containing the FEC Element, and send an "Unknown FEC" Notification 306 message to its LDP peer signaling an error. 308 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 309 be the only FEC Element in the FEC TLV. 311 2.3. The LDP MP Opaque Value Element 313 The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC 314 Elements defined in subsequent sections. It carries information that 315 is meaningful to Ingress LSRs and Leaf LSRs, but need not be 316 interpreted by Transit LSRs. 318 The LDP MP Opaque Value Element basic type is encoded as follows: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type < 255 | Length | Value ... | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 325 ~ ~ 326 | | 327 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Type: The Type of the LDP MP Opaque Value Element. IANA maintains a 332 registry of basic types (see Section 11). 334 Length: The length of the Value field, in octets. 336 Value: String of Length octets, to be interpreted as specified by 337 the Type field. 339 The LDP MP Opaque Value Element extended type is encoded as follows: 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type = 255 | Extended Type | Length (high) | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 346 | Length (low) | Value | 347 +-+-+-+-+-+-+-+-+ | 348 ~ ~ 349 | | 350 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Type: Type = 255. 356 Extended Type: The Extended Type of the LDP MP Opaque Value Element. 357 IANA maintains a registry of extended types (see Section 11). 359 Length: The length of the Value field, in octets. 361 Value: String of Length octets, to be interpreted as specified by 362 the Type field. 364 2.3.1. The Generic LSP Identifier 366 The generic LSP identifier is a type of Opaque Value Element basic 367 type encoded as follows: 369 Type: 1 (to be assigned by IANA) 371 Length: 4 373 Value: A 32bit integer, unique in the context of the root, as 374 identified by the root's address. 376 This type of Opaque Value Element is recommended when mapping of 377 traffic to LSPs is non-algorithmic, and done by means outside LDP. 379 2.4. Using the P2MP FEC Element 381 This section defines the rules for the processing and propagation of 382 the P2MP FEC Element. The following notation is used in the 383 processing rules: 385 1. P2MP FEC Element : a FEC Element with Root Node Address X 386 and Opaque Value Y. 388 2. P2MP Label Mapping : a Label Mapping message with a FEC 389 TLV with a single P2MP FEC Element and Label TLV with 390 label L. Label L MUST be allocated from the per-platform label 391 space (see [RFC3031] section 3.14) of the LSR sending the Label 392 Mapping Message. The use of the interface label space is outside 393 the scope of this document. 395 3. P2MP Label Withdraw : a Label Withdraw message with a 396 FEC TLV with a single P2MP FEC Element and Label TLV with 397 label L. 399 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 400 Address X and Opaque Value Y. 402 5. The notation L' -> { ..., } on LSR X 403 means that on receiving a packet with label L', X makes n copies 404 of the packet. For copy i of the packet, X swaps L' with Li and 405 sends it out over interface Ii. 407 The procedures below are organized by the role which the node plays 408 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 409 process which is outside the scope of this document. During the 410 course of protocol operation, the root node recognizes its role 411 because it owns the Root Node Address. A transit node is any node 412 (other than the root node) that receives a P2MP Label Mapping message 413 (i.e., one that has leaf nodes downstream of it). 415 Note that a transit node (and indeed the root node) may also be a 416 leaf node. 418 2.4.1. Label Mapping 420 The remainder of This section specifies the procedures for 421 originating P2MP Label Mapping messages and for processing received 422 P2MP Label Mapping messages for a particular LSP. The procedures for 423 a particular LSR depend upon the role that LSR plays in the LSP 424 (ingress, transit, or egress). 426 All labels discussed here are downstream-assigned [RFC5332] except 427 those which are assigned using the procedures of Section 6. 429 2.4.1.1. Determining one's 'upstream LSR' 431 Each node that is either an Leaf or Transit LSR of MP LSP needs to 432 use the procedures below to select an upstream LSR. A node Z that 433 wants to join a MP LSP determines the LDP peer U which is Z's 434 next-hop on the best path from Z to the root node X. If there is more 435 than one such LDP peer, only one of them is picked. U is Z's 436 "Upstream LSR" for . 438 When there are several candidate upstream LSRs, the LSR MUST select 439 one upstream LSR. The algorithm used for the LSR selection is a 440 local matter. If the LSR selection is done over a LAN interface and 441 the Section 6 procedures are applied, the following procedure SHOULD 442 be applied to ensure that the same upstream LSR is elected among a 443 set of candidate receivers on that LAN. 445 1. The candidate upstream LSRs are numbered from lower to higher IP 446 address 448 2. The following hash is performed: H = (CRC32(Opaque Value)) modulo 449 N, where N is the number of upstream LSRs. The 'Opaque Value' is 450 the field identified in the FEC Element right after 'Opaque 451 Length'. The 'Opaque Length' indicates the size of the Opaque 452 Value used in this calculation. 454 3. The selected upstream LSR U is the LSR that has the number H. 456 This procedure will ensure that there is a single forwarder over the 457 LAN for a particular LSP. 459 2.4.1.2. Determining the forwarding interface to an LSR 461 Suppose LSR U receives a MP Label Mapping message from a downstream 462 LSR D, specifying label L. Suppose further that U is connected to D 463 over several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If 464 U needs to transmit to D a data packet whose top label is L, U is 465 free to transmit the packet on any of those interfaces. The 466 algorithm it uses to choose a particular interface and next-hop for a 467 particular such packet is a local matter. For completeness the 468 following procedure MAY be used. LSR U may do a lookup in the 469 unicast routing table to find the best interface and next-hop to 470 reach LSR D. If the next-hop and interface are also advertised by LSR 471 D via the LDP session it can be used to transmit the packet to LSR D. 473 2.4.1.3. Leaf Operation 475 A leaf node Z of P2MP LSP determines its upstream LSR U for 476 as per Section 2.4.1.1, allocates a label L, and sends a P2MP 477 Label Mapping to U. 479 2.4.1.4. Transit Node operation 481 Suppose a transit node Z receives a P2MP Label Mapping from 482 LSR T. Z checks whether it already has state for . If not, Z 483 determines its upstream LSR U for as per Section 2.4.1.1. 484 Using this Label Mapping to update the label forwarding table MUST 485 NOT be done as long as LSR T is equal to LSR U. If LSR U is different 486 from LSR T, Z will allocate a label L', and install state to swap L' 487 with L over interface I associated with LSR T and send a P2MP Label 488 Mapping to LSR U. Interface I is determind via the 489 procedures in Section 2.4.1.2. 491 If Z already has state for , then Z does not send a Label 492 Mapping message for P2MP LSP . If LSR T is not equal to the 493 upstream LSR of and does not already exist as 494 forwarding state, the forwarding state updated. Assuming its old 495 forwarding state was L'-> { ..., }, its new 496 forwarding state becomes L'-> { ..., , }. If the LSR T is equal to the installed upstream LSR, the Label 498 Mapping from LSR T MUST be retained and MUST NOT update the label 499 forwarding table. 501 2.4.1.5. Root Node Operation 503 Suppose the root node Z receives a P2MP Label Mapping from 504 LSR T. Z checks whether it already has forwarding state for . 505 If not, Z creates forwarding state to push label L onto the traffic 506 that Z wants to forward over the P2MP LSP (how this traffic is 507 determined is outside the scope of this document). 509 If Z already has forwarding state for , then Z adds "push label 510 L, send over interface I" to the nexthop, where I is the interface 511 associated with LSR T and determined via the procedures in 512 Section 2.4.1.2. 514 2.4.2. Label Withdraw 516 The following section lists procedures for generating and processing 517 P2MP Label Withdraw messages for nodes that participate in a P2MP 518 LSP. An LSR should apply those procedures that apply to it, based on 519 its role in the P2MP LSP. 521 2.4.2.1. Leaf Operation 523 If a leaf node Z discovers that it has no downstream neighbors in 524 that LSP, and that it has no need to be an egress LSR for that LSP 525 (by means outside the scope of this document), then it SHOULD send a 526 Label Withdraw to its upstream LSR U for , where L is 527 the label it had previously advertised to U for . 529 2.4.2.2. Transit Node Operation 531 If a transit node Z receives a Label Withdraw message from 532 a node W, it deletes label L from its forwarding state, and sends a 533 Label Release message with label L to W. 535 If deleting L from Z's forwarding state for P2MP LSP results 536 in no state remaining for , then Z propagates the Label 537 Withdraw for , to its upstream T, by sending a Label Withdraw 538 where L1 is the label Z had previously advertised to T for 539 . 541 2.4.2.3. Root Node Operation 543 The procedure when the root node of a P2MP LSP receives a Label 544 Withdraw message are the same as for transit nodes, except that it 545 would not propagate the Label Withdraw upstream (as it has no 546 upstream). 548 2.4.3. Upstream LSR change 550 Suppose that for a given node Z participating in a P2MP LSP , 551 the upstream LSR changes from U to U' as per Section 2.4.1.1. Z MUST 552 update its forwarding state as follows. It allocates a new label, 553 L', for . The forwarding state for L' is copied from the 554 forwarding state for L, with one exception: if U' was present in the 555 forwarding state of L, it MUST NOT be installed in the forwarding 556 state of L'. Then the forwarding state for L is deleted and the 557 forwarding state for L' is installed. In addition Z MUST send a 558 Label Mapping to U' and send a Label Withdraw to 559 U. Note, if there was a downstream mapping from U that was not 560 installed in the forwarding due to Section 2.4.1.4 it can now be 561 installed. 563 While changing the upstream LSR the following must be taken into 564 consideration. If L' is added before L is removed, there is a 565 potential risk of packet duplication, and/or the creation of a 566 transient dataplane forwarding loop. If L is removed before L' is 567 added, packet loss may result. Ideally the change from L to L' is 568 done atomically such that no packet loss or duplication occurs. If 569 that is not possible, the RECOMMENDED default behavior is to remove L 570 before adding L'. 572 3. Setting up MP2MP LSPs with LDP 574 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 575 root node, zero or more transit nodes and one or more leaf LSRs 576 acting equally as Ingress or Egress LSR. A leaf node participates in 577 the setup of an MP2MP LSP by establishing both a downstream LSP, 578 which is much like a P2MP LSP from the root, and an upstream LSP 579 which is used to send traffic toward the root and other leaf nodes. 580 Transit nodes support the setup by propagating the upstream and 581 downstream LSP setup toward the root and installing the necessary 582 MPLS forwarding state. The transmission of packets from the root 583 node of a MP2MP LSP to the receivers is identical to that for a P2MP 584 LSP. Traffic from a downstream node follows the upstream LSP toward 585 the root node and branches downward along the downstream LSP as 586 required to reach other leaf nodes. A packet that is received from a 587 downstream node MUST never be forwarded back out to that same node. 588 Mapping traffic to the MP2MP LSP may happen at any leaf node. How 589 that mapping is established is outside the scope of this document. 591 Due to how a MP2MP LSP is built a leaf LSR that is sending packets on 592 the MP2MP LSP does not receive its own packets. There is also no 593 additional mechanism needed on the root or transit LSR to match 594 upstream traffic to the downstream forwarding state. Packets that 595 are forwarded over a MP2MP LSP will not traverse a link more than 596 once, with the possible exception of LAN links (see Section 3.3.1), 597 if the procedures of [RFC5331] are not provided. 599 3.1. Support for MP2MP LSP setup with LDP 601 Support for the setup of MP2MP LSPs is advertised using LDP 602 capabilities as defined in [RFC5561]. An implementation supporting 603 the MP2MP procedures specified in this document MUST implement the 604 procedures for Capability Parameters in Initialization Messages. 606 A new Capability Parameter TLV is defined, the MP2MP Capability. 607 Following is the format of the MP2MP Capability Parameter. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |1|0| MP2MP Capability TBD IANA | Length (= 1) | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 |S| Reserved | 615 +-+-+-+-+-+-+-+-+ 617 S: As specified in [RFC5561] 619 The MP2MP Capability TLV MUST be advertised in the LDP Initialization 620 Message. Advertisement of the MP2MP Capability indicates support of 621 the procedures for MP2MP LSP setup detailed in this document. If the 622 peer has not advertised the corresponding capability, then label 623 messages using the MP2MP upstream and downstream FEC Elements SHOULD 624 NOT be sent to the peer. 626 3.2. The MP2MP downstream and upstream FEC Elements. 628 For the setup of a MP2MP LSP with LDP we define 2 new protocol 629 entities, the MP2MP downstream FEC and upstream FEC Element. Both 630 elements will be used as FEC Elements in the FEC TLV. Note that the 631 MP2MP FEC Elements do not necessarily identify the traffic that must 632 be mapped to the LSP, so from that point of view, the use of the term 633 FEC is a misnomer. The description of the MP2MP FEC Elements follow. 635 The structure, encoding and error handling for the MP2MP downstream 636 and upstream FEC Elements are the same as for the P2MP FEC Element 637 described in Section 2.2. The difference is that two new FEC types 638 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 640 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 641 MUST be the only FEC Element in the FEC TLV. 643 Note, except when using the procedures of [RFC5331], the MPLS labels 644 used are "downstream-assigned" [RFC5332], even if they are bound to 645 the "upstream FEC element". 647 3.3. Using the MP2MP FEC Elements 649 This section defines the rules for the processing and propagation of 650 the MP2MP FEC Elements. The following notation is used in the 651 processing rules: 653 1. MP2MP downstream LSP (or simply downstream ): an 654 MP2MP LSP downstream path with root node address X and opaque 655 value Y. 657 2. MP2MP upstream LSP (or simply upstream ): a 658 MP2MP LSP upstream path for downstream node D with root node 659 address X and opaque value Y. 661 3. MP2MP downstream FEC Element : a FEC Element with root 662 node address X and opaque value Y used for a downstream MP2MP 663 LSP. 665 4. MP2MP upstream FEC Element : a FEC Element with root node 666 address X and opaque value Y used for an upstream MP2MP LSP. 668 5. MP2MP-D Label Mapping : A Label Mapping message with a 669 FEC TLV with a single MP2MP downstream FEC Element and 670 label TLV with label L. Label L MUST be allocated from the per- 671 platform label space (see [RFC3031] section 3.14) of the LSR 672 sending the Label Mapping Message. The use of the interface 673 label space is outside the scope of this document. 675 6. MP2MP-U Label Mapping : A Label Mapping message with a 676 FEC TLV with a single MP2MP upstream FEC Element and 677 label TLV with label Lu. Label Lu MUST be allocated from the 678 per-platform label space (see [RFC3031] section 3.14) of the LSR 679 sending the Label Mapping Message. The use of the interface 680 label space is outside the scope of this document. 682 7. MP2MP-D Label Withdraw : a Label Withdraw message with 683 a FEC TLV with a single MP2MP downstream FEC Element and 684 label TLV with label L. 686 8. MP2MP-U Label Withdraw : a Label Withdraw message with 687 a FEC TLV with a single MP2MP upstream FEC Element and 688 label TLV with label Lu. 690 9. MP2MP-D Label Release : a Label Release message with a 691 FEC TLV with a single MP2MP downstream FEC Element and 692 label TLV with label L. 694 10. MP2MP-U Label Release : a Label Release message with a 695 FEC TLV with a single MP2MP upstream FEC Element and 696 label TLV with label Lu. 698 The procedures below are organized by the role which the node plays 699 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 700 process which is outside the scope of this document. During the 701 course of the protocol operation, the root node recognizes its role 702 because it owns the root node address. A transit node is any node 703 (other then the root node) that receives a MP2MP Label Mapping 704 message (i.e., one that has leaf nodes downstream of it). 706 Note that a transit node (and indeed the root node) may also be a 707 leaf node and the root node does not have to be an ingress LSR or 708 leaf of the MP2MP LSP. 710 3.3.1. MP2MP Label Mapping 712 The remainder of This section specifies the procedures for 713 originating MP2MP Label Mapping messages and for processing received 714 MP2MP Label Mapping messages for a particular LSP. The procedures 715 for a particular LSR depend upon the role that LSR plays in the LSP 716 (ingress, transit, or egress). 718 All labels discussed here are downstream-assigned [RFC5332] except 719 those which are assigned using the procedures of Section 6. 721 3.3.1.1. Determining one's upstream MP2MP LSR 723 Determining the upstream LDP peer U for a MP2MP LSP follows 724 the procedure for a P2MP LSP described in Section 2.4.1.1. 726 3.3.1.2. Determining one's downstream MP2MP LSR 728 A LDP peer U which receives a MP2MP-D Label Mapping from a LDP peer D 729 will treat D as downstream MP2MP LSR. 731 3.3.1.3. Installing the upstream path of a MP2MP LSP 733 There are two methods for installing the upstream path of a MP2MP LSP 734 to a downstream neighbor. 736 1. We can install the upstream MP2MP path (to a downstream neighbor) 737 based on receiving a MP2MP-D Label Mapping from the downstream 738 neighbor. This will install the upstream path on a per hop by 739 hop basis. 741 2. We install the upstream MP2MP path (to a downstream neighbor) 742 based on receiving a MP2MP-U Label Mapping from the upstream 743 neighbor. An LSR does not need to wait for the MP2MP-U Label 744 Mapping if it is the root of the MP2MP LSP or already has 745 received an MP2MP-U Label Mapping from the upstream neighbor. We 746 call this method ordered mode. The typical result of this mode 747 is that the downstream path of the MP2MP is built hop by hop 748 towards the root. Once the root is reached, the root node will 749 trigger a MP2MP-U Label Mapping to the downstream neighbor(s). 751 For setting up the upstream path of a MP2MP LSP ordered mode SHOULD 752 be used. Due to ordered mode the upstream path of the MP2MP LSP is 753 installed at the leaf node once the path to the root is completed. 754 The advantage is that when a leaf starts sending immediately after 755 the upstream path is installed, packets are able to reach the root 756 node without being dropped due to an incomplete LSP. Method 1 is not 757 able to guarantee that the upstream path is completed before the leaf 758 starts sending. 760 3.3.1.4. MP2MP leaf node operation 762 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 763 as per Section 3.3.1.1, allocates a label L, and sends a 764 MP2MP-D Label Mapping to U. 766 Leaf node Z expects an MP2MP-U Label Mapping from node U 767 in response to the MP2MP-D Label Mapping it sent to node U. Z checks 768 whether it already has forwarding state for upstream . If not, 769 Z creates forwarding state to push label Lu onto the traffic that Z 770 wants to forward over the MP2MP LSP. How it determines what traffic 771 to forward on this MP2MP LSP is outside the scope of this document. 773 3.3.1.5. MP2MP transit node operation 775 Suppose node Z receives a MP2MP-D Label Mapping from LSR D. 776 Z checks whether it has forwarding state for downstream . If 777 not, Z determines its upstream LSR U for as per 778 Section 3.3.1.1. Using this Label Mapping to update the label 779 forwarding table MUST NOT be done as long as LSR D is equal to LSR U. 780 If LSR U is different from LSR D, Z will allocate a label L' and 781 install downstream forwarding state to swap label L' with label L 782 over interface I associated with LSR D and send a MP2MP-D Label 783 Mapping to U. Interface I is determined via the procedures 784 in Section 2.4.1.2. 786 If Z already has forwarding state for downstream , all that Z 787 needs to do in this case is check that LSR D is not equal to the 788 upstream LSR of and update its forwarding state. Assuming its 789 old forwarding state was L'-> { ..., }, its 790 new forwarding state becomes L'-> { ..., , 791 }. If the LSR D is equal to the installed upstream LSR, the 792 Label Mapping from LSR D MUST be retained and MUST NOT update the 793 label forwarding table. 795 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 797 Mapping from LSR U. See Section 3.3.1.3. Once the MP2MP-U 798 Label Mapping is received from LSR U, node Z checks whether it 799 already has forwarding state upstream . If it does, then no 800 further action needs to happen. If it does not, it allocates a label 801 Lu' and creates a new label swap for Lu' with Label Lu over interface 802 Iu. Interface Iu is determined via the procedures in 803 Section 2.4.1.2. In addition, it also adds the label swap(s) from 804 the forwarding state downstream , omitting the swap on 805 interface I for node D. The swap on interface I for node D is omitted 806 to prevent packet originated by D to be forwarded back to D. 808 Node Z determines the downstream MP2MP LSR as per Section 3.3.1.2, 809 and sends a MP2MP-U Label Mapping to node D. 811 3.3.1.6. MP2MP root node operation 813 3.3.1.6.1. Root node is also a leaf 815 Suppose root/leaf node Z receives a MP2MP-D Label Mapping 816 from node D. Z checks whether it already has forwarding state 817 downstream . If not, Z creates forwarding state for downstream 818 to push label L on traffic that Z wants to forward down the MP2MP 819 LSP. How it determines what traffic to forward on this MP2MP LSP is 820 outside the scope of this document. If Z already has forwarding 821 state for downstream , then Z will add the label push for L 822 over interface I to it. Interface I is determined via the procedures 823 in Section 2.4.1.2. 825 Node Z checks if it has forwarding state for upstream If 826 not, Z allocates a label Lu' and creates upstream forwarding state to 827 swap Lu' with the label swap(s) from the forwarding state downstream 828 , except the swap on interface I for node D. This allows 829 upstream traffic to go down the MP2MP to other node(s), except the 830 node from which the traffic was received. Node Z determines the 831 downstream MP2MP LSR as per section Section 3.3.1.2, and sends a 832 MP2MP-U Label Mapping to node D. Since Z is the root of 833 the tree Z will not send a MP2MP-D Label Mapping and will not receive 834 a MP2MP-U Label Mapping. 836 3.3.1.6.2. Root node is not a leaf 838 Suppose the root node Z receives a MP2MP-D Label Mapping 839 from node D. Z checks whether it already has forwarding state for 840 downstream . If not, Z creates downstream forwarding state and 841 installs a outgoing label L over interface I. Interface I is 842 determined via the procedures in Section 2.4.1.2. If Z already has 843 forwarding state for downstream , then Z will add label L over 844 interface I to the existing state. 846 Node Z checks if it has forwarding state for upstream . If 847 not, Z allocates a label Lu' and creates forwarding state to swap Lu' 848 with the label swap(s) from the forwarding state downstream , 849 except the swap for node D. This allows upstream traffic to go down 850 the MP2MP to other node(s), except the node is was received from. 851 Root node Z determines the downstream MP2MP LSR D as per 852 Section 3.3.1.2, and sends a MP2MP-U Label Mapping to it. 853 Since Z is the root of the tree Z will not send a MP2MP-D Label 854 Mapping and will not receive a MP2MP-U Label Mapping. 856 3.3.2. MP2MP Label Withdraw 858 The following section lists procedures for generating and processing 859 MP2MP Label Withdraw messages for nodes that participate in a MP2MP 860 LSP. An LSR should apply those procedures that apply to it, based on 861 its role in the MP2MP LSP. 863 3.3.2.1. MP2MP leaf operation 865 If a leaf node Z discovers (by means outside the scope of this 866 document) that it has no downstream neighbors in that LSP, and that 867 it has no need to be an egress LSR for that LSP (by means outside the 868 scope of this document), then it SHOULD send a MP2MP-D Label Withdraw 869 to its upstream LSR U for , where L is the label it 870 had previously advertised to U for . Leaf node Z will also send 871 a unsolicited label release to U to indicate that the 872 upstream path is no longer used and that Label Lu can be removed. 874 Leaf node Z expects the upstream router U to respond by sending a 875 downstream label release for L. 877 3.3.2.2. MP2MP transit node operation 879 If a transit node Z receives a MP2MP-D Label Withdraw message from node D, it deletes label L from its forwarding state 881 downstream and from all its upstream states for . Node 882 Z sends a MP2MP-D Label Release message with label L to D. Since node 883 D is no longer part of the downstream forwarding state, Z cleans up 884 the forwarding state upstream . There is no need to send an 885 MP2MP-U Label Withdraw to D because node D already removed 886 Lu and send a label release for Lu to Z. 888 If deleting L from Z's forwarding state for downstream results 889 in no state remaining for , then Z propagates the MP2MP-D Label 890 Withdraw to its upstream node U for and will also 891 send a unsolicited MP2MP-U Label Release to U to indicate 892 that the upstream path is no longer used and that Label Lu can be 893 removed. 895 3.3.2.3. MP2MP root node operation 897 The procedure when the root node of a MP2MP LSP receives a MP2MP-D 898 Label Withdraw message is the same as for transit nodes, except that 899 the root node would not propagate the Label Withdraw upstream (as it 900 has no upstream). 902 3.3.3. MP2MP Upstream LSR change 904 The procedure for changing the upstream LSR is the same as documented 905 in Section 2.4.3, except it is applied to MP2MP FECs, using the 906 procedures described in Section 3.3.1 through Section 3.3.2.3. 908 4. Micro-loops in MP LSPs 910 Micro-loops created by the unicast routing protocol during 911 convergence may also effect mLDP MP LSPs. Since the tree building 912 logic in mLDP is based on unicast routing, a unicast routing loop may 913 also result in a micro-loop in the MP LSPs. Micro-loops that involve 914 2 directly connected routers don't create a loop in mLDP. mLDP is 915 able to prevent this inconsistency by never allowing an upstream LDP 916 neighbor to be added as a downstream LDP neighbor into the Label 917 Forwarding Table (LFT) for the same FEC. Micro-loops that involve 918 more than 2 LSRs are not prevented. 920 Micro-loops that involve more than 2 LSRs may create a micro-loop in 921 the downstream path of either a MP2MP LSP or P2MP LSP and the 922 upstream path of the MP2MP LSP. The loops are transient and will 923 disappear as soon as the unicast routing protocol converges and mLDP 924 has updated the forwarding state accordingly. Micro-loops that occur 925 in the upstream path of a MP2MP LSP may be detected by including LDP 926 path vector in the MP2MP-U Label Mapping messages. These procedures 927 are currently under investigation and are subjected to further study. 929 5. The LDP MP Status TLV 931 An LDP MP capable router MAY use an LDP MP Status TLV to indicate 932 additional status for a MP LSP to its remote peers. This includes 933 signaling to peers that are either upstream or downstream of the LDP 934 MP capable router. The value of the LDP MP status TLV will remain 935 opaque to LDP and MAY encode one or more status elements. 937 The LDP MP Status TLV is encoded as follows: 939 0 1 2 3 940 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 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 |1|0| LDP MP Status Type(TBD) | Length | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Value | 945 ~ ~ 946 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. 952 Length: Length of the LDP MP Status Value in octets. 954 Value: One or more LDP MP Status Value elements. 956 5.1. The LDP MP Status Value Element 958 The LDP MP Status Value Element that is included in the LDP MP Status 959 TLV Value has the following encoding. 961 0 1 2 3 962 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 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Type | Length | Value ... | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 966 ~ ~ 967 | | 968 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 Type: The type of the LDP MP Status Value Element. IANA maintains a 974 registry of status value types (see Section 11). 976 Length: The length of the Value field, in octets. 978 Value: String of Length octets, to be interpreted as specified by 979 the Type field. 981 5.2. LDP Messages containing LDP MP Status messages 983 The LDP MP Status TLV may appear either in a Label Mapping message or 984 a LDP Notification message. 986 5.2.1. LDP MP Status sent in LDP notification messages 988 An LDP MP status TLV sent in a notification message must be 989 accompanied with a Status TLV, as described in [RFC5036]. The 990 general format of the Notification Message with an LDP MP status TLV 991 is: 993 0 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 |0| Notification (0x0001) | Message Length | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Message ID | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Status TLV | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | LDP MP Status TLV | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Optional LDP MP FEC TLV | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Optional Label TLV | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 The Status TLV status code is used to indicate that LDP MP status TLV 1010 and any additional information follows in the Notification message's 1011 "optional parameter" section. Depending on the actual contents of 1012 the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may 1013 also be present to provide context to the LDP MP Status TLV. (NOTE: 1014 Status Code is pending IANA assignment). 1016 Since the notification does not refer to any particular message, the 1017 Message Id and Message Type fields are set to 0. 1019 5.2.2. LDP MP Status TLV in Label Mapping Message 1021 An example of the Label Mapping Message defined in RFC3036 is shown 1022 below to illustrate the message with an Optional LDP MP Status TLV 1023 present. 1025 0 1 2 3 1026 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 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 |0| Label Mapping (0x0400) | Message Length | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Message ID | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | FEC TLV | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Label TLV | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Optional LDP MP Status TLV | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Additional Optional Parameters | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 6. Upstream label allocation on a LAN 1043 On a LAN, the procedures so far discussed would require the upstream 1044 LSR to send a copy of the packet to each receiver individually. If 1045 there is more than one receiver on the LAN we don't take full benefit 1046 of the multi-access capability of the network. We may optimize the 1047 bandwidth consumption on the LAN and replication overhead on the 1048 upstream LSR by using upstream label allocation [RFC5331]. 1049 Procedures on how to distribute upstream labels using LDP is 1050 documented in [I-D.ietf-mpls-ldp-upstream]. 1052 6.1. LDP Multipoint-to-Multipoint on a LAN 1054 The procedure to allocate a context label on a LAN is defined in 1055 [RFC5331]. That procedure results in each LSR on a given LAN having 1056 a context label which, on that LAN, can be used to identify itself 1057 uniquely. Each LSR advertises its context label as an upstream- 1058 assigned label, following the procedures of 1059 [I-D.ietf-mpls-ldp-upstream]. Any LSR for which the LAN is a 1060 downstream link on some P2MP or MP2MP LSP will allocate an upstream- 1061 assigned label identifying that LSP. When the LSR forwards a packet 1062 downstream on one of those LSPs, the packet's top label must be the 1063 LSR's context label, and the packet's second label is the label 1064 identifying the LSP. We will call the top label the "upstream LSR 1065 label" and the second label the "LSP label". 1067 6.1.1. MP2MP downstream forwarding 1069 The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so 1070 we will use the same procedures as defined in 1071 [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is 1072 sent to the upstream LSR. The Label Mapping that is received from 1073 the upstream LSR contains the LSP label for the MP2MP FEC and the 1074 upstream LSR context label. The MP2MP downstream path (corresponding 1075 to the LSP label) will be installed in the context specific 1076 forwarding table corresponding to the upstream LSR label. Packets 1077 sent by the upstream router can be forwarded downstream using this 1078 forwarding state based on a two label lookup. 1080 6.1.2. MP2MP upstream forwarding 1082 A MP2MP LSP also has an upstream forwarding path. Upstream packets 1083 need to be forwarded in the direction of the root and downstream on 1084 any node on the LAN that has a downstream interface for the LSP. For 1085 a given MP2MP LSP on a given LAN, exactly one LSR is considered to be 1086 the upstream LSR. If an LSR on the LAN receives a packet from one of 1087 its downstream interfaces for the LSP, and if it needs to forward the 1088 packet onto the LAN, it ensures that the packet's top label is the 1089 context label of the upstream LSR, and that its second label is the 1090 LSP label that was assigned by the upstream LSR. 1092 Other LSRs receiving the packet will not be able to tell whether the 1093 packet really came from the upstream router, but that makes no 1094 difference in the processing of the packet. The upstream LSR will 1095 see its own upstream LSR in the label, and this will enable it to 1096 determine that the packet is traveling upstream. 1098 7. Root node redundancy 1100 The root node is a single point of failure for an MP LSP, whether 1101 this is P2MP or MP2MP. The problem is particularly severe for MP2MP 1102 LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same 1103 root node to set up the MP2MP LSP, because otherwise the traffic 1104 sourced by some leafs is not received by others. Because the root 1105 node is the single point of failure for an MP LSP, we need a fast and 1106 efficient mechanism to recover from a root node failure. 1108 An MP LSP is uniquely identified in the network by the opaque value 1109 and the root node address. It is likely that the root node for an MP 1110 LSP is defined statically. The root node address may be configured 1111 on each leaf statically or learned using a dynamic protocol. How 1112 leafs learn about the root node is out of the scope of this document. 1114 Suppose that for the same opaque value we define two (or more) root 1115 node addresses and we build a tree to each root using the same opaque 1116 value. Effectively these will be treated as different MP LSPs in the 1117 network. Once the trees are built, the procedures differ for P2MP 1118 and MP2MP LSPs. The different procedures are explained in the 1119 sections below. 1121 7.1. Root node redundancy - procedures for P2MP LSPs 1123 Since all leafs have set up P2MP LSPs to all the roots, they are 1124 prepared to receive packets on either one of these LSPs. However, 1125 only one of the roots should be forwarding traffic at any given time, 1126 for the following reasons: 1) to achieve bandwidth savings in the 1127 network and 2) to ensure that the receiving leafs don't receive 1128 duplicate packets (since one cannot assume that the receiving leafs 1129 are able to discard duplicates). How the roots determine which one 1130 is the active sender is outside the scope of this document. 1132 7.2. Root node redundancy - procedures for MP2MP LSPs 1134 Since all leafs have set up an MP2MP LSP to each one of the root 1135 nodes for this opaque value, a sending leaf may pick either of the 1136 two (or more) MP2MP LSPs to forward a packet on. The leaf nodes 1137 receive the packet on one of the MP2MP LSPs. The client of the MP2MP 1138 LSP does not care on which MP2MP LSP the packet is received, as long 1139 as they are for the same opaque value. The sending leaf MUST only 1140 forward a packet on one MP2MP LSP at a given point in time. The 1141 receiving leafs are unable to discard duplicate packets because they 1142 accept on all LSPs. Using all the available MP2MP LSPs we can 1143 implement redundancy using the following procedures. 1145 A sending leaf selects a single root node out of the available roots 1146 for a given opaque value. A good strategy MAY be to look at the 1147 unicast routing table and select a root that is closest in terms of 1148 the unicast metric. As soon as the root address of the active root 1149 disappears from the unicast routing table (or becomes less 1150 attractive) due to root node or link failure, the leaf can select a 1151 new best root address and start forwarding to it directly. If 1152 multiple root nodes have the same unicast metric, the highest root 1153 node addresses MAY be selected, or per session load balancing MAY be 1154 done over the root nodes. 1156 All leafs participating in a MP2MP LSP MUST join to all the available 1157 root nodes for a given opaque value. Since the sending leaf may pick 1158 any MP2MP LSP, it must be prepared to receive on it. 1160 The advantage of pre-building multiple MP2MP LSPs for a single opaque 1161 value is that convergence from a root node failure happens as fast as 1162 the unicast routing protocol is able to notify. There is no need for 1163 an additional protocol to advertise to the leaf nodes which root node 1164 is the active root. The root selection is a local leaf policy that 1165 does not need to be coordinated with other leafs. The disadvantage 1166 of pre-building multiple MP2MP LSPs is that more label resources are 1167 used, depending on how many root nodes are defined. 1169 8. Make Before Break (MBB) 1171 An LSR selects as its upstream LSR for a MP LSP the LSR that is its 1172 next hop to the root of the LSP. When the best path to reach the 1173 root changes the LSR must choose a new upstream LSR. Sections 1174 Section 2.4.3 and Section 3.3.3 describe these procedures. 1176 When the best path to the root changes the LSP may be broken 1177 temporarily resulting in packet loss until the LSP "reconverges" to a 1178 new upstream LSR. The goal of MBB when this happens is to keep the 1179 duration of packet loss as short as possible. In addition, there are 1180 scenarios where the best path from the LSR to the root changes but 1181 the LSP continues to forward packets to the prevous next hop to the 1182 root. That may occur when a link comes up or routing metrics change. 1183 In such a case a new LSP should be established before the old LSP is 1184 removed to limit the duration of packet loss. The procedures 1185 described below deal with both scenarios in a way that an LSR does 1186 not need to know which of the events described above caused its 1187 upstream router for an MBB LSP to change. 1189 The MBB procedures are an optional extension to the MP LSP building 1190 procedures described in this draft. The procedures in this section 1191 offer a make-before-break behavior, except in cases where the new 1192 path is part of a transient routing loop involving more than 2 LSRs 1193 (also see Section 4). 1195 8.1. MBB overview 1197 The MBB procedures use additional LDP signaling. 1199 Suppose some event causes a downstream LSR-D to select a new upstream 1200 LSR-U for FEC-A. The new LSR-U may already be forwarding packets for 1201 FEC-A; that is, to downstream LSRs other than LSR-D. After LSR-U 1202 receives a label for FEC-A from LSR-D, it will notify LSR-D when it 1203 knows that the LSP for FEC-A has been established from the root to 1204 itself. When LSR-D receives this MBB notification it will change its 1205 next hop for the LSP root to LSR-U. 1207 The assumption is that if LSR-U has received an MBB notification from 1208 its upstream router for the FEC-A LSP and has installed forwarding 1209 state the LSP it is capable of forwarding packets on the LSP. At 1210 that point LSR-U should signal LSR-D by means of an MBB notification 1211 that it has become part of the tree identified by FEC-A and that 1212 LSR-D should initiate its switchover to the LSP. 1214 At LSR-U the LSP for FEC-A may be in 1 of 3 states. 1216 1. There is no state for FEC-A. 1218 2. State for FEC-A exists and LSR-U is waiting for MBB notification 1219 that the LSP from the root to it exists. 1221 3. State for FEC-A exists and the MBB notification has been received 1222 or it is the Root node for FEC-A. 1224 After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U 1225 MUST NOT reply with an MBB notification to LSR-D until its state for 1226 the LSP is state #3 above. If the state of the LSP at LSR-U is state 1227 #1 or #2, LSR-U should remember receipt of the Label Mapping message 1228 from LSR-D while waiting for an MBB notification from its upstream 1229 LSR for the LSP. When LSR-U receives the MBB notification from LSR-U 1230 it transitions to LSP state #3 and sends an MBB notification to 1231 LSR-D. 1233 8.2. The MBB Status code 1235 As noted in Section 8.1, the procedures to establish an MBB MP LSP 1236 are different from those to establish normal MP LSPs. 1238 When a downstream LSR sends a Label Mapping message for MP LSP to its 1239 upstream LSR it MAY include an LDP MP Status TLV that carries a MBB 1240 Status Code to indicate MBB procedures apply to the LSP. This new 1241 MBB Status Code MAY also appear in an LDP Notification message used 1242 by an upstream LSR to signal LSP state #3 to the downstream LSR; that 1243 is, that the upstream LSRs state for the LSP exists and that it has 1244 received notification from its upstream LSR that the LSP is in state 1245 #3. 1247 The MBB Status is a type of the LDP MP Status Value Element as 1248 described in Section 5.1. It is encoded as follows: 1250 0 1 2 3 1251 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 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | MBB Type = 1 | Length = 1 | Status code | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 MBB Type: Type 1 (to be assigned by IANA) 1258 Length: 1 1260 Status code: 1 = MBB request 1262 2 = MBB ack 1264 8.3. The MBB capability 1266 An LSR MAY advertise that it is capable of handling MBB LSPs using 1267 the capability advertisement as defined in [RFC5561]. The LDP MP MBB 1268 capability has the following format: 1270 0 1 2 3 1271 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 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 |1|0| LDP MP MBB Capability | Length = 1 | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 |S| Reserved | 1276 +-+-+-+-+-+-+-+-+ 1278 Note: LDP MP MBB Capability (Pending IANA assignment) 1280 S: As specified in [RFC5561] 1282 If an LSR has not advertised that it is MBB capable, its LDP peers 1283 MUST NOT send it messages which include MBB parameters. If an LSR 1284 receives a Label Mapping message with a MBB parameter from downstream 1285 LSR-D and its upstream LSR-U has not advertised that it is MBB 1286 capable, the LSR MUST send an MBB notification immediatly to LSR-U 1287 (see Section 8.4). If this happens an MBB MP LSP will not be 1288 established, but normal a MP LSP will be the result. 1290 8.4. The MBB procedures 1292 8.4.1. Terminology 1294 1. MBB LSP : A P2MP or MP2MP Make Before Break (MBB) LSP entry 1295 with Root Node Address X and Opaque Value Y. 1297 2. A(N, L): An Accepting element that consists of an upstream 1298 Neighbor N and Local label L. This LSR assigned label L to 1299 neighbor N for a specific MBB LSP. For an active element the 1300 corresponding Label is stored in the label forwarding database. 1302 3. iA(N, L): An inactive Accepting element that consists of an 1303 upstream neighbor N and local Label L. This LSR assigned label L 1304 to neighbor N for a specific MBB LSP. For an inactive element 1305 the corresponding Label is not stored in the label forwarding 1306 database. 1308 4. F(N, L): A Forwarding state that consists of downstream Neighbor 1309 N and Label L. This LSR is sending label packets with label L to 1310 neighbor N for a specific FEC. 1312 5. F'(N, L): A Forwarding state that has been marked for sending a 1313 MBB Notification message to Neighbor N with Label L. 1315 6. MBB Notification : A LDP notification message with a MP 1316 LSP , Label L and MBB Status code 2. 1318 7. MBB Label Mapping : A P2MP Label Mapping or MP2MP Label 1319 Mapping downstream with a FEC element , Label L and MBB 1320 Status code 1. 1322 8.4.2. Accepting elements 1324 An accepting element represents a specific label value L that has 1325 been advertised to a neighbor N for a MBB LSP and is a 1326 candidate for accepting labels switched packets on. An LSR can have 1327 two accepting elements for a specific MBB LSP LSP, only one of 1328 them MUST be active. An active element is the element for which the 1329 label value has been installed in the label forwarding database. An 1330 inactive accepting element is created after a new upstream LSR is 1331 chosen and is pending to replace the active element in the label 1332 forwarding database. Inactive elements only exist temporarily while 1333 switching to a new upstream LSR. Once the switch has been completed 1334 only one active element remains. During network convergence it is 1335 possible that an inactive accepting element is created while an other 1336 inactive accepting element is pending. If that happens the older 1337 inactive accepting element MUST be replaced with an newer inactive 1338 element. If an accepting element is removed a Label Withdraw has to 1339 be send for label L to neighbor N for . 1341 8.4.3. Procedures for upstream LSR change 1343 Suppose a node Z has a MBB LSP with an active accepting 1344 element A(N1, L1). Due to a routing change it detects a new best 1345 path for root X and selects a new upstream LSR N2. Node Z allocates 1346 a new local label L2 and creates an inactive accepting element iA(N2, 1347 L2). Node Z sends MBB Label Mapping to N2 and waits for 1348 the new upstream LSR N2 to respond with a MBB Notification for . During this transition phase there are two accepting elements, 1350 the element A(N1, L1) still accepting packets from N1 over label L1 1351 and the new inactive element iA(N2, L2). 1353 While waiting for the MBB Notification from upstream LSR N2, it is 1354 possible that another transition occurs due to a routing change. 1355 Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) 1356 is created and the old inactive element iA(N2, L2) MUST be removed. 1357 A label withdraw MUST be sent to N2 for from N2 will be ignored because the 1359 inactive element is removed. 1361 It is possible that the MBB Notification from upstream LSR is never 1362 received due to link or node failure. To prevent waiting 1363 indefinitely for the MBB Notification a timeout SHOULD be applied. 1364 As soon as the timer expires, the procedures in Section 8.4.5 are 1365 applied as if a MBB Notification was received for the inactive 1366 element. If a downstream LSR detects that the old upstream LSR went 1367 down while waiting for the MBB Notification from the new upstream 1368 LSR, the downstream LSR can immediately proceed without waiting for 1369 the timer to expire. 1371 8.4.4. Receiving a Label Mapping with MBB status code 1373 Suppose node Z has state for a MBB LSP and receives a MBB 1374 Label Mapping from N2. A new forwarding state F(N2, L2) 1375 will be added to the MP LSP if it did not already exist. If this MBB 1376 LSP has an active accepting element or node Z is the root of the MBB 1377 LSP a MBB notification is sent to node N2. If node Z has 1378 an inactive accepting element it marks the Forwarding state as . If router Z upstream LSR for happens to be N2, 1380 then Z MUST NOT send an MBB notification to N2 at once. Sending the 1381 MBB notification to N2 must be done only after Z upstream for 1382 stops being N2. 1384 8.4.5. Receiving a Notification with MBB status code 1386 Suppose node Z receives a MBB Notification from N. If node 1387 Z has state for MBB LSP and an inactive accepting element 1388 iA(N, L) that matches with N and L, we activate this accepting 1389 element and install label L in the label forwarding database. If an 1390 other active accepting was present it will be removed from the label 1391 forwarding database. 1393 If this MBB LSP also has Forwarding states marked for sending 1394 MBB Notifications, like , MBB Notifications are 1395 sent to these downstream LSRs. If node Z receives a MBB Notification 1396 for an accepting element that is not inactive or does not match the 1397 Label value and Neighbor address, the MBB notification is ignored. 1399 8.4.6. Node operation for MP2MP LSPs 1401 The procedures described above apply to the downstream path of a 1402 MP2MP LSP. The upstream path of the MP2MP is setup as normal without 1403 including a MBB Status code. If the MBB procedures apply to a MP2MP 1404 downstream FEC element, the upstream path to a node N is only 1405 installed in the label forwarding database if node N is part of the 1406 active accepting element. If node N is part of an inactive accepting 1407 element, the upstream path is installed when this inactive accepting 1408 element is activated. 1410 9. Typed Wildcard for mLDP FEC Element 1412 The format of the mLDP FEC Typed Wildcard FEC is as follows: 1414 0 1 2 3 1415 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 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Typed Wcard | Type | Len = 2 | AFI ~ 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 ~ | 1420 +-+-+-+-+-+-+-+-+ 1422 Type Wcard: As specified in [RFC5918] 1424 Type: The type of FEC Element Type. Either the P2MP FEC Element or 1425 the MP2MP FEC Element using the values defined for those FEC 1426 Elements when carried in the FEC TLV as defined in this document. 1428 Len: Len FEC Type Info, two octets (=0x02). 1430 AFI: Address Family, two octet quantity containing a value from 1431 IANA's "Address Family Numbers" registry. 1433 10. Security Considerations 1435 The same security considerations apply as for the base LDP 1436 specification, as described in [RFC5036]. 1438 The protocol specified in this document does not provide any 1439 authorization mechanism for controlling the set of LSRs that may join 1440 a given MP LSP. If such authorization is desirable, additional 1441 mechanisms, outside the scope of this document, are needed. Note 1442 that authorization policies cannot be implemented and/or configure 1443 solely at the root node of the LSP, because the root node does not 1444 learn the identities of all the leaf nodes. 1446 11. IANA Considerations 1448 This document creates three new registries to be managed by IANA. 1450 1. "LDP MP Opaque Value Element basic type" 1452 The range is 0-255, with the following values allocated in this 1453 document: 1455 1: Generic LSP identifier 1457 255: Extended Type field is present in the following two bytes 1459 The allocation policy for this space is 'Standards Action with 1460 Early Allocation' 1462 2. "LDP MP Opaque Value Element extended type" 1464 The range is 0-65335, with the following allocation policies: 1466 0-32767: Standards Action with Early Allocation 1468 32768-65535: First Come, First Served 1470 3. "LDP MP Status Value Element type" 1472 The range is 0-255, with the following value allocated in this 1473 document: 1475 1: MBB Status 1477 The allocation policy for this space is 'Standards Action with 1478 Early Allocation' 1480 The requested code point values listed below have been allocated by 1481 IANA through early allocation. 1483 This document requires allocation of three new code points from the 1484 IANA managed LDP registry "Forwarding Equivalence Class (FEC) Type 1485 Name Space". The values are: 1487 P2MP FEC type - requested value 0x06 1489 MP2MP-up FEC type - requested value 0x07 1491 MP2MP-down FEC type - requested value 0x08 1493 This document requires the assignment of three new code points for 1494 three new Capability Parameter TLVs from the IANA managed LDP 1495 registry "TLV Type Name Space", corresponding to the advertisement of 1496 the P2MP, MP2MP and MBB capabilities. The values requested are: 1498 P2MP Capability Parameter - requested value 0x0508 1500 MP2MP Capability Parameter - requested value 0x0509 1502 MBB Capability Parameter - requested value 0x050A 1504 This document requires the assignment of a LDP Status Code to 1505 indicate a LDP MP Status TLV is following in the Notification 1506 message. The value requested from the IANA managed LDP registry "LDP 1507 Status Code Name Space" is: 1509 LDP MP status - requested value 0x00000040 1511 This document requires the assigment of a new code point for a LDP MP 1512 Status TLV. The value requested from the IANA managed LDP registry 1513 "LDP TLV Type Name Space" is: 1515 LDP MP Status TLV Type - requested value 0x096F 1517 12. Acknowledgments 1519 The authors would like to thank the following individuals for their 1520 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 1521 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, 1522 George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel, Thomas Morin 1523 and Ben Niven-Jenkins. 1525 13. Contributing authors 1527 Below is a list of the contributing authors in alphabetical order: 1529 Shane Amante 1530 Level 3 Communications, LLC 1531 1025 Eldorado Blvd 1532 Broomfield, CO 80021 1533 US 1534 Email: Shane.Amante@Level3.com 1536 Luyuan Fang 1537 Cisco Systems 1538 300 Beaver Brook Road 1539 Boxborough, MA 01719 1540 US 1541 Email: lufang@cisco.com 1543 Hitoshi Fukuda 1544 NTT Communications Corporation 1545 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1546 Tokyo 100-8019, 1547 Japan 1548 Email: hitoshi.fukuda@ntt.com 1550 Yuji Kamite 1551 NTT Communications Corporation 1552 Tokyo Opera City Tower 1553 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1554 Tokyo 163-1421, 1555 Japan 1556 Email: y.kamite@ntt.com 1558 Kireeti Kompella 1559 Juniper Networks 1560 1194 N. Mathilda Ave. 1561 Sunnyvale, CA 94089 1562 US 1563 Email: kireeti@juniper.net 1565 Ina Minei 1566 Juniper Networks 1567 1194 N. Mathilda Ave. 1568 Sunnyvale, CA 94089 1569 US 1570 Email: ina@juniper.net 1571 Jean-Louis Le Roux 1572 France Telecom 1573 2, avenue Pierre-Marzin 1574 Lannion, Cedex 22307 1575 France 1576 Email: jeanlouis.leroux@francetelecom.com 1578 Bob Thomas 1579 Cisco Systems, Inc. 1580 300 Beaver Brook Road 1581 Boxborough, MA, 01719 1582 E-mail: bobthomas@alum.mit.edu 1584 Lei Wang 1585 Telenor 1586 Snaroyveien 30 1587 Fornebu 1331 1588 Norway 1589 Email: lei.wang@telenor.com 1591 IJsbrand Wijnands 1592 Cisco Systems, Inc. 1593 De kleetlaan 6a 1594 1831 Diegem 1595 Belgium 1596 E-mail: ice@cisco.com 1598 14. References 1600 14.1. Normative References 1602 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1603 Specification", RFC 5036, October 2007. 1605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1606 Requirement Levels", BCP 14, RFC 2119, March 1997. 1608 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1609 Label Switching Architecture", RFC 3031, January 2001. 1611 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1612 Label Assignment and Context-Specific Label Space", 1613 RFC 5331, August 2008. 1615 [I-D.ietf-mpls-ldp-upstream] 1616 Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment 1617 for LDP", draft-ietf-mpls-ldp-upstream-10 (work in 1618 progress), February 2011. 1620 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 1621 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 1623 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 1624 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 1625 (FEC)", RFC 5918, August 2010. 1627 [ITU.V42.1994] 1628 International Telecommunications Union, "Error-correcting 1629 Procedures for DCEs Using Asynchronous-to-Synchronous 1630 Conversion", ITU-T Recommendation V.42, 1994. 1631 http://www.itu.int/rec/T-REC-V.42-200203-I 1633 14.2. Informative References 1635 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1636 "Extensions to Resource Reservation Protocol - Traffic 1637 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1638 Switched Paths (LSPs)", RFC 4875, May 2007. 1640 [I-D.ietf-mpls-mp-ldp-reqs] 1641 Morin, T., "Requirements for Point-To-Multipoint 1642 Extensions to the Label Distribution Protocol", 1643 draft-ietf-mpls-mp-ldp-reqs-06 (work in progress), 1644 December 2010. 1646 [I-D.ietf-l3vpn-2547bis-mcast] 1647 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 1648 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 1649 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work 1650 in progress), January 2010. 1652 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 1653 Multicast Encapsulations", RFC 5332, August 2008. 1655 Authors' Addresses 1657 Ina Minei (editor) 1658 Juniper Networks 1659 1194 N. Mathilda Ave. 1660 Sunnyvale, CA 94089 1661 US 1663 Email: ina@juniper.net 1665 IJsbrand Wijnands (editor) 1666 Cisco Systems, Inc. 1667 De kleetlaan 6a 1668 Diegem 1831 1669 Belgium 1671 Email: ice@cisco.com 1673 Kireeti Kompella 1674 Juniper Networks 1675 1194 N. Mathilda Ave. 1676 Sunnyvale, CA 94089 1677 US 1679 Email: kireeti@juniper.net 1681 Bob Thomas 1682 300 Beaver Brook Road 1683 Boxborough 01719 1684 US 1686 Email: bobthomas@alum.mit.edu