idnits 2.17.1 draft-ietf-mpls-ldp-p2mp-02.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 on line 979. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 990. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 997. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1003. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (June 2006) is 6515 days in the past. Is this intentional? 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) ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-06 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-02 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 10 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: December 3, 2006 I. Wijnands (Editor) 6 B. Thomas 7 Cisco Systems, Inc. 8 June 2006 10 Label Distribution Protocol Extensions for Point-to-Multipoint and 11 Multipoint-to-Multipoint Label Switched Paths 12 draft-ietf-mpls-ldp-p2mp-02 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 December 3, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions used in this document . . . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 4 63 2.1. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 4 64 2.2. The LDP MP Opaque Value Element . . . . . . . . . . . . . 6 65 2.2.1. The Generic LSP Identifier . . . . . . . . . . . . . . 6 66 2.3. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 7 67 2.3.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 8 68 2.3.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 9 69 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 11 71 4.1. The MP2MP downstream and upstream FEC elements. . . . . . 11 72 4.2. Using the MP2MP FEC elements . . . . . . . . . . . . . . . 11 73 4.2.1. MP2MP Label Map upstream and downstream . . . . . . . 13 74 4.2.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 15 75 5. Upstream label allocation on Ethernet networks . . . . . . . . 16 76 6. Root node redundancy for MP2MP LSPs . . . . . . . . . . . . . 16 77 6.1. Root node redundancy procedure . . . . . . . . . . . . . . 16 78 7. Make before break . . . . . . . . . . . . . . . . . . . . . . 17 79 7.1. Protocol event . . . . . . . . . . . . . . . . . . . . . . 18 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 83 11. Contributing authors . . . . . . . . . . . . . . . . . . . . . 19 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 88 Intellectual Property and Copyright Statements . . . . . . . . . . 23 90 1. Introduction 92 The LDP protocol is described in [1]. It defines mechanisms for 93 setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs 94 in the network. This document describes extensions to LDP for 95 setting up point-to-multipoint (P2MP) and multipoint-to-multipoint 96 (MP2MP) LSPs. These are collectively referred to as multipoint LSPs 97 (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) 98 node to be delivered to a number of leaf (or egress) nodes. A MP2MP 99 LSP allows traffic from multiple ingress nodes to be delivered to 100 multiple egress nodes. Only a single copy of the packet will be sent 101 on any link traversed by the MP LSP (see note at end of 102 Section 2.3.1). This is accomplished without the use of a multicast 103 protocol in the network. There can be several MP LSPs rooted at a 104 given ingress node, each with its own identifier. 106 The solution assumes that the leaf nodes of the MP LSP know the root 107 node and identifier of the MP LSP to which they belong. The 108 mechanisms for the distribution of this information are outside the 109 scope of this document. The specification of how an application can 110 use a MP LSP signaled by LDP is also outside the scope of this 111 document. 113 Interested readers may also wish to peruse the requirement draft [4] 114 and other documents [8] and [9]. 116 1.1. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [2]. 122 1.2. Terminology 124 The following terminology is taken from [4]. 126 P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 128 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 129 LSRs. 131 MP2P LSP: A LSP that has one or more Ingress LSRs and one unique 132 Egress LSR. 134 MP2MP LSP: A LSP that connects a set of leaf nodes, acting 135 indifferently as ingress or egress. 137 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 139 Ingress LSR: Source of the P2MP LSP, also referred to as root node. 141 Egress LSR: One of potentially many destinations of an LSP, also 142 referred to as leaf node in the case of P2MP and MP2MP LSPs. 144 Transit LSR: An LSR that has one or more directly connected 145 downstream LSRs. 147 Bud LSR: An LSR that is an egress but also has one or more directly 148 connected downstream LSRs. 150 2. Setting up P2MP LSPs with LDP 152 A P2MP LSP consists of a single root node, zero or more transit nodes 153 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and 154 tear-down. Leaf nodes also install forwarding state to deliver the 155 traffic received on a P2MP LSP to wherever it needs to go; how this 156 is done is outside the scope of this document. Transit nodes install 157 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 158 down) toward the root. The root node installs forwarding state to 159 map traffic into the P2MP LSP; how the root node determines which 160 traffic should go over the P2MP LSP is outside the scope of this 161 document. 163 For the setup of a P2MP LSP with LDP, we define one new protocol 164 entity, the P2MP FEC Element to be used in the FEC TLV. The 165 description of the P2MP FEC Element follows. 167 2.1. The P2MP FEC Element 169 The P2MP FEC Element consists of the address of the root of the P2MP 170 LSP and an opaque value. The opaque value consists of one or more 171 LDP MP Opaque Value Elements. The opaque value is unique within the 172 context of the root node. The combination of (Root Node Address, 173 Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. 175 The P2MP FEC element is encoded as follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |P2MP Type (TBD)| Address Family | Address Length| 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Root Node Address | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Opaque Length | Opaque Value ... | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 186 ~ ~ 187 | | 188 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Type: The type of the P2MP FEC element is to be assigned by IANA. 194 Address Family: Two octet quantity containing a value from ADDRESS 195 FAMILY NUMBERS in [3] that encodes the address family for the Root 196 LSR Address. 198 Address Length: Length of the Root LSR Address in octets. 200 Root Node Address: A host address encoded according to the Address 201 Family field. 203 Opaque Length: The length of the Opaque Value, in octets. 205 Opaque Value: One or more MP Opaque Value elements, uniquely 206 identifying the P2MP LSP in the context of the Root Node. This is 207 described in the next section. 209 If the Address Family is IPv4, the Address Length MUST be 4; if the 210 Address Family is IPv6, the Address Length MUST be 16. No other 211 Address Lengths are defined at present. 213 If the Address Length doesn't match the defined length for the 214 Address Family, the receiver SHOULD abort processing the message 215 containing the FEC Element, and send an "Unknown FEC" Notification 216 message to its LDP peer signaling an error. 218 If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST 219 be the only FEC Element in the FEC TLV. 221 2.2. The LDP MP Opaque Value Element 223 The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC 224 elements defined in subsequent sections. It carries information that 225 is meaningful to leaf (and bud) LSRs, but need not be interpreted by 226 non-leaf LSRs. 228 The LDP MP Opaque Value Element is encoded as follows: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type(TBD) | Length | Value ... | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 235 ~ ~ 236 | | 237 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Type: The type of the LDP MP Opaque Value Element is to be assigned 243 by IANA. 245 Length: The length of the Value field, in octets. 247 Value: String of Length octets, to be interpreted as specified by 248 the Type field. 250 2.2.1. The Generic LSP Identifier 252 The generic LSP identifier is a type of Opaque Value Element encoded 253 as follows: 255 Type: 1 (to be assigned by IANA) 256 Length: 4 258 Value: A 32bit integer, unique in the context of the root, as 259 identified by the root's address. 261 This type of opaque value element is recommended when mapping of 262 traffic to LSPs is non-algorithmic, and done by means outside LDP. 264 2.3. Using the P2MP FEC Element 266 This section defines the rules for the processing and propagation of 267 the P2MP FEC Element. The following notation is used in the 268 processing rules: 270 1. P2MP FEC Element : a FEC Element with Root Node Address X 271 and Opaque Value Y. 273 2. P2MP Label Map : a Label Map message with a FEC TLV with 274 a single P2MP FEC Element and Label TLV with label L. 276 3. P2MP Label Withdraw : a Label Withdraw message with a 277 FEC TLV with a single P2MP FEC Element and Label TLV with 278 label L. 280 4. P2MP LSP (or simply ): a P2MP LSP with Root Node 281 Address X and Opaque Value Y. 283 5. The notation L' -> { ..., } on LSR X 284 means that on receiving a packet with label L', X makes n copies 285 of the packet. For copy i of the packet, X swaps L' with Li and 286 sends it out over interface Ii. 288 The procedures below are organized by the role which the node plays 289 in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 290 process which is outside the scope of this document. During the 291 course of protocol operation, the root node recognizes its role 292 because it owns the Root Node Address. A transit node is any node 293 (other than the root node) that receives a P2MP Label Map message 294 (i.e., one that has leaf nodes downstream of it). 296 Note that a transit node (and indeed the root node) may also be a 297 leaf node. 299 2.3.1. Label Map 301 The following lists procedures for generating and processing P2MP 302 Label Map messages for nodes that participate in a P2MP LSP. An LSR 303 should apply those procedures that apply to it, based on its role in 304 the P2MP LSP. 306 For the approach described here we use downstream assigned labels. 307 On Ethernet networks this may be less optimal, see Section 5. 309 2.3.1.1. Determining one's 'upstream LSR' 311 A node Z that is part of P2MP LSP determines the LDP peer U 312 which lies on the best path from Z to the root node X. If there are 313 more than one such LDP peers, only one of them is picked. U is Z's 314 "Upstream LSR" for . 316 When there are several candidate upstream LSRs, the LSR MAY select 317 one upstream LSR using the following procedure: 319 1. The candidate upstream LSRs are numbered from lower to higher IP 320 address 322 2. The following hash is performed: H = (Sum Opaque value) modulo N, 323 where N is the number of candidate upstream LSRs 325 3. The selected upstream LSR U is the LSR that has the number H. 327 This allows for load balancing of a set of LSPs among a set of 328 candidate upstream LSRs, while ensuring that on a LAN interface a 329 single upstream LSR is selected. 331 2.3.1.2. Leaf Operation 333 A leaf node Z of P2MP LSP determines its upstream LSR U for 334 as per Section 2.3.1.1, allocates a label L, and sends a P2MP 335 Label Map to U. 337 2.3.1.3. Transit Node operation 339 Suppose a transit node Z receives a P2MP Label Map from LDP 340 peer T. Z checks whether it already has state for . If not, Z 341 allocates a label L', and installs state to swap L' with L over 342 interface I associated with peer T. Z also determines its upstream 343 LSR U for as per Section 2.3.1.1, and sends a P2MP Label Map 344 to U. 346 If Z already has state for , then Z does not send a Label Map 347 message for P2MP LSP . All that Z needs to do in this case is 348 update its forwarding state. Assuming its old forwarding state was 349 L'-> { ..., }, its new forwarding state 350 becomes L'-> { ..., , }. 352 2.3.1.4. Root Node Operation 354 Suppose the root node Z receives a P2MP Label Map from peer 355 T. Z checks whether it already has forwarding state for . If 356 not, Z creates forwarding state to push label L onto the traffic that 357 Z wants to forward over the P2MP LSP (how this traffic is determined 358 is outside the scope of this document). 360 If Z already has forwarding state for , then Z adds "push label 361 L, send over interface I" to the nexthop, where I is the interface 362 associated with peer T. 364 2.3.2. Label Withdraw 366 The following lists procedures for generating and processing P2MP 367 Label Withdraw messages for nodes that participate in a P2MP LSP. An 368 LSR should apply those procedures that apply to it, based on its role 369 in the P2MP LSP. 371 2.3.2.1. Leaf Operation 373 If a leaf node Z discovers (by means outside the scope of this 374 document) that it is no longer a leaf of the P2MP LSP, it SHOULD send 375 a Label Withdraw to its upstream LSR U for , where L 376 is the label it had previously advertised to U for . 378 2.3.2.2. Transit Node Operation 380 If a transit node Z receives a Label Withdraw message from 381 a node W, it deletes label L from its forwarding state, and sends a 382 Label Release message with label L to W. 384 If deleting L from Z's forwarding state for P2MP LSP results 385 in no state remaining for , then Z propagates the Label 386 Withdraw for , to its upstream T, by sending a Label Withdraw 387 where L1 is the label Z had previously advertised to T for 388 . 390 2.3.2.3. Root Node Operation 392 The procedure when the root node of a P2MP LSP receives a Label 393 Withdraw message are the same as for transit nodes, except that it 394 would not propagate the Label Withdraw upstream (as it has no 395 upstream). 397 2.3.2.4. Upstream LSR change 399 If, for a given node Z participating in a P2MP LSP , the 400 upstream LSR changes, say from U to U', then Z MUST update its 401 forwarding state by deleting the state for label L, allocating a new 402 label, L', for , and installing the forwarding state for L'. In 403 addition Z MUST send a Label Map to U' and send a Label 404 Withdraw to U. 406 3. Shared Trees 408 The mechanism described above shows how to build a tree with a single 409 root and multiple leaves, i.e., a P2MP LSP. One can use essentially 410 the same mechanism to build Shared Trees with LDP. A Shared Tree can 411 be used by a group of routers that want to multicast traffic among 412 themselves, i.e., each node is both a root node (when it sources 413 traffic) and a leaf node (when any other member of the group sources 414 traffic). A Shared Tree offers similar functionality to a MP2MP LSP, 415 but the underlying multicasting mechanism uses a P2MP LSP. One 416 example where a Shared Tree is useful is video-conferencing. Another 417 is Virtual Private LAN Service (VPLS) [7], where for some types of 418 traffic, each device participating in a VPLS must send packets to 419 every other device in that VPLS. 421 One way to build a Shared Tree is to build an LDP P2MP LSP rooted at 422 a common point, the Shared Root (SR), and whose leaves are all the 423 members of the group. Each member of the Shared Tree unicasts 424 traffic to the SR (using, for example, the MP2P LSP created by the 425 unicast LDP FEC advertised by the SR); the SR then splices this 426 traffic into the LDP P2MP LSP. The SR may be (but need not be) a 427 member of the multicast group. 429 A major advantage of this approach is that no further protocol 430 mechanisms beyond the one already described are needed to set up a 431 Shared Tree. Furthermore, a Shared Tree is very efficient in terms 432 of the multicast state in the network, and is reasonably efficient in 433 terms of the bandwidth required to send traffic. 435 A property of this approach is that a sender will receive its own 436 packets as part of the multicast; thus a sender must be prepared to 437 recognize and discard packets that it itself has sent. For a number 438 of applications (for example, VPLS), this requirement is easy to 439 meet. Another consideration is the various techniques that can be 440 used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will 441 be described in a later revision. 443 4. Setting up MP2MP LSPs with LDP 445 An MP2MP LSP is much like a P2MP LSP in that it consists of a single 446 root node, zero or more transit nodes and one or more leaf LSRs 447 acting equally as Ingress or Egress LSR. A leaf node participates in 448 the setup of an MP2MP LSP by establishing both a downstream LSP, 449 which is much like a P2MP LSP from the root, and an upstream LSP 450 which is used to send traffic toward the root and other leaf nodes. 451 Transit nodes support the setup by propagating the upstream and 452 downstream LSP setup toward the root and installing the necessary 453 MPLS forwarding state. The transmission of packets from the root 454 node of a MP2MP LSP to the receivers is identical to that for a P2MP 455 LSP. Traffic from a leaf node follows the upstream LSP toward the 456 root node and branches downward along the downstream LSP as required 457 to reach other leaf nodes. Mapping traffic to the MP2MP LSP may 458 happen at any leaf node. How that mapping is established is outside 459 the scope of this document. 461 Due to how a MP2MP LSP is built a leaf LSR that is sending packets on 462 the MP2MP LSP does not receive its own packets. There is also no 463 additional mechanism needed on the root or transit LSR to match 464 upstream traffic to the downstream forwarding state. Packets that 465 are forwarded over a MP2MP LSP will not traverse a link more than 466 once, with the exception of LAN links which are discussed in 467 Section 4.2.1 469 For the setup of a MP2MP LSP with LDP we define 2 new protocol 470 entities, the MP2MP downstream FEC and upstream FEC element. Both 471 elements will be used in the FEC TLV. The description of the MP2MP 472 elements follow. 474 4.1. The MP2MP downstream and upstream FEC elements. 476 The structure, encoding and error handling for the MP2MP downstream 477 and upstream FEC elements are the same as for the P2MP FEC element 478 described in Section 2.1. The difference is that two new FEC types 479 are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). 481 If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element 482 MUST be the only FEC Element in the FEC TLV. 484 4.2. Using the MP2MP FEC elements 486 This section defines the rules for the processing and propagation of 487 the MP2MP FEC elements. The following notation is used in the 488 processing rules: 490 1. MP2MP downstream LSP (or simply downstream ): an 491 MP2MP LSP downstream path with root node address X and opaque 492 value Y. 494 2. MP2MP upstream LSP (or simply upstream ): a 495 MP2MP LSP upstream path for downstream node D with root node 496 address X and opaque value Y. 498 3. MP2MP downstream FEC element : a FEC element with root node 499 address X and opaque value Y used for a downstream MP2MP LSP. 501 4. MP2MP upstream FEC element : a FEC element with root node 502 address X and opaque value Y used for an upstream MP2MP LSP. 504 5. MP2MP Label Map downstream : A Label Map message with a 505 FEC TLV with a single MP2MP downstream FEC element and 506 label TLV with label L. 508 6. MP2MP Label Map upstream : A Label Map message with a 509 FEC TLV with a single MP2MP upstream FEC element and label 510 TLV with label Lu. 512 7. MP2MP Label Withdraw downstream : a Label Withdraw 513 message with a FEC TLV with a single MP2MP downstream FEC element 514 and label TLV with label L. 516 8. MP2MP Label Withdraw upstream : a Label Withdraw 517 message with a FEC TLV with a single MP2MP upstream FEC element 518 and label TLV with label Lu. 520 The procedures below are organized by the role which the node plays 521 in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery 522 process which is outside the scope of this document. During the 523 course of the protocol operation, the root node recognizes its role 524 because it owns the root node address. A transit node is any node 525 (other then the root node) that receives a MP2MP Label Map message 526 (i.e., one that has leaf nodes downstream of it). 528 Note that a transit node (and indeed the root node) may also be a 529 leaf node and the root node does not have to be an ingress LSR or 530 leaf of the MP2MP LSP. 532 4.2.1. MP2MP Label Map upstream and downstream 534 The following lists procedures for generating and processing MP2MP 535 Label Map messages for nodes that participate in a MP2MP LSP. An LSR 536 should apply those procedures that apply to it, based on its role in 537 the MP2MP LSP. 539 For the approach described here if there are several receivers for a 540 MP2MP LSP on a LAN, packets are replicated over the LAN. This may 541 not be optimal; optimizing this case is for further study, see [5]. 543 4.2.1.1. Determining one's upstream MP2MP LSR 545 Determining the upstream LDP peer U for a MP2MP LSP follows 546 the procedure for a P2MP LSP described in Section 2.3.1.1. 548 4.2.1.2. Determining one's downstream MP2MP LSR 550 A LDP peer U which receives a MP2MP Label Map downstream from a LDP 551 peer D will treat D as downstream MP2MP LSR. 553 4.2.1.3. MP2MP leaf node operation 555 A leaf node Z of a MP2MP LSP determines its upstream LSR U for 556 as per Section 4.2.1.1, allocates a label L, and sends a MP2MP 557 Label Map downstream to U. 559 Leaf node Z expects an MP2MP Label Map upstream from node 560 U in response to the MP2MP Label Map downstream it sent to node U. Z 561 checks whether it already has forwarding state for upstream . 562 If not, Z creates forwarding state to push label Lu onto the traffic 563 that Z wants to forward over the MP2MP LSP. How it determines what 564 traffic to forward on this MP2MP LSP is outside the scope of this 565 document. 567 4.2.1.4. MP2MP transit node operation 569 When node Z receives a MP2MP Label Map downstream from peer 570 D associated with interface I, it checks whether it has forwarding 571 state for downstream . If not, Z allocates a label L' and 572 installs downstream forwarding state to swap label L' with label L 573 over interface I. Z also determines its upstream LSR U for as 574 per Section 4.2.1.1, and sends a MP2MP Label Map downstream to U. 577 If Z already has forwarding state for downstream , all that Z 578 needs to do is update its forwarding state. Assuming its old 579 forwarding state was L'-> { ..., }, its new 580 forwarding state becomes L'-> { ..., , }. 583 Node Z checks whether it already has forwarding state upstream . If it does, then no further action needs to happen. If it does 585 not, it allocates a label Lu and creates a new label swap for Lu from 586 the label swap(s) from the forwarding state downstream , 587 omitting the swap on interface I for node D. This allows upstream 588 traffic to follow the MP2MP tree down to other node(s) except the 589 node from which Z received the MP2MP Label Map downstream . 590 Node Z determines the downstream MP2MP LSR as per Section 4.2.1.2, 591 and sends a MP2MP Label Map upstream to node D. 593 Transit node Z will also receive a MP2MP Label Map upstream in response to the MP2MP Label Map downstream sent to node U 595 associated with interface Iu. Node Z will add label swap Lu over 596 interface Iu to the forwarding state upstream . This allows 597 packets to go up the tree towards the root node. 599 4.2.1.5. MP2MP root node operation 601 4.2.1.5.1. Root node is also a leaf 603 Suppose root/leaf node Z receives a MP2MP Label Map downstream from node D associated with interface I. Z checks whether it 605 already has forwarding state downstream . If not, Z creates 606 forwarding state for downstream to push label L on traffic that Z 607 wants to forward down the MP2MP LSP. How it determines what traffic 608 to forward on this MP2MP LSP is outside the scope of this document. 609 If Z already has forwarding state for downstream , then Z will 610 add the label push for L over interface I to it. 612 Node Z checks if it has forwarding state for upstream . If 613 not, Z allocates a label Lu and creates upstream forwarding state to 614 push Lu with the label push(s) from the forwarding state downstream 615 , except the push on interface I for node D. This allows 616 upstream traffic to go down the MP2MP to other node(s), except the 617 node from which the traffic was received. Node Z determines the 618 downstream MP2MP LSR as per section Section 4.2.1.2, and sends a 619 MP2MP Label Map upstream to node D. Since Z is the root of 620 the tree Z will not send a MP2MP downstream map and will not receive 621 a MP2MP upstream map. 623 4.2.1.5.2. Root node is not a leaf 625 Suppose the root node Z receives a MP2MP Label Map dowbstream from node D associated with interface I. Z checks whether it 627 already has forwarding state for downstream . If not, Z 628 creates downstream forwarding state and installs a outgoing label L 629 over interface I. If Z already has forwarding state for downstream 630 , then Z will add label L over interface I to the existing 631 state. 633 Node Z checks if it has forwarding state for upstream . If 634 not, Z allocates a label Lu and creates forwarding state to swap Lu 635 with the label swap(s) from the forwarding state downstream , 636 except the swap for node D. This allows upstream traffic to go down 637 the MP2MP to other node(s), except the node is was received from. 638 Root node Z determines the downstream MP2MP LSR D as per 639 Section 4.2.1.2, and sends a MP2MP Label Map upstream to 640 it. Since Z is the root of the tree Z will not send a MP2MP 641 downstream map and will not receive a MP2MP upstream map. 643 4.2.2. MP2MP Label Withdraw 645 The following lists procedures for generating and processing MP2MP 646 Label Withdraw messages for nodes that participate in a MP2MP LSP. 647 An LSR should apply those procedures that apply to it, based on its 648 role in the MP2MP LSP. 650 4.2.2.1. MP2MP leaf operation 652 If a leaf node Z discovers (by means outside the scope of this 653 document) that it is no longer a leaf of the MP2MP LSP, it SHOULD 654 send a downstream Label Withdraw to its upstream LSR U for 655 , where L is the label it had previously advertised to U for 656 . 658 Leaf node Z expects the upstream router U to respond by sending a 659 downstream label release for L and a upstream Label Withdraw for to remove Lu from the upstream state. Node Z will remove 661 label Lu from its upstream state and send a label release message 662 with label Lu to U. 664 4.2.2.2. MP2MP transit node operation 666 If a transit node Z receives a downstream label withdraw message from node D, it deletes label L from its forwarding state 668 downstream and from all its upstream states for . Node 669 Z sends a label release message with label L to D. Since node D is no 670 longer part of the downstream forwarding state, Z cleans up the 671 forwarding state upstream and sends a upstream Label 672 Withdraw for to D. 674 If deleting L from Z's forwarding state for downstream results 675 in no state remaining for , then Z propagates the Label 676 Withdraw to its upstream node U for . 678 4.2.2.3. MP2MP root node operation 680 The procedure when the root node of a MP2MP LSP receives a label 681 withdraw message is the same as for transit nodes, except that the 682 root node would not propagate the Label Withdraw upstream (as it has 683 no upstream). 685 4.2.2.4. MP2MP Upstream LSR change 687 The procedure for changing the upstream LSR is the same as documented 688 in Section 2.3.2.4, except it is applied to MP2MP FECs, using the 689 procedures described in Section 4.2.1 through Section 4.2.2.3. 691 5. Upstream label allocation on Ethernet networks 693 On Ethernet networks the upstream LSR will send a copy of the packet 694 to each receiver individually. If there is more then one receiver on 695 the Ethernet we don't take full benefit of the multi-access 696 capability of the network. We may optimize the bandwidth consumption 697 on the Ethernet and replication overhead on the upstream LSR by using 698 upstream label allocation [5]. Procedures on how to distribute 699 upstream labels using LDP is documented in [6]. 701 6. Root node redundancy for MP2MP LSPs 703 MP2MP leaf nodes must use the same root node to setup the MP2MP LSP. 704 Otherwise there will be partitioned MP2MP LSP and traffic sourced by 705 some leafs is not received by others. Having a single root node for 706 a MP2MP LSP is a single point of failure, which is not preferred. We 707 need a fast and efficient mechanism to recover from a root node 708 failure. 710 6.1. Root node redundancy procedure 712 It is likely that the root node for a MP2MP LSP is defined 713 statically. The root node address may be configured on each leaf 714 statically or learned using a dynamic protocol. How MP2MP leafs 715 learn about the root node is out of the scope of this document. A 716 MP2MP LSP is uniquely identified by a opaque value and the root node 717 address. Suppose that for the same opaque value we define two root 718 node addresses and we build a tree to each root using the same opaque 719 value. Effectively these will be treated as different MP2MP LSPs in 720 the network. Since all leafs have setup a MP2MP LSP to each one of 721 the root nodes for this opaque value, a sending leaf may pick either 722 of the two MP2MP LSPs to forward a packet on. The leaf nodes will 723 receive the packet on one of the MP2MP LSPs, the client of the MP2MP 724 LSP does not care on which MP2MP LSP the packet was received from, as 725 long as they are for the same opaque value. The sending leaf MUST 726 only forward a packet on one MP2MP LSP at a given point in time. The 727 receiving leafs are unable to discard duplicate packets because they 728 accept on both LSPs. Using both these MP2MP LSPs we can implement 729 redundancy using the following procedures. 731 A sending leaf selects a single root node out of the available roots 732 for a given opaque value. A good strategy MAY be to look at the 733 unicast routing table and select a root that is closest according in 734 terms of unicast metric. As soon as the root address of our active 735 root disappears from the unicast routing table (or becomes less 736 attractive) due to root node or link failure we can select a new best 737 root address and start forwarding to it directly. If multiple root 738 nodes have the same unicast metric, the highest root node addresses 739 MAY be selected, or we MAY do per session load balancing over the 740 root nodes. 742 All leafs participating in a MP2MP LSP MUST join to all the available 743 root nodes for a given opaque value. Since the sending leaf may pick 744 any MP2MP LSP, it must be prepared to receive on it. 746 The advantage of pre-building multiple MP2MP LSPs for a single opaque 747 value is that we can converge from a root node failure as fast as the 748 unicast routing protocol is able to notify us. There is no need for 749 an additional protocol to advertise to the leaf nodes which root node 750 is the active root. The root selection is a local leaf policy that 751 does not need to be coordinated with other leafs. The disadvantage 752 is that we are using more label resources depending on how many root 753 nodes are defined. 755 7. Make before break 757 An upstream LSR is chosen based on the best path to reach the root of 758 the MP LSP. When the best path to reach the root changes it needs to 759 choose a new upstream LSR. Section 2.3.2.4 and Section 4.2.2.4 760 describes these procedures. When the best path to the root changes 761 the LSP may be broken and packet forwarding is interrupted, in that 762 case it needs to converge to a new upstream LSR ASAP. There are also 763 scenarios where the best path changed, but the LSP is still 764 forwarding packets. That happens when links come up or routing 765 metrics are changed. In that case it would like to build the new LSP 766 before it breaks the old LSP to minimize the traffic interruption. 767 The approuch described below deals with both scenarios and does not 768 require LDP to know which of the events above caused the upstream 769 router to change. The approuch below is an optional extention to the 770 MP LSP building procedures described in this draft. 772 7.1. Protocol event 774 An approach is to use additional signaling in LDP. Suppose a 775 downstream LSR-D is changing to a new upstream LSR-U for FEC-A, this 776 LSR-U may already be forwarding packets for this FEC-A. Based on the 777 existence of state for FEC-A, LSR-U will send a notification to the 778 LSR-D to initiate the switchover. The assumption is that if our 779 upstream LSR-U has state for the FEC-A and it has received a 780 notification from its upstream router, then this LSR is forwarding 781 packets for this FEC-A and it can send a notification back to 782 initiate the switchover. You could say there is an explicit 783 notification to tell the LSR it became part of the tree identified by 784 FEC-A. LSR-D can be in 3 different states. 786 1. There no state for a given FEC-A. 788 2. State for FEC-A has just been created and is waiting for 789 notification. 791 3. State for FEC-A exists and notification was received. 793 Suppose LSR-D sends a label mapping for FEC-A to LSR-U. LSR-U must 794 only reply with a notification to LSR-D if it is in state #3 as 795 described above. If LSR-U is in state 1 or 2, it should remember it 796 has received a label mapping from LSR-D which is waiting for a 797 notification. As soon as LSR-U received a notification from its 798 upstream LSR it can move to state #3 and trigger notifications to its 799 downstream LSR's that requested it. More details will be added in 800 the next revision of the draft. 802 8. Security Considerations 804 The same security considerations apply as for the base LDP 805 specification, as described in [1]. 807 9. IANA considerations 809 This document creates a new name space (the LDP MP Opaque Value 810 Element type) that is to be managed by IANA. Also, this document 811 requires allocation of three new LDP FEC element types: the P2MP 812 type, the MP2MP-up and the MP2MP-down types. 814 10. Acknowledgments 816 The authors would like to thank the following individuals for their 817 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul 818 Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert and 819 George Swallow. 821 11. Contributing authors 823 Below is a list of the contributing authors in alphabetical order: 825 Shane Amante 826 Level 3 Communications, LLC 827 1025 Eldorado Blvd 828 Broomfield, CO 80021 829 US 830 Email: Shane.Amante@Level3.com 832 Luyuan Fang 833 AT&T 834 200 Laurel Avenue, Room C2-3B35 835 Middletown, NJ 07748 836 US 837 Email: luyuanfang@att.com 839 Hitoshi Fukuda 840 NTT Communications Corporation 841 1-1-6, Uchisaiwai-cho, Chiyoda-ku 842 Tokyo 100-8019, 843 Japan 844 Email: hitoshi.fukuda@ntt.com 846 Yuji Kamite 847 NTT Communications Corporation 848 Tokyo Opera City Tower 849 3-20-2 Nishi Shinjuku, Shinjuku-ku, 850 Tokyo 163-1421, 851 Japan 852 Email: y.kamite@ntt.com 853 Kireeti Kompella 854 Juniper Networks 855 1194 N. Mathilda Ave. 856 Sunnyvale, CA 94089 857 US 858 Email: kireeti@juniper.net 860 Ina Minei 861 Juniper Networks 862 1194 N. Mathilda Ave. 863 Sunnyvale, CA 94089 864 US 865 Email: ina@juniper.net 867 Jean-Louis Le Roux 868 France Telecom 869 2, avenue Pierre-Marzin 870 Lannion, Cedex 22307 871 France 872 Email: jeanlouis.leroux@francetelecom.com 874 Bob Thomas 875 Cisco Systems, Inc. 876 300 Beaver Brook Road 877 Boxborough, MA, 01719 878 E-mail: rhthomas@cisco.com 880 Lei Wang 881 Telenor 882 Snaroyveien 30 883 Fornebu 1331 884 Norway 885 Email: lei.wang@telenor.com 887 IJsbrand Wijnands 888 Cisco Systems, Inc. 889 De kleetlaan 6a 890 1831 Diegem 891 Belgium 892 E-mail: ice@cisco.com 894 12. References 895 12.1. Normative References 897 [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 898 Thomas, "LDP Specification", RFC 3036, January 2001. 900 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 901 Levels", BCP 14, RFC 2119, March 1997. 903 [3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 904 October 1994. 906 [4] Roux, J., "Requirements for point-to-multipoint extensions to 907 the Label Distribution Protocol", 908 draft-leroux-mpls-mp-ldp-reqs-03 (work in progress), 909 February 2006. 911 [5] Aggarwal, R., "MPLS Upstream Label Assignment and Context 912 Specific Label Space", draft-raggarwa-mpls-upstream-label-01 913 (work in progress), October 2005. 915 [6] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for 916 RSVP-TE and LDP", draft-raggarwa-mpls-rsvp-ldp-upstream-00 (work 917 in progress), July 2005. 919 12.2. Informative References 921 [7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 922 Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05 923 (work in progress), June 2004. 925 [8] Aggarwal, R., "Extensions to RSVP-TE for Point-to-Multipoint TE 926 LSPs", draft-ietf-mpls-rsvp-te-p2mp-06 (work in progress), 927 August 2006. 929 [9] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", 930 draft-ietf-l3vpn-2547bis-mcast-02 (work in progress), June 2006. 932 Authors' Addresses 934 Ina Minei 935 Juniper Networks 936 1194 N. Mathilda Ave. 937 Sunnyvale, CA 94089 938 US 940 Email: ina@juniper.net 941 Kireeti Kompella 942 Juniper Networks 943 1194 N. Mathilda Ave. 944 Sunnyvale, CA 94089 945 US 947 Email: kireeti@juniper.net 949 IJsbrand Wijnands 950 Cisco Systems, Inc. 951 De kleetlaan 6a 952 Diegem 1831 953 Belgium 955 Email: ice@cisco.com 957 Bob Thomas 958 Cisco Systems, Inc. 959 300 Beaver Brook Road 960 Boxborough 01719 961 US 963 Email: rhthomas@cisco.com 965 Full Copyright Statement 967 Copyright (C) The Internet Society (2006). 969 This document is subject to the rights, licenses and restrictions 970 contained in BCP 78, and except as set forth therein, the authors 971 retain all their rights. 973 This document and the information contained herein are provided on an 974 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 975 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 976 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 977 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 978 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 979 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 981 Intellectual Property 983 The IETF takes no position regarding the validity or scope of any 984 Intellectual Property Rights or other rights that might be claimed to 985 pertain to the implementation or use of the technology described in 986 this document or the extent to which any license under such rights 987 might or might not be available; nor does it represent that it has 988 made any independent effort to identify any such rights. Information 989 on the procedures with respect to rights in RFC documents can be 990 found in BCP 78 and BCP 79. 992 Copies of IPR disclosures made to the IETF Secretariat and any 993 assurances of licenses to be made available, or the result of an 994 attempt made to obtain a general license or permission for the use of 995 such proprietary rights by implementers or users of this 996 specification can be obtained from the IETF on-line IPR repository at 997 http://www.ietf.org/ipr. 999 The IETF invites any interested party to bring to its attention any 1000 copyrights, patents or patent applications, or other proprietary 1001 rights that may cover technology that may be required to implement 1002 this standard. Please address the information to the IETF at 1003 ietf-ipr@ietf.org. 1005 Acknowledgment 1007 Funding for the RFC Editor function is provided by the IETF 1008 Administrative Support Activity (IASA).