idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-10.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If Z already has state for , then Z does not send a Label Map message for P2MP LSP . All that Z needs to do in this case is check that LSR T is not equal to the upstream LSR of and update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. If the LSR T is equal to the installed upstream LSR, the Label Map from LSR T MUST be retained and MUST not update the label forwarding table. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If Z already has forwarding state for downstream , all that Z needs to do in this case is check that LSR D is not equal to the upstream LSR of and update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. If the LSR D is equal to the installed upstream LSR, the Label Map from LSR D MUST be retained and MUST not update the label forwarding table. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2010) is 5009 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) == Missing Reference: 'IANA-AF' is mentioned on line 1414, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3232 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-05 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-ldp-upstream-02 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-capabilities-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mp-ldp-reqs-04 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-06 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-multicast-encaps-09 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Minei (Editor) 3 Internet-Draft K. Kompella 4 Intended status: Standards Track Juniper Networks 5 Expires: January 12, 2011 I. Wijnands (Editor) 6 B. Thomas 7 Cisco Systems, Inc. 8 July 11, 2010 10 Label Distribution Protocol Extensions for Point-to-Multipoint and 11 Multipoint-to-Multipoint Label Switched Paths 12 draft-ietf-mpls-ldp-p2mp-10 14 Abstract 16 This document describes extensions to the Label Distribution Protocol 17 (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- 18 multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol 19 Label Switching (MPLS) networks. These extensions are also referred 20 to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs 21 without interacting with or relying upon any other multicast tree 22 construction protocol. Protocol elements and procedures for this 23 solution are described for building such LSPs in a receiver-initiated 24 manner. There can be various applications for P2MP/MP2MP LSPs, for 25 example IP multicast or support for multicast in BGP/MPLS L3VPNs. 26 Specification of how such applications can use a LDP signaled P2MP/ 27 MP2MP LSP is outside the scope of this document. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on January 12, 2011. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 This document may contain material from IETF Documents or IETF 68 Contributions published or made publicly available before November 69 10, 2008. The person(s) controlling the copyright in some of this 70 material may not have granted the IETF Trust the right to allow 71 modifications of such material outside the IETF Standards Process. 72 Without obtaining an adequate license from the person(s) controlling 73 the copyright in such materials, this document may not be modified 74 outside the IETF Standards Process, and derivative works of it may 75 not be created outside the IETF Standards Process, except to format 76 it for publication as an RFC or to translate it into languages other 77 than English. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.1. Conventions used in this document . . . . . . . . . . . . 4 83 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 84 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 5 85 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 6 86 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6 87 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 8 88 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 8 89 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 9 90 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 10 91 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 11 92 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 12 93 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 13 95 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 14 96 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 14 97 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15 98 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 16 99 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 19 100 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 20 101 5. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 20 102 6. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21 103 6.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22 104 6.2. LDP Messages containing LDP MP Status messages . . . . . . 22 105 6.2.1. LDP MP Status sent in LDP notification messages . . . 22 106 6.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23 107 7. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24 108 7.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24 109 7.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24 110 7.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24 111 8. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 112 8.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25 113 8.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 114 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26 115 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 116 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 117 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 118 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 119 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 120 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 121 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 122 9.4.4. Receiving a Label Map with MBB status code . . . . . . 31 123 9.4.5. Receiving a Notification with MBB status code . . . . 31 124 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 125 10. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 32 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 127 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 128 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 129 14. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33 130 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 131 15.1. Normative References . . . . . . . . . . . . . . . . . . . 35 132 15.2. Informative References . . . . . . . . . . . . . . . . . . 36 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 135 1. Introduction 137 The LDP protocol is described in [RFC5036]. It defines mechanisms 138 for setting up point-to-point (P2P) and multipoint-to-point (MP2P) 139 LSPs in the network. This document describes extensions to LDP for 140 setting up point-to-multipoint (P2MP) and multipoint-to-multipoint 141 (MP2MP) LSPs. These are collectively referred to as multipoint LSPs 142 (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) 143 node to be delivered to a number of leaf (or egress) nodes. A MP2MP 144 LSP allows traffic from multiple ingress nodes to be delivered to 145 multiple egress nodes. Only a single copy of the packet will be sent 146 on any link traversed by the MP LSP (see note at end of 147 Section 2.4.1). This is accomplished without the use of a multicast 148 protocol in the network. There can be several MP LSPs rooted at a 149 given ingress node, each with its own identifier. 151 The solution assumes that the leaf nodes of the MP LSP know the root 152 node and identifier of the MP LSP to which they belong. The 153 mechanisms for the distribution of this information are outside the 154 scope of this document. The specification of how an application can 155 use a MP LSP signaled by LDP is also outside the scope of this 156 document. 158 Interested readers may also wish to peruse the requirements draft 159 [I-D.ietf-mpls-mp-ldp-reqs] and other documents [RFC4875] and 160 [I-D.ietf-l3vpn-2547bis-mcast]. 162 1.1. Conventions used in this document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 1.2. Terminology 170 The following terminology is taken from [I-D.ietf-mpls-mp-ldp-reqs]. 172 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 174 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 175 LSRs. 177 MP2P LSP: An LSP that has one or more Ingress LSRs and one unique 178 Egress LSR. 180 MP2MP LSP: An LSP that connects a set of nodes, such that traffic 181 sent by any node in the LSP is delivered to all others. 183 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 185 Ingress LSR: An ingress LSR for a particular LSP is an LSR that can 186 send a data packet along the LSP. MP2MP LSPs can have multiple 187 ingress LSRs, P2MP LSPs have just one, and that node is often 188 referred to as the "root node". 190 Egress LSR: An egress LSR for a particular LSP is an LSR that can 191 remove a data packet from that LSP for further processing. P2P 192 and MP2P LSPs have only a single egress node, but P2MP and MP2MP 193 LSPs can have multiple egress nodes. 195 Transit LSR: An LSR that has reachability to the root of the MP LSP 196 via a directly connected upstream LSR and one or more directly 197 connected downstream LSRs. 199 Bud LSR: An LSR that is an egress but also has one or more directly 200 connected downstream LSRs. 202 Leaf node: A Leaf node can be either an Egress or Bud LSR when 203 referred in the context of a P2MP LSP. In the context of a MP2MP 204 LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and 205 can also be a Bud LSR. 207 2. Setting up P2MP LSPs with LDP 209 A P2MP LSP consists of a single root node, zero or more transit nodes 210 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 211 tear-down. Leaf nodes also install forwarding state to deliver the 212 traffic received on a P2MP LSP to wherever it needs to go; how this 213 is done is outside the scope of this document. Transit nodes install 214 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 215 down) toward the root. The root node installs forwarding state to 216 map traffic into the P2MP LSP; how the root node determines which 217 traffic should go over the P2MP LSP is outside the scope of this 218 document. 220 2.1. Support for P2MP LSP setup with LDP 222 Support for the setup of P2MP LSPs is advertised using LDP 223 capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An 224 implementation supporting the P2MP procedures specified in this 225 document MUST implement the procedures for Capability Parameters in 226 Initialization Messages. 228 A new Capability Parameter TLV is defined, the P2MP Capability. 229 Following is the format of the P2MP Capability Parameter. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |1|0| P2MP Capability (TBD IANA) | Length (= 1) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |1| Reserved | 237 +-+-+-+-+-+-+-+-+ 239 The P2MP Capability TLV MUST be supported in the LDP Initialization 240 Message. Advertisement of the P2MP Capability indicates support of 241 the procedures for P2MP LSP setup detailed in this document. If the 242 peer has not advertised the corresponding capability, then no label 243 messages using the P2MP FEC Element should be sent to the peer. 245 2.2. The P2MP FEC Element 247 For the setup of a P2MP LSP with LDP, we define one new protocol 248 entity, the P2MP FEC Element to be used as a FEC Element in the FEC 249 TLV. Note that the P2MP FEC Element does not necessarily identify 250 the traffic that must be mapped to the LSP, so from that point of 251 view, the use of the term FEC is a misnomer. The description of the 252 P2MP FEC Element follows. 254 The P2MP FEC Element consists of the address of the root of the P2MP 255 LSP and an opaque value. The opaque value consists of one or more 256 LDP MP Opaque Value Elements. The opaque value is unique within the 257 context of the root node. The combination of (Root Node Address, 258 Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. 260 The P2MP FEC Element is encoded as follows: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |P2MP Type (TBD)| Address Family | Address Length| 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 ~ Root Node Address ~ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Opaque Length | Opaque Value ... | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 271 ~ ~ 272 | | 273 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Type: The type of the P2MP FEC Element is to be assigned by IANA. 279 Address Family: Two octet quantity containing a value from ADDRESS 280 FAMILY NUMBERS in [RFC3232] that encodes the address family for 281 the Root LSR Address. 283 Address Length: Length of the Root LSR Address in octets. 285 Root Node Address: A host address encoded according to the Address 286 Family field. 288 Opaque Length: The length of the Opaque Value, in octets. 290 Opaque Value: One or more MP Opaque Value elements, uniquely 291 identifying the P2MP LSP in the context of the Root Node. This is 292 described in the next section. 294 If the Address Family is IPv4, the Address Length MUST be 4; if the 295 Address Family is IPv6, the Address Length MUST be 16. No other 296 Address Lengths are defined at present. 298 If the Address Length doesn't match the defined length for the 299 Address Family, the receiver SHOULD abort processing the message 300 containing the FEC Element, and send an "Unknown FEC" Notification 301 message to its LDP peer signaling an error. 303 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 304 be the only FEC Element in the FEC TLV. 306 2.3. The LDP MP Opaque Value Element 308 The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC 309 Elements defined in subsequent sections. It carries information that 310 is meaningful to Ingress LSRs and Leaf LSRs, but need not be 311 interpreted by Transit LSRs. 313 The LDP MP Opaque Value Element is encoded as follows: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type(TBD) | Length | Value ... | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 320 ~ ~ 321 | | 322 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Type: The type of the LDP MP Opaque Value Element is to be assigned 328 by IANA. 330 Length: The length of the Value field, in octets. 332 Value: String of Length octets, to be interpreted as specified by 333 the Type field. 335 2.3.1. The Generic LSP Identifier 337 The generic LSP identifier is a type of Opaque Value Element encoded 338 as follows: 340 Type: 1 (to be assigned by IANA) 341 Length: 4 343 Value: A 32bit integer, unique in the context of the root, as 344 identified by the root's address. 346 This type of Opaque Value Element is recommended when mapping of 347 traffic to LSPs is non-algorithmic, and done by means outside LDP. 349 2.4. Using the P2MP FEC Element 351 This section defines the rules for the processing and propagation of 352 the P2MP FEC Element. The following notation is used in the 353 processing rules: 355 1. P2MP FEC Element : a FEC Element with Root Node Address X 356 and Opaque Value Y. 358 2. P2MP Label Map : a Label Map message with a FEC TLV with 359 a single P2MP FEC Element and Label TLV with label L. 360 Label L MUST be allocated from the per-platform label space (see 361 [RFC3031] section 3.14) of the LSR sending the Label Map Message. 363 3. P2MP Label Withdraw : a Label Withdraw message with a 364 FEC TLV with a single P2MP FEC Element and Label TLV with 365 label L. 367 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 368 Address X and Opaque Value Y. 370 5. The notation L' -> { ..., } on LSR X 371 means that on receiving a packet with label L', X makes n copies 372 of the packet. For copy i of the packet, X swaps L' with Li and 373 sends it out over interface Ii. 375 The procedures below are organized by the role which the node plays 376 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 377 process which is outside the scope of this document. During the 378 course of protocol operation, the root node recognizes its role 379 because it owns the Root Node Address. A transit node is any node 380 (other than the root node) that receives a P2MP Label Map message 381 (i.e., one that has leaf nodes downstream of it). 383 Note that a transit node (and indeed the root node) may also be a 384 leaf node. 386 2.4.1. Label Map 388 The remainder of this section specifies the procedures for 389 originating P2MP Label Map messages and for processing received P2MP 390 label map messages for a particular LSP. The procedures for a 391 particular LSR depend upon the role that LSR plays in the LSP 392 (ingress, transit, or egress). 394 All labels discussed here are downstream-assigned 395 [I-D.ietf-mpls-multicast-encaps] except those which are assigned 396 using the procedures of Section 7. 398 2.4.1.1. Determining one's 'upstream LSR' 400 Each node that is either an Leaf or Transit LSR of MP LSP needs to 401 use the procedures below to select an upstream LSR. A node Z that 402 wants to join a MP LSP determines the LDP peer U which is Z's 403 next-hop on the best path from Z to the root node X. If there is more 404 than one such LDP peer, only one of them is picked. U is Z's 405 "Upstream LSR" for . 407 When there are several candidate upstream LSRs, the LSR MAY select 408 one upstream LSR using the following procedure: 410 1. The candidate upstream LSRs are numbered from lower to higher IP 411 address 413 2. The following hash is performed: H = (CRC32(Opaque value)) modulo 414 N, where N is the number of upstream LSRs. 416 3. The selected upstream LSR U is the LSR that has the number H. 418 This allows for load balancing of a set of LSPs among a set of 419 candidate upstream LSRs, while ensuring that on a LAN interface a 420 single upstream LSR is selected. 422 2.4.1.2. Determining the forwarding interface to an LSR 424 Suppose LSR U receives a MP Label Map message from a downstream LSR 425 D, specifying label L. Suppose further that U is connected to D over 426 several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If U 427 needs to transmit to D a data packet whose top label is L, U is free 428 to transmit the packet on any of those interfaces. LSR U is able to 429 discover the directly connected interfaces via the LDP Discovery 430 messages exchanged between the LSR U and D. The algorithm it uses to 431 choose a particular interface for a particular such packet is a local 432 matter. 434 2.4.1.3. Leaf Operation 436 A leaf node Z of P2MP LSP determines its upstream LSR U for 437 as per Section 2.4.1.1, allocates a label L, and sends a P2MP 438 Label Map to U. 440 2.4.1.4. Transit Node operation 442 Suppose a transit node Z receives a P2MP Label Map from LSR 443 T. Z checks whether it already has state for . If not, Z 444 determines its upstream LSR U for as per Section 2.4.1.1. 445 Using this Label Map to update the label forwarding table MUST NOT be 446 done as long as LSR T is equal to LSR U. If LSR U is different from 447 LSR T, Z will allocate a label L', and install state to swap L' with 448 L over interface I associated with LSR T and send a P2MP Label Map 449 to LSR U. Interface I is determind via the procedures in 450 Section 2.4.1.2. 452 If Z already has state for , then Z does not send a Label Map 453 message for P2MP LSP . All that Z needs to do in this case is 454 check that LSR T is not equal to the upstream LSR of and 455 update its forwarding state. Assuming its old forwarding state was 456 L'-> { ..., }, its new forwarding state 457 becomes L'-> { ..., , }. If the LSR T 458 is equal to the installed upstream LSR, the Label Map from LSR T MUST 459 be retained and MUST not update the label forwarding table. 461 2.4.1.5. Root Node Operation 463 Suppose the root node Z receives a P2MP Label Map from LSR 464 T. Z checks whether it already has forwarding state for . If 465 not, Z creates forwarding state to push label L onto the traffic that 466 Z wants to forward over the P2MP LSP (how this traffic is determined 467 is outside the scope of this document). 469 If Z already has forwarding state for , then Z adds "push label 470 L, send over interface I" to the nexthop, where I is the interface 471 associated with LSR T and determind via the procedures in 472 Section 2.4.1.2. 474 2.4.2. Label Withdraw 476 The following lists procedures for generating and processing P2MP 477 Label Withdraw messages for nodes that participate in a P2MP LSP. An 478 LSR should apply those procedures that apply to it, based on its role 479 in the P2MP LSP. 481 2.4.2.1. Leaf Operation 483 If a leaf node Z discovers (by means outside the scope of this 484 document) that it has no downstream neighbors in that LSP, and that 485 it has no need to be an egress LSR for that LSP, then it SHOULD send 486 a Label Withdraw to its upstream LSR U for , where L 487 is the label it had previously advertised to U for . 489 2.4.2.2. Transit Node Operation 491 If a transit node Z receives a Label Withdraw message from 492 a node W, it deletes label L from its forwarding state, and sends a 493 Label Release message with label L to W. 495 If deleting L from Z's forwarding state for P2MP LSP results 496 in no state remaining for , then Z propagates the Label 497 Withdraw for , to its upstream T, by sending a Label Withdraw 498 where L1 is the label Z had previously advertised to T for 499 . 501 2.4.2.3. Root Node Operation 503 The procedure when the root node of a P2MP LSP receives a Label 504 Withdraw message are the same as for transit nodes, except that it 505 would not propagate the Label Withdraw upstream (as it has no 506 upstream). 508 2.4.3. Upstream LSR change 510 Suppose that for a given node Z participating in a P2MP LSP , 511 the upstream LSR changes from U to U' as per Section 2.4.1.1. If U' 512 is present in the forwarding table of then it MUST be removed. 513 Z MUST also update its forwarding state by deleting the state for 514 label L, allocating a new label, L', for , and installing the 515 forwarding state for L'. Installing the forwarding state for L' MUST 516 NOT be done before the forwarding state L is removed to avoid 517 microloops. In addition Z MUST send a Label Map to U' and 518 send a Label Withdraw to U. Note, if there was a downstream 519 mapping from U that was not installed in the forwarding due to 520 Section 2.4.1.4 it can now be installed. 522 3. Shared Trees 524 The mechanism described above shows how to build a tree with a single 525 root and multiple leaves, i.e., a P2MP LSP. One can use essentially 526 the same mechanism to build Shared Trees with LDP. A Shared Tree can 527 be used by a group of routers that want to multicast traffic among 528 themselves, i.e., each node is both a root node (when it sources 529 traffic) and a leaf node (when any other member of the group sources 530 traffic). A Shared Tree offers similar functionality to a MP2MP LSP, 531 but the underlying multicasting mechanism uses a P2MP LSP. One 532 example where a Shared Tree is useful is video-conferencing. Another 533 is Virtual Private LAN Service (VPLS) [RFC4664], where for some types 534 of traffic, each device participating in a VPLS must send packets to 535 every other device in that VPLS. 537 One way to build a Shared Tree is to build an LDP P2MP LSP rooted at 538 a common point, the Shared Root (SR), and whose leaves are all the 539 members of the group. Each member of the Shared Tree unicasts 540 traffic to the SR (using, for example, the MP2P LSP created by the 541 unicast LDP FEC advertised by the SR); the SR then splices this 542 traffic into the LDP P2MP LSP. The SR may be (but need not be) a 543 member of the multicast group. 545 A major advantage of this approach is that no further protocol 546 mechanisms beyond the one already described are needed to set up a 547 Shared Tree. Furthermore, a Shared Tree is very efficient in terms 548 of the multicast state in the network, and is reasonably efficient in 549 terms of the bandwidth required to send traffic. 551 A property of this approach is that a sender will receive its own 552 packets as part of the multicast; thus a sender must be prepared to 553 recognize and discard packets that it itself has sent. For a number 554 of applications (for example, VPLS), this requirement is easy to 555 meet. Another consideration is the various techniques that can be 556 used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will 557 be described in a later revision. 559 4. Setting up MP2MP LSPs with LDP 561 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 562 root node, zero or more transit nodes and one or more leaf LSRs 563 acting equally as Ingress or Egress LSR. A leaf node participates in 564 the setup of an MP2MP LSP by establishing both a downstream LSP, 565 which is much like a P2MP LSP from the root, and an upstream LSP 566 which is used to send traffic toward the root and other leaf nodes. 567 Transit nodes support the setup by propagating the upstream and 568 downstream LSP setup toward the root and installing the necessary 569 MPLS forwarding state. The transmission of packets from the root 570 node of a MP2MP LSP to the receivers is identical to that for a P2MP 571 LSP. Traffic from a downstream node follows the upstream LSP toward 572 the root node and branches downward along the downstream LSP as 573 required to reach other leaf nodes. A packet that is received from a 574 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 4.3.1), 585 if the procedures of [I-D.ietf-mpls-upstream-label] are not provided. 587 4.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 [I-D.ietf-mpls-ldp-capabilities]. An 591 implementation supporting the MP2MP procedures specified in this 592 document MUST implement the procedures for Capability Parameters in 593 Initialization Messages. 595 A new Capability Parameter TLV is defined, the MP2MP Capability. 596 Following is the format of the MP2MP Capability Parameter. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |1|0| MP2MP Capability (TBD IANA) | Length (= 1) | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |1| Reserved | 604 +-+-+-+-+-+-+-+-+ 606 The MP2MP Capability TLV MUST be supported in the LDP Initialization 607 Message. Advertisement of the MP2MP Capability indicates support of 608 the procedures for MP2MP LSP setup detailed in this document. If the 609 peer has not advertised the corresponding capability, then no label 610 messages using the MP2MP upstream and downstream FEC Elements should 611 be sent to the peer. 613 4.2. The MP2MP downstream and upstream FEC Elements. 615 For the setup of a MP2MP LSP with LDP we define 2 new protocol 616 entities, the MP2MP downstream FEC and upstream FEC Element. Both 617 elements will be used as FEC Elements in the FEC TLV. Note that the 618 MP2MP FEC Elements do not necessarily identify the traffic that must 619 be mapped to the LSP, so from that point of view, the use of the term 620 FEC is a misnomer. The description of the MP2MP FEC Elements follow. 622 The structure, encoding and error handling for the MP2MP downstream 623 and upstream FEC Elements are the same as for the P2MP FEC Element 624 described in Section 2.2. The difference is that two new FEC types 625 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 627 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 628 MUST be the only FEC Element in the FEC TLV. 630 Note, except when using the procedures of 631 [I-D.ietf-mpls-upstream-label], the MPLS labels used are "downstream- 632 assigned" [I-D.ietf-mpls-multicast-encaps], even if they are bound to 633 the "upstream FEC element". 635 4.3. Using the MP2MP FEC Elements 637 This section defines the rules for the processing and propagation of 638 the MP2MP FEC Elements. The following notation is used in the 639 processing rules: 641 1. MP2MP downstream LSP (or simply downstream ): an 642 MP2MP LSP downstream path with root node address X and opaque 643 value Y. 645 2. MP2MP upstream LSP (or simply upstream ): a 646 MP2MP LSP upstream path for downstream node D with root node 647 address X and opaque value Y. 649 3. MP2MP downstream FEC Element : a FEC Element with root 650 node address X and opaque value Y used for a downstream MP2MP 651 LSP. 653 4. MP2MP upstream FEC Element : a FEC Element with root node 654 address X and opaque value Y used for an upstream MP2MP LSP. 656 5. MP2MP-D Label Map : A Label Map message with a FEC TLV 657 with a single MP2MP downstream FEC Element and label TLV 658 with label L. Label L MUST be allocated from the per-platform 659 label space (see [RFC3031] section 3.14) of the LSR sending the 660 Label Map Message. 662 6. MP2MP-U Label Map : A Label Map message with a FEC TLV 663 with a single MP2MP upstream FEC Element and label TLV 664 with label Lu. Label L MUST be allocated from the per-platform 665 label space (see [RFC3031] section 3.14) of the LSR sending the 666 Label Map Message. 668 7. MP2MP-D Label Withdraw : a Label Withdraw message with 669 a FEC TLV with a single MP2MP downstream FEC Element and 670 label TLV with label L. 672 8. MP2MP-U Label Withdraw : a Label Withdraw message with 673 a FEC TLV with a single MP2MP upstream FEC Element and 674 label TLV with label Lu. 676 9. MP2MP-D Label Release : a Label Release message with a 677 FEC TLV with a single MP2MP downstream FEC Element and 678 label TLV with label L. 680 10. MP2MP-U Label Release : a Label Release message with a 681 FEC TLV with a single MP2MP upstream FEC Element and 682 label TLV with label Lu. 684 The procedures below are organized by the role which the node plays 685 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 686 process which is outside the scope of this document. During the 687 course of the protocol operation, the root node recognizes its role 688 because it owns the root node address. A transit node is any node 689 (other then the root node) that receives a MP2MP Label Map message 690 (i.e., one that has leaf nodes downstream of it). 692 Note that a transit node (and indeed the root node) may also be a 693 leaf node and the root node does not have to be an ingress LSR or 694 leaf of the MP2MP LSP. 696 4.3.1. MP2MP Label Map 698 The remainder of this section specifies the procedures for 699 originating MP2MP Label Map messages and for processing received 700 MP2MP label map messages for a particular LSP. The procedures for a 701 particular LSR depend upon the role that LSR plays in the LSP 702 (ingress, transit, or egress). 704 All labels discussed here are downstream-assigned 705 [I-D.ietf-mpls-multicast-encaps] except those which are assigned 706 using the procedures of Section 7. 708 4.3.1.1. Determining one's upstream MP2MP LSR 710 Determining the upstream LDP peer U for a MP2MP LSP follows 711 the procedure for a P2MP LSP described in Section 2.4.1.1. 713 4.3.1.2. Determining one's downstream MP2MP LSR 715 A LDP peer U which receives a MP2MP-D Label Map from a LDP peer D 716 will treat D as downstream MP2MP LSR. 718 4.3.1.3. Installing the upstream path of a MP2MP LSP 720 There are two methods for installing the upstream path of a MP2MP LSP 721 to a downstream neighbor. 723 1. We can install the upstream MP2MP path (to a downstream neighbor) 724 based on receiving a MP2MP-D Label Map from the downstream 725 neighbor. This will install the upstream path on a per hop by 726 hop bases. 728 2. We install the upstream MP2MP path (to a downstream neighbor) 729 based on receiving a MP2MP-U Label Map from the upstream 730 neighbor. An LSR does not need to wait for the MP2MP-U Label Map 731 if it is the root of the MP2MP LSP or already has received an 732 MP2MP-U Label Map from the upstream neighbor. We call this 733 method ordered mode. The typical result of this mode is that the 734 downstream path of the MP2MP is build hop by hop towards the 735 root. Once the root is reached, the root node will trigger a 736 MP2MP-U Label Map to the downstream neighbor(s). 738 For setting up the upstream path of a MP2MP LSP ordered mode MUST be 739 used. Due to ordered mode the upstream path of the MP2MP LSP is 740 installed at the leaf node once the path to the root is completed. 741 The advantage is that when a leaf starts sending immediately after 742 the upstream path is installed, packets are able to reach the root 743 node without being dropped due to an incomplete LSP. Method 1 is not 744 able to guarantee that the upstream path is completed before the leaf 745 starts sending. 747 4.3.1.4. MP2MP leaf node operation 749 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 750 as per Section 4.3.1.1, allocates a label L, and sends a 751 MP2MP-D Label Map to U. 753 Leaf node Z expects an MP2MP-U Label Map from node U in 754 response to the MP2MP-D Label Map it sent to node U. Z checks whether 755 it already has forwarding state for upstream . If not, Z 756 creates forwarding state to push label Lu onto the traffic that Z 757 wants to forward over the MP2MP LSP. How it determines what traffic 758 to forward on this MP2MP LSP is outside the scope of this document. 760 4.3.1.5. MP2MP transit node operation 762 Suppose node Z receives a MP2MP-D Label Map from LSR D. Z 763 checks whether it has forwarding state for downstream . If 764 not, Z determines its upstream LSR U for as per 765 Section 4.3.1.1. Using this Label Map to update the label forwarding 766 table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U 767 is different from LSR D, Z will allocate a label L' and install 768 downstream forwarding state to swap label L' with label L over 769 interface I associated with LSR D and send a MP2MP-D Label Map to U. Interface I is determind via the procedures in 771 Section 2.4.1.2. 773 If Z already has forwarding state for downstream , all that Z 774 needs to do in this case is check that LSR D is not equal to the 775 upstream LSR of and update its forwarding state. Assuming its 776 old forwarding state was L'-> { ..., }, its 777 new forwarding state becomes L'-> { ..., , 778 }. If the LSR D is equal to the installed upstream LSR, the 779 Label Map from LSR D MUST be retained and MUST not update the label 780 forwarding table. 782 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 784 Map from LSR U. See Section 4.3.1.3. Once the MP2MP-U 785 Label Map is received from LSR U, node Z checks whether it already 786 has forwarding state upstream . If it does, then no further 787 action needs to happen. If it does not, it allocates a label Lu' and 788 creates a new label swap for Lu' with Label Lu over interface Iu. 789 Interface Iu is determind via the procedures in Section 2.4.1.2. In 790 addition, it also adds the label swap(s) from the forwarding state 791 downstream , omitting the swap on interface I for node D. The 792 swap on interface I for node D is omitted to prevent packet 793 originated by D to be forwarded back to D. 795 Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2, 796 and sends a MP2MP-U Label Map to node D. 798 4.3.1.6. MP2MP root node operation 800 4.3.1.6.1. Root node is also a leaf 802 Suppose root/leaf node Z receives a MP2MP-D Label Map from 803 node D. Z checks whether it already has forwarding state downstream 804 . If not, Z creates forwarding state for downstream to push 805 label L on traffic that Z wants to forward down the MP2MP LSP. How 806 it determines what traffic to forward on this MP2MP LSP is outside 807 the scope of this document. If Z already has forwarding state for 808 downstream , then Z will add the label push for L over 809 interface I to it. Interface I is determind via the procedures in 810 Section 2.4.1.2. 812 Node Z checks if it has forwarding state for upstream If 813 not, Z allocates a label Lu' and creates upstream forwarding state to 814 push Lu' with the label push(s) from the forwarding state downstream 815 , except the push on interface I for node D. This allows 816 upstream traffic to go down the MP2MP to other node(s), except the 817 node from which the traffic was received. Node Z determines the 818 downstream MP2MP LSR as per section Section 4.3.1.2, and sends a 819 MP2MP-U Label Map to node D. Since Z is the root of the 820 tree Z will not send a MP2MP-D Label Map and will not receive a 821 MP2MP-U Label Map. 823 4.3.1.6.2. Root node is not a leaf 825 Suppose the root node Z receives a MP2MP-D Label Map from 826 node D. Z checks whether it already has forwarding state for 827 downstream . If not, Z creates downstream forwarding state and 828 installs a outgoing label L over interface I. Interface I is 829 determind via the procedures in Section 2.4.1.2. If Z already has 830 forwarding state for downstream , then Z will add label L over 831 interface I to the existing state. 833 Node Z checks if it has forwarding state for upstream . If 834 not, Z allocates a label Lu' and creates forwarding state to swap Lu' 835 with the label swap(s) from the forwarding state downstream , 836 except the swap for node D. This allows upstream traffic to go down 837 the MP2MP to other node(s), except the node is was received from. 838 Root node Z determines the downstream MP2MP LSR D as per 839 Section 4.3.1.2, and sends a MP2MP-U Label Map to it. 840 Since Z is the root of the tree Z will not send a MP2MP-D Label Map 841 and will not receive a MP2MP-U Label Map. 843 4.3.2. MP2MP Label Withdraw 845 The following lists procedures for generating and processing MP2MP 846 Label Withdraw messages for nodes that participate in a MP2MP LSP. 847 An LSR should apply those procedures that apply to it, based on its 848 role in the MP2MP LSP. 850 4.3.2.1. MP2MP leaf operation 852 If a leaf node Z discovers (by means outside the scope of this 853 document) that it has no downstream neighbors in that LSP, and that 854 it has no need to be an egress LSR for that LSP, then it SHOULD send 855 a MP2MP-D Label Withdraw to its upstream LSR U for , 856 where L is the label it had previously advertised to U for . 857 Leaf node Z will also send a unsolicited label release to 858 U to indicate that the upstream path is no longer used and that Label 859 Lu can be removed. 861 Leaf node Z expects the upstream router U to respond by sending a 862 downstream label release for L. 864 4.3.2.2. MP2MP transit node operation 866 If a transit node Z receives a MP2MP-D Label Withdraw message from node D, it deletes label L from its forwarding state 868 downstream and from all its upstream states for . Node 869 Z sends a MP2MP-D Label Release message with label L to D. Since node 870 D is no longer part of the downstream forwarding state, Z cleans up 871 the forwarding state upstream . There is no need to send an 872 MP2MP-U Label Withdraw to D because node D already removed 873 Lu and send a label release for Lu to Z. 875 If deleting L from Z's forwarding state for downstream results 876 in no state remaining for , then Z propagates the MP2MP-D Label 877 Withdraw to its upstream node U for and will also 878 send a unsolicited MP2MP-U Label Release to U to indicate 879 that the upstream path is no longer used and that Label Lu can be 880 removed. 882 4.3.2.3. MP2MP root node operation 884 The procedure when the root node of a MP2MP LSP receives a MP2MP-D 885 Label Withdraw message is the same as for transit nodes, except that 886 the root node would not propagate the Label Withdraw upstream (as it 887 has no upstream). 889 4.3.3. MP2MP Upstream LSR change 891 The procedure for changing the upstream LSR is the same as documented 892 in Section 2.4.3, except it is applied to MP2MP FECs, using the 893 procedures described in Section 4.3.1 through Section 4.3.2.3. 895 5. Micro-loops in MP LSPs 897 Micro-loops created by the unicast routing protocol during 898 convergence may also effect mLDP MP LSPs. Since the tree building 899 logic in mLDP is based on unicast routing, a unicast routing loop may 900 also result in a micro-loop in the MP LSPs. Micro-loops that involve 901 2 directly connected routers don't create a loop in mLDP. mLDP is 902 able to prevent this inconsistency by never allowing an upstream LDP 903 neighbor to be added as a downstream LDP neighbor into the LFT for 904 the same FEC. Micro-loops that involve more then 2 LSRs are not 905 prevented. 907 Micro-loops that involve more then 2 LSRs may create a micro-loop in 908 the downstream path of either a MP2MP LSP or P2MP LSP and the 909 upstream path of the MP2MP LSP. The loops are transient and will 910 disappear as soon as the unicast routing protocol converges. Micro- 911 loops that occur in the upstream path of a MP2MP LSP may be detected 912 by including LDP path vector in the MP2MP-U Label Map messages. 913 These procedures are currently under investigation and are subjected 914 to further study. 916 6. The LDP MP Status TLV 918 An LDP MP capable router MAY use an LDP MP Status TLV to indicate 919 additional status for a MP LSP to its remote peers. This includes 920 signaling to peers that are either upstream or downstream of the LDP 921 MP capable router. The value of the LDP MP status TLV will remain 922 opaque to LDP and MAY encode one or more status elements. 924 The LDP MP Status TLV is encoded as follows: 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 |1|0| LDP MP Status Type(TBD) | Length | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Value | 932 ~ ~ 933 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. 939 Length: Length of the LDP MP Status Value in octets. 941 Value: One or more LDP MP Status Value elements. 943 6.1. The LDP MP Status Value Element 945 The LDP MP Status Value Element that is included in the LDP MP Status 946 TLV Value has the following encoding. 948 0 1 2 3 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Type(TBD) | Length | Value ... | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 953 ~ ~ 954 | | 955 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 Type: The type of the LDP MP Status Value Element is to be assigned 961 by IANA. 963 Length: The length of the Value field, in octets. 965 Value: String of Length octets, to be interpreted as specified by 966 the Type field. 968 6.2. LDP Messages containing LDP MP Status messages 970 The LDP MP status message may appear either in a label mapping 971 message or a LDP notification message. 973 6.2.1. LDP MP Status sent in LDP notification messages 975 An LDP MP status TLV sent in a notification message must be 976 accompanied with a Status TLV. The general format of the 977 Notification Message with an LDP MP status TLV is: 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 |0| Notification (0x0001) | Message Length | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Message ID | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Status TLV | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | LDP MP Status TLV | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Optional LDP MP FEC TLV | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Optional Label TLV | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 The Status TLV status code is used to indicate that LDP MP status TLV 996 and an additional information follows in the Notification message's 997 "optional parameter" section. Depending on the actual contents of 998 the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may 999 also be present to provide context to the LDP MP Status TLV. (NOTE: 1000 Status Code is pending IANA assignment). 1002 Since the notification does not refer to any particular message, the 1003 Message Id and Message Type fields are set to 0. 1005 6.2.2. LDP MP Status TLV in Label Mapping Message 1007 An example of the Label Mapping Message defined in RFC3036 is shown 1008 below to illustrate the message with an Optional LDP MP Status TLV 1009 present. 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 |0| Label Mapping (0x0400) | Message Length | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Message ID | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | FEC TLV | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Label TLV | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Optional LDP MP Status TLV | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Additional Optional Parameters | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 7. Upstream label allocation on a LAN 1029 On a LAN, the procedures so far discussed would require the upstream 1030 LSR to send a copy of the packet to each receiver individually. If 1031 there is more then one receiver on the LAN we don't take full benefit 1032 of the multi-access capability of the network. We may optimize the 1033 bandwidth consumption on the LAN and replication overhead on the 1034 upstream LSR by using upstream label allocation 1035 [I-D.ietf-mpls-upstream-label]. Procedures on how to distribute 1036 upstream labels using LDP is documented in 1037 [I-D.ietf-mpls-ldp-upstream]. 1039 7.1. LDP Multipoint-to-Multipoint on a LAN 1041 The procedure to allocate a context label on a LAN is defined in 1042 [I-D.ietf-mpls-upstream-label]. That procedure results in each LSR 1043 on a given LAN having a context label which, on that LAN, can be used 1044 to identify itself uniquely. Each LSR advertises its context label 1045 as an upstream-assigned label, following the procedures of 1046 [I-D.ietf-mpls-ldp-upstream]. Any LSR for which the LAN is a 1047 downstream link on some P2MP or MP2MP LSP will allocate an upstream- 1048 assigned label identifying that LSP. When the LSR forwards a packet 1049 downstream on one of those LSPs, the packet's top label must be the 1050 LSR's context label, and the packet's second label is the label 1051 identifying the LSP. We will call the top label the "upstream LSR 1052 label" and the second label the "LSP label". 1054 7.1.1. MP2MP downstream forwarding 1056 The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so 1057 we will use the same procedures as defined in 1058 [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is 1059 send to the upstream LSR. The label mapping that is received from 1060 the upstream LSR contains the LSP label for the MP2MP FEC and the 1061 upstream LSR context label. The MP2MP downstream path (corresponding 1062 to the LSP label) will be installed the context specific forwarding 1063 table corresponding to the upstream LSR label. Packets sent by the 1064 upstream router can be forwarded downstream using this forwarding 1065 state based on a two label lookup. 1067 7.1.2. MP2MP upstream forwarding 1069 A MP2MP LSP also has an upstream forwarding path. Upstream packets 1070 need to be forwarded in the direction of the root and downstream on 1071 any node on the LAN that has a downstream interface for the LSP. For 1072 a given MP2MP LSP on a given LAN, exactly one LSR is considered to be 1073 the upstream LSR. If an LSR on the LAN receives a packet from one of 1074 its downstream interfaces for the LSP, and if it needs to forward the 1075 packet onto the LAN, it ensures that the packet's top label is the 1076 context label of the upstream LSR, and that its second label is the 1077 LSP label that was assigned by the upstream LSR. 1079 Other LSRs receiving the packet will not be able to tell whether the 1080 packet really came from the upstream router, but that makes no 1081 difference in the processing of the packet. The upstream LSR will 1082 see its own upstream LSR in the label, and this will enable it to 1083 determine that the packet is traveling upstream. 1085 8. Root node redundancy 1087 The root node is a single point of failure for an MP LSP, whether 1088 this is P2MP or MP2MP. The problem is particularly severe for MP2MP 1089 LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same 1090 root node to set up the MP2MP LSP, because otherwise the traffic 1091 sourced by some leafs is not received by others. Because the root 1092 node is the single point of failure for an MP LSP, we need a fast and 1093 efficient mechanism to recover from a root node failure. 1095 An MP LSP is uniquely identified in the network by the opaque value 1096 and the root node address. It is likely that the root node for an MP 1097 LSP is defined statically. The root node address may be configured 1098 on each leaf statically or learned using a dynamic protocol. How 1099 leafs learn about the root node is out of the scope of this document. 1101 Suppose that for the same opaque value we define two (or more) root 1102 node addresses and we build a tree to each root using the same opaque 1103 value. Effectively these will be treated as different MP LSPs in the 1104 network. Once the trees are built, the procedures differ for P2MP 1105 and MP2MP LSPs. The different procedures are explained in the 1106 sections below. 1108 8.1. Root node redundancy - procedures for P2MP LSPs 1110 Since all leafs have set up P2MP LSPs to all the roots, they are 1111 prepared to receive packets on either one of these LSPs. However, 1112 only one of the roots should be forwarding traffic at any given time, 1113 for the following reasons: 1) to achieve bandwidth savings in the 1114 network and 2) to ensure that the receiving leafs don't receive 1115 duplicate packets (since one cannot assume that the receiving leafs 1116 are able to discard duplicates). How the roots determine which one 1117 is the active sender is outside the scope of this document. 1119 8.2. Root node redundancy - procedures for MP2MP LSPs 1121 Since all leafs have set up an MP2MP LSP to each one of the root 1122 nodes for this opaque value, a sending leaf may pick either of the 1123 two (or more) MP2MP LSPs to forward a packet on. The leaf nodes 1124 receive the packet on one of the MP2MP LSPs. The client of the MP2MP 1125 LSP does not care on which MP2MP LSP the packet is received, as long 1126 as they are for the same opaque value. The sending leaf MUST only 1127 forward a packet on one MP2MP LSP at a given point in time. The 1128 receiving leafs are unable to discard duplicate packets because they 1129 accept on all LSPs. Using all the available MP2MP LSPs we can 1130 implement redundancy using the following procedures. 1132 A sending leaf selects a single root node out of the available roots 1133 for a given opaque value. A good strategy MAY be to look at the 1134 unicast routing table and select a root that is closest in terms of 1135 the unicast metric. As soon as the root address of the active root 1136 disappears from the unicast routing table (or becomes less 1137 attractive) due to root node or link failure, the leaf can select a 1138 new best root address and start forwarding to it directly. If 1139 multiple root nodes have the same unicast metric, the highest root 1140 node addresses MAY be selected, or per session load balancing MAY be 1141 done over the root nodes. 1143 All leafs participating in a MP2MP LSP MUST join to all the available 1144 root nodes for a given opaque value. Since the sending leaf may pick 1145 any MP2MP LSP, it must be prepared to receive on it. 1147 The advantage of pre-building multiple MP2MP LSPs for a single opaque 1148 value is that convergence from a root node failure happens as fast as 1149 the unicast routing protocol is able to notify. There is no need for 1150 an additional protocol to advertise to the leaf nodes which root node 1151 is the active root. The root selection is a local leaf policy that 1152 does not need to be coordinated with other leafs. The disadvantage 1153 of pre-building multiple MP2MP LSPs is that more label resources are 1154 used, depending on how many root nodes are defined. 1156 9. Make Before Break (MBB) 1158 An LSR selects as its upstream LSR for a MP LSP the LSR that is its 1159 next hop to the root of the LSP. When the best path to reach the 1160 root changes the LSR must choose a new upstream LSR. Sections 1161 Section 2.4.3 and Section 4.3.3 describe these procedures. 1163 When the best path to the root changes the LSP may be broken 1164 temporarily resulting in packet loss until the LSP "reconverges" to a 1165 new upstream LSR. The goal of MBB when this happens is to keep the 1166 duration of packet loss as short as possible. In addition, there are 1167 scenarios where the best path from the LSR to the root changes but 1168 the LSP continues to forward packets to the prevous next hop to the 1169 root. That may occur when a link comes up or routing metrics change. 1170 In such a case a new LSP should be established before the old LSP is 1171 removed to limit the duration of packet loss. The procedures 1172 described below deal with both scenarios in a way that an LSR does 1173 not need to know which of the events described above caused its 1174 upstream router for an MBB LSP to change. 1176 This MBB procedures are an optional extension to the MP LSP building 1177 procedures described in this draft. 1179 9.1. MBB overview 1181 The MBB procedues 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 LSR's 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 1206 received. 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 its 1214 upstream LSR it transitions to LSP state #3 and sends an MBB 1215 notification to LSR-D. 1217 9.2. The MBB Status code 1219 As noted in Section 9.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 LSR's 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 6.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 9.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 1252 [I-D.ietf-mpls-ldp-capabilities]. The LDP MP MBB capability has the 1253 following format: 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 |1|0| LDP MP MBB Capability | Length = 1 | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 |1| Reserved | 1261 +-+-+-+-+-+-+-+-+ 1263 Note: LDP MP MBB Capability (Pending IANA assignment) 1265 0 1 2 3 1266 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 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 |1|0| LDP MP MBB Capability | Length = 1 | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 |1| Reserved | 1271 +-+-+-+-+-+-+-+-+ 1273 If an LSR has not advertised that it is MBB capable, its LDP peers 1274 MUST NOT send it messages which include MBB parameters. If an LSR 1275 receives a Label Mapping message with a MBB parameter from downstream 1276 LSR-D and its upstream LSR-U has not advertised that it is MBB 1277 capable, the LSR MUST send an MBB notification immediatly to LSR-U 1278 (see Section 9.4). If this happens an MBB MP LSP will not be 1279 established, but normal a MP LSP will be the result. 1281 9.4. The MBB procedures 1283 9.4.1. Terminology 1285 1. MBB LSP : A P2MP or MP2MP Make Before Break (MBB) LSP entry 1286 with Root Node Address X and Opaque Value Y. 1288 2. A(N, L): An Accepting element that consists of an upstream 1289 Neighbor N and Local label L. This LSR assigned label L to 1290 neighbor N for a specific MBB LSP. For an active element the 1291 corresponding Label is stored in the label forwarding database. 1293 3. iA(N, L): An inactive Accepting element that consists of an 1294 upstream neighbor N and local Label L. This LSR assigned label L 1295 to neighbor N for a specific MBB LSP. For an inactive element 1296 the corresponding Label is not stored in the label forwarding 1297 database. 1299 4. F(N, L): A Forwarding state that consists of downstream Neighbor 1300 N and Label L. This LSR is sending label packets with label L to 1301 neighbor N for a specific FEC. 1303 5. F'(N, L): A Forwarding state that has been marked for sending a 1304 MBB Notification message to Neighbor N with Label L. 1306 6. MBB Notification : A LDP notification message with a MP 1307 LSP , Label L and MBB Status code 2. 1309 7. MBB Label Map : A P2MP Label Map or MP2MP Label Map 1310 downstream with a FEC element , Label L and MBB Status code 1311 1. 1313 9.4.2. Accepting elements 1315 An accepting element represents a specific label value L that has 1316 been advertised to a neighbor N for a MBB LSP and is a 1317 candidate for accepting labels switched packets on. An LSR can have 1318 two accepting elements for a specific MBB LSP LSP, only one of 1319 them MUST be active. An active element is the element for which the 1320 label value has been installed in the label forwarding database. An 1321 inactive accepting element is created after a new upstream LSR is 1322 chosen and is pending to replace the active element in the label 1323 forwarding database. Inactive elements only exist temporarily while 1324 switching to a new upstream LSR. Once the switch has been completed 1325 only one active element remains. During network convergence it is 1326 possible that an inactive accepting element is created while an other 1327 inactive accepting element is pending. If that happens the older 1328 inactive accepting element MUST be replaced with an newer inactive 1329 element. If an accepting element is removed a Label Withdraw has to 1330 be send for label L to neighbor N for . 1332 9.4.3. Procedures for upstream LSR change 1334 Suppose a node Z has a MBB LSP with an active accepting 1335 element A(N1, L1). Due to a routing change it detects a new best 1336 path for root X and selects a new upstream LSR N2. Node Z allocates 1337 a new local label L2 and creates an inactive accepting element iA(N2, 1338 L2). Node Z sends MBB Label Map to N2 and waits for the 1339 new upstream LSR N2 to respond with a MBB Notification for . During this transition phase there are two accepting elements, 1341 the element A(N1, L1) still accepting packets from N1 over label L1 1342 and the new inactive element iA(N2, L2). 1344 While waiting for the MBB Notification from upstream LSR N2, it is 1345 possible that an other transition occurs due to a routing change. 1346 Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) 1347 is created and the old inactive element iA(N2, L2) MUST be removed. 1348 A label withdraw MUST be sent to N2 for from N2 will be ignored because the 1350 inactive element is removed. 1352 It is possible that the MBB Notification from upstream LSR is never 1353 received due to link or node failure. To prevent waiting 1354 indefinitely for the MBB Notification a timeout SHOULD be applied. 1355 As soon as the timer expires, the procedures in Section 9.4.5 are 1356 applied as if a MBB Notification was received for the inactive 1357 element. 1359 9.4.4. Receiving a Label Map with MBB status code 1361 Suppose node Z has state for a MBB LSP and receives a MBB 1362 Label Map from N2. A new forwarding state F(N2, L2) will 1363 be added to the MP LSP if it did not already exist. If this MBB LSP 1364 has an active accepting element or node Z is the root of the MBB LSP 1365 a MBB notification is send to node N2. If node Z has an 1366 inactive accepting element it marks the Forwarding state as . 1369 9.4.5. Receiving a Notification with MBB status code 1371 Suppose node Z receives a MBB Notification from N. If node 1372 Z has state for MBB LSP and an inactive accepting element 1373 iA(N, L) that matches with N and L, we activate this accepting 1374 element and install label L in the label forwarding database. If an 1375 other active accepting was present it will be removed from the label 1376 forwarding database. 1378 If this MBB LSP also has Forwarding states marked for sending 1379 MBB Notifications, like , MBB Notifications are 1380 send to these downstream LSRs. If node Z receives a MBB Notification 1381 for an accepting element that is not inactive or does not match the 1382 Label value and Neighbor address, the MBB notification is ignored. 1384 9.4.6. Node operation for MP2MP LSPs 1386 The procedures described above apply to the downstream path of a 1387 MP2MP LSP. The upstream path of the MP2MP is setup as normal without 1388 including a MBB Status code. If the MBB procedures apply to a MP2MP 1389 downstream FEC element, the upstream path to a node N is only 1390 installed in the label forwarding database if node N is part of the 1391 active accepting element. If node N is part of an inactive accepting 1392 element, the upstream path is installed when this inactive accepting 1393 element is activated. 1395 10. Typed Wildcard for mLDP FEC Element 1397 The format of the mLDP FEC Typed Wildcard FEC is as follows: 1399 0 1 2 3 1400 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 2 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Typed Wcard | Type = mLDP | Len = 2 | AFI ~ 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 ~ | 1405 +-+-+-+-+-+-+-+-+ 1407 Type Wcard: As specified in [I-D.ietf-mpls-ldp-typed-wildcard] 1409 Type: mLDP FEC Element Type as documented in this draft. 1411 Len: Len FEC Type Info, two octets (=0x02). 1413 AFI: Address Family, two octet quantity containing a value from 1414 ADDRESS FAMILY NUMBERS in [IANA-AF]. 1416 11. Security Considerations 1418 The same security considerations apply as for the base LDP 1419 specification, as described in [RFC5036]. 1421 12. IANA considerations 1423 This document creates a new name space (the LDP MP Opaque Value 1424 Element type) that is to be managed by IANA, and the allocation of 1425 the value 1 for the type of Generic LSP Identifier. 1427 This document requires allocation of three new LDP FEC Element types: 1429 1. the P2MP FEC type - requested value 0x06 1431 2. the MP2MP-up FEC type - requested value 0x07 1433 3. the MP2MP-down FEC type - requested value 0x08 1435 This document requires the assignment of three new code points for 1436 three new Capability Parameter TLVs, corresponding to the 1437 advertisement of the P2MP, MP2MP and MBB capabilities. The values 1438 requested are: 1440 P2MP Capability Parameter - requested value 0x0508 1442 MP2MP Capability Parameter - requested value 0x0509 1444 MBB Capability Parameter - requested value 0x050A 1446 This document requires the assignment of a LDP Status Code to 1447 indicate a LDP MP Status TLV is following in the Notification 1448 message. The value requested from the LDP Status Code Name Space: 1450 LDP MP status - requested value 0x00000040 1452 This document requires the assigment of a new code point for a LDP MP 1453 Status TLV. The value requested from the LDP TLV Type Name Space: 1455 LDP MP Status TLV Type - requested value 0x096F 1457 This document creates a new name space (the LDP MP Status Value 1458 Element type) that is to be managed by IANA, and the allocation of 1459 the value 1 for the type of MBB Status. 1461 This document creates a new name space (the LDP MP Opaque Value 1462 Element type) that is to be managed by IANA. 1464 13. Acknowledgments 1466 The authors would like to thank the following individuals for their 1467 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 1468 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, 1469 George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas 1470 Morin. 1472 14. Contributing authors 1474 Below is a list of the contributing authors in alphabetical order: 1476 Shane Amante 1477 Level 3 Communications, LLC 1478 1025 Eldorado Blvd 1479 Broomfield, CO 80021 1480 US 1481 Email: Shane.Amante@Level3.com 1482 Luyuan Fang 1483 Cisco Systems 1484 300 Beaver Brook Road 1485 Boxborough, MA 01719 1486 US 1487 Email: lufang@cisco.com 1489 Hitoshi Fukuda 1490 NTT Communications Corporation 1491 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1492 Tokyo 100-8019, 1493 Japan 1494 Email: hitoshi.fukuda@ntt.com 1496 Yuji Kamite 1497 NTT Communications Corporation 1498 Tokyo Opera City Tower 1499 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1500 Tokyo 163-1421, 1501 Japan 1502 Email: y.kamite@ntt.com 1504 Kireeti Kompella 1505 Juniper Networks 1506 1194 N. Mathilda Ave. 1507 Sunnyvale, CA 94089 1508 US 1509 Email: kireeti@juniper.net 1511 Ina Minei 1512 Juniper Networks 1513 1194 N. Mathilda Ave. 1514 Sunnyvale, CA 94089 1515 US 1516 Email: ina@juniper.net 1518 Jean-Louis Le Roux 1519 France Telecom 1520 2, avenue Pierre-Marzin 1521 Lannion, Cedex 22307 1522 France 1523 Email: jeanlouis.leroux@francetelecom.com 1524 Bob Thomas 1525 Cisco Systems, Inc. 1526 300 Beaver Brook Road 1527 Boxborough, MA, 01719 1528 E-mail: bobthomas@alum.mit.edu 1530 Lei Wang 1531 Telenor 1532 Snaroyveien 30 1533 Fornebu 1331 1534 Norway 1535 Email: lei.wang@telenor.com 1537 IJsbrand Wijnands 1538 Cisco Systems, Inc. 1539 De kleetlaan 6a 1540 1831 Diegem 1541 Belgium 1542 E-mail: ice@cisco.com 1544 15. References 1546 15.1. Normative References 1548 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1549 Specification", RFC 5036, October 2007. 1551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1552 Requirement Levels", BCP 14, RFC 2119, March 1997. 1554 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1555 an On-line Database", RFC 3232, January 2002. 1557 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1558 Label Switching Architecture", RFC 3031, January 2001. 1560 [I-D.ietf-mpls-upstream-label] 1561 Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1562 Label Assignment and Context-Specific Label Space", 1563 draft-ietf-mpls-upstream-label-05 (work in progress), 1564 April 2008. 1566 [I-D.ietf-mpls-ldp-upstream] 1567 Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment 1568 for LDP", draft-ietf-mpls-ldp-upstream-02 (work in 1569 progress), November 2007. 1571 [I-D.ietf-mpls-ldp-capabilities] 1572 Thomas, B., "LDP Capabilities", 1573 draft-ietf-mpls-ldp-capabilities-02 (work in progress), 1574 March 2008. 1576 [I-D.ietf-mpls-ldp-typed-wildcard] 1577 Minei, I., Thomas, B., and R. Asati, "Label Distribution 1578 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 1579 (FEC)", draft-ietf-mpls-ldp-typed-wildcard-07 (work in 1580 progress), March 2010. 1582 15.2. Informative References 1584 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1585 Private Networks (L2VPNs)", RFC 4664, September 2006. 1587 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1588 "Extensions to Resource Reservation Protocol - Traffic 1589 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1590 Switched Paths (LSPs)", RFC 4875, May 2007. 1592 [I-D.ietf-mpls-mp-ldp-reqs] 1593 Roux, J., "Requirements for Point-To-Multipoint Extensions 1594 to the Label Distribution Protocol", 1595 draft-ietf-mpls-mp-ldp-reqs-04 (work in progress), 1596 February 2008. 1598 [I-D.ietf-l3vpn-2547bis-mcast] 1599 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 1600 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 1601 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work 1602 in progress), January 2008. 1604 [I-D.ietf-mpls-multicast-encaps] 1605 Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 1606 Multicast Encapsulations", 1607 draft-ietf-mpls-multicast-encaps-09 (work in progress), 1608 May 2008. 1610 Authors' Addresses 1612 Ina Minei 1613 Juniper Networks 1614 1194 N. Mathilda Ave. 1615 Sunnyvale, CA 94089 1616 US 1618 Email: ina@juniper.net 1620 Kireeti Kompella 1621 Juniper Networks 1622 1194 N. Mathilda Ave. 1623 Sunnyvale, CA 94089 1624 US 1626 Email: kireeti@juniper.net 1628 IJsbrand Wijnands 1629 Cisco Systems, Inc. 1630 De kleetlaan 6a 1631 Diegem 1831 1632 Belgium 1634 Email: ice@cisco.com 1636 Bob Thomas 1637 Cisco Systems, Inc. 1638 300 Beaver Brook Road 1639 Boxborough 01719 1640 US 1642 Email: bobthomas@alum.mit.edu