idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-11.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. == 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: Suppose node Z has state for a MBB LSP and receives a MBB Label Map from N2. A new forwarding state F(N2, L2) will be added to the MP LSP if it did not already exist. If this MBB LSP has an active accepting element or node Z is the root of the MBB LSP a MBB notification is send to node N2. If node Z has an inactive accepting element it marks the Forwarding state as . If router Z upstream LSR for happens to be N2, then Z MUST not send an MBB notification to N2 at once. Sending the MBB notification to N2 must be done only after Z upstream for stops being N2. -- 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 (October 8, 2010) is 4942 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 1425, 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 (~~), 11 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: April 11, 2011 I. Wijnands (Editor) 6 B. Thomas 7 Cisco Systems, Inc. 8 October 8, 2010 10 Label Distribution Protocol Extensions for Point-to-Multipoint and 11 Multipoint-to-Multipoint Label Switched Paths 12 draft-ietf-mpls-ldp-p2mp-11 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 April 11, 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 . . . . . . . . . . . . . . . . . . . . 12 92 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 12 93 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . 20 100 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 21 101 5. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . 23 105 6.2.1. LDP MP Status sent in LDP notification messages . . . 23 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 . . . . . . . . . . . . . 25 110 7.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 25 111 8. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 112 8.1. Root node redundancy - procedures for P2MP LSPs . . . . . 26 113 8.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 114 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 27 115 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 116 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 117 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 29 118 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30 119 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30 120 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 121 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 31 122 9.4.4. Receiving a Label Map with MBB status code . . . . . . 31 123 9.4.5. Receiving a Notification with MBB status code . . . . 32 124 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 32 125 10. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 32 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 127 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33 128 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 129 14. Contributing authors . . . . . . . . . . . . . . . . . . . . . 34 130 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 131 15.1. Normative References . . . . . . . . . . . . . . . . . . . 36 132 15.2. Informative References . . . . . . . . . . . . . . . . . . 37 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 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. The algorithm used for the LSR selection is a 409 local matter. If the LSR selection is done over a LAN interface and 410 the Section 7 procedures are applied, the following procedure SHOULD 411 be applied to ensure that the same upstream LSR is elected amoung a 412 set of candidate receivers on that LAN. 414 1. The candidate upstream LSRs are numbered from lower to higher IP 415 address 417 2. The following hash is performed: H = (CRC32(Opaque value)) modulo 418 N, where N is the number of upstream LSRs. 420 3. The selected upstream LSR U is the LSR that has the number H. 422 This procedure will ensure that there is a single forwarder over the 423 LAN for a particular LSP. 425 2.4.1.2. Determining the forwarding interface to an LSR 427 Suppose LSR U receives a MP Label Map message from a downstream LSR 428 D, specifying label L. Suppose further that U is connected to D over 429 several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If U 430 needs to transmit to D a data packet whose top label is L, U is free 431 to transmit the packet on any of those interfaces. The algorithm it 432 uses to choose a particular interface and next-hop for a particular 433 such packet is a local matter. For completeness the following 434 procedure MAY be used. LSR U may do a lookup in the unicast routing 435 table to find the best interface and next-hop to reach LSR D. If the 436 next-hop and interface are also advertised by LSR D via the LDP 437 session it can be used to transmit the packet to LSR D. 439 2.4.1.3. Leaf Operation 441 A leaf node Z of P2MP LSP determines its upstream LSR U for 442 as per Section 2.4.1.1, allocates a label L, and sends a P2MP 443 Label Map to U. 445 2.4.1.4. Transit Node operation 447 Suppose a transit node Z receives a P2MP Label Map from LSR 448 T. Z checks whether it already has state for . If not, Z 449 determines its upstream LSR U for as per Section 2.4.1.1. 450 Using this Label Map to update the label forwarding table MUST NOT be 451 done as long as LSR T is equal to LSR U. If LSR U is different from 452 LSR T, Z will allocate a label L', and install state to swap L' with 453 L over interface I associated with LSR T and send a P2MP Label Map 454 to LSR U. Interface I is determind via the procedures in 455 Section 2.4.1.2. 457 If Z already has state for , then Z does not send a Label Map 458 message for P2MP LSP . All that Z needs to do in this case is 459 check that LSR T is not equal to the upstream LSR of and 460 update its forwarding state. Assuming its old forwarding state was 461 L'-> { ..., }, its new forwarding state 462 becomes L'-> { ..., , }. If the LSR T 463 is equal to the installed upstream LSR, the Label Map from LSR T MUST 464 be retained and MUST not update the label forwarding table. 466 2.4.1.5. Root Node Operation 468 Suppose the root node Z receives a P2MP Label Map from LSR 469 T. Z checks whether it already has forwarding state for . If 470 not, Z creates forwarding state to push label L onto the traffic that 471 Z wants to forward over the P2MP LSP (how this traffic is determined 472 is outside the scope of this document). 474 If Z already has forwarding state for , then Z adds "push label 475 L, send over interface I" to the nexthop, where I is the interface 476 associated with LSR T and determined via the procedures in 477 Section 2.4.1.2. 479 2.4.2. Label Withdraw 481 The following lists procedures for generating and processing P2MP 482 Label Withdraw messages for nodes that participate in a P2MP LSP. An 483 LSR should apply those procedures that apply to it, based on its role 484 in the P2MP LSP. 486 2.4.2.1. Leaf Operation 488 If a leaf node Z discovers (by means outside the scope of this 489 document) that it has no downstream neighbors in that LSP, and that 490 it has no need to be an egress LSR for that LSP, then it SHOULD send 491 a Label Withdraw to its upstream LSR U for , where L 492 is the label it had previously advertised to U for . 494 2.4.2.2. Transit Node Operation 496 If a transit node Z receives a Label Withdraw message from 497 a node W, it deletes label L from its forwarding state, and sends a 498 Label Release message with label L to W. 500 If deleting L from Z's forwarding state for P2MP LSP results 501 in no state remaining for , then Z propagates the Label 502 Withdraw for , to its upstream T, by sending a Label Withdraw 503 where L1 is the label Z had previously advertised to T for 504 . 506 2.4.2.3. Root Node Operation 508 The procedure when the root node of a P2MP LSP receives a Label 509 Withdraw message are the same as for transit nodes, except that it 510 would not propagate the Label Withdraw upstream (as it has no 511 upstream). 513 2.4.3. Upstream LSR change 515 Suppose that for a given node Z participating in a P2MP LSP , 516 the upstream LSR changes from U to U' as per Section 2.4.1.1. If U' 517 is present in the forwarding table of then it MUST be removed. 518 Z MUST also update its forwarding state by deleting the state for 519 label L, allocating a new label, L', for , and installing the 520 forwarding state for L'. In addition Z MUST send a Label Map to U' and send a Label Withdraw to U. Note, if there 522 was a downstream mapping from U that was not installed in the 523 forwarding due to Section 2.4.1.4 it can now be installed. 525 3. Shared Trees 527 The mechanism described above shows how to build a tree with a single 528 root and multiple leaves, i.e., a P2MP LSP. One can use essentially 529 the same mechanism to build Shared Trees with LDP. A Shared Tree can 530 be used by a group of routers that want to multicast traffic among 531 themselves, i.e., each node is both a root node (when it sources 532 traffic) and a leaf node (when any other member of the group sources 533 traffic). A Shared Tree offers similar functionality to a MP2MP LSP, 534 but the underlying multicasting mechanism uses a P2MP LSP. One 535 example where a Shared Tree is useful is video-conferencing. Another 536 is Virtual Private LAN Service (VPLS) [RFC4664], where for some types 537 of traffic, each device participating in a VPLS must send packets to 538 every other device in that VPLS. 540 One way to build a Shared Tree is to build an LDP P2MP LSP rooted at 541 a common point, the Shared Root (SR), and whose leaves are all the 542 members of the group. Each member of the Shared Tree unicasts 543 traffic to the SR (using, for example, the MP2P LSP created by the 544 unicast LDP FEC advertised by the SR); the SR then splices this 545 traffic into the LDP P2MP LSP. The SR may be (but need not be) a 546 member of the multicast group. 548 A major advantage of this approach is that no further protocol 549 mechanisms beyond the one already described are needed to set up a 550 Shared Tree. Furthermore, a Shared Tree is very efficient in terms 551 of the multicast state in the network, and is reasonably efficient in 552 terms of the bandwidth required to send traffic. 554 A property of this approach is that a sender will receive its own 555 packets as part of the multicast; thus a sender must be prepared to 556 recognize and discard packets that it itself has sent. For a number 557 of applications (for example, VPLS), this requirement is easy to 558 meet. Another consideration is the various techniques that can be 559 used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will 560 be described in a later revision. 562 4. Setting up MP2MP LSPs with LDP 564 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 565 root node, zero or more transit nodes and one or more leaf LSRs 566 acting equally as Ingress or Egress LSR. A leaf node participates in 567 the setup of an MP2MP LSP by establishing both a downstream LSP, 568 which is much like a P2MP LSP from the root, and an upstream LSP 569 which is used to send traffic toward the root and other leaf nodes. 570 Transit nodes support the setup by propagating the upstream and 571 downstream LSP setup toward the root and installing the necessary 572 MPLS forwarding state. The transmission of packets from the root 573 node of a MP2MP LSP to the receivers is identical to that for a P2MP 574 LSP. Traffic from a downstream node follows the upstream LSP toward 575 the root node and branches downward along the downstream LSP as 576 required to reach other leaf nodes. A packet that is received from a 577 downstream node MUST never be forwarded back out to that same node. 578 Mapping traffic to the MP2MP LSP may happen at any leaf node. How 579 that mapping is established is outside the scope of this document. 581 Due to how a MP2MP LSP is built a leaf LSR that is sending packets on 582 the MP2MP LSP does not receive its own packets. There is also no 583 additional mechanism needed on the root or transit LSR to match 584 upstream traffic to the downstream forwarding state. Packets that 585 are forwarded over a MP2MP LSP will not traverse a link more than 586 once, with the possible exception of LAN links (see Section 4.3.1), 587 if the procedures of [I-D.ietf-mpls-upstream-label] are not provided. 589 4.1. Support for MP2MP LSP setup with LDP 591 Support for the setup of MP2MP LSPs is advertised using LDP 592 capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An 593 implementation supporting the MP2MP procedures specified in this 594 document MUST implement the procedures for Capability Parameters in 595 Initialization Messages. 597 A new Capability Parameter TLV is defined, the MP2MP Capability. 598 Following is the format of the MP2MP Capability Parameter. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |1|0| MP2MP Capability (TBD IANA) | Length (= 1) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |1| Reserved | 606 +-+-+-+-+-+-+-+-+ 608 The MP2MP Capability TLV MUST be supported in the LDP Initialization 609 Message. Advertisement of the MP2MP Capability indicates support of 610 the procedures for MP2MP LSP setup detailed in this document. If the 611 peer has not advertised the corresponding capability, then no label 612 messages using the MP2MP upstream and downstream FEC Elements should 613 be sent to the peer. 615 4.2. The MP2MP downstream and upstream FEC Elements. 617 For the setup of a MP2MP LSP with LDP we define 2 new protocol 618 entities, the MP2MP downstream FEC and upstream FEC Element. Both 619 elements will be used as FEC Elements in the FEC TLV. Note that the 620 MP2MP FEC Elements do not necessarily identify the traffic that must 621 be mapped to the LSP, so from that point of view, the use of the term 622 FEC is a misnomer. The description of the MP2MP FEC Elements follow. 624 The structure, encoding and error handling for the MP2MP downstream 625 and upstream FEC Elements are the same as for the P2MP FEC Element 626 described in Section 2.2. The difference is that two new FEC types 627 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 629 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 630 MUST be the only FEC Element in the FEC TLV. 632 Note, except when using the procedures of 633 [I-D.ietf-mpls-upstream-label], the MPLS labels used are "downstream- 634 assigned" [I-D.ietf-mpls-multicast-encaps], even if they are bound to 635 the "upstream FEC element". 637 4.3. Using the MP2MP FEC Elements 639 This section defines the rules for the processing and propagation of 640 the MP2MP FEC Elements. The following notation is used in the 641 processing rules: 643 1. MP2MP downstream LSP (or simply downstream ): an 644 MP2MP LSP downstream path with root node address X and opaque 645 value Y. 647 2. MP2MP upstream LSP (or simply upstream ): a 648 MP2MP LSP upstream path for downstream node D with root node 649 address X and opaque value Y. 651 3. MP2MP downstream FEC Element : a FEC Element with root 652 node address X and opaque value Y used for a downstream MP2MP 653 LSP. 655 4. MP2MP upstream FEC Element : a FEC Element with root node 656 address X and opaque value Y used for an upstream MP2MP LSP. 658 5. MP2MP-D Label Map : A Label Map message with a FEC TLV 659 with a single MP2MP downstream FEC Element and label TLV 660 with label L. Label L MUST be allocated from the per-platform 661 label space (see [RFC3031] section 3.14) of the LSR sending the 662 Label Map Message. 664 6. MP2MP-U Label Map : A Label Map message with a FEC TLV 665 with a single MP2MP upstream FEC Element and label TLV 666 with label Lu. Label L MUST be allocated from the per-platform 667 label space (see [RFC3031] section 3.14) of the LSR sending the 668 Label Map Message. 670 7. MP2MP-D Label Withdraw : a Label Withdraw message with 671 a FEC TLV with a single MP2MP downstream FEC Element and 672 label TLV with label L. 674 8. MP2MP-U Label Withdraw : a Label Withdraw message with 675 a FEC TLV with a single MP2MP upstream FEC Element and 676 label TLV with label Lu. 678 9. MP2MP-D Label Release : a Label Release message with a 679 FEC TLV with a single MP2MP downstream FEC Element and 680 label TLV with label L. 682 10. MP2MP-U Label Release : a Label Release message with a 683 FEC TLV with a single MP2MP upstream FEC Element and 684 label TLV with label Lu. 686 The procedures below are organized by the role which the node plays 687 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 688 process which is outside the scope of this document. During the 689 course of the protocol operation, the root node recognizes its role 690 because it owns the root node address. A transit node is any node 691 (other then the root node) that receives a MP2MP Label Map message 692 (i.e., one that has leaf nodes downstream of it). 694 Note that a transit node (and indeed the root node) may also be a 695 leaf node and the root node does not have to be an ingress LSR or 696 leaf of the MP2MP LSP. 698 4.3.1. MP2MP Label Map 700 The remainder of this section specifies the procedures for 701 originating MP2MP Label Map messages and for processing received 702 MP2MP label map messages for a particular LSP. The procedures for a 703 particular LSR depend upon the role that LSR plays in the LSP 704 (ingress, transit, or egress). 706 All labels discussed here are downstream-assigned 707 [I-D.ietf-mpls-multicast-encaps] except those which are assigned 708 using the procedures of Section 7. 710 4.3.1.1. Determining one's upstream MP2MP LSR 712 Determining the upstream LDP peer U for a MP2MP LSP follows 713 the procedure for a P2MP LSP described in Section 2.4.1.1. 715 4.3.1.2. Determining one's downstream MP2MP LSR 717 A LDP peer U which receives a MP2MP-D Label Map from a LDP peer D 718 will treat D as downstream MP2MP LSR. 720 4.3.1.3. Installing the upstream path of a MP2MP LSP 722 There are two methods for installing the upstream path of a MP2MP LSP 723 to a downstream neighbor. 725 1. We can install the upstream MP2MP path (to a downstream neighbor) 726 based on receiving a MP2MP-D Label Map from the downstream 727 neighbor. This will install the upstream path on a per hop by 728 hop bases. 730 2. We install the upstream MP2MP path (to a downstream neighbor) 731 based on receiving a MP2MP-U Label Map from the upstream 732 neighbor. An LSR does not need to wait for the MP2MP-U Label Map 733 if it is the root of the MP2MP LSP or already has received an 734 MP2MP-U Label Map from the upstream neighbor. We call this 735 method ordered mode. The typical result of this mode is that the 736 downstream path of the MP2MP is build hop by hop towards the 737 root. Once the root is reached, the root node will trigger a 738 MP2MP-U Label Map to the downstream neighbor(s). 740 For setting up the upstream path of a MP2MP LSP ordered mode MUST be 741 used. Due to ordered mode the upstream path of the MP2MP LSP is 742 installed at the leaf node once the path to the root is completed. 743 The advantage is that when a leaf starts sending immediately after 744 the upstream path is installed, packets are able to reach the root 745 node without being dropped due to an incomplete LSP. Method 1 is not 746 able to guarantee that the upstream path is completed before the leaf 747 starts sending. 749 4.3.1.4. MP2MP leaf node operation 751 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 752 as per Section 4.3.1.1, allocates a label L, and sends a 753 MP2MP-D Label Map to U. 755 Leaf node Z expects an MP2MP-U Label Map from node U in 756 response to the MP2MP-D Label Map it sent to node U. Z checks whether 757 it already has forwarding state for upstream . If not, Z 758 creates forwarding state to push label Lu onto the traffic that Z 759 wants to forward over the MP2MP LSP. How it determines what traffic 760 to forward on this MP2MP LSP is outside the scope of this document. 762 4.3.1.5. MP2MP transit node operation 764 Suppose node Z receives a MP2MP-D Label Map from LSR D. Z 765 checks whether it has forwarding state for downstream . If 766 not, Z determines its upstream LSR U for as per 767 Section 4.3.1.1. Using this Label Map to update the label forwarding 768 table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U 769 is different from LSR D, Z will allocate a label L' and install 770 downstream forwarding state to swap label L' with label L over 771 interface I associated with LSR D and send a MP2MP-D Label Map to U. Interface I is determined via the procedures in 773 Section 2.4.1.2. 775 If Z already has forwarding state for downstream , all that Z 776 needs to do in this case is check that LSR D is not equal to the 777 upstream LSR of and update its forwarding state. Assuming its 778 old forwarding state was L'-> { ..., }, its 779 new forwarding state becomes L'-> { ..., , 780 }. If the LSR D is equal to the installed upstream LSR, the 781 Label Map from LSR D MUST be retained and MUST not update the label 782 forwarding table. 784 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 786 Map from LSR U. See Section 4.3.1.3. Once the MP2MP-U 787 Label Map is received from LSR U, node Z checks whether it already 788 has forwarding state upstream . If it does, then no further 789 action needs to happen. If it does not, it allocates a label Lu' and 790 creates a new label swap for Lu' with Label Lu over interface Iu. 791 Interface Iu is determined via the procedures in Section 2.4.1.2. In 792 addition, it also adds the label swap(s) from the forwarding state 793 downstream , omitting the swap on interface I for node D. The 794 swap on interface I for node D is omitted to prevent packet 795 originated by D to be forwarded back to D. 797 Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2, 798 and sends a MP2MP-U Label Map to node D. 800 4.3.1.6. MP2MP root node operation 802 4.3.1.6.1. Root node is also a leaf 804 Suppose root/leaf node Z receives a MP2MP-D Label Map from 805 node D. Z checks whether it already has forwarding state downstream 806 . If not, Z creates forwarding state for downstream to push 807 label L on traffic that Z wants to forward down the MP2MP LSP. How 808 it determines what traffic to forward on this MP2MP LSP is outside 809 the scope of this document. If Z already has forwarding state for 810 downstream , then Z will add the label push for L over 811 interface I to it. Interface I is determined via the procedures in 812 Section 2.4.1.2. 814 Node Z checks if it has forwarding state for upstream If 815 not, Z allocates a label Lu' and creates upstream forwarding state to 816 swap Lu' with the label swap(s) from the forwarding state downstream 817 , except the swap on interface I for node D. This allows 818 upstream traffic to go down the MP2MP to other node(s), except the 819 node from which the traffic was received. Node Z determines the 820 downstream MP2MP LSR as per section Section 4.3.1.2, and sends a 821 MP2MP-U Label Map to node D. Since Z is the root of the 822 tree Z will not send a MP2MP-D Label Map and will not receive a 823 MP2MP-U Label Map. 825 4.3.1.6.2. Root node is not a leaf 827 Suppose the root node Z receives a MP2MP-D Label Map from 828 node D. Z checks whether it already has forwarding state for 829 downstream . If not, Z creates downstream forwarding state and 830 installs a outgoing label L over interface I. Interface I is 831 determined via the procedures in Section 2.4.1.2. If Z already has 832 forwarding state for downstream , then Z will add label L over 833 interface I to the existing state. 835 Node Z checks if it has forwarding state for upstream . If 836 not, Z allocates a label Lu' and creates forwarding state to swap Lu' 837 with the label swap(s) from the forwarding state downstream , 838 except the swap for node D. This allows upstream traffic to go down 839 the MP2MP to other node(s), except the node is was received from. 840 Root node Z determines the downstream MP2MP LSR D as per 841 Section 4.3.1.2, and sends a MP2MP-U Label Map to it. 842 Since Z is the root of the tree Z will not send a MP2MP-D Label Map 843 and will not receive a MP2MP-U Label Map. 845 4.3.2. MP2MP Label Withdraw 847 The following lists procedures for generating and processing MP2MP 848 Label Withdraw messages for nodes that participate in a MP2MP LSP. 849 An LSR should apply those procedures that apply to it, based on its 850 role in the MP2MP LSP. 852 4.3.2.1. MP2MP leaf operation 854 If a leaf node Z discovers (by means outside the scope of this 855 document) that it has no downstream neighbors in that LSP, and that 856 it has no need to be an egress LSR for that LSP, then it SHOULD send 857 a MP2MP-D Label Withdraw to its upstream LSR U for , 858 where L is the label it had previously advertised to U for . 859 Leaf node Z will also send a unsolicited label release to 860 U to indicate that the upstream path is no longer used and that Label 861 Lu can be removed. 863 Leaf node Z expects the upstream router U to respond by sending a 864 downstream label release for L. 866 4.3.2.2. MP2MP transit node operation 868 If a transit node Z receives a MP2MP-D Label Withdraw message from node D, it deletes label L from its forwarding state 870 downstream and from all its upstream states for . Node 871 Z sends a MP2MP-D Label Release message with label L to D. Since node 872 D is no longer part of the downstream forwarding state, Z cleans up 873 the forwarding state upstream . There is no need to send an 874 MP2MP-U Label Withdraw to D because node D already removed 875 Lu and send a label release for Lu to Z. 877 If deleting L from Z's forwarding state for downstream results 878 in no state remaining for , then Z propagates the MP2MP-D Label 879 Withdraw to its upstream node U for and will also 880 send a unsolicited MP2MP-U Label Release to U to indicate 881 that the upstream path is no longer used and that Label Lu can be 882 removed. 884 4.3.2.3. MP2MP root node operation 886 The procedure when the root node of a MP2MP LSP receives a MP2MP-D 887 Label Withdraw message is the same as for transit nodes, except that 888 the root node would not propagate the Label Withdraw upstream (as it 889 has no upstream). 891 4.3.3. MP2MP Upstream LSR change 893 The procedure for changing the upstream LSR is the same as documented 894 in Section 2.4.3, except it is applied to MP2MP FECs, using the 895 procedures described in Section 4.3.1 through Section 4.3.2.3. 897 5. Micro-loops in MP LSPs 899 Micro-loops created by the unicast routing protocol during 900 convergence may also effect mLDP MP LSPs. Since the tree building 901 logic in mLDP is based on unicast routing, a unicast routing loop may 902 also result in a micro-loop in the MP LSPs. Micro-loops that involve 903 2 directly connected routers don't create a loop in mLDP. mLDP is 904 able to prevent this inconsistency by never allowing an upstream LDP 905 neighbor to be added as a downstream LDP neighbor into the LFT for 906 the same FEC. Micro-loops that involve more than 2 LSRs are not 907 prevented. 909 Micro-loops that involve more than 2 LSRs may create a micro-loop in 910 the downstream path of either a MP2MP LSP or P2MP LSP and the 911 upstream path of the MP2MP LSP. The loops are transient and will 912 disappear as soon as the unicast routing protocol converges. Micro- 913 loops that occur in the upstream path of a MP2MP LSP may be detected 914 by including LDP path vector in the MP2MP-U Label Map messages. 915 These procedures are currently under investigation and are subjected 916 to further study. 918 6. The LDP MP Status TLV 920 An LDP MP capable router MAY use an LDP MP Status TLV to indicate 921 additional status for a MP LSP to its remote peers. This includes 922 signaling to peers that are either upstream or downstream of the LDP 923 MP capable router. The value of the LDP MP status TLV will remain 924 opaque to LDP and MAY encode one or more status elements. 926 The LDP MP Status TLV is encoded as follows: 928 0 1 2 3 929 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 |1|0| LDP MP Status Type(TBD) | Length | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Value | 934 ~ ~ 935 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. 941 Length: Length of the LDP MP Status Value in octets. 943 Value: One or more LDP MP Status Value elements. 945 6.1. The LDP MP Status Value Element 947 The LDP MP Status Value Element that is included in the LDP MP Status 948 TLV Value has the following encoding. 950 0 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Type(TBD) | Length | Value ... | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 955 ~ ~ 956 | | 957 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Type: The type of the LDP MP Status Value Element is to be assigned 963 by IANA. 965 Length: The length of the Value field, in octets. 967 Value: String of Length octets, to be interpreted as specified by 968 the Type field. 970 6.2. LDP Messages containing LDP MP Status messages 972 The LDP MP status message may appear either in a label mapping 973 message or a LDP notification message. 975 6.2.1. LDP MP Status sent in LDP notification messages 977 An LDP MP status TLV sent in a notification message must be 978 accompanied with a Status TLV. The general format of the 979 Notification Message with an LDP MP status TLV is: 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 |0| Notification (0x0001) | Message Length | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Message ID | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Status TLV | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | LDP MP Status TLV | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Optional LDP MP FEC TLV | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Optional Label TLV | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 The Status TLV status code is used to indicate that LDP MP status TLV 998 and an additional information follows in the Notification message's 999 "optional parameter" section. Depending on the actual contents of 1000 the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may 1001 also be present to provide context to the LDP MP Status TLV. (NOTE: 1002 Status Code is pending IANA assignment). 1004 Since the notification does not refer to any particular message, the 1005 Message Id and Message Type fields are set to 0. 1007 6.2.2. LDP MP Status TLV in Label Mapping Message 1009 An example of the Label Mapping Message defined in RFC3036 is shown 1010 below to illustrate the message with an Optional LDP MP Status TLV 1011 present. 1013 0 1 2 3 1014 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 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 |0| Label Mapping (0x0400) | Message Length | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Message ID | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | FEC TLV | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Label TLV | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Optional LDP MP Status TLV | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Additional Optional Parameters | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 7. Upstream label allocation on a LAN 1031 On a LAN, the procedures so far discussed would require the upstream 1032 LSR to send a copy of the packet to each receiver individually. If 1033 there is more than one receiver on the LAN we don't take full benefit 1034 of the multi-access capability of the network. We may optimize the 1035 bandwidth consumption on the LAN and replication overhead on the 1036 upstream LSR by using upstream label allocation 1037 [I-D.ietf-mpls-upstream-label]. Procedures on how to distribute 1038 upstream labels using LDP is documented in 1039 [I-D.ietf-mpls-ldp-upstream]. 1041 7.1. LDP Multipoint-to-Multipoint on a LAN 1043 The procedure to allocate a context label on a LAN is defined in 1044 [I-D.ietf-mpls-upstream-label]. That procedure results in each LSR 1045 on a given LAN having a context label which, on that LAN, can be used 1046 to identify itself uniquely. Each LSR advertises its context label 1047 as an upstream-assigned label, following the procedures of 1048 [I-D.ietf-mpls-ldp-upstream]. Any LSR for which the LAN is a 1049 downstream link on some P2MP or MP2MP LSP will allocate an upstream- 1050 assigned label identifying that LSP. When the LSR forwards a packet 1051 downstream on one of those LSPs, the packet's top label must be the 1052 LSR's context label, and the packet's second label is the label 1053 identifying the LSP. We will call the top label the "upstream LSR 1054 label" and the second label the "LSP label". 1056 7.1.1. MP2MP downstream forwarding 1058 The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so 1059 we will use the same procedures as defined in 1060 [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is 1061 send to the upstream LSR. The label mapping that is received from 1062 the upstream LSR contains the LSP label for the MP2MP FEC and the 1063 upstream LSR context label. The MP2MP downstream path (corresponding 1064 to the LSP label) will be installed the context specific forwarding 1065 table corresponding to the upstream LSR label. Packets sent by the 1066 upstream router can be forwarded downstream using this forwarding 1067 state based on a two label lookup. 1069 7.1.2. MP2MP upstream forwarding 1071 A MP2MP LSP also has an upstream forwarding path. Upstream packets 1072 need to be forwarded in the direction of the root and downstream on 1073 any node on the LAN that has a downstream interface for the LSP. For 1074 a given MP2MP LSP on a given LAN, exactly one LSR is considered to be 1075 the upstream LSR. If an LSR on the LAN receives a packet from one of 1076 its downstream interfaces for the LSP, and if it needs to forward the 1077 packet onto the LAN, it ensures that the packet's top label is the 1078 context label of the upstream LSR, and that its second label is the 1079 LSP label that was assigned by the upstream LSR. 1081 Other LSRs receiving the packet will not be able to tell whether the 1082 packet really came from the upstream router, but that makes no 1083 difference in the processing of the packet. The upstream LSR will 1084 see its own upstream LSR in the label, and this will enable it to 1085 determine that the packet is traveling upstream. 1087 8. Root node redundancy 1089 The root node is a single point of failure for an MP LSP, whether 1090 this is P2MP or MP2MP. The problem is particularly severe for MP2MP 1091 LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same 1092 root node to set up the MP2MP LSP, because otherwise the traffic 1093 sourced by some leafs is not received by others. Because the root 1094 node is the single point of failure for an MP LSP, we need a fast and 1095 efficient mechanism to recover from a root node failure. 1097 An MP LSP is uniquely identified in the network by the opaque value 1098 and the root node address. It is likely that the root node for an MP 1099 LSP is defined statically. The root node address may be configured 1100 on each leaf statically or learned using a dynamic protocol. How 1101 leafs learn about the root node is out of the scope of this document. 1103 Suppose that for the same opaque value we define two (or more) root 1104 node addresses and we build a tree to each root using the same opaque 1105 value. Effectively these will be treated as different MP LSPs in the 1106 network. Once the trees are built, the procedures differ for P2MP 1107 and MP2MP LSPs. The different procedures are explained in the 1108 sections below. 1110 8.1. Root node redundancy - procedures for P2MP LSPs 1112 Since all leafs have set up P2MP LSPs to all the roots, they are 1113 prepared to receive packets on either one of these LSPs. However, 1114 only one of the roots should be forwarding traffic at any given time, 1115 for the following reasons: 1) to achieve bandwidth savings in the 1116 network and 2) to ensure that the receiving leafs don't receive 1117 duplicate packets (since one cannot assume that the receiving leafs 1118 are able to discard duplicates). How the roots determine which one 1119 is the active sender is outside the scope of this document. 1121 8.2. Root node redundancy - procedures for MP2MP LSPs 1123 Since all leafs have set up an MP2MP LSP to each one of the root 1124 nodes for this opaque value, a sending leaf may pick either of the 1125 two (or more) MP2MP LSPs to forward a packet on. The leaf nodes 1126 receive the packet on one of the MP2MP LSPs. The client of the MP2MP 1127 LSP does not care on which MP2MP LSP the packet is received, as long 1128 as they are for the same opaque value. The sending leaf MUST only 1129 forward a packet on one MP2MP LSP at a given point in time. The 1130 receiving leafs are unable to discard duplicate packets because they 1131 accept on all LSPs. Using all the available MP2MP LSPs we can 1132 implement redundancy using the following procedures. 1134 A sending leaf selects a single root node out of the available roots 1135 for a given opaque value. A good strategy MAY be to look at the 1136 unicast routing table and select a root that is closest in terms of 1137 the unicast metric. As soon as the root address of the active root 1138 disappears from the unicast routing table (or becomes less 1139 attractive) due to root node or link failure, the leaf can select a 1140 new best root address and start forwarding to it directly. If 1141 multiple root nodes have the same unicast metric, the highest root 1142 node addresses MAY be selected, or per session load balancing MAY be 1143 done over the root nodes. 1145 All leafs participating in a MP2MP LSP MUST join to all the available 1146 root nodes for a given opaque value. Since the sending leaf may pick 1147 any MP2MP LSP, it must be prepared to receive on it. 1149 The advantage of pre-building multiple MP2MP LSPs for a single opaque 1150 value is that convergence from a root node failure happens as fast as 1151 the unicast routing protocol is able to notify. There is no need for 1152 an additional protocol to advertise to the leaf nodes which root node 1153 is the active root. The root selection is a local leaf policy that 1154 does not need to be coordinated with other leafs. The disadvantage 1155 of pre-building multiple MP2MP LSPs is that more label resources are 1156 used, depending on how many root nodes are defined. 1158 9. Make Before Break (MBB) 1160 An LSR selects as its upstream LSR for a MP LSP the LSR that is its 1161 next hop to the root of the LSP. When the best path to reach the 1162 root changes the LSR must choose a new upstream LSR. Sections 1163 Section 2.4.3 and Section 4.3.3 describe these procedures. 1165 When the best path to the root changes the LSP may be broken 1166 temporarily resulting in packet loss until the LSP "reconverges" to a 1167 new upstream LSR. The goal of MBB when this happens is to keep the 1168 duration of packet loss as short as possible. In addition, there are 1169 scenarios where the best path from the LSR to the root changes but 1170 the LSP continues to forward packets to the prevous next hop to the 1171 root. That may occur when a link comes up or routing metrics change. 1172 In such a case a new LSP should be established before the old LSP is 1173 removed to limit the duration of packet loss. The procedures 1174 described below deal with both scenarios in a way that an LSR does 1175 not need to know which of the events described above caused its 1176 upstream router for an MBB LSP to change. 1178 The MBB procedures are an optional extension to the MP LSP building 1179 procedures described in this draft. The procedures in this section 1180 offer a make-before-break behavior, except in cases where the new 1181 path is part of a transient routing loop involving more than 2 LSRs 1182 (also see Section 5). 1184 9.1. MBB overview 1186 The MBB procedures use additional LDP signaling. 1188 Suppose some event causes a downstream LSR-D to select a new upstream 1189 LSR-U for FEC-A. The new LSR-U may already be forwarding packets for 1190 FEC-A; that is, to downstream LSRs other than LSR-D. After LSR-U 1191 receives a label for FEC-A from LSR-D, it will notify LSR-D when it 1192 knows that the LSP for FEC-A has been established from the root to 1193 itself. When LSR-D receives this MBB notification it will change its 1194 next hop for the LSP root to LSR-U. 1196 The assumption is that if LSR-U has received an MBB notification from 1197 its upstream router for the FEC-A LSP and has installed forwarding 1198 state the LSP it is capable of forwarding packets on the LSP. At 1199 that point LSR-U should signal LSR-D by means of an MBB notification 1200 that it has become part of the tree identified by FEC-A and that 1201 LSR-D should initiate its switchover to the LSP. 1203 At LSR-U the LSP for FEC-A may be in 1 of 3 states. 1205 1. There is no state for FEC-A. 1207 2. State for FEC-A exists and LSR-U is waiting for MBB notification 1208 that the LSP from the root to it exists. 1210 3. State for FEC-A exists and the MBB notification has been received 1211 or it is the Root node for FEC-A. 1213 After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U 1214 MUST NOT reply with an MBB notification to LSR-D until its state for 1215 the LSP is state #3 above. If the state of the LSP at LSR-U is state 1216 #1 or #2, LSR-U should remember receipt of the Label Mapping message 1217 from LSR-D while waiting for an MBB notification from its upstream 1218 LSR for the LSP. When LSR-U receives the MBB notification from LSR-U 1219 it transitions to LSP state #3 and sends an MBB notification to 1220 LSR-D. 1222 9.2. The MBB Status code 1224 As noted in Section 9.1, the procedures to establish an MBB MP LSP 1225 are different from those to establish normal MP LSPs. 1227 When a downstream LSR sends a Label Mapping message for MP LSP to its 1228 upstream LSR it MAY include an LDP MP Status TLV that carries a MBB 1229 Status Code to indicate MBB procedures apply to the LSP. This new 1230 MBB Status Code MAY also appear in an LDP Notification message used 1231 by an upstream LSR to signal LSP state #3 to the downstream LSR; that 1232 is, that the upstream LSRs state for the LSP exists and that it has 1233 received notification from its upstream LSR that the LSP is in state 1234 #3. 1236 The MBB Status is a type of the LDP MP Status Value Element as 1237 described in Section 6.1. It is encoded as follows: 1239 0 1 2 3 1240 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 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | MBB Type = 1 | Length = 1 | Status code | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 MBB Type: Type 1 (to be assigned by IANA) 1247 Length: 1 1249 Status code: 1 = MBB request 1251 2 = MBB ack 1253 9.3. The MBB capability 1255 An LSR MAY advertise that it is capable of handling MBB LSPs using 1256 the capability advertisement as defined in 1257 [I-D.ietf-mpls-ldp-capabilities]. The LDP MP MBB capability has the 1258 following format: 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 |1|0| LDP MP MBB Capability | Length = 1 | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 |1| Reserved | 1266 +-+-+-+-+-+-+-+-+ 1268 Note: LDP MP MBB Capability (Pending IANA assignment) 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 |1| Reserved | 1276 +-+-+-+-+-+-+-+-+ 1278 If an LSR has not advertised that it is MBB capable, its LDP peers 1279 MUST NOT send it messages which include MBB parameters. If an LSR 1280 receives a Label Mapping message with a MBB parameter from downstream 1281 LSR-D and its upstream LSR-U has not advertised that it is MBB 1282 capable, the LSR MUST send an MBB notification immediatly to LSR-U 1283 (see Section 9.4). If this happens an MBB MP LSP will not be 1284 established, but normal a MP LSP will be the result. 1286 9.4. The MBB procedures 1288 9.4.1. Terminology 1290 1. MBB LSP : A P2MP or MP2MP Make Before Break (MBB) LSP entry 1291 with Root Node Address X and Opaque Value Y. 1293 2. A(N, L): An Accepting element that consists of an upstream 1294 Neighbor N and Local label L. This LSR assigned label L to 1295 neighbor N for a specific MBB LSP. For an active element the 1296 corresponding Label is stored in the label forwarding database. 1298 3. iA(N, L): An inactive Accepting element that consists of an 1299 upstream neighbor N and local Label L. This LSR assigned label L 1300 to neighbor N for a specific MBB LSP. For an inactive element 1301 the corresponding Label is not stored in the label forwarding 1302 database. 1304 4. F(N, L): A Forwarding state that consists of downstream Neighbor 1305 N and Label L. This LSR is sending label packets with label L to 1306 neighbor N for a specific FEC. 1308 5. F'(N, L): A Forwarding state that has been marked for sending a 1309 MBB Notification message to Neighbor N with Label L. 1311 6. MBB Notification : A LDP notification message with a MP 1312 LSP , Label L and MBB Status code 2. 1314 7. MBB Label Map : A P2MP Label Map or MP2MP Label Map 1315 downstream with a FEC element , Label L and MBB Status code 1316 1. 1318 9.4.2. Accepting elements 1320 An accepting element represents a specific label value L that has 1321 been advertised to a neighbor N for a MBB LSP and is a 1322 candidate for accepting labels switched packets on. An LSR can have 1323 two accepting elements for a specific MBB LSP LSP, only one of 1324 them MUST be active. An active element is the element for which the 1325 label value has been installed in the label forwarding database. An 1326 inactive accepting element is created after a new upstream LSR is 1327 chosen and is pending to replace the active element in the label 1328 forwarding database. Inactive elements only exist temporarily while 1329 switching to a new upstream LSR. Once the switch has been completed 1330 only one active element remains. During network convergence it is 1331 possible that an inactive accepting element is created while an other 1332 inactive accepting element is pending. If that happens the older 1333 inactive accepting element MUST be replaced with an newer inactive 1334 element. If an accepting element is removed a Label Withdraw has to 1335 be send for label L to neighbor N for . 1337 9.4.3. Procedures for upstream LSR change 1339 Suppose a node Z has a MBB LSP with an active accepting 1340 element A(N1, L1). Due to a routing change it detects a new best 1341 path for root X and selects a new upstream LSR N2. Node Z allocates 1342 a new local label L2 and creates an inactive accepting element iA(N2, 1343 L2). Node Z sends MBB Label Map to N2 and waits for the 1344 new upstream LSR N2 to respond with a MBB Notification for . During this transition phase there are two accepting elements, 1346 the element A(N1, L1) still accepting packets from N1 over label L1 1347 and the new inactive element iA(N2, L2). 1349 While waiting for the MBB Notification from upstream LSR N2, it is 1350 possible that an other transition occurs due to a routing change. 1351 Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) 1352 is created and the old inactive element iA(N2, L2) MUST be removed. 1353 A label withdraw MUST be sent to N2 for from N2 will be ignored because the 1355 inactive element is removed. 1357 It is possible that the MBB Notification from upstream LSR is never 1358 received due to link or node failure. To prevent waiting 1359 indefinitely for the MBB Notification a timeout SHOULD be applied. 1360 As soon as the timer expires, the procedures in Section 9.4.5 are 1361 applied as if a MBB Notification was received for the inactive 1362 element. If a downstream LSR detects that the old upstream LSR went 1363 down while waiting for the MBB Notification from the new upstream 1364 LSR, the downstream LSR can immediately proceed without waiting for 1365 the timer to expire. 1367 9.4.4. Receiving a Label Map with MBB status code 1369 Suppose node Z has state for a MBB LSP and receives a MBB 1370 Label Map from N2. A new forwarding state F(N2, L2) will 1371 be added to the MP LSP if it did not already exist. If this MBB LSP 1372 has an active accepting element or node Z is the root of the MBB LSP 1373 a MBB notification is send to node N2. If node Z has an 1374 inactive accepting element it marks the Forwarding state as . If router Z upstream LSR for happens to be N2, 1376 then Z MUST not send an MBB notification to N2 at once. Sending the 1377 MBB notification to N2 must be done only after Z upstream for 1378 stops being N2. 1380 9.4.5. Receiving a Notification with MBB status code 1382 Suppose node Z receives a MBB Notification from N. If node 1383 Z has state for MBB LSP and an inactive accepting element 1384 iA(N, L) that matches with N and L, we activate this accepting 1385 element and install label L in the label forwarding database. If an 1386 other active accepting was present it will be removed from the label 1387 forwarding database. 1389 If this MBB LSP also has Forwarding states marked for sending 1390 MBB Notifications, like , MBB Notifications are 1391 send to these downstream LSRs. If node Z receives a MBB Notification 1392 for an accepting element that is not inactive or does not match the 1393 Label value and Neighbor address, the MBB notification is ignored. 1395 9.4.6. Node operation for MP2MP LSPs 1397 The procedures described above apply to the downstream path of a 1398 MP2MP LSP. The upstream path of the MP2MP is setup as normal without 1399 including a MBB Status code. If the MBB procedures apply to a MP2MP 1400 downstream FEC element, the upstream path to a node N is only 1401 installed in the label forwarding database if node N is part of the 1402 active accepting element. If node N is part of an inactive accepting 1403 element, the upstream path is installed when this inactive accepting 1404 element is activated. 1406 10. Typed Wildcard for mLDP FEC Element 1408 The format of the mLDP FEC Typed Wildcard FEC is as follows: 1410 0 1 2 3 1411 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 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | Typed Wcard | Type = mLDP | Len = 2 | AFI ~ 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 ~ | 1416 +-+-+-+-+-+-+-+-+ 1418 Type Wcard: As specified in [I-D.ietf-mpls-ldp-typed-wildcard] 1420 Type: mLDP FEC Element Type as documented in this draft. 1422 Len: Len FEC Type Info, two octets (=0x02). 1424 AFI: Address Family, two octet quantity containing a value from 1425 ADDRESS FAMILY NUMBERS in [IANA-AF]. 1427 11. Security Considerations 1429 The same security considerations apply as for the base LDP 1430 specification, as described in [RFC5036]. 1432 12. IANA considerations 1434 This document creates a new name space (the LDP MP Opaque Value 1435 Element type) that is to be managed by IANA, and the allocation of 1436 the value 1 for the type of Generic LSP Identifier. 1438 This document requires allocation of three new LDP FEC Element types: 1440 1. the P2MP FEC type - requested value 0x06 1442 2. the MP2MP-up FEC type - requested value 0x07 1444 3. the MP2MP-down FEC type - requested value 0x08 1446 This document requires the assignment of three new code points for 1447 three new Capability Parameter TLVs, corresponding to the 1448 advertisement of the P2MP, MP2MP and MBB capabilities. The values 1449 requested are: 1451 P2MP Capability Parameter - requested value 0x0508 1453 MP2MP Capability Parameter - requested value 0x0509 1455 MBB Capability Parameter - requested value 0x050A 1457 This document requires the assignment of a LDP Status Code to 1458 indicate a LDP MP Status TLV is following in the Notification 1459 message. The value requested from the LDP Status Code Name Space: 1461 LDP MP status - requested value 0x00000040 1463 This document requires the assigment of a new code point for a LDP MP 1464 Status TLV. The value requested from the LDP TLV Type Name Space: 1466 LDP MP Status TLV Type - requested value 0x096F 1468 This document creates a new name space (the LDP MP Status Value 1469 Element type) that is to be managed by IANA, and the allocation of 1470 the value 1 for the type of MBB Status. 1472 This document creates a new name space (the LDP MP Opaque Value 1473 Element type) that is to be managed by IANA. 1475 13. Acknowledgments 1477 The authors would like to thank the following individuals for their 1478 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 1479 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, 1480 George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas 1481 Morin. 1483 14. Contributing authors 1485 Below is a list of the contributing authors in alphabetical order: 1487 Shane Amante 1488 Level 3 Communications, LLC 1489 1025 Eldorado Blvd 1490 Broomfield, CO 80021 1491 US 1492 Email: Shane.Amante@Level3.com 1494 Luyuan Fang 1495 Cisco Systems 1496 300 Beaver Brook Road 1497 Boxborough, MA 01719 1498 US 1499 Email: lufang@cisco.com 1501 Hitoshi Fukuda 1502 NTT Communications Corporation 1503 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1504 Tokyo 100-8019, 1505 Japan 1506 Email: hitoshi.fukuda@ntt.com 1507 Yuji Kamite 1508 NTT Communications Corporation 1509 Tokyo Opera City Tower 1510 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1511 Tokyo 163-1421, 1512 Japan 1513 Email: y.kamite@ntt.com 1515 Kireeti Kompella 1516 Juniper Networks 1517 1194 N. Mathilda Ave. 1518 Sunnyvale, CA 94089 1519 US 1520 Email: kireeti@juniper.net 1522 Ina Minei 1523 Juniper Networks 1524 1194 N. Mathilda Ave. 1525 Sunnyvale, CA 94089 1526 US 1527 Email: ina@juniper.net 1529 Jean-Louis Le Roux 1530 France Telecom 1531 2, avenue Pierre-Marzin 1532 Lannion, Cedex 22307 1533 France 1534 Email: jeanlouis.leroux@francetelecom.com 1536 Bob Thomas 1537 Cisco Systems, Inc. 1538 300 Beaver Brook Road 1539 Boxborough, MA, 01719 1540 E-mail: bobthomas@alum.mit.edu 1542 Lei Wang 1543 Telenor 1544 Snaroyveien 30 1545 Fornebu 1331 1546 Norway 1547 Email: lei.wang@telenor.com 1548 IJsbrand Wijnands 1549 Cisco Systems, Inc. 1550 De kleetlaan 6a 1551 1831 Diegem 1552 Belgium 1553 E-mail: ice@cisco.com 1555 15. References 1557 15.1. Normative References 1559 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1560 Specification", RFC 5036, October 2007. 1562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1563 Requirement Levels", BCP 14, RFC 2119, March 1997. 1565 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1566 an On-line Database", RFC 3232, January 2002. 1568 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1569 Label Switching Architecture", RFC 3031, January 2001. 1571 [I-D.ietf-mpls-upstream-label] 1572 Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1573 Label Assignment and Context-Specific Label Space", 1574 draft-ietf-mpls-upstream-label-05 (work in progress), 1575 April 2008. 1577 [I-D.ietf-mpls-ldp-upstream] 1578 Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment 1579 for LDP", draft-ietf-mpls-ldp-upstream-02 (work in 1580 progress), November 2007. 1582 [I-D.ietf-mpls-ldp-capabilities] 1583 Thomas, B., "LDP Capabilities", 1584 draft-ietf-mpls-ldp-capabilities-02 (work in progress), 1585 March 2008. 1587 [I-D.ietf-mpls-ldp-typed-wildcard] 1588 Minei, I., Thomas, B., and R. Asati, "Label Distribution 1589 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 1590 (FEC)", draft-ietf-mpls-ldp-typed-wildcard-07 (work in 1591 progress), March 2010. 1593 15.2. Informative References 1595 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1596 Private Networks (L2VPNs)", RFC 4664, September 2006. 1598 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1599 "Extensions to Resource Reservation Protocol - Traffic 1600 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1601 Switched Paths (LSPs)", RFC 4875, May 2007. 1603 [I-D.ietf-mpls-mp-ldp-reqs] 1604 Roux, J., "Requirements for Point-To-Multipoint Extensions 1605 to the Label Distribution Protocol", 1606 draft-ietf-mpls-mp-ldp-reqs-04 (work in progress), 1607 February 2008. 1609 [I-D.ietf-l3vpn-2547bis-mcast] 1610 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 1611 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 1612 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work 1613 in progress), January 2008. 1615 [I-D.ietf-mpls-multicast-encaps] 1616 Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 1617 Multicast Encapsulations", 1618 draft-ietf-mpls-multicast-encaps-09 (work in progress), 1619 May 2008. 1621 Authors' Addresses 1623 Ina Minei 1624 Juniper Networks 1625 1194 N. Mathilda Ave. 1626 Sunnyvale, CA 94089 1627 US 1629 Email: ina@juniper.net 1631 Kireeti Kompella 1632 Juniper Networks 1633 1194 N. Mathilda Ave. 1634 Sunnyvale, CA 94089 1635 US 1637 Email: kireeti@juniper.net 1638 IJsbrand Wijnands 1639 Cisco Systems, Inc. 1640 De kleetlaan 6a 1641 Diegem 1831 1642 Belgium 1644 Email: ice@cisco.com 1646 Bob Thomas 1647 Cisco Systems, Inc. 1648 300 Beaver Brook Road 1649 Boxborough 01719 1650 US 1652 Email: bobthomas@alum.mit.edu