idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-04.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 1454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1478. 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 -- 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 (February 22, 2008) is 5907 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) ** Obsolete normative reference: RFC 3036 (ref. '1') (Obsoleted by RFC 5036) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '3') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-02 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-ldp-upstream-01 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-capabilities-00 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mp-ldp-reqs-02 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-00 Summary: 3 errors (**), 0 flaws (~~), 6 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: August 25, 2008 I. Wijnands (Editor) 6 B. Thomas 7 Cisco Systems, Inc. 8 February 22, 2008 10 Label Distribution Protocol Extensions for Point-to-Multipoint and 11 Multipoint-to-Multipoint Label Switched Paths 12 draft-ietf-mpls-ldp-p2mp-04 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 August 25, 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. The solution relies on LDP without 49 requiring a multicast routing protocol in the network. Protocol 50 elements and procedures for this solution are described for building 51 such LSPs in a receiver-initiated manner. There can be various 52 applications for P2MP/MP2MP LSPs, for example IP multicast or support 53 for multicast in BGP/MPLS L3VPNs. Specification of how such 54 applications can use a LDP signaled P2MP/MP2MP LSP is outside the 55 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 . . . . . . . . . . . 5 64 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6 65 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 7 66 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 8 67 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 8 68 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 9 69 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 11 70 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 12 72 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 13 73 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 13 74 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 14 75 4.3.1. MP2MP Label Map upstream and downstream . . . . . . . 15 76 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 17 77 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 18 78 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 19 79 5.2. LDP Messages containing LDP MP Status messages . . . . . . 20 80 5.2.1. LDP MP Status sent in LDP notification messages . . . 20 81 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 20 82 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 21 83 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 21 84 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 21 85 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 22 86 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 22 87 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 23 88 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 23 89 8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 24 90 8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 24 91 8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 25 92 8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 26 93 8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 26 94 8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 26 95 8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 27 96 8.4.3. Procedures for upstream LSR change . . . . . . . . . . 27 97 8.4.4. Receiving a Label Map with MBB status code . . . . . . 28 98 8.4.5. Receiving a Notification with MBB status code . . . . 28 99 8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 29 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 101 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 102 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 103 12. Contributing authors . . . . . . . . . . . . . . . . . . . . . 30 104 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 106 13.2. Informative References . . . . . . . . . . . . . . . . . . 32 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 108 Intellectual Property and Copyright Statements . . . . . . . . . . 34 110 1. Introduction 112 The LDP protocol is described in [1]. It defines mechanisms for 113 setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs 114 in the network. This document describes extensions to LDP for 115 setting up point-to-multipoint (P2MP) and multipoint-to-multipoint 116 (MP2MP) LSPs. These are collectively referred to as multipoint LSPs 117 (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) 118 node to be delivered to a number of leaf (or egress) nodes. A MP2MP 119 LSP allows traffic from multiple ingress nodes to be delivered to 120 multiple egress nodes. Only a single copy of the packet will be sent 121 on any link traversed by the MP LSP (see note at end of 122 Section 2.4.1). This is accomplished without the use of a multicast 123 protocol in the network. There can be several MP LSPs rooted at a 124 given ingress node, each with its own identifier. 126 The solution assumes that the leaf nodes of the MP LSP know the root 127 node and identifier of the MP LSP to which they belong. The 128 mechanisms for the distribution of this information are outside the 129 scope of this document. The specification of how an application can 130 use a MP LSP signaled by LDP is also outside the scope of this 131 document. 133 Interested readers may also wish to peruse the requirements draft [9] 134 and other documents [8] and [10]. 136 1.1. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [2]. 142 1.2. Terminology 144 The following terminology is taken from [9]. 146 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 148 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 149 LSRs. 151 MP2P LSP: An LSP that has one or more Ingress LSRs and one unique 152 Egress LSR. 154 MP2MP LSP: An LSP that connects a set of leaf nodes, acting 155 indifferently as ingress or egress. 157 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 159 Ingress LSR: Source of the P2MP LSP, also referred to as root node. 161 Egress LSR: One of potentially many destinations of an LSP, also 162 referred to as leaf node in the case of P2MP and MP2MP LSPs. 164 Transit LSR: An LSR that has one or more directly connected 165 downstream LSRs. 167 Bud LSR: An LSR that is an egress but also has one or more directly 168 connected downstream LSRs. 170 2. Setting up P2MP LSPs with LDP 172 A P2MP LSP consists of a single root node, zero or more transit nodes 173 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 174 tear-down. Leaf nodes also install forwarding state to deliver the 175 traffic received on a P2MP LSP to wherever it needs to go; how this 176 is done is outside the scope of this document. Transit nodes install 177 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 178 down) toward the root. The root node installs forwarding state to 179 map traffic into the P2MP LSP; how the root node determines which 180 traffic should go over the P2MP LSP is outside the scope of this 181 document. 183 2.1. Support for P2MP LSP setup with LDP 185 Support for the setup of P2MP LSPs is advertised using LDP 186 capabilities as defined in [6]. An implementation supporting the 187 P2MP procedures specified in this document MUST implement the 188 procedures for Capability Parameters in Initialization Messages. 190 A new Capability Parameter TLV is defined, the P2MP Capability. 191 Following is the format of the P2MP Capability Parameter. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |1|0| P2MP Capability (TBD IANA) | Length (= 1) | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |1| Reserved | 199 +-+-+-+-+-+-+-+-+ 201 The P2MP Capability TLV MUST be supported in the LDP Initialization 202 Message. Advertisement of the P2MP Capability indicates support of 203 the procedures for P2MP LSP setup detailed in this document. If the 204 peer has not advertised the corresponding capability, then no label 205 messages using the P2MP FEC Element should be sent to the peer. 207 2.2. The P2MP FEC Element 209 For the setup of a P2MP LSP with LDP, we define one new protocol 210 entity, the P2MP FEC Element to be used as a FEC Element in the FEC 211 TLV. Note that the P2MP FEC Element does not necessarily identify 212 the traffic that must be mapped to the LSP, so from that point of 213 view, the use of the term FEC is a misnomer. The description of the 214 P2MP FEC Element follows. 216 The P2MP FEC Element consists of the address of the root of the P2MP 217 LSP and an opaque value. The opaque value consists of one or more 218 LDP MP Opaque Value Elements. The opaque value is unique within the 219 context of the root node. The combination of (Root Node Address, 220 Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. 222 The P2MP FEC Element is encoded as follows: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |P2MP Type (TBD)| Address Family | Address Length| 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 ~ Root Node Address ~ 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Opaque Length | Opaque Value ... | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 233 ~ ~ 234 | | 235 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Type: The type of the P2MP FEC Element is to be assigned by IANA. 241 Address Family: Two octet quantity containing a value from ADDRESS 242 FAMILY NUMBERS in [3] that encodes the address family for the Root 243 LSR Address. 245 Address Length: Length of the Root LSR Address in octets. 247 Root Node Address: A host address encoded according to the Address 248 Family field. 250 Opaque Length: The length of the Opaque Value, in octets. 252 Opaque Value: One or more MP Opaque Value elements, uniquely 253 identifying the P2MP LSP in the context of the Root Node. This is 254 described in the next section. 256 If the Address Family is IPv4, the Address Length MUST be 4; if the 257 Address Family is IPv6, the Address Length MUST be 16. No other 258 Address Lengths are defined at present. 260 If the Address Length doesn't match the defined length for the 261 Address Family, the receiver SHOULD abort processing the message 262 containing the FEC Element, and send an "Unknown FEC" Notification 263 message to its LDP peer signaling an error. 265 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 266 be the only FEC Element in the FEC TLV. 268 2.3. The LDP MP Opaque Value Element 270 The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC 271 Elements defined in subsequent sections. It carries information that 272 is meaningful to leaf (and bud) LSRs, but need not be interpreted by 273 non-leaf LSRs. 275 The LDP MP Opaque Value Element is encoded as follows: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type(TBD) | Length | Value ... | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 282 ~ ~ 283 | | 284 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Type: The type of the LDP MP Opaque Value Element is to be assigned 290 by IANA. 292 Length: The length of the Value field, in octets. 294 Value: String of Length octets, to be interpreted as specified by 295 the Type field. 297 2.3.1. The Generic LSP Identifier 299 The generic LSP identifier is a type of Opaque Value Element encoded 300 as follows: 302 Type: 1 (to be assigned by IANA) 304 Length: 4 306 Value: A 32bit integer, unique in the context of the root, as 307 identified by the root's address. 309 This type of Opaque Value Element is recommended when mapping of 310 traffic to LSPs is non-algorithmic, and done by means outside LDP. 312 2.4. Using the P2MP FEC Element 314 This section defines the rules for the processing and propagation of 315 the P2MP FEC Element. The following notation is used in the 316 processing rules: 318 1. P2MP FEC Element : a FEC Element with Root Node Address X 319 and Opaque Value Y. 321 2. P2MP Label Map : a Label Map message with a FEC TLV with 322 a single P2MP FEC Element and Label TLV with label L. 324 3. P2MP Label Withdraw : a Label Withdraw message with a 325 FEC TLV with a single P2MP FEC Element and Label TLV with 326 label L. 328 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 329 Address X and Opaque Value Y. 331 5. The notation L' -> { ..., } on LSR X 332 means that on receiving a packet with label L', X makes n copies 333 of the packet. For copy i of the packet, X swaps L' with Li and 334 sends it out over interface Ii. 336 The procedures below are organized by the role which the node plays 337 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 338 process which is outside the scope of this document. During the 339 course of protocol operation, the root node recognizes its role 340 because it owns the Root Node Address. A transit node is any node 341 (other than the root node) that receives a P2MP Label Map message 342 (i.e., one that has leaf nodes downstream of it). 344 Note that a transit node (and indeed the root node) may also be a 345 leaf node. 347 2.4.1. Label Map 349 The following lists procedures for generating and processing P2MP 350 Label Map messages for nodes that participate in a P2MP LSP. An LSR 351 should apply those procedures that apply to it, based on its role in 352 the P2MP LSP. 354 For the approach described here we use downstream assigned labels. 355 On Ethernet networks this may be less optimal, see Section 6. 357 2.4.1.1. Determining one's 'upstream LSR' 359 A node Z that is part of P2MP LSP determines the LDP peer U 360 which lies on the best path from Z to the root node X. If there are 361 more than one such LDP peers, only one of them is picked. U is Z's 362 "Upstream LSR" for . 364 When there are several candidate upstream LSRs, the LSR MAY select 365 one upstream LSR using the following procedure: 367 1. The candidate upstream LSRs are numbered from lower to higher IP 368 address 370 2. The following hash is performed: H = (Sum Opaque value) modulo N, 371 where N is the number of candidate upstream LSRs 373 3. The selected upstream LSR U is the LSR that has the number H. 375 This allows for load balancing of a set of LSPs among a set of 376 candidate upstream LSRs, while ensuring that on a LAN interface a 377 single upstream LSR is selected. 379 2.4.1.2. Leaf Operation 381 A leaf node Z of P2MP LSP determines its upstream LSR U for 382 as per Section 2.4.1.1, allocates a label L, and sends a P2MP 383 Label Map to U. 385 2.4.1.3. Transit Node operation 387 Suppose a transit node Z receives a P2MP Label Map from LDP 388 peer T. Z checks whether it already has state for . If not, Z 389 allocates a label L', and installs state to swap L' with L over 390 interface I associated with peer T. Z also determines its upstream 391 LSR U for as per Section 2.4.1.1, and sends a P2MP Label Map 392 to U. 394 If Z already has state for , then Z does not send a Label Map 395 message for P2MP LSP . All that Z needs to do in this case is 396 update its forwarding state. Assuming its old forwarding state was 397 L'-> { ..., }, its new forwarding state 398 becomes L'-> { ..., , }. 400 2.4.1.4. Root Node Operation 402 Suppose the root node Z receives a P2MP Label Map from peer 403 T. Z checks whether it already has forwarding state for . If 404 not, Z creates forwarding state to push label L onto the traffic that 405 Z wants to forward over the P2MP LSP (how this traffic is determined 406 is outside the scope of this document). 408 If Z already has forwarding state for , then Z adds "push label 409 L, send over interface I" to the nexthop, where I is the interface 410 associated with peer T. 412 2.4.2. Label Withdraw 414 The following lists procedures for generating and processing P2MP 415 Label Withdraw messages for nodes that participate in a P2MP LSP. An 416 LSR should apply those procedures that apply to it, based on its role 417 in the P2MP LSP. 419 2.4.2.1. Leaf Operation 421 If a leaf node Z discovers (by means outside the scope of this 422 document) that it is no longer a leaf of the P2MP LSP, it SHOULD send 423 a Label Withdraw to its upstream LSR U for , where L 424 is the label it had previously advertised to U for . 426 2.4.2.2. Transit Node Operation 428 If a transit node Z receives a Label Withdraw message from 429 a node W, it deletes label L from its forwarding state, and sends a 430 Label Release message with label L to W. 432 If deleting L from Z's forwarding state for P2MP LSP results 433 in no state remaining for , then Z propagates the Label 434 Withdraw for , to its upstream T, by sending a Label Withdraw 435 where L1 is the label Z had previously advertised to T for 436 . 438 2.4.2.3. Root Node Operation 440 The procedure when the root node of a P2MP LSP receives a Label 441 Withdraw message are the same as for transit nodes, except that it 442 would not propagate the Label Withdraw upstream (as it has no 443 upstream). 445 2.4.2.4. Upstream LSR change 447 If, for a given node Z participating in a P2MP LSP , the 448 upstream LSR changes, say from U to U', then Z MUST update its 449 forwarding state by deleting the state for label L, allocating a new 450 label, L', for , and installing the forwarding state for L'. In 451 addition Z MUST send a Label Map to U' and send a Label 452 Withdraw to U. 454 3. Shared Trees 456 The mechanism described above shows how to build a tree with a single 457 root and multiple leaves, i.e., a P2MP LSP. One can use essentially 458 the same mechanism to build Shared Trees with LDP. A Shared Tree can 459 be used by a group of routers that want to multicast traffic among 460 themselves, i.e., each node is both a root node (when it sources 461 traffic) and a leaf node (when any other member of the group sources 462 traffic). A Shared Tree offers similar functionality to a MP2MP LSP, 463 but the underlying multicasting mechanism uses a P2MP LSP. One 464 example where a Shared Tree is useful is video-conferencing. Another 465 is Virtual Private LAN Service (VPLS) [7], where for some types of 466 traffic, each device participating in a VPLS must send packets to 467 every other device in that VPLS. 469 One way to build a Shared Tree is to build an LDP P2MP LSP rooted at 470 a common point, the Shared Root (SR), and whose leaves are all the 471 members of the group. Each member of the Shared Tree unicasts 472 traffic to the SR (using, for example, the MP2P LSP created by the 473 unicast LDP FEC advertised by the SR); the SR then splices this 474 traffic into the LDP P2MP LSP. The SR may be (but need not be) a 475 member of the multicast group. 477 A major advantage of this approach is that no further protocol 478 mechanisms beyond the one already described are needed to set up a 479 Shared Tree. Furthermore, a Shared Tree is very efficient in terms 480 of the multicast state in the network, and is reasonably efficient in 481 terms of the bandwidth required to send traffic. 483 A property of this approach is that a sender will receive its own 484 packets as part of the multicast; thus a sender must be prepared to 485 recognize and discard packets that it itself has sent. For a number 486 of applications (for example, VPLS), this requirement is easy to 487 meet. Another consideration is the various techniques that can be 488 used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will 489 be described in a later revision. 491 4. Setting up MP2MP LSPs with LDP 493 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 494 root node, zero or more transit nodes and one or more leaf LSRs 495 acting equally as Ingress or Egress LSR. A leaf node participates in 496 the setup of an MP2MP LSP by establishing both a downstream LSP, 497 which is much like a P2MP LSP from the root, and an upstream LSP 498 which is used to send traffic toward the root and other leaf nodes. 499 Transit nodes support the setup by propagating the upstream and 500 downstream LSP setup toward the root and installing the necessary 501 MPLS forwarding state. The transmission of packets from the root 502 node of a MP2MP LSP to the receivers is identical to that for a P2MP 503 LSP. Traffic from a leaf node follows the upstream LSP toward the 504 root node and branches downward along the downstream LSP as required 505 to reach other leaf nodes. Mapping traffic to the MP2MP LSP may 506 happen at any leaf node. How that mapping is established is outside 507 the scope of this document. 509 Due to how a MP2MP LSP is built a leaf LSR that is sending packets on 510 the MP2MP LSP does not receive its own packets. There is also no 511 additional mechanism needed on the root or transit LSR to match 512 upstream traffic to the downstream forwarding state. Packets that 513 are forwarded over a MP2MP LSP will not traverse a link more than 514 once, with the exception of LAN links which are discussed in 515 Section 4.3.1 517 4.1. Support for MP2MP LSP setup with LDP 519 Support for the setup of MP2MP LSPs is advertised using LDP 520 capabilities as defined in [6]. An implementation supporting the 521 MP2MP procedures specified in this document MUST implement the 522 procedures for Capability Parameters in Initialization Messages. 524 A new Capability Parameter TLV is defined, the MP2MP Capability. 525 Following is the format of the MP2MP Capability Parameter. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 |1|0| MP2MP Capability (TBD IANA) | Length (= 1) | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 |1| Reserved | 533 +-+-+-+-+-+-+-+-+ 535 The MP2MP Capability TLV MUST be supported in the LDP Initialization 536 Message. Advertisement of the MP2MP Capability indicates support of 537 the procedures for MP2MP LSP setup detailed in this document. If the 538 peer has not advertised the corresponding capability, then no label 539 messages using the MP2MP upstream and downstream FEC Elements should 540 be sent to the peer. 542 4.2. The MP2MP downstream and upstream FEC Elements. 544 For the setup of a MP2MP LSP with LDP we define 2 new protocol 545 entities, the MP2MP downstream FEC and upstream FEC Element. Both 546 elements will be used as FEC Elements in the FEC TLV. Note that the 547 MP2MP FEC Elements do not necessarily identify the traffic that must 548 be mapped to the LSP, so from that point of view, the use of the term 549 FEC is a misnomer. The description of the MP2MP FEC Elements follow. 551 The structure, encoding and error handling for the MP2MP downstream 552 and upstream FEC Elements are the same as for the P2MP FEC Element 553 described in Section 2.2. The difference is that two new FEC types 554 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 556 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 557 MUST be the only FEC Element in the FEC TLV. 559 4.3. Using the MP2MP FEC Elements 561 This section defines the rules for the processing and propagation of 562 the MP2MP FEC Elements. The following notation is used in the 563 processing rules: 565 1. MP2MP downstream LSP (or simply downstream ): an 566 MP2MP LSP downstream path with root node address X and opaque 567 value Y. 569 2. MP2MP upstream LSP (or simply upstream ): a 570 MP2MP LSP upstream path for downstream node D with root node 571 address X and opaque value Y. 573 3. MP2MP downstream FEC Element : a FEC Element with root node 574 address X and opaque value Y used for a downstream MP2MP LSP. 576 4. MP2MP upstream FEC Element : a FEC Element with root node 577 address X and opaque value Y used for an upstream MP2MP LSP. 579 5. MP2MP Label Map downstream : A Label Map message with a 580 FEC TLV with a single MP2MP downstream FEC Element and 581 label TLV with label L. 583 6. MP2MP Label Map upstream : A Label Map message with a 584 FEC TLV with a single MP2MP upstream FEC Element and label 585 TLV with label Lu. 587 7. MP2MP Label Withdraw downstream : a Label Withdraw 588 message with a FEC TLV with a single MP2MP downstream FEC Element 589 and label TLV with label L. 591 8. MP2MP Label Withdraw upstream : a Label Withdraw 592 message with a FEC TLV with a single MP2MP upstream FEC Element 593 and label TLV with label Lu. 595 The procedures below are organized by the role which the node plays 596 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 597 process which is outside the scope of this document. During the 598 course of the protocol operation, the root node recognizes its role 599 because it owns the root node address. A transit node is any node 600 (other then the root node) that receives a MP2MP Label Map message 601 (i.e., one that has leaf nodes downstream of it). 603 Note that a transit node (and indeed the root node) may also be a 604 leaf node and the root node does not have to be an ingress LSR or 605 leaf of the MP2MP LSP. 607 4.3.1. MP2MP Label Map upstream and downstream 609 The following lists procedures for generating and processing MP2MP 610 Label Map messages for nodes that participate in a MP2MP LSP. An LSR 611 should apply those procedures that apply to it, based on its role in 612 the MP2MP LSP. 614 For the approach described here if there are several receivers for a 615 MP2MP LSP on a LAN, packets are replicated over the LAN. This may 616 not be optimal; optimizing this case is for further study, see [4]. 618 4.3.1.1. Determining one's upstream MP2MP LSR 620 Determining the upstream LDP peer U for a MP2MP LSP follows 621 the procedure for a P2MP LSP described in Section 2.4.1.1. 623 4.3.1.2. Determining one's downstream MP2MP LSR 625 A LDP peer U which receives a MP2MP Label Map downstream from a LDP 626 peer D will treat D as downstream MP2MP LSR. 628 4.3.1.3. MP2MP leaf node operation 630 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 631 as per Section 4.3.1.1, allocates a label L, and sends a MP2MP 632 Label Map downstream to U. 634 Leaf node Z expects an MP2MP Label Map upstream from node 635 U in response to the MP2MP Label Map downstream it sent to node U. Z 636 checks whether it already has forwarding state for upstream . 637 If not, Z creates forwarding state to push label Lu onto the traffic 638 that Z wants to forward over the MP2MP LSP. How it determines what 639 traffic to forward on this MP2MP LSP is outside the scope of this 640 document. 642 4.3.1.4. MP2MP transit node operation 644 When node Z receives a MP2MP Label Map downstream from peer 645 D associated with interface I, it checks whether it has forwarding 646 state for downstream . If not, Z allocates a label L' and 647 installs downstream forwarding state to swap label L' with label L 648 over interface I. Z also determines its upstream LSR U for as 649 per Section 4.3.1.1, and sends a MP2MP Label Map downstream to U. 652 If Z already has forwarding state for downstream , all that Z 653 needs to do is update its forwarding state. Assuming its old 654 forwarding state was L'-> { ..., }, its new 655 forwarding state becomes L'-> { ..., , }. 658 Node Z checks whether it already has forwarding state upstream . If it does, then no further action needs to happen. If it does 660 not, it allocates a label Lu and creates a new label swap for Lu from 661 the label swap(s) from the forwarding state downstream , 662 omitting the swap on interface I for node D. This allows upstream 663 traffic to follow the MP2MP tree down to other node(s) except the 664 node from which Z received the MP2MP Label Map downstream . 665 Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2, 666 and sends a MP2MP Label Map upstream to node D. 668 Transit node Z will also receive a MP2MP Label Map upstream in response to the MP2MP Label Map downstream sent to node U 670 associated with interface Iu. Node Z will add label swap Lu over 671 interface Iu to the forwarding state upstream . This allows 672 packets to go up the tree towards the root node. 674 4.3.1.5. MP2MP root node operation 676 4.3.1.5.1. Root node is also a leaf 678 Suppose root/leaf node Z receives a MP2MP Label Map downstream from node D associated with interface I. Z checks whether it 680 already has forwarding state downstream . If not, Z creates 681 forwarding state for downstream to push label L on traffic that Z 682 wants to forward down the MP2MP LSP. How it determines what traffic 683 to forward on this MP2MP LSP is outside the scope of this document. 684 If Z already has forwarding state for downstream , then Z will 685 add the label push for L over interface I to it. 687 Node Z checks if it has forwarding state for upstream . If 688 not, Z allocates a label Lu and creates upstream forwarding state to 689 push Lu with the label push(s) from the forwarding state downstream 690 , except the push on interface I for node D. This allows 691 upstream traffic to go down the MP2MP to other node(s), except the 692 node from which the traffic was received. Node Z determines the 693 downstream MP2MP LSR as per section Section 4.3.1.2, and sends a 694 MP2MP Label Map upstream to node D. Since Z is the root of 695 the tree Z will not send a MP2MP downstream map and will not receive 696 a MP2MP upstream map. 698 4.3.1.5.2. Root node is not a leaf 700 Suppose the root node Z receives a MP2MP Label Map downstream from node D associated with interface I. Z checks whether it 702 already has forwarding state for downstream . If not, Z 703 creates downstream forwarding state and installs a outgoing label L 704 over interface I. If Z already has forwarding state for downstream 705 , then Z will add label L over interface I to the existing 706 state. 708 Node Z checks if it has forwarding state for upstream . If 709 not, Z allocates a label Lu and creates forwarding state to swap Lu 710 with the label swap(s) from the forwarding state downstream , 711 except the swap for node D. This allows upstream traffic to go down 712 the MP2MP to other node(s), except the node is was received from. 713 Root node Z determines the downstream MP2MP LSR D as per 714 Section 4.3.1.2, and sends a MP2MP Label Map upstream to 715 it. Since Z is the root of the tree Z will not send a MP2MP 716 downstream map and will not receive a MP2MP upstream map. 718 4.3.2. MP2MP Label Withdraw 720 The following lists procedures for generating and processing MP2MP 721 Label Withdraw messages for nodes that participate in a MP2MP LSP. 722 An LSR should apply those procedures that apply to it, based on its 723 role in the MP2MP LSP. 725 4.3.2.1. MP2MP leaf operation 727 If a leaf node Z discovers (by means outside the scope of this 728 document) that it is no longer a leaf of the MP2MP LSP, it SHOULD 729 send a downstream Label Withdraw to its upstream LSR U for 730 , where L is the label it had previously advertised to U for 731 . 733 Leaf node Z expects the upstream router U to respond by sending a 734 downstream label release for L and a upstream Label Withdraw for to remove Lu from the upstream state. Node Z will remove 736 label Lu from its upstream state and send a label release message 737 with label Lu to U. 739 4.3.2.2. MP2MP transit node operation 741 If a transit node Z receives a downstream label withdraw message from node D, it deletes label L from its forwarding state 743 downstream and from all its upstream states for . Node 744 Z sends a label release message with label L to D. Since node D is no 745 longer part of the downstream forwarding state, Z cleans up the 746 forwarding state upstream and sends a upstream Label 747 Withdraw for to D. 749 If deleting L from Z's forwarding state for downstream results 750 in no state remaining for , then Z propagates the Label 751 Withdraw to its upstream node U for . 753 4.3.2.3. MP2MP root node operation 755 The procedure when the root node of a MP2MP LSP receives a label 756 withdraw message is the same as for transit nodes, except that the 757 root node would not propagate the Label Withdraw upstream (as it has 758 no upstream). 760 4.3.2.4. MP2MP Upstream LSR change 762 The procedure for changing the upstream LSR is the same as documented 763 in Section 2.4.2.4, except it is applied to MP2MP FECs, using the 764 procedures described in Section 4.3.1 through Section 4.3.2.3. 766 5. The LDP MP Status TLV 768 An LDP MP capable router MAY use an LDP MP Status TLV to indicate 769 additional status for a MP LSP to its remote peers. This includes 770 signaling to peers that are either upstream or downstream of the LDP 771 MP capable router. The value of the LDP MP status TLV will remain 772 opaque to LDP and MAY encode one or more status elements. 774 The LDP MP Status TLV is encoded as follows: 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 |1|0| LDP MP Status Type(TBD) | Length | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Value | 782 ~ ~ 783 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. 789 Length: Length of the LDP MP Status Value in octets. 791 Value: One or more LDP MP Status Value elements. 793 5.1. The LDP MP Status Value Element 795 The LDP MP Status Value Element that is included in the LDP MP Status 796 TLV Value has the following encoding. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type(TBD) | Length | Value ... | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 803 ~ ~ 804 | | 805 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Type: The type of the LDP MP Status Value Element is to be assigned 811 by IANA. 813 Length: The length of the Value field, in octets. 815 Value: String of Length octets, to be interpreted as specified by 816 the Type field. 818 5.2. LDP Messages containing LDP MP Status messages 820 The LDP MP status message may appear either in a label mapping 821 message or a LDP notification message. 823 5.2.1. LDP MP Status sent in LDP notification messages 825 An LDP MP status TLV sent in a notification message must be 826 accompanied with a Status TLV. The general format of the 827 Notification Message with an LDP MP status TLV is: 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 |0| Notification (0x0001) | Message Length | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Message ID | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Status TLV | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | LDP MP Status TLV | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Optional LDP MP FEC TLV | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Optional Label TLV | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 The Status TLV status code is used to indicate that LDP MP status TLV 846 and an additional information follows in the Notification message's 847 "optional parameter" section. Depending on the actual contents of 848 the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may 849 also be present to provide context to the LDP MP Status TLV. (NOTE: 850 Status Code is pending IANA assignment). 852 Since the notification does not refer to any particular message, the 853 Message Id and Message Type fields are set to 0. 855 5.2.2. LDP MP Status TLV in Label Mapping Message 857 An example of the Label Mapping Message defined in RFC3036 is shown 858 below to illustrate the message with an Optional LDP MP Status TLV 859 present. 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 |0| Label Mapping (0x0400) | Message Length | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Message ID | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | FEC TLV | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Label TLV | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Optional LDP MP Status TLV | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Additional Optional Parameters | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 6. Upstream label allocation on a LAN 879 On a LAN the upstream LSR will send a copy of the packet to each 880 receiver individually. If there is more then one receiver on the LAN 881 we don't take full benefit of the multi-access capability of the 882 network. We may optimize the bandwidth consumption on the LAN and 883 replication overhead on the upstream LSR by using upstream label 884 allocation [4]. Procedures on how to distribute upstream labels 885 using LDP is documented in [5]. 887 6.1. LDP Multipoint-to-Multipoint on a LAN 889 The procedure to allocate a context label on a LAN is defined in [4]. 890 That procedure results in each LSR on a given LAN having a context 891 label which, on that LAN, can be used to identify itself uniquely. 892 Each LSR advertises its context label as an upstream-assigned label, 893 following the procedures of [5]. Any LSR for which the LAN is a 894 downstream link on some P2MP or MP2MP LSP will allocate an upstream- 895 assigned label identifying that LSP. When the LSR forwards a packet 896 downstream on one of those LSPs, the packet's top label must be the 897 LSR's context label, and the packet's second label is the label 898 identifying the LSP. We will call the top label the "upstream LSR 899 label" and the second label the "LSP label". 901 6.1.1. MP2MP downstream forwarding 903 The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so 904 we will use the same procedures as defined in [5]. A label request 905 for a LSP label is send to the upstream LSR. The label mapping that 906 is received from the upstream LSR contains the LSP label for the 907 MP2MP FEC and the upstream LSR context label. The MP2MP downstream 908 path (corresponding to the LSP label) will be installed the context 909 specific forwarding table corresponding to the upstream LSR label. 910 Packets sent by the upstream router can be forwarded downstream using 911 this forwarding state based on a two label lookup. 913 6.1.2. MP2MP upstream forwarding 915 A MP2MP LSP also has an upstream forwarding path. Upstream packets 916 need to be forwarded in the direction of the root and downstream on 917 any node on the LAN that has a downstream interface for the LSP. For 918 a given MP2MP LSP on a given LAN, exactly one LSR is considered to be 919 the upstream LSR. If an LSR on the LAN receives a packet from one of 920 its downstream interfaces for the LSP, and if it needs to forward the 921 packet onto the LAN, it ensures that the packet's top label is the 922 context label of the upstream LSR, and that its second label is the 923 LSP label that was assigned by the upstream LSR. 925 Other LSRs receiving the packet will not be able to tell whether the 926 packet really came from the upstream router, but that makes no 927 difference in the processing of the packet. The upstream LSR will 928 see its own upstream LSR in the label, and this will enable it to 929 determine that the packet is traveling upstream. 931 7. Root node redundancy 933 The root node is a single point of failure for an MP LSP, whether 934 this is P2MP or MP2MP. The problem is particularly severe for MP2MP 935 LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same 936 root node to set up the MP2MP LSP, because otherwise the traffic 937 sourced by some leafs is not received by others. Because the root 938 node is the single point of failure for an MP LSP, we need a fast and 939 efficient mechanism to recover from a root node failure. 941 An MP LSP is uniquely identified in the network by the opaque value 942 and the root node address. It is likely that the root node for an MP 943 LSP is defined statically. The root node address may be configured 944 on each leaf statically or learned using a dynamic protocol. How 945 leafs learn about the root node is out of the scope of this document. 947 Suppose that for the same opaque value we define two (or more) root 948 node addresses and we build a tree to each root using the same opaque 949 value. Effectively these will be treated as different MP LSPs in the 950 network. Once the trees are built, the procedures differ for P2MP 951 and MP2MP LSPs. The different procedures are explained in the 952 sections below. 954 7.1. Root node redundancy - procedures for P2MP LSPs 956 Since all leafs have set up P2MP LSPs to all the roots, they are 957 prepared to receive packets on either one of these LSPs. However, 958 only one of the roots should be forwarding traffic at any given time, 959 for the following reasons: 1) to achieve bandwidth savings in the 960 network and 2) to ensure that the receiving leafs don't receive 961 duplicate packets (since one cannot assume that the receiving leafs 962 are able to discard duplicates). How the roots determine which one 963 is the active sender is outside the scope of this document. 965 7.2. Root node redundancy - procedures for MP2MP LSPs 967 Since all leafs have set up an MP2MP LSP to each one of the root 968 nodes for this opaque value, a sending leaf may pick either of the 969 two (or more) MP2MP LSPs to forward a packet on. The leaf nodes 970 receive the packet on one of the MP2MP LSPs. The client of the MP2MP 971 LSP does not care on which MP2MP LSP the packet is received, as long 972 as they are for the same opaque value. The sending leaf MUST only 973 forward a packet on one MP2MP LSP at a given point in time. The 974 receiving leafs are unable to discard duplicate packets because they 975 accept on all LSPs. Using all the available MP2MP LSPs we can 976 implement redundancy using the following procedures. 978 A sending leaf selects a single root node out of the available roots 979 for a given opaque value. A good strategy MAY be to look at the 980 unicast routing table and select a root that is closest in terms of 981 the unicast metric. As soon as the root address of the active root 982 disappears from the unicast routing table (or becomes less 983 attractive) due to root node or link failure, the leaf can select a 984 new best root address and start forwarding to it directly. If 985 multiple root nodes have the same unicast metric, the highest root 986 node addresses MAY be selected, or per session load balancing MAY be 987 done over the root nodes. 989 All leafs participating in a MP2MP LSP MUST join to all the available 990 root nodes for a given opaque value. Since the sending leaf may pick 991 any MP2MP LSP, it must be prepared to receive on it. 993 The advantage of pre-building multiple MP2MP LSPs for a single opaque 994 value is that convergence from a root node failure happens as fast as 995 the unicast routing protocol is able to notify. There is no need for 996 an additional protocol to advertise to the leaf nodes which root node 997 is the active root. The root selection is a local leaf policy that 998 does not need to be coordinated with other leafs. The disadvantage 999 of pre-building multiple MP2MP LSPs is that more label resources are 1000 used, depending on how many root nodes are defined. 1002 8. Make Before Break (MBB) 1004 An LSR selects as its upstream LSR for a MP LSP the LSR that is its 1005 next hop to the root of the LSP. When the best path to reach the 1006 root changes the LSR must choose a new upstream LSR. Sections 1007 Section 2.4.2.4 and Section 4.3.2.4 describe these procedures. 1009 When the best path to the root changes the LSP may be broken 1010 temporarily resulting in packet loss until the LSP "reconverges" to a 1011 new upstream LSR. The goal of MBB when this happens is to keep the 1012 duration of packet loss as short as possible. In addition, there are 1013 scenarios where the best path from the LSR to the root changes but 1014 the LSP continues to forward packets to the prevous next hop to the 1015 root. That may occur when a link comes up or routing metrics change. 1016 In such a case a new LSP should be established before the old LSP is 1017 removed to limit the duration of packet loss. The procedures 1018 described below deal with both scenarios in a way that an LSR does 1019 not need to know which of the events described above caused its 1020 upstream router for an MBB LSP to change. 1022 This MBB procedures are an optional extension to the MP LSP building 1023 procedures described in this draft. 1025 8.1. MBB overview 1027 The MBB procedues use additional LDP signaling. 1029 Suppose some event causes a downstream LSR-D to select a new upstream 1030 LSR-U for FEC-A. The new LSR-U may already be forwarding packets for 1031 FEC-A; that is, to downstream LSR's other than LSR-D. After LSR-U 1032 receives a label for FEC-A from LSR-D, it will notify LSR-D when it 1033 knows that the LSP for FEC-A has been established from the root to 1034 itself. When LSR-D receives this MBB notification it will change its 1035 next hop for the LSP root to LSR-U. 1037 The assumption is that if LSR-U has received an MBB notification from 1038 its upstream router for the FEC-A LSP and has installed forwarding 1039 state the LSP it is capable of forwarding packets on the LSP. At 1040 that point LSR-U should signal LSR-D by means of an MBB notification 1041 that it has become part of the tree identified by FEC-A and that 1042 LSR-D should initiate its switchover to the LSP. 1044 At LSR-U the LSP for FEC-A may be in 1 of 3 states. 1046 1. There is no state for FEC-A. 1048 2. State for FEC-A exists and LSR-U is waiting for MBB notification 1049 that the LSP from the root to it exists. 1051 3. State for FEC-A exists and the MBB notification has been 1052 received. 1054 After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U 1055 MUST NOT reply with an MBB notification to LSR-D until its state for 1056 the LSP is state #3 above. If the state of the LSP at LSR-U is state 1057 #1 or #2, LSR-U should remember receipt of the Label Mapping message 1058 from LSR-D while waiting for an MBB notification from its upstream 1059 LSR for the LSP. When LSR-U receives the MBB notification from its 1060 upstream LSR it transitions to LSP state #3 and sends an MBB 1061 notification to LSR-D. 1063 8.2. The MBB Status code 1065 As noted in Section 8.1, the procedures to establish an MBB MP LSP 1066 are different from those to establish normal MP LSPs. 1068 When a downstream LSR sends a Label Mapping message for MP LSP to its 1069 upstream LSR it MAY include an LDP MP Status TLV that carries a MBB 1070 Status Code to indicate MBB procedures apply to the LSP. This new 1071 MBB Status Code MAY also appear in an LDP Notification message used 1072 by an upstream LSR to signal LSP state #3 to the downstream LSR; that 1073 is, that the upstream LSR's state for the LSP exists and that it has 1074 received notification from its upstream LSR that the LSP is in state 1075 #3. 1077 The MBB Status is a type of the LDP MP Status Value Element as 1078 described in Section 5.1. It is encoded as follows: 1080 0 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | MBB Type = 1 | Length = 1 | Status code | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 MBB Type: Type 1 (to be assigned by IANA) 1088 Length: 1 1090 Status code: 1 = MBB request 1091 2 = MBB ack 1093 8.3. The MBB capability 1095 An LSR MAY advertise that it is capable of handling MBB LSPs using 1096 the capability advertisement as defined in [6]. The LDP MP MBB 1097 capability has the following format: 1099 0 1 2 3 1100 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 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 |1|0| LDP MP MBB Capability | Length = 1 | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 |1| Reserved | 1105 +-+-+-+-+-+-+-+-+ 1107 Note: LDP MP MBB Capability (Pending IANA assignment) 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 |1|0| LDP MP MBB Capability | Length = 1 | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 |1| Reserved | 1115 +-+-+-+-+-+-+-+-+ 1117 If an LSR has not advertised that it is MBB capable, its LDP peers 1118 MUST NOT send it messages which include MBB parameters. If an LSR 1119 receives a Label Mapping message with a MBB parameter from downstream 1120 LSR-D and its upstream LSR-U has not advertised that it is MBB 1121 capable, the LSR MUST send an MBB notification immediatly to LSR-U 1122 (see Section 8.4). If this happens an MBB MP LSP will not be 1123 established, but normal a MP LSP will be the result. 1125 8.4. The MBB procedures 1127 8.4.1. Terminology 1129 1. MBB LSP : A P2MP or MP2MP Make Before Break (MBB) LSP entry 1130 with Root Node Address X and Opaque Value Y. 1132 2. A(N, L): An Accepting element that consists of an upstream 1133 Neighbor N and Local label L. This LSR assigned label L to 1134 neighbor N for a specific MBB LSP. For an active element the 1135 corresponding Label is stored in the label forwarding database. 1137 3. iA(N, L): An inactive Accepting element that consists of an 1138 upstream neighbor N and local Label L. This LSR assigned label L 1139 to neighbor N for a specific MBB LSP. For an inactive element 1140 the corresponding Label is not stored in the label forwarding 1141 database. 1143 4. F(N, L): A Forwarding state that consists of downstream Neighbor 1144 N and Label L. This LSR is sending label packets with label L to 1145 neighbor N for a specific FEC. 1147 5. F'(N, L): A Forwarding state that has been marked for sending a 1148 MBB Notification message to Neighbor N with Label L. 1150 6. MBB Notification : A LDP notification message with a MP 1151 LSP , Label L and MBB Status code 2. 1153 7. MBB Label Map : A P2MP Label Map or MP2MP Label Map 1154 downstream with a FEC element , Label L and MBB Status code 1155 1. 1157 8.4.2. Accepting elements 1159 An accepting element represents a specific label value L that has 1160 been advertised to a neighbor N for a MBB LSP and is a 1161 candidate for accepting labels switched packets on. An LSR can have 1162 two accepting elements for a specific MBB LSP LSP, only one of 1163 them MUST be active. An active element is the element for which the 1164 label value has been installed in the label forwarding database. An 1165 inactive accepting element is created after a new upstream LSR is 1166 chosen and is pending to replace the active element in the label 1167 forwarding database. Inactive elements only exist temporarily while 1168 switching to a new upstream LSR. Once the switch has been completed 1169 only one active element remains. During network convergence it is 1170 possible that an inactive accepting element is created while an other 1171 inactive accepting element is pending. If that happens the older 1172 inactive accepting element MUST be replaced with an newer inactive 1173 element. If an accepting element is removed a Label Withdraw has to 1174 be send for label L to neighbor N for . 1176 8.4.3. Procedures for upstream LSR change 1178 Suppose a node Z has a MBB LSP with an active accepting 1179 element A(N1, L1). Due to a routing change it detects a new best 1180 path for root X and selects a new upstream LSR N2. Node Z allocates 1181 a new local label L2 and creates an inactive accepting element iA(N2, 1182 L2). Node Z sends MBB Label Map to N2 and waits for the 1183 new upstream LSR N2 to respond with a MBB Notification for . During this transition phase there are two accepting elements, 1185 the element A(N1, L1) still accepting packets from N1 over label L1 1186 and the new inactive element iA(N2, L2). 1188 While waiting for the MBB Notification from upstream LSR N2, it is 1189 possible that an other transition occurs due to a routing change. 1190 Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) 1191 is created and the old inactive element iA(N2, L2) MUST be removed. 1192 A label withdraw MUST be sent to N2 for from N2 will be ignored because the 1194 inactive element is removed. 1196 It is possible that the MBB Notification from upstream LSR is never 1197 received due to link or node failure. To prevent waiting 1198 indefinitely for the MBB Notification a timeout SHOULD be applied. 1199 As soon as the timer expires, the procedures in Section 8.4.5 are 1200 applied as if a MBB Notification was received for the inactive 1201 element. 1203 8.4.4. Receiving a Label Map with MBB status code 1205 Suppose node Z has state for a MBB LSP and receives a MBB 1206 Label Map from N2. A new forwarding state F(N2, L2) will 1207 be added to the MP LSP if it did not already exist. If this MBB LSP 1208 has an active accepting element or node Z is the root of the MBB LSP 1209 a MBB notification is send to node N2. If node Z has an 1210 inactive accepting element it marks the Forwarding state as . 1213 8.4.5. Receiving a Notification with MBB status code 1215 Suppose node Z receives a MBB Notification from N. If node 1216 Z has state for MBB LSP and an inactive accepting element 1217 iA(N, L) that matches with N and L, we activate this accepting 1218 element and install label L in the label forwarding database. If an 1219 other active accepting was present it will be removed from the label 1220 forwarding database. 1222 If this MBB LSP also has Forwarding states marked for sending 1223 MBB Notifications, like , MBB Notifications are 1224 send to these downstream LSRs. If node Z receives a MBB Notification 1225 for an accepting element that is not inactive or does not match the 1226 Label value and Neighbor address, the MBB notification is ignored. 1228 8.4.6. Node operation for MP2MP LSPs 1230 The procedures described above apply to the downstream path of a 1231 MP2MP LSP. The upstream path of the MP2MP is setup as normal without 1232 including a MBB Status code. If the MBB procedures apply to a MP2MP 1233 downstream FEC element, the upstream path to a node N is only 1234 installed in the label forwarding database if node N is part of the 1235 active accepting element. If node N is part of an inactive accepting 1236 element, the upstream path is installed when this inactive accepting 1237 element is activated. 1239 9. Security Considerations 1241 The same security considerations apply as for the base LDP 1242 specification, as described in [1]. 1244 10. IANA considerations 1246 This document creates a new name space (the LDP MP Opaque Value 1247 Element type) that is to be managed by IANA, and the allocation of 1248 the value 1 for the type of Generic LSP Identifier. 1250 This document requires allocation of three new LDP FEC Element types: 1252 1. the P2MP FEC type - requested value 0x04 1254 2. the MP2MP-up FEC type - requested value 0x05 1256 3. the MP2MP-down FEC type - requested value 0x06 1258 This document requires the assignment of three new code points for 1259 three new Capability Parameter TLVs, corresponding to the 1260 advertisement of the P2MP, MP2MP and MBB capabilities. The values 1261 requested are: 1263 P2MP Capability Parameter - requested value 0x0508 1265 MP2MP Capability Parameter - requested value 0x0509 1267 MBB Capability Parameter - requested value 0x050A 1269 This document requires the assignment of a LDP Status TLV code to 1270 indicate a LDP MP Status TLV is following in the Notification 1271 message. The value requested is: 1273 LDP MP status - requested value 0x0000002C 1275 This document requires the assigment of a new code point for a LDP MP 1276 Status TLV. The value requested is: 1278 LDP MP Status TLV Type - requested value 0x096D 1280 This document creates a new name space (the LDP MP Status Value 1281 Element type) that is to be managed by IANA, and the allocation of 1282 the value 1 for the type of MBB Status. 1284 11. Acknowledgments 1286 The authors would like to thank the following individuals for their 1287 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 1288 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, 1289 George Swallow, Jin Lizhong, Vanson Lim and Adrian Farrel. 1291 12. Contributing authors 1293 Below is a list of the contributing authors in alphabetical order: 1295 Shane Amante 1296 Level 3 Communications, LLC 1297 1025 Eldorado Blvd 1298 Broomfield, CO 80021 1299 US 1300 Email: Shane.Amante@Level3.com 1302 Luyuan Fang 1303 Cisco Systems 1304 300 Beaver Brook Road 1305 Boxborough, MA 01719 1306 US 1307 Email: lufang@cisco.com 1309 Hitoshi Fukuda 1310 NTT Communications Corporation 1311 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1312 Tokyo 100-8019, 1313 Japan 1314 Email: hitoshi.fukuda@ntt.com 1315 Yuji Kamite 1316 NTT Communications Corporation 1317 Tokyo Opera City Tower 1318 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1319 Tokyo 163-1421, 1320 Japan 1321 Email: y.kamite@ntt.com 1323 Kireeti Kompella 1324 Juniper Networks 1325 1194 N. Mathilda Ave. 1326 Sunnyvale, CA 94089 1327 US 1328 Email: kireeti@juniper.net 1330 Ina Minei 1331 Juniper Networks 1332 1194 N. Mathilda Ave. 1333 Sunnyvale, CA 94089 1334 US 1335 Email: ina@juniper.net 1337 Jean-Louis Le Roux 1338 France Telecom 1339 2, avenue Pierre-Marzin 1340 Lannion, Cedex 22307 1341 France 1342 Email: jeanlouis.leroux@francetelecom.com 1344 Bob Thomas 1345 Cisco Systems, Inc. 1346 300 Beaver Brook Road 1347 Boxborough, MA, 01719 1348 E-mail: rhthomas@cisco.com 1350 Lei Wang 1351 Telenor 1352 Snaroyveien 30 1353 Fornebu 1331 1354 Norway 1355 Email: lei.wang@telenor.com 1356 IJsbrand Wijnands 1357 Cisco Systems, Inc. 1358 De kleetlaan 6a 1359 1831 Diegem 1360 Belgium 1361 E-mail: ice@cisco.com 1363 13. References 1365 13.1. Normative References 1367 [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 1368 Thomas, "LDP Specification", RFC 3036, January 2001. 1370 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1371 Levels", BCP 14, RFC 2119, March 1997. 1373 [3] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 1374 line Database", RFC 3232, January 2002. 1376 [4] Aggarwal, R., "MPLS Upstream Label Assignment and Context 1377 Specific Label Space", draft-ietf-mpls-upstream-label-02 (work 1378 in progress), March 2007. 1380 [5] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for 1381 LDP", draft-ietf-mpls-ldp-upstream-01 (work in progress), 1382 March 2007. 1384 [6] Thomas, B., "LDP Capabilities", 1385 draft-ietf-mpls-ldp-capabilities-00 (work in progress), 1386 May 2007. 1388 13.2. Informative References 1390 [7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1391 Private Networks (L2VPNs)", RFC 4664, September 2006. 1393 [8] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions 1394 to Resource Reservation Protocol - Traffic Engineering 1395 (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths 1396 (LSPs)", RFC 4875, May 2007. 1398 [9] Roux, J., "Requirements for Point-To-Multipoint Extensions to 1399 the Label Distribution Protocol", 1400 draft-ietf-mpls-mp-ldp-reqs-02 (work in progress), March 2007. 1402 [10] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", 1403 draft-ietf-l3vpn-2547bis-mcast-00 (work in progress), 1404 June 2005. 1406 Authors' Addresses 1408 Ina Minei 1409 Juniper Networks 1410 1194 N. Mathilda Ave. 1411 Sunnyvale, CA 94089 1412 US 1414 Email: ina@juniper.net 1416 Kireeti Kompella 1417 Juniper Networks 1418 1194 N. Mathilda Ave. 1419 Sunnyvale, CA 94089 1420 US 1422 Email: kireeti@juniper.net 1424 IJsbrand Wijnands 1425 Cisco Systems, Inc. 1426 De kleetlaan 6a 1427 Diegem 1831 1428 Belgium 1430 Email: ice@cisco.com 1432 Bob Thomas 1433 Cisco Systems, Inc. 1434 300 Beaver Brook Road 1435 Boxborough 01719 1436 US 1438 Email: rhthomas@cisco.com 1440 Full Copyright Statement 1442 Copyright (C) The IETF Trust (2008). 1444 This document is subject to the rights, licenses and restrictions 1445 contained in BCP 78, and except as set forth therein, the authors 1446 retain all their rights. 1448 This document and the information contained herein are provided on an 1449 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1450 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1451 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1452 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1453 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1454 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1456 Intellectual Property 1458 The IETF takes no position regarding the validity or scope of any 1459 Intellectual Property Rights or other rights that might be claimed to 1460 pertain to the implementation or use of the technology described in 1461 this document or the extent to which any license under such rights 1462 might or might not be available; nor does it represent that it has 1463 made any independent effort to identify any such rights. Information 1464 on the procedures with respect to rights in RFC documents can be 1465 found in BCP 78 and BCP 79. 1467 Copies of IPR disclosures made to the IETF Secretariat and any 1468 assurances of licenses to be made available, or the result of an 1469 attempt made to obtain a general license or permission for the use of 1470 such proprietary rights by implementers or users of this 1471 specification can be obtained from the IETF on-line IPR repository at 1472 http://www.ietf.org/ipr. 1474 The IETF invites any interested party to bring to its attention any 1475 copyrights, patents or patent applications, or other proprietary 1476 rights that may cover technology that may be required to implement 1477 this standard. Please address the information to the IETF at 1478 ietf-ipr@ietf.org. 1480 Acknowledgment 1482 Funding for the RFC Editor function is provided by the IETF 1483 Administrative Support Activity (IASA).