idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1596. 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 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2008) is 5825 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '3') == 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 (~~), 8 warnings (==), 8 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: November 2, 2008 I. Wijnands (Editor) 6 B. Thomas 7 Cisco Systems, Inc. 8 May 2008 10 Label Distribution Protocol Extensions for Point-to-Multipoint and 11 Multipoint-to-Multipoint Label Switched Paths 12 draft-ietf-mpls-ldp-p2mp-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 2, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes extensions to the Label Distribution Protocol 46 (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- 47 multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol 48 Label Switching (MPLS) networks. LDP constructs the P2MP or MP2MP 49 LSPs without interacting with or relying upon any other multicast 50 tree construction protocol. Protocol elements and procedures for 51 this solution are described for building such LSPs in a receiver- 52 initiated manner. There can be various applications for P2MP/MP2MP 53 LSPs, for example IP multicast or support for multicast in BGP/MPLS 54 L3VPNs. Specification of how such applications can use a LDP 55 signaled P2MP/MP2MP LSP is outside the scope of this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Conventions used in this document . . . . . . . . . . . . 4 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 5 63 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 6 64 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6 65 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 8 66 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 8 67 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 9 68 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 10 69 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 11 70 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 12 71 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 13 73 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 13 74 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 14 75 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 14 76 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 16 77 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 19 78 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 20 79 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 20 80 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 20 81 5.2. LDP Messages containing LDP MP Status messages . . . . . . 21 82 5.2.1. LDP MP Status sent in LDP notification messages . . . 21 83 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 22 84 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 22 85 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 23 86 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 23 87 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 23 88 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 23 89 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 24 90 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 24 91 8. MP LSP micro loops . . . . . . . . . . . . . . . . . . . . . . 25 92 8.1. MP2MP upstream path . . . . . . . . . . . . . . . . . . . 25 93 8.2. MP2MP micro loop prevention procedures . . . . . . . . . . 26 94 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26 95 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 26 96 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 27 97 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 98 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 99 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 100 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 29 101 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 102 9.4.4. Receiving a Label Map with MBB status code . . . . . . 30 103 9.4.5. Receiving a Notification with MBB status code . . . . 31 104 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 106 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 107 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 108 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 32 109 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 110 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 111 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 113 Intellectual Property and Copyright Statements . . . . . . . . . . 37 115 1. Introduction 117 The LDP protocol is described in [1]. It defines mechanisms for 118 setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs 119 in the network. This document describes extensions to LDP for 120 setting up point-to-multipoint (P2MP) and multipoint-to-multipoint 121 (MP2MP) LSPs. These are collectively referred to as multipoint LSPs 122 (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) 123 node to be delivered to a number of leaf (or egress) nodes. A MP2MP 124 LSP allows traffic from multiple ingress nodes to be delivered to 125 multiple egress nodes. Only a single copy of the packet will be sent 126 on any link traversed by the MP LSP (see note at end of 127 Section 2.4.1). This is accomplished without the use of a multicast 128 protocol in the network. There can be several MP LSPs rooted at a 129 given ingress node, each with its own identifier. 131 The solution assumes that the leaf nodes of the MP LSP know the root 132 node and identifier of the MP LSP to which they belong. The 133 mechanisms for the distribution of this information are outside the 134 scope of this document. The specification of how an application can 135 use a MP LSP signaled by LDP is also outside the scope of this 136 document. 138 Interested readers may also wish to peruse the requirements draft [9] 139 and other documents [8] and [10]. 141 1.1. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [2]. 147 1.2. Terminology 149 The following terminology is taken from [9]. 151 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 153 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 154 LSRs. 156 MP2P LSP: An LSP that has one or more Ingress LSRs and one unique 157 Egress LSR. 159 MP2MP LSP: An LSP that connects a set of nodes, such that traffic 160 sent by any node in the LSP is delivered to all others. 162 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 164 Ingress LSR: An ingress LSR for a particular LSP is an LSR that can 165 send a data packet along the LSP. MP2MP LSPs can have multiple 166 ingress LSRs, P2MP LSPs have just one, and that node is often 167 referred to as the "root node". 169 Egress LSR: An egress LSR for a particular LSP is an LSR that can 170 remove a data packet from that LSP for further processing. P2P 171 and MP2P LSPs have only a single egress node, but P2MP and MP2MP 172 LSPs can have multiple egress nodes. 174 Transit LSR: An LSR that has reachability to a) the root of the MP 175 LSP via a directly connected upstream LSR and b) via one or more 176 directly connected downstream LSRs. 178 Bud LSR: An LSR that is an egress but also has one or more directly 179 connected downstream LSRs. 181 Leaf node: A Leaf node can be either an Egress or Bud LSR when 182 referred in the context of a P2MP LSP. In the context of a MP2MP 183 LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and 184 can also be a Bud LSR. 186 2. Setting up P2MP LSPs with LDP 188 A P2MP LSP consists of a single root node, zero or more transit nodes 189 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 190 tear-down. Leaf nodes also install forwarding state to deliver the 191 traffic received on a P2MP LSP to wherever it needs to go; how this 192 is done is outside the scope of this document. Transit nodes install 193 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 194 down) toward the root. The root node installs forwarding state to 195 map traffic into the P2MP LSP; how the root node determines which 196 traffic should go over the P2MP LSP is outside the scope of this 197 document. 199 2.1. Support for P2MP LSP setup with LDP 201 Support for the setup of P2MP LSPs is advertised using LDP 202 capabilities as defined in [6]. An implementation supporting the 203 P2MP procedures specified in this document MUST implement the 204 procedures for Capability Parameters in Initialization Messages. 206 A new Capability Parameter TLV is defined, the P2MP Capability. 207 Following is the format of the P2MP Capability Parameter. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 |1|0| P2MP Capability (TBD IANA) | Length (= 1) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |1| Reserved | 215 +-+-+-+-+-+-+-+-+ 217 The P2MP Capability TLV MUST be supported in the LDP Initialization 218 Message. Advertisement of the P2MP Capability indicates support of 219 the procedures for P2MP LSP setup detailed in this document. If the 220 peer has not advertised the corresponding capability, then no label 221 messages using the P2MP FEC Element should be sent to the peer. 223 2.2. The P2MP FEC Element 225 For the setup of a P2MP LSP with LDP, we define one new protocol 226 entity, the P2MP FEC Element to be used as a FEC Element in the FEC 227 TLV. Note that the P2MP FEC Element does not necessarily identify 228 the traffic that must be mapped to the LSP, so from that point of 229 view, the use of the term FEC is a misnomer. The description of the 230 P2MP FEC Element follows. 232 The P2MP FEC Element consists of the address of the root of the P2MP 233 LSP and an opaque value. The opaque value consists of one or more 234 LDP MP Opaque Value Elements. The opaque value is unique within the 235 context of the root node. The combination of (Root Node Address, 236 Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. 238 The P2MP FEC Element is encoded as follows: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |P2MP Type (TBD)| Address Family | Address Length| 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 ~ Root Node Address ~ 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Opaque Length | Opaque Value ... | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 249 ~ ~ 250 | | 251 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Type: The type of the P2MP FEC Element is to be assigned by IANA. 257 Address Family: Two octet quantity containing a value from ADDRESS 258 FAMILY NUMBERS in [3] that encodes the address family for the Root 259 LSR Address. 261 Address Length: Length of the Root LSR Address in octets. 263 Root Node Address: A host address encoded according to the Address 264 Family field. 266 Opaque Length: The length of the Opaque Value, in octets. 268 Opaque Value: One or more MP Opaque Value elements, uniquely 269 identifying the P2MP LSP in the context of the Root Node. This is 270 described in the next section. 272 If the Address Family is IPv4, the Address Length MUST be 4; if the 273 Address Family is IPv6, the Address Length MUST be 16. No other 274 Address Lengths are defined at present. 276 If the Address Length doesn't match the defined length for the 277 Address Family, the receiver SHOULD abort processing the message 278 containing the FEC Element, and send an "Unknown FEC" Notification 279 message to its LDP peer signaling an error. 281 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 282 be the only FEC Element in the FEC TLV. 284 2.3. The LDP MP Opaque Value Element 286 The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC 287 Elements defined in subsequent sections. It carries information that 288 is meaningful to Ingress LSRs and Leaf LSRs, but need not be 289 interpreted by Transit LSRs. 291 The LDP MP Opaque Value Element is encoded as follows: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type(TBD) | Length | Value ... | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 298 ~ ~ 299 | | 300 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Type: The type of the LDP MP Opaque Value Element is to be assigned 306 by IANA. 308 Length: The length of the Value field, in octets. 310 Value: String of Length octets, to be interpreted as specified by 311 the Type field. 313 2.3.1. The Generic LSP Identifier 315 The generic LSP identifier is a type of Opaque Value Element encoded 316 as follows: 318 Type: 1 (to be assigned by IANA) 319 Length: 4 321 Value: A 32bit integer, unique in the context of the root, as 322 identified by the root's address. 324 This type of Opaque Value Element is recommended when mapping of 325 traffic to LSPs is non-algorithmic, and done by means outside LDP. 327 2.4. Using the P2MP FEC Element 329 This section defines the rules for the processing and propagation of 330 the P2MP FEC Element. The following notation is used in the 331 processing rules: 333 1. P2MP FEC Element : a FEC Element with Root Node Address X 334 and Opaque Value Y. 336 2. P2MP Label Map : a Label Map message with a FEC TLV with 337 a single P2MP FEC Element and Label TLV with label L. 339 3. P2MP Label Withdraw : a Label Withdraw message with a 340 FEC TLV with a single P2MP FEC Element and Label TLV with 341 label L. 343 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 344 Address X and Opaque Value Y. 346 5. The notation L' -> { ..., } on LSR X 347 means that on receiving a packet with label L', X makes n copies 348 of the packet. For copy i of the packet, X swaps L' with Li and 349 sends it out over interface Ii. 351 The procedures below are organized by the role which the node plays 352 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 353 process which is outside the scope of this document. During the 354 course of protocol operation, the root node recognizes its role 355 because it owns the Root Node Address. A transit node is any node 356 (other than the root node) that receives a P2MP Label Map message 357 (i.e., one that has leaf nodes downstream of it). 359 Note that a transit node (and indeed the root node) may also be a 360 leaf node. 362 2.4.1. Label Map 364 The remainder of this section specifies the procedures for 365 originating P2MP Label Map messages and for processing received P2MP 366 label map messages for a particular LSP. The procedures for a 367 particular LSR depend upon the role that LSR plays in the LSP 368 (ingress, transit, or egress). 370 All labels discussed here are downstream-assigned [11] except those 371 which are assigned using the procedures of Section 6. 373 2.4.1.1. Determining one's 'upstream LSR' 375 Each node that is either a Leaf or Transit LSR of an MP LSP needs to 376 use the procedures below to select an upstream LSR. A node Z that 377 wants to join a MP LSP determines the LDP peer U which is Z's 378 next-hop on the best path from Z to the root node X. If there is more 379 than one such LDP peer, only one of them is picked. U is Z's 380 "Upstream LSR" for . 382 When there are several candidate upstream LSRs, the LSR MAY select 383 one upstream LSR using the following procedure: 385 1. The candidate upstream LSRs are numbered from lower to higher IP 386 address 388 2. The following hash is performed: H = (Sum Opaque value) modulo N, 389 where N is the number of candidate upstream LSRs 391 3. The selected upstream LSR U is the LSR that has the number H. 393 This allows for load balancing of a set of LSPs among a set of 394 candidate upstream LSRs, while ensuring that on a LAN interface a 395 single upstream LSR is selected. 397 2.4.1.2. Leaf Operation 399 A leaf node Z of P2MP LSP determines its upstream LSR U for 400 as per Section 2.4.1.1, allocates a label L, and sends a P2MP 401 Label Map to U. 403 2.4.1.3. Transit Node operation 405 Suppose a transit node Z receives a P2MP Label Map from LDP 406 peer T. Z checks whether it already has state for . If not, Z 407 allocates a label L', and installs state to swap L' with L over 408 interface I associated with peer T. Z also determines its upstream 409 LSR U for as per Section 2.4.1.1, and sends a P2MP Label Map 410 to U. 412 If Z already has state for , then Z does not send a Label Map 413 message for P2MP LSP . All that Z needs to do in this case is 414 update its forwarding state. Assuming its old forwarding state was 415 L'-> { ..., }, its new forwarding state 416 becomes L'-> { ..., , }. 418 2.4.1.4. Root Node Operation 420 Suppose the root node Z receives a P2MP Label Map from peer 421 T. Z checks whether it already has forwarding state for . If 422 not, Z creates forwarding state to push label L onto the traffic that 423 Z wants to forward over the P2MP LSP (how this traffic is determined 424 is outside the scope of this document). 426 If Z already has forwarding state for , then Z adds "push label 427 L, send over interface I" to the nexthop, where I is the interface 428 associated with peer T. 430 2.4.2. Label Withdraw 432 The following lists procedures for generating and processing P2MP 433 Label Withdraw messages for nodes that participate in a P2MP LSP. An 434 LSR should apply those procedures that apply to it, based on its role 435 in the P2MP LSP. 437 2.4.2.1. Leaf Operation 439 If a leaf node Z discovers (by means outside the scope of this 440 document) that it has no downstream neighbors in that LSP, and that 441 it has no need to be an egress LSR for that LSP, then it SHOULD send 442 a Label Withdraw to its upstream LSR U for , where L 443 is the label it had previously advertised to U for . 445 2.4.2.2. Transit Node Operation 447 If a transit node Z receives a Label Withdraw message from 448 a node W, it deletes label L from its forwarding state, and sends a 449 Label Release message with label L to W. 451 If deleting L from Z's forwarding state for P2MP LSP results 452 in no state remaining for , then Z propagates the Label 453 Withdraw for , to its upstream T, by sending a Label Withdraw 454 where L1 is the label Z had previously advertised to T for 455 . 457 2.4.2.3. Root Node Operation 459 The procedure when the root node of a P2MP LSP receives a Label 460 Withdraw message are the same as for transit nodes, except that it 461 would not propagate the Label Withdraw upstream (as it has no 462 upstream). 464 2.4.3. Upstream LSR change 466 If, for a given node Z participating in a P2MP LSP , the 467 upstream LSR changes, say from U to U', then Z MUST update its 468 forwarding state by deleting the state for label L, allocating a new 469 label, L', for , and installing the forwarding state for L'. In 470 addition Z MUST send a Label Map to U' and send a Label 471 Withdraw to U. 473 3. Shared Trees 475 The mechanism described above shows how to build a tree with a single 476 root and multiple leaves, i.e., a P2MP LSP. One can use essentially 477 the same mechanism to build Shared Trees with LDP. A Shared Tree can 478 be used by a group of routers that want to multicast traffic among 479 themselves, i.e., each node is both a root node (when it sources 480 traffic) and a leaf node (when any other member of the group sources 481 traffic). A Shared Tree offers similar functionality to a MP2MP LSP, 482 but the underlying multicasting mechanism uses a P2MP LSP. One 483 example where a Shared Tree is useful is video-conferencing. Another 484 is Virtual Private LAN Service (VPLS) [7], where for some types of 485 traffic, each device participating in a VPLS must send packets to 486 every other device in that VPLS. 488 One way to build a Shared Tree is to build an LDP P2MP LSP rooted at 489 a common point, the Shared Root (SR), and whose leaves are all the 490 members of the group. Each member of the Shared Tree unicasts 491 traffic to the SR (using, for example, the MP2P LSP created by the 492 unicast LDP FEC advertised by the SR); the SR then splices this 493 traffic into the LDP P2MP LSP. The SR may be (but need not be) a 494 member of the multicast group. 496 A major advantage of this approach is that no further protocol 497 mechanisms beyond the one already described are needed to set up a 498 Shared Tree. Furthermore, a Shared Tree is very efficient in terms 499 of the multicast state in the network, and is reasonably efficient in 500 terms of the bandwidth required to send traffic. 502 A property of this approach is that a sender will receive its own 503 packets as part of the multicast; thus a sender must be prepared to 504 recognize and discard packets that it itself has sent. For a number 505 of applications (for example, VPLS), this requirement is easy to 506 meet. Another consideration is the various techniques that can be 507 used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will 508 be described in a later revision. 510 4. Setting up MP2MP LSPs with LDP 512 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 513 root node, zero or more transit nodes and one or more leaf LSRs 514 acting equally as Ingress or Egress LSR. A leaf node participates in 515 the setup of an MP2MP LSP by establishing both a downstream LSP, 516 which is much like a P2MP LSP from the root, and an upstream LSP 517 which is used to send traffic toward the root and other leaf nodes. 518 Transit nodes support the setup by propagating the upstream and 519 downstream LSP setup toward the root and installing the necessary 520 MPLS forwarding state. The transmission of packets from the root 521 node of a MP2MP LSP to the receivers is identical to that for a P2MP 522 LSP. Traffic from a downstream node follows the upstream LSP toward 523 the root node and branches downward along the downstream LSP as 524 required to reach other leaf nodes. A packet that is received from a 525 downstream node MUST never be forwarded back out to that same node. 526 Mapping traffic to the MP2MP LSP may happen at any leaf node. How 527 that mapping is established is outside the scope of this document. 529 Due to how a MP2MP LSP is built a leaf LSR that is sending packets on 530 the MP2MP LSP does not receive its own packets. There is also no 531 additional mechanism needed on the root or transit LSR to match 532 upstream traffic to the downstream forwarding state. Packets that 533 are forwarded over a MP2MP LSP will not traverse a link more than 534 once, with the possible exception of LAN links (see Section 4.3.1), 535 if the procedures of [4] are not provided. 537 4.1. Support for MP2MP LSP setup with LDP 539 Support for the setup of MP2MP LSPs is advertised using LDP 540 capabilities as defined in [6]. An implementation supporting the 541 MP2MP procedures specified in this document MUST implement the 542 procedures for Capability Parameters in Initialization Messages. 544 A new Capability Parameter TLV is defined, the MP2MP Capability. 545 Following is the format of the MP2MP Capability Parameter. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |1|0| MP2MP Capability (TBD IANA) | Length (= 1) | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 |1| Reserved | 553 +-+-+-+-+-+-+-+-+ 555 The MP2MP Capability TLV MUST be supported in the LDP Initialization 556 Message. Advertisement of the MP2MP Capability indicates support of 557 the procedures for MP2MP LSP setup detailed in this document. If the 558 peer has not advertised the corresponding capability, then no label 559 messages using the MP2MP upstream and downstream FEC Elements should 560 be sent to the peer. 562 4.2. The MP2MP downstream and upstream FEC Elements. 564 For the setup of a MP2MP LSP with LDP we define 2 new protocol 565 entities, the MP2MP downstream FEC and upstream FEC Element. Both 566 elements will be used as FEC Elements in the FEC TLV. Note that the 567 MP2MP FEC Elements do not necessarily identify the traffic that must 568 be mapped to the LSP, so from that point of view, the use of the term 569 FEC is a misnomer. The description of the MP2MP FEC Elements follow. 571 The structure, encoding and error handling for the MP2MP downstream 572 and upstream FEC Elements are the same as for the P2MP FEC Element 573 described in Section 2.2. The difference is that two new FEC types 574 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 576 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 577 MUST be the only FEC Element in the FEC TLV. 579 Note, except when using the procedures of [4], the MPLS labels used 580 are "downstream-assigned" [11], even if they are bound to the 581 "upstream FEC element". 583 4.3. Using the MP2MP FEC Elements 585 This section defines the rules for the processing and propagation of 586 the MP2MP FEC Elements. The following notation is used in the 587 processing rules: 589 1. MP2MP downstream LSP (or simply downstream ): an 590 MP2MP LSP downstream path with root node address X and opaque 591 value Y. 593 2. MP2MP upstream LSP (or simply upstream ): a 594 MP2MP LSP upstream path for downstream node D with root node 595 address X and opaque value Y. 597 3. MP2MP downstream FEC Element : a FEC Element with root 598 node address X and opaque value Y used for a downstream MP2MP 599 LSP. 601 4. MP2MP upstream FEC Element : a FEC Element with root node 602 address X and opaque value Y used for an upstream MP2MP LSP. 604 5. MP2MP-D Label Map : A Label Map message with a FEC TLV 605 with a single MP2MP downstream FEC Element and label TLV 606 with label L. 608 6. MP2MP-U Label Map : A Label Map message with a FEC TLV 609 with a single MP2MP upstream FEC Element and label TLV 610 with label Lu. 612 7. MP2MP-D Label Withdraw : a Label Withdraw message with 613 a FEC TLV with a single MP2MP downstream FEC Element and 614 label TLV with label L. 616 8. MP2MP-U Label Withdraw : a Label Withdraw message with 617 a FEC TLV with a single MP2MP upstream FEC Element and 618 label TLV with label Lu. 620 9. MP2MP-D Label Release : a Label Release message with a 621 FEC TLV with a single MP2MP downstream FEC Element and 622 label TLV with label L. 624 10. MP2MP-U Label Release : a Label Release message with a 625 FEC TLV with a single MP2MP upstream FEC Element and 626 label TLV with label Lu. 628 The procedures below are organized by the role which the node plays 629 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 630 process which is outside the scope of this document. During the 631 course of the protocol operation, the root node recognizes its role 632 because it owns the root node address. A transit node is any node 633 (other then the root node) that receives a MP2MP Label Map message 634 (i.e., one that has leaf nodes downstream of it). 636 Note that a transit node (and indeed the root node) may also be a 637 leaf node and the root node does not have to be an ingress LSR or 638 leaf of the MP2MP LSP. 640 4.3.1. MP2MP Label Map 642 The remainder of this section specifies the procedures for 643 originating MP2MP Label Map messages and for processing received 644 MP2MP label map messages for a particular LSP. The procedures for a 645 particular LSR depend upon the role that LSR plays in the LSP 646 (ingress, transit, or egress). 648 All labels discussed here are downstream-assigned [11] except those 649 which are assigned using the procedures of Section 6. 651 4.3.1.1. Determining one's upstream MP2MP LSR 653 Determining the upstream LDP peer U for a MP2MP LSP follows 654 the procedure for a P2MP LSP described in Section 2.4.1.1. 656 4.3.1.2. Determining one's downstream MP2MP LSR 658 A LDP peer U which receives a MP2MP-D Label Map from a LDP peer D 659 will treat D as downstream MP2MP LSR. 661 4.3.1.3. Installing the upstream path of a MP2MP LSP 663 There are two methods for installing the upstream path of a MP2MP LSP 664 to a downstream neighbor. 666 1. We can install the upstream MP2MP path (to a downstream neighbor) 667 based on receiving a MP2MP-D Label Map from the downstream 668 neighbor. This will install the upstream path on a per hop by 669 hop bases. 671 2. We install the upstream MP2MP path (to a downstream neighbor) 672 based on receiving a MP2MP-U Label Map from the upstream 673 neighbor. An LSR does not need to wait for the MP2MP-U Label Map 674 if it is the root of the MP2MP LSP or already has received an 675 MP2MP-U Label Map from the upstream neighbor. We call this 676 method ordered mode. The typical result of this mode is that the 677 downstream path of the MP2MP is build hop by hop towards the 678 root. Once the root is reached, the root node will trigger a 679 MP2MP-U Label Map to the downstream neighbor(s). 681 For setting up the upstream path of a MP2MP LSP ordered mode MUST be 682 used. Due to ordered mode the upstream path of the MP2MP LSP is 683 installed at the leaf node once the path to the root is completed. 684 The advantage is that when a leaf starts sending immediately after 685 the upstream path is installed, packets are able to reach the root 686 node without being dropped due to an incomplete LSP. Method 1 is not 687 able to guarantee that the upstream path is completed before the leaf 688 starts sending. 690 4.3.1.4. MP2MP leaf node operation 692 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 693 as per Section 4.3.1.1, allocates a label L, and sends a 694 MP2MP-D Label Map to U. 696 Leaf node Z expects an MP2MP-U Label Map from node U in 697 response to the MP2MP-D Label Map it sent to node U. Z checks whether 698 it already has forwarding state for upstream . If not, Z 699 creates forwarding state to push label Lu onto the traffic that Z 700 wants to forward over the MP2MP LSP. How it determines what traffic 701 to forward on this MP2MP LSP is outside the scope of this document. 703 4.3.1.5. MP2MP transit node operation 705 When node Z receives a MP2MP-D Label Map from LSR D 706 associated with interface I, it checks whether it has forwarding 707 state for downstream . If not, Z allocates a label L' and 708 installs downstream forwarding state to swap label L' with label L 709 over interface I. Z also determines its upstream LSR U for as 710 per Section 4.3.1.1, and sends a MP2MP-D Label Map to U. 712 If Z already has forwarding state for downstream , all that Z 713 needs to do in this case is check that LSR D is not equal to the 714 upstream LSR of and update its forwarding state. Assuming its 715 old forwarding state was L'-> { ..., }, its 716 new forwarding state becomes L'-> { ..., , 717 }. If the LSR D is equal to the installed upstream LSR, the 718 Label Map from LSR D MUST be retained and MUST not update the label 719 forwarding table. 721 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 723 Map from LSR U associated with interface Iu. See 724 Section 4.3.1.3. Once the MP2MP-U Label Map for Lu over interface Iu 725 is received from LSR U, node Z checks whether it already has 726 forwarding state upstream . If it does, then no further 727 action needs to happen. If it does not, it allocates a label Lu' and 728 creates a new label swap for Lu' with Label Lu over interface Iu. In 729 addition, it also adds the label swap(s) from the forwarding state 730 downstream , omitting the swap on interface I for node D. The 731 swap on interface I for node D is omitted to prevent packet 732 originated by D to be forwarded back to D. 734 Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2, 735 and sends a MP2MP-U Label Map to node D. 737 4.3.1.6. MP2MP root node operation 739 4.3.1.6.1. Root node is also a leaf 741 Suppose root/leaf node Z receives a MP2MP-D Label Map from 742 node D associated with interface I. Z checks whether it already has 743 forwarding state downstream . If not, Z creates forwarding 744 state for downstream to push label L on traffic that Z wants to 745 forward down the MP2MP LSP. How it determines what traffic to 746 forward on this MP2MP LSP is outside the scope of this document. If 747 Z already has forwarding state for downstream , then Z will add 748 the label push for L over interface I to it. 750 Node Z checks if it has forwarding state for upstream If 751 not, Z allocates a label Lu' and creates upstream forwarding state to 752 push Lu' with the label push(s) from the forwarding state downstream 753 , except the push on interface I for node D. This allows 754 upstream traffic to go down the MP2MP to other node(s), except the 755 node from which the traffic was received. Node Z determines the 756 downstream MP2MP LSR as per section Section 4.3.1.2, and sends a 757 MP2MP-U Label Map to node D. Since Z is the root of the 758 tree Z will not send a MP2MP-D Label Map and will not receive a 759 MP2MP-U Label Map. 761 4.3.1.6.2. Root node is not a leaf 763 Suppose the root node Z receives a MP2MP-D Label Map from 764 node D associated with interface I. Z checks whether it already has 765 forwarding state for downstream . If not, Z creates downstream 766 forwarding state and installs a outgoing label L over interface I. If 767 Z already has forwarding state for downstream , then Z will add 768 label L over interface I to the existing state. 770 Node Z checks if it has forwarding state for upstream . If 771 not, Z allocates a label Lu' and creates forwarding state to swap Lu' 772 with the label swap(s) from the forwarding state downstream , 773 except the swap for node D. This allows upstream traffic to go down 774 the MP2MP to other node(s), except the node is was received from. 775 Root node Z determines the downstream MP2MP LSR D as per 776 Section 4.3.1.2, and sends a MP2MP-U Label Map to it. 778 Since Z is the root of the tree Z will not send a MP2MP-D Label Map 779 and will not receive a MP2MP-U Label Map. 781 4.3.2. MP2MP Label Withdraw 783 The following lists procedures for generating and processing MP2MP 784 Label Withdraw messages for nodes that participate in a MP2MP LSP. 785 An LSR should apply those procedures that apply to it, based on its 786 role in the MP2MP LSP. 788 4.3.2.1. MP2MP leaf operation 790 If a leaf node Z discovers (by means outside the scope of this 791 document) that it has no downstream neighbors in that LSP, and that 792 it has no need to be an egress LSR for that LSP, then it SHOULD send 793 a MP2MP-D Label Withdraw to its upstream LSR U for , 794 where L is the label it had previously advertised to U for . 795 Leaf node Z will also send a unsolicited label release to 796 U to indicate that the upstream path is no longer used and that Label 797 Lu can be removed. 799 Leaf node Z expects the upstream router U to respond by sending a 800 downstream label release for L. 802 4.3.2.2. MP2MP transit node operation 804 If a transit node Z receives a MP2MP-D Label Withdraw message from node D, it deletes label L from its forwarding state 806 downstream and from all its upstream states for . Node 807 Z sends a MP2MP-D Label Release message with label L to D. Since node 808 D is no longer part of the downstream forwarding state, Z cleans up 809 the forwarding state upstream . There is no need to send an 810 MP2MP-U Label Withdraw to D because node D already removed 811 Lu and send a label release for Lu to Z. 813 If deleting L from Z's forwarding state for downstream results 814 in no state remaining for , then Z propagates the MP2MP-D Label 815 Withdraw to its upstream node U for and will also 816 send a unsolicited MP2MP-U Label Release to U to indicate 817 that the upstream path is no longer used and that Label Lu can be 818 removed. 820 4.3.2.3. MP2MP root node operation 822 The procedure when the root node of a MP2MP LSP receives a MP2MP-D 823 Label Withdraw message is the same as for transit nodes, except that 824 the root node would not propagate the Label Withdraw upstream (as it 825 has no upstream). 827 4.3.3. MP2MP Upstream LSR change 829 The procedure for changing the upstream LSR is the same as documented 830 in Section 2.4.3, except it is applied to MP2MP FECs, using the 831 procedures described in Section 4.3.1 through Section 4.3.2.3. 833 5. The LDP MP Status TLV 835 An LDP MP capable router MAY use an LDP MP Status TLV to indicate 836 additional status for a MP LSP to its remote peers. This includes 837 signaling to peers that are either upstream or downstream of the LDP 838 MP capable router. The value of the LDP MP status TLV will remain 839 opaque to LDP and MAY encode one or more status elements. 841 The LDP MP Status TLV is encoded as follows: 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 |1|0| LDP MP Status Type(TBD) | Length | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Value | 849 ~ ~ 850 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. 856 Length: Length of the LDP MP Status Value in octets. 858 Value: One or more LDP MP Status Value elements. 860 5.1. The LDP MP Status Value Element 862 The LDP MP Status Value Element that is included in the LDP MP Status 863 TLV Value has the following encoding. 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Type(TBD) | Length | Value ... | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 870 ~ ~ 871 | | 872 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 Type: The type of the LDP MP Status Value Element is to be assigned 878 by IANA. 880 Length: The length of the Value field, in octets. 882 Value: String of Length octets, to be interpreted as specified by 883 the Type field. 885 5.2. LDP Messages containing LDP MP Status messages 887 The LDP MP status message may appear either in a label mapping 888 message or a LDP notification message. 890 5.2.1. LDP MP Status sent in LDP notification messages 892 An LDP MP status TLV sent in a notification message must be 893 accompanied with a Status TLV. The general format of the 894 Notification Message with an LDP MP status TLV is: 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 |0| Notification (0x0001) | Message Length | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Message ID | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Status TLV | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | LDP MP Status TLV | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Optional LDP MP FEC TLV | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Optional Label TLV | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 The Status TLV status code is used to indicate that LDP MP status TLV 913 and an additional information follows in the Notification message's 914 "optional parameter" section. Depending on the actual contents of 915 the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may 916 also be present to provide context to the LDP MP Status TLV. (NOTE: 917 Status Code is pending IANA assignment). 919 Since the notification does not refer to any particular message, the 920 Message Id and Message Type fields are set to 0. 922 5.2.2. LDP MP Status TLV in Label Mapping Message 924 An example of the Label Mapping Message defined in RFC3036 is shown 925 below to illustrate the message with an Optional LDP MP Status TLV 926 present. 928 0 1 2 3 929 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 |0| Label Mapping (0x0400) | Message Length | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Message ID | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | FEC TLV | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Label TLV | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Optional LDP MP Status TLV | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Additional Optional Parameters | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 6. Upstream label allocation on a LAN 946 On a LAN, the procedures so far discussed would require the upstream 947 LSR to send a copy of the packet to each receiver individually. If 948 there is more then one receiver on the LAN we don't take full benefit 949 of the multi-access capability of the network. We may optimize the 950 bandwidth consumption on the LAN and replication overhead on the 951 upstream LSR by using upstream label allocation [4]. Procedures on 952 how to distribute upstream labels using LDP is documented in [5]. 954 6.1. LDP Multipoint-to-Multipoint on a LAN 956 The procedure to allocate a context label on a LAN is defined in [4]. 957 That procedure results in each LSR on a given LAN having a context 958 label which, on that LAN, can be used to identify itself uniquely. 959 Each LSR advertises its context label as an upstream-assigned label, 960 following the procedures of [5]. Any LSR for which the LAN is a 961 downstream link on some P2MP or MP2MP LSP will allocate an upstream- 962 assigned label identifying that LSP. When the LSR forwards a packet 963 downstream on one of those LSPs, the packet's top label must be the 964 LSR's context label, and the packet's second label is the label 965 identifying the LSP. We will call the top label the "upstream LSR 966 label" and the second label the "LSP label". 968 6.1.1. MP2MP downstream forwarding 970 The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so 971 we will use the same procedures as defined in [5]. A label request 972 for a LSP label is send to the upstream LSR. The label mapping that 973 is received from the upstream LSR contains the LSP label for the 974 MP2MP FEC and the upstream LSR context label. The MP2MP downstream 975 path (corresponding to the LSP label) will be installed the context 976 specific forwarding table corresponding to the upstream LSR label. 977 Packets sent by the upstream router can be forwarded downstream using 978 this forwarding state based on a two label lookup. 980 6.1.2. MP2MP upstream forwarding 982 A MP2MP LSP also has an upstream forwarding path. Upstream packets 983 need to be forwarded in the direction of the root and downstream on 984 any node on the LAN that has a downstream interface for the LSP. For 985 a given MP2MP LSP on a given LAN, exactly one LSR is considered to be 986 the upstream LSR. If an LSR on the LAN receives a packet from one of 987 its downstream interfaces for the LSP, and if it needs to forward the 988 packet onto the LAN, it ensures that the packet's top label is the 989 context label of the upstream LSR, and that its second label is the 990 LSP label that was assigned by the upstream LSR. 992 Other LSRs receiving the packet will not be able to tell whether the 993 packet really came from the upstream router, but that makes no 994 difference in the processing of the packet. The upstream LSR will 995 see its own upstream LSR in the label, and this will enable it to 996 determine that the packet is traveling upstream. 998 7. Root node redundancy 1000 The root node is a single point of failure for an MP LSP, whether 1001 this is P2MP or MP2MP. The problem is particularly severe for MP2MP 1002 LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same 1003 root node to set up the MP2MP LSP, because otherwise the traffic 1004 sourced by some leafs is not received by others. Because the root 1005 node is the single point of failure for an MP LSP, we need a fast and 1006 efficient mechanism to recover from a root node failure. 1008 An MP LSP is uniquely identified in the network by the opaque value 1009 and the root node address. It is likely that the root node for an MP 1010 LSP is defined statically. The root node address may be configured 1011 on each leaf statically or learned using a dynamic protocol. How 1012 leafs learn about the root node is out of the scope of this document. 1014 Suppose that for the same opaque value we define two (or more) root 1015 node addresses and we build a tree to each root using the same opaque 1016 value. Effectively these will be treated as different MP LSPs in the 1017 network. Once the trees are built, the procedures differ for P2MP 1018 and MP2MP LSPs. The different procedures are explained in the 1019 sections below. 1021 7.1. Root node redundancy - procedures for P2MP LSPs 1023 Since all leafs have set up P2MP LSPs to all the roots, they are 1024 prepared to receive packets on either one of these LSPs. However, 1025 only one of the roots should be forwarding traffic at any given time, 1026 for the following reasons: 1) to achieve bandwidth savings in the 1027 network and 2) to ensure that the receiving leafs don't receive 1028 duplicate packets (since one cannot assume that the receiving leafs 1029 are able to discard duplicates). How the roots determine which one 1030 is the active sender is outside the scope of this document. 1032 7.2. Root node redundancy - procedures for MP2MP LSPs 1034 Since all leafs have set up an MP2MP LSP to each one of the root 1035 nodes for this opaque value, a sending leaf may pick either of the 1036 two (or more) MP2MP LSPs to forward a packet on. The leaf nodes 1037 receive the packet on one of the MP2MP LSPs. The client of the MP2MP 1038 LSP does not care on which MP2MP LSP the packet is received, as long 1039 as they are for the same opaque value. The sending leaf MUST only 1040 forward a packet on one MP2MP LSP at a given point in time. The 1041 receiving leafs are unable to discard duplicate packets because they 1042 accept on all LSPs. Using all the available MP2MP LSPs we can 1043 implement redundancy using the following procedures. 1045 A sending leaf selects a single root node out of the available roots 1046 for a given opaque value. A good strategy MAY be to look at the 1047 unicast routing table and select a root that is closest in terms of 1048 the unicast metric. As soon as the root address of the active root 1049 disappears from the unicast routing table (or becomes less 1050 attractive) due to root node or link failure, the leaf can select a 1051 new best root address and start forwarding to it directly. If 1052 multiple root nodes have the same unicast metric, the highest root 1053 node addresses MAY be selected, or per session load balancing MAY be 1054 done over the root nodes. 1056 All leafs participating in a MP2MP LSP MUST join to all the available 1057 root nodes for a given opaque value. Since the sending leaf may pick 1058 any MP2MP LSP, it must be prepared to receive on it. 1060 The advantage of pre-building multiple MP2MP LSPs for a single opaque 1061 value is that convergence from a root node failure happens as fast as 1062 the unicast routing protocol is able to notify. There is no need for 1063 an additional protocol to advertise to the leaf nodes which root node 1064 is the active root. The root selection is a local leaf policy that 1065 does not need to be coordinated with other leafs. The disadvantage 1066 of pre-building multiple MP2MP LSPs is that more label resources are 1067 used, depending on how many root nodes are defined. 1069 8. MP LSP micro loops 1071 A MP LSP is built hop by hop following the best path to reach the 1072 root of the LSP. If the routing protocol used to calculate the best 1073 path is subjected to micro-loops, the MP LSP may contain a micro 1074 loop. Both P2MP and MP2MP LSPs may end up containing a micro-loop. 1075 However, there is a difference between loops in P2MP and MP2MP LSP. 1076 In a P2MP LSP, once a loop s formed, no new packet can enter it, but 1077 in a MP2MP LSP, packets may continue to enter the loop. This makes a 1078 loop in MP2MP LSP worse compared to loop in P2MP LSP. If the routing 1079 protocol is not subjected to micro-loops, the MP LSP will not end up 1080 in a micro-loop and no additional procedures are necessary. The 1081 following section describes procedures that MAY be applied to prevent 1082 micro-loops in MP2MP LSPs in case the routing protocol is not able to 1083 guarantee a loop-free best path selection. 1085 8.1. MP2MP upstream path 1087 A MP2MP LSP has multiple injection points, there is one injection 1088 point from the root down the LSP towards the leafs, which is the same 1089 as a P2MP LSP. Other injection point(s) are from each leaf towards 1090 the root of the LSP. These procedures solve micro-loops which are 1091 the result of injecting packets from the leaf towards the root. It 1092 does not solve micro-loops which are the result of injecting packets 1093 from the root. This makes the MP2MP LSP as good as P2MP LSPs. 1095 8.2. MP2MP micro loop prevention procedures 1097 Based on the procedures defined in Section 4.3.1.3 ordered mode is 1098 used to build the upstream path from the root down to the leaves. 1099 The MP2MP-U Label Map will add a path vector TLV [1] as optional 1100 parameter to the MP2MP-U Label Map message. Each LSR will add its 1101 own router ID to the path list TLV before sending the MP2MP-U Label 1102 Map to the downstream LSRs. Suppose node Z receives a 1103 MP2MP-U Label Map from LSR D with Label Lu. If node Z finds its own 1104 router ID in the path vector list it will complete the procedures for 1105 MP2MP LSP's defined in this draft with the following exception, the 1106 Label Forwarding Database for the MP2MP upstream with Lu is 1107 not installed, but is retained. By not installing Label Lu the loop 1108 is prevented. If node Z receives a MP2MP-U Label Map that updates 1109 the path vector list such that it does not include its own router ID, 1110 Label Lu can be safely installed into forwarding. 1112 9. Make Before Break (MBB) 1114 An LSR selects as its upstream LSR for a MP LSP the LSR that is its 1115 next hop to the root of the LSP. When the best path to reach the 1116 root changes the LSR must choose a new upstream LSR. Sections 1117 Section 2.4.3 and Section 4.3.3 describe these procedures. 1119 When the best path to the root changes the LSP may be broken 1120 temporarily resulting in packet loss until the LSP "reconverges" to a 1121 new upstream LSR. The goal of MBB when this happens is to keep the 1122 duration of packet loss as short as possible. In addition, there are 1123 scenarios where the best path from the LSR to the root changes but 1124 the LSP continues to forward packets to the prevous next hop to the 1125 root. That may occur when a link comes up or routing metrics change. 1126 In such a case a new LSP should be established before the old LSP is 1127 removed to limit the duration of packet loss. The procedures 1128 described below deal with both scenarios in a way that an LSR does 1129 not need to know which of the events described above caused its 1130 upstream router for an MBB LSP to change. 1132 This MBB procedures are an optional extension to the MP LSP building 1133 procedures described in this draft. 1135 9.1. MBB overview 1137 The MBB procedues use additional LDP signaling. 1139 Suppose some event causes a downstream LSR-D to select a new upstream 1140 LSR-U for FEC-A. The new LSR-U may already be forwarding packets for 1141 FEC-A; that is, to downstream LSR's other than LSR-D. After LSR-U 1142 receives a label for FEC-A from LSR-D, it will notify LSR-D when it 1143 knows that the LSP for FEC-A has been established from the root to 1144 itself. When LSR-D receives this MBB notification it will change its 1145 next hop for the LSP root to LSR-U. 1147 The assumption is that if LSR-U has received an MBB notification from 1148 its upstream router for the FEC-A LSP and has installed forwarding 1149 state the LSP it is capable of forwarding packets on the LSP. At 1150 that point LSR-U should signal LSR-D by means of an MBB notification 1151 that it has become part of the tree identified by FEC-A and that 1152 LSR-D should initiate its switchover to the LSP. 1154 At LSR-U the LSP for FEC-A may be in 1 of 3 states. 1156 1. There is no state for FEC-A. 1158 2. State for FEC-A exists and LSR-U is waiting for MBB notification 1159 that the LSP from the root to it exists. 1161 3. State for FEC-A exists and the MBB notification has been 1162 received. 1164 After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U 1165 MUST NOT reply with an MBB notification to LSR-D until its state for 1166 the LSP is state #3 above. If the state of the LSP at LSR-U is state 1167 #1 or #2, LSR-U should remember receipt of the Label Mapping message 1168 from LSR-D while waiting for an MBB notification from its upstream 1169 LSR for the LSP. When LSR-U receives the MBB notification from its 1170 upstream LSR it transitions to LSP state #3 and sends an MBB 1171 notification to LSR-D. 1173 9.2. The MBB Status code 1175 As noted in Section 9.1, the procedures to establish an MBB MP LSP 1176 are different from those to establish normal MP LSPs. 1178 When a downstream LSR sends a Label Mapping message for MP LSP to its 1179 upstream LSR it MAY include an LDP MP Status TLV that carries a MBB 1180 Status Code to indicate MBB procedures apply to the LSP. This new 1181 MBB Status Code MAY also appear in an LDP Notification message used 1182 by an upstream LSR to signal LSP state #3 to the downstream LSR; that 1183 is, that the upstream LSR's state for the LSP exists and that it has 1184 received notification from its upstream LSR that the LSP is in state 1185 #3. 1187 The MBB Status is a type of the LDP MP Status Value Element as 1188 described in Section 5.1. It is encoded as follows: 1190 0 1 2 3 1191 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 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | MBB Type = 1 | Length = 1 | Status code | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 MBB Type: Type 1 (to be assigned by IANA) 1198 Length: 1 1200 Status code: 1 = MBB request 1202 2 = MBB ack 1204 9.3. The MBB capability 1206 An LSR MAY advertise that it is capable of handling MBB LSPs using 1207 the capability advertisement as defined in [6]. The LDP MP MBB 1208 capability has the following format: 1210 0 1 2 3 1211 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 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 |1|0| LDP MP MBB Capability | Length = 1 | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 |1| Reserved | 1216 +-+-+-+-+-+-+-+-+ 1218 Note: LDP MP MBB Capability (Pending IANA assignment) 1220 0 1 2 3 1221 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 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 |1|0| LDP MP MBB Capability | Length = 1 | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 |1| Reserved | 1226 +-+-+-+-+-+-+-+-+ 1228 If an LSR has not advertised that it is MBB capable, its LDP peers 1229 MUST NOT send it messages which include MBB parameters. If an LSR 1230 receives a Label Mapping message with a MBB parameter from downstream 1231 LSR-D and its upstream LSR-U has not advertised that it is MBB 1232 capable, the LSR MUST send an MBB notification immediatly to LSR-U 1233 (see Section 9.4). If this happens an MBB MP LSP will not be 1234 established, but normal a MP LSP will be the result. 1236 9.4. The MBB procedures 1238 9.4.1. Terminology 1240 1. MBB LSP : A P2MP or MP2MP Make Before Break (MBB) LSP entry 1241 with Root Node Address X and Opaque Value Y. 1243 2. A(N, L): An Accepting element that consists of an upstream 1244 Neighbor N and Local label L. This LSR assigned label L to 1245 neighbor N for a specific MBB LSP. For an active element the 1246 corresponding Label is stored in the label forwarding database. 1248 3. iA(N, L): An inactive Accepting element that consists of an 1249 upstream neighbor N and local Label L. This LSR assigned label L 1250 to neighbor N for a specific MBB LSP. For an inactive element 1251 the corresponding Label is not stored in the label forwarding 1252 database. 1254 4. F(N, L): A Forwarding state that consists of downstream Neighbor 1255 N and Label L. This LSR is sending label packets with label L to 1256 neighbor N for a specific FEC. 1258 5. F'(N, L): A Forwarding state that has been marked for sending a 1259 MBB Notification message to Neighbor N with Label L. 1261 6. MBB Notification : A LDP notification message with a MP 1262 LSP , Label L and MBB Status code 2. 1264 7. MBB Label Map : A P2MP Label Map or MP2MP Label Map 1265 downstream with a FEC element , Label L and MBB Status code 1266 1. 1268 9.4.2. Accepting elements 1270 An accepting element represents a specific label value L that has 1271 been advertised to a neighbor N for a MBB LSP and is a 1272 candidate for accepting labels switched packets on. An LSR can have 1273 two accepting elements for a specific MBB LSP LSP, only one of 1274 them MUST be active. An active element is the element for which the 1275 label value has been installed in the label forwarding database. An 1276 inactive accepting element is created after a new upstream LSR is 1277 chosen and is pending to replace the active element in the label 1278 forwarding database. Inactive elements only exist temporarily while 1279 switching to a new upstream LSR. Once the switch has been completed 1280 only one active element remains. During network convergence it is 1281 possible that an inactive accepting element is created while an other 1282 inactive accepting element is pending. If that happens the older 1283 inactive accepting element MUST be replaced with an newer inactive 1284 element. If an accepting element is removed a Label Withdraw has to 1285 be send for label L to neighbor N for . 1287 9.4.3. Procedures for upstream LSR change 1289 Suppose a node Z has a MBB LSP with an active accepting 1290 element A(N1, L1). Due to a routing change it detects a new best 1291 path for root X and selects a new upstream LSR N2. Node Z allocates 1292 a new local label L2 and creates an inactive accepting element iA(N2, 1293 L2). Node Z sends MBB Label Map to N2 and waits for the 1294 new upstream LSR N2 to respond with a MBB Notification for . During this transition phase there are two accepting elements, 1296 the element A(N1, L1) still accepting packets from N1 over label L1 1297 and the new inactive element iA(N2, L2). 1299 While waiting for the MBB Notification from upstream LSR N2, it is 1300 possible that an other transition occurs due to a routing change. 1301 Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) 1302 is created and the old inactive element iA(N2, L2) MUST be removed. 1303 A label withdraw MUST be sent to N2 for from N2 will be ignored because the 1305 inactive element is removed. 1307 It is possible that the MBB Notification from upstream LSR is never 1308 received due to link or node failure. To prevent waiting 1309 indefinitely for the MBB Notification a timeout SHOULD be applied. 1310 As soon as the timer expires, the procedures in Section 9.4.5 are 1311 applied as if a MBB Notification was received for the inactive 1312 element. 1314 9.4.4. Receiving a Label Map with MBB status code 1316 Suppose node Z has state for a MBB LSP and receives a MBB 1317 Label Map from N2. A new forwarding state F(N2, L2) will 1318 be added to the MP LSP if it did not already exist. If this MBB LSP 1319 has an active accepting element or node Z is the root of the MBB LSP 1320 a MBB notification is send to node N2. If node Z has an 1321 inactive accepting element it marks the Forwarding state as . 1324 9.4.5. Receiving a Notification with MBB status code 1326 Suppose node Z receives a MBB Notification from N. If node 1327 Z has state for MBB LSP and an inactive accepting element 1328 iA(N, L) that matches with N and L, we activate this accepting 1329 element and install label L in the label forwarding database. If an 1330 other active accepting was present it will be removed from the label 1331 forwarding database. 1333 If this MBB LSP also has Forwarding states marked for sending 1334 MBB Notifications, like , MBB Notifications are 1335 send to these downstream LSRs. If node Z receives a MBB Notification 1336 for an accepting element that is not inactive or does not match the 1337 Label value and Neighbor address, the MBB notification is ignored. 1339 9.4.6. Node operation for MP2MP LSPs 1341 The procedures described above apply to the downstream path of a 1342 MP2MP LSP. The upstream path of the MP2MP is setup as normal without 1343 including a MBB Status code. If the MBB procedures apply to a MP2MP 1344 downstream FEC element, the upstream path to a node N is only 1345 installed in the label forwarding database if node N is part of the 1346 active accepting element. If node N is part of an inactive accepting 1347 element, the upstream path is installed when this inactive accepting 1348 element is activated. 1350 10. Security Considerations 1352 The same security considerations apply as for the base LDP 1353 specification, as described in [1]. 1355 11. IANA considerations 1357 This document creates a new name space (the LDP MP Opaque Value 1358 Element type) that is to be managed by IANA, and the allocation of 1359 the value 1 for the type of Generic LSP Identifier. 1361 This document requires allocation of three new LDP FEC Element types: 1363 1. the P2MP FEC type - requested value 0x06 1365 2. the MP2MP-up FEC type - requested value 0x07 1367 3. the MP2MP-down FEC type - requested value 0x08 1369 This document requires the assignment of three new code points for 1370 three new Capability Parameter TLVs, corresponding to the 1371 advertisement of the P2MP, MP2MP and MBB capabilities. The values 1372 requested are: 1374 P2MP Capability Parameter - requested value 0x0508 1376 MP2MP Capability Parameter - requested value 0x0509 1378 MBB Capability Parameter - requested value 0x050A 1380 This document requires the assignment of a LDP Status TLV code to 1381 indicate a LDP MP Status TLV is following in the Notification 1382 message. The value requested is: 1384 LDP MP status - requested value 0x0000002D 1386 This document requires the assigment of a new code point for a LDP MP 1387 Status TLV. The value requested is: 1389 LDP MP Status TLV Type - requested value 0x096D 1391 This document creates a new name space (the LDP MP Status Value 1392 Element type) that is to be managed by IANA, and the allocation of 1393 the value 1 for the type of MBB Status. 1395 12. Acknowledgments 1397 The authors would like to thank the following individuals for their 1398 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 1399 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, 1400 George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas 1401 Morin. 1403 13. Contributing authors 1405 Below is a list of the contributing authors in alphabetical order: 1407 Shane Amante 1408 Level 3 Communications, LLC 1409 1025 Eldorado Blvd 1410 Broomfield, CO 80021 1411 US 1412 Email: Shane.Amante@Level3.com 1413 Luyuan Fang 1414 Cisco Systems 1415 300 Beaver Brook Road 1416 Boxborough, MA 01719 1417 US 1418 Email: lufang@cisco.com 1420 Hitoshi Fukuda 1421 NTT Communications Corporation 1422 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1423 Tokyo 100-8019, 1424 Japan 1425 Email: hitoshi.fukuda@ntt.com 1427 Yuji Kamite 1428 NTT Communications Corporation 1429 Tokyo Opera City Tower 1430 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1431 Tokyo 163-1421, 1432 Japan 1433 Email: y.kamite@ntt.com 1435 Kireeti Kompella 1436 Juniper Networks 1437 1194 N. Mathilda Ave. 1438 Sunnyvale, CA 94089 1439 US 1440 Email: kireeti@juniper.net 1442 Ina Minei 1443 Juniper Networks 1444 1194 N. Mathilda Ave. 1445 Sunnyvale, CA 94089 1446 US 1447 Email: ina@juniper.net 1449 Jean-Louis Le Roux 1450 France Telecom 1451 2, avenue Pierre-Marzin 1452 Lannion, Cedex 22307 1453 France 1454 Email: jeanlouis.leroux@francetelecom.com 1455 Bob Thomas 1456 Cisco Systems, Inc. 1457 300 Beaver Brook Road 1458 Boxborough, MA, 01719 1459 E-mail: bobthomas@alum.mit.edu 1461 Lei Wang 1462 Telenor 1463 Snaroyveien 30 1464 Fornebu 1331 1465 Norway 1466 Email: lei.wang@telenor.com 1468 IJsbrand Wijnands 1469 Cisco Systems, Inc. 1470 De kleetlaan 6a 1471 1831 Diegem 1472 Belgium 1473 E-mail: ice@cisco.com 1475 14. References 1477 14.1. Normative References 1479 [1] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", 1480 RFC 5036, October 2007. 1482 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1483 Levels", BCP 14, RFC 2119, March 1997. 1485 [3] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 1486 line Database", RFC 3232, January 2002. 1488 [4] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label 1489 Assignment and Context-Specific Label Space", 1490 draft-ietf-mpls-upstream-label-05 (work in progress), 1491 April 2008. 1493 [5] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for 1494 LDP", draft-ietf-mpls-ldp-upstream-02 (work in progress), 1495 November 2007. 1497 [6] Thomas, B., "LDP Capabilities", 1498 draft-ietf-mpls-ldp-capabilities-02 (work in progress), 1499 March 2008. 1501 14.2. Informative References 1503 [7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1504 Private Networks (L2VPNs)", RFC 4664, September 2006. 1506 [8] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions 1507 to Resource Reservation Protocol - Traffic Engineering 1508 (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths 1509 (LSPs)", RFC 4875, May 2007. 1511 [9] Roux, J., "Requirements for Point-To-Multipoint Extensions to 1512 the Label Distribution Protocol", 1513 draft-ietf-mpls-mp-ldp-reqs-04 (work in progress), 1514 February 2008. 1516 [10] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 1517 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/ 1518 BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work in 1519 progress), January 2008. 1521 [11] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 1522 Multicast Encapsulations", draft-ietf-mpls-multicast-encaps-09 1523 (work in progress), May 2008. 1525 Authors' Addresses 1527 Ina Minei 1528 Juniper Networks 1529 1194 N. Mathilda Ave. 1530 Sunnyvale, CA 94089 1531 US 1533 Email: ina@juniper.net 1535 Kireeti Kompella 1536 Juniper Networks 1537 1194 N. Mathilda Ave. 1538 Sunnyvale, CA 94089 1539 US 1541 Email: kireeti@juniper.net 1542 IJsbrand Wijnands 1543 Cisco Systems, Inc. 1544 De kleetlaan 6a 1545 Diegem 1831 1546 Belgium 1548 Email: ice@cisco.com 1550 Bob Thomas 1551 Cisco Systems, Inc. 1552 300 Beaver Brook Road 1553 Boxborough 01719 1554 US 1556 Email: bobthomas@alum.mit.edu 1558 Full Copyright Statement 1560 Copyright (C) The IETF Trust (2008). 1562 This document is subject to the rights, licenses and restrictions 1563 contained in BCP 78, and except as set forth therein, the authors 1564 retain all their rights. 1566 This document and the information contained herein are provided on an 1567 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1568 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1569 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1570 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1571 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1572 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1574 Intellectual Property 1576 The IETF takes no position regarding the validity or scope of any 1577 Intellectual Property Rights or other rights that might be claimed to 1578 pertain to the implementation or use of the technology described in 1579 this document or the extent to which any license under such rights 1580 might or might not be available; nor does it represent that it has 1581 made any independent effort to identify any such rights. Information 1582 on the procedures with respect to rights in RFC documents can be 1583 found in BCP 78 and BCP 79. 1585 Copies of IPR disclosures made to the IETF Secretariat and any 1586 assurances of licenses to be made available, or the result of an 1587 attempt made to obtain a general license or permission for the use of 1588 such proprietary rights by implementers or users of this 1589 specification can be obtained from the IETF on-line IPR repository at 1590 http://www.ietf.org/ipr. 1592 The IETF invites any interested party to bring to its attention any 1593 copyrights, patents or patent applications, or other proprietary 1594 rights that may cover technology that may be required to implement 1595 this standard. Please address the information to the IETF at 1596 ietf-ipr@ietf.org. 1598 Acknowledgment 1600 Funding for the RFC Editor function is provided by the IETF 1601 Administrative Support Activity (IASA).