idnits 2.17.1 draft-brockners-ldp-half-duplex-mp2mp-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 17. -- Found old boilerplate from RFC 3978, Section 5.3 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 923. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 936. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 854, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 857, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 868, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 882, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 885, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 888, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. '1') (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mp-ldp-reqs-03 ** Downref: Normative reference to an Historic draft: draft-ietf-mpls-mp-ldp-reqs (ref. '4') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-03 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-rsvp-upstream-02 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-03 -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-06 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group F. Brockners 2 I. Wijnands 3 Internet Draft A. Sajassi 4 Intended status: Standards Track Cisco Systems 5 Expires: August 22, 2008 February 22, 2008 7 Label Distribution Protocol Extensions for Half-Duplex 8 Multipoint-to-Multipoint Label Switched Paths 9 draft-brockners-ldp-half-duplex-mp2mp-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 This document may only be posted in an Internet-Draft. 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 22, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes a mechanism to construct Label Switched Paths 46 (LSP) over MPLS using an extended version of the Label Distribution 47 Protocol (LDP) between a set of clients and servers. This 48 communication mechanism has the capability that servers can 49 communicate with other servers and clients, whereas clients can only 50 communicate with servers but not with other clients. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119. 58 Table of Contents 60 1. Introduction...................................................3 61 1.1. Service Connectivity Categorization.......................3 62 1.2. Problem Statement and Motivation..........................4 63 1.3. Terminology (for reference only)..........................5 64 2. Half duplex MP2MP (HD-MP2MP) Service with LDP..................6 65 2.1. FEC elements for HD-MP2MP.................................7 66 2.2. Using the HD-MP2MP FEC elements: Notation.................8 67 2.3. HD-MP2MP Label Mapping...................................10 68 2.3.1. Determining one's upstream MP2MP LSR................10 69 2.3.2. Determining one's downstream MP2MP LSR..............10 70 2.3.3. HD-MP2MP client leaf node operation.................10 71 2.3.4. HD-MP2MP server leaf node operation.................11 72 2.3.5. Transit node operation..............................12 73 2.3.5.1. Transit node operation overview................12 74 2.3.5.2. Client Downstream Label Map received...........13 75 2.3.5.3. Server Downstream Label Map received...........14 76 2.3.6. HD-MP2MP root node operation........................15 77 2.3.6.1. Client Downstream Label Map received...........15 78 2.3.6.2. Server Downstream Label Map received...........16 79 2.3.7. HD-MP2MP Label Withdraw.............................17 80 2.3.7.1. HD-MP2MP Client operation......................17 81 2.3.7.2. HD-MP2MP Server operation......................17 82 2.3.7.3. HD-MP2MP transit node operation................18 83 2.3.7.4. HD-MP2MP root node operation...................18 84 2.3.7.5. HD-MP2MP Upstream LSR Change...................18 85 3. Security Considerations.......................................19 86 4. IANA Considerations...........................................19 87 5. References....................................................19 88 5.1. Normative References.....................................19 89 5.2. Informative References...................................19 90 Author's Addresses...............................................20 91 Intellectual Property Statement..................................20 92 Disclaimer of Validity...........................................21 94 1. Introduction 96 The LDP protocol is described in [1]. It defines mechanisms for 97 setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs 98 in the network. This document describes a mechanism to construct 99 Half-Duplex Multipoint to Multipoint LSPs (HD-MP2MP LSPs) over an 100 MPLS infrastructure using LDP. 102 1.1. Service Connectivity Categorization 104 The following general types of connectivity using some transport 105 vehicle (e.g. a LSP) are acknowledged within the industry (see e.g. 106 [8]) between a set of User to Network (UNI) interfaces: 108 o Point to Point Connectivity: For Point-to-Point connectivity, 109 exactly two UNIs are associated with one another. An ingress 110 service frame mapped to the transport vehicle at one UNI shall not 111 result in an egress service frame at a UNI other than the other 112 UNI associated with the transport vehicle. 114 o Multipoint Connectivity: For Multipoint connectivity two or more 115 UNIs are associated with one another. An ingress service frame 116 mapped to the transport vehicle at one of the UNIs shall not 117 result in an egress service frame at a UNI that is not associated 118 with the transport vehicle. Multipoint connectivity can further be 119 differentiated into multipoint to multipoint connectivity as well 120 as rooted-multipoint connectivity. 122 * Multipoint to Multipoint Connectivity: An ingress service frame 123 at a given UNI would be replicated in the network and a single 124 copy would be delivered to each of the other UNIs associated 125 with the transport vehicle. 127 * Rooted-Multipoint Connectivity: For rooted multipoint 128 connectivity, one or more of the UNIs shall be designated as a 129 servers and each of the other UNIs shall be designated as a 130 clients. An ingress service frame mapped to the transport 131 vehicle at a server UNI should be delivered to one or more of 132 the other UNIs. An ingress service frame mapped to the 133 transport vehicle at a client UNI shall not result in an 134 egress service frame at another client UNI but can result in 135 an egress service frame at some or all of the server UNIs. 137 Using the LDP Protocol [1], one can establish point to point as well 138 as multipoint connectivity using LSPs. For multipoint operation, 139 multipoint to multipoint, point to multipoint as well as multipoint 140 to point connectivity models are supported. While rooted-multipoint 141 connectivity can be established by combining point to multipoint with 142 multipoint to point LSPs, a more efficient mechanism to establish 143 rooted-multipoint connectivity (which could be understood as a 144 generalized version of point to multipoint connectivity) is 145 desirable. Half-Duplex MDT with LDP can be leveraged to establish 146 rooted multipoint connectivity. 148 1.2. Problem Statement and Motivation 150 Some deployment scenarios, such as broadcast TV delivery over 151 aggregation networks or broadcast/multicast wholesale require 152 efficient mechanisms to transport multicast/broadcast type of data 153 from a set of sources to many receivers over an MPLS network, while 154 isolating the receivers from each other. Achieving such a 155 connectivity model with a limited amount of configuration on the leaf 156 nodes is seen as beneficial. 158 The desired behavior is as follows: 160 o The set of users can be divided into two non-overlapping sets: 161 Client nodes (or short "Clients") and server nodes (or short 162 "Servers"). 164 o Servers can communicate with each other and with the clients, i.e. 165 Servers can send data to each other as well as to clients and can 166 receive data from each other as well as from clients. 168 o Clients can only communicate with servers, i.e. Clients can send 169 data to servers and can receive data from servers but cannot send 170 data to other clients nor can receive data from other clients. 172 o All data is transported as broadcast: Any data sent by a server is 173 received by all other servers and all clients. Any data sent by a 174 client is received by all servers. 176 o The setup of the forwarding behavior between clients and servers 177 should be automatic, i.e. should not require any configuration on 178 network elements other than the client and server nodes. 179 Provisioning a new client should not require any manual 180 reconfiguration but on the client itself. 182 As a result of this behavior, a local connectivity between clients is 183 prevented and it is ensured that connectivity between clients can 184 only be provided through server sites. This ensures that in a 185 broadband aggregation deployment case, individual subscribers cannot 186 directly connect with each other, bypassing functions implemented on 187 the edge router such as accounting or admission control. 189 One way to achieve the desired communication behavior with restricted 190 connectivity between clients is to use a combination of LDP P2MP LSPs 191 and LDP MP2P LSPs: One P2MP LSP per server (with the server forming 192 the root of the P2MP LSP and the clients other servers forming the 193 leaves) would be established for server to client (and other servers) 194 communication. One MP2P LSP per server (forming the root of the MP2P 195 tree) would be used to enable clients and other servers to 196 communicate with the server forming the root. As a result, each 197 client is connected to N P2MP LSPs and N MP2P LSPs, with N 198 representing the number of servers. 200 The major advantage of this approach is that no further protocol 201 mechanisms beyond the ones already defined in [1] and [7] would be 202 required. 204 A property of this approach is that clients need to handle send and 205 receive operations across multiple LSPs for the same service 206 instance. Clients wishing to send traffic to the set of servers are 207 required to send the data multiple times (once per server, or in 208 other words once per MP2P LSP). Furthermore, the addition or removal 209 of a server from the overall configuration would also require 210 configuration changes on all connected servers and clients. 212 HD-MP2MP LSP described here aim at reducing the configuration 213 requirements on the leaf nodes, so that clients or servers can be 214 added without a reconfiguration on other clients or servers and at 215 simplifying traffic handling by using only a single LSP to send data 216 to and a single LSP to receive data from. 218 1.3. Terminology (for reference only) 220 The following terminology is taken from [4] and is repeated here to 221 ease readability of the document. 223 o P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 225 o P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 226 LSRs. 228 o MP2P LSP: A LSP that has one or more Ingress LSRs and one unique 230 o Egress LSR. 232 o MP2MP LSP: A LSP that connects a set of leaf nodes, acting 233 indifferently as ingress or egress. 235 o MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 237 o Ingress LSR: Source of the P2MP LSP, also referred to as root 238 node. 240 o Egress LSR: One of potentially many destinations of an LSP, also 241 referred to as leaf node in the case of P2MP and MP2MP LSPs. 243 o Transit LSR: An LSR that has one or more directly connected 244 downstream LSRs. 246 o Bud LSR: An LSR that is an egress but also has one or more 247 directly connected downstream LSRs. 249 To ease readability of this document this section briefly lists the 250 notation for the P2MP FEC element as they are described in [7]. 251 Please refer to [7] for a comprehensive description. 253 o P2MP FEC Element : a FEC Element with Root Node Address X 254 and Opaque Value Y. 256 o P2MP Label Map : a Label Map message with a FEC TLV with 257 a single P2MP FEC Element and Label TLV with label L. 259 o P2MP Label Withdraw : a Label Withdraw message with a FEC 260 TLV with a single P2MP FEC Element and Label TLV with label 261 L. 263 o P2MP LSP (or simply ): a P2MP LSP with Root Node 264 Address X and Opaque Value Y. 266 o The notation L' -> { ..., } on LSR X 267 means that on receiving a packet with label L', X makes n copies 268 of the packet. For copy i of the packet, X swaps L' with Li and 269 sends it out over interface Ii. 271 2. Half duplex MP2MP (HD-MP2MP) Service with LDP 273 An HD-MP2MP combines two LSPs. The LSPs used to construct a HD-MP2MP 274 service are similar to a MP2MP LSP in that it consists of a single 275 root node, zero or more transit nodes and one or more leaf LSRs 276 acting equally as Ingress or Egress LSR. Leaf LSRs fulfill either the 277 role of a client or a server. Correspondingly they are called "Client 278 LSR" and "Server LSR". 280 For HD-MP2MP operation, two trees will be combined: A "Client Tree" 281 which allows communication from all Clients to all Servers and a 282 "Server Tree" allows communication from all servers to all clients 283 and all servers. 285 A leaf node participates in the setup of a HD-MP2MP LSP by 286 establishing both a downstream LSP, which is much like a P2MP LSP 287 from the root, and an upstream LSP which is used to send traffic 288 toward the root and other leaf nodes. Depending on the type of the 289 leaf (Client or Server), traffic sent by a leaf will either be 290 forwarded to all leafs (which means clients and servers - this is in 291 case of a leaf being a server), or only to servers (in case of a leaf 292 being a client). 294 Transit nodes support the setup by propagating the upstream and 295 downstream LSP setup toward the root and installing the necessary 296 MPLS forwarding state. 298 Traffic from a client leaf node follows the upstream LSP towards the 299 root node and branches downward along the downstream LSP as required 300 to reach other server nodes (but no other client nodes). Similarly, 301 traffic from a server leaf node follows the upstream LSP toward the 302 root node and branches downward along the downstream LSP as required 303 to reach client nodes and server nodes. 305 Mapping traffic to the HD-MP2MP LSP may happen at any leaf node (the 306 root may be a leaf node as well). How that mapping is established is 307 outside the scope of this document. 309 Due to how a HD-MP2MP LSP is built a leaf LSR that is sending packets 310 on the HD-MP2MP LSP does not receive its own packets. There is also 311 no additional mechanism needed on the root or transit LSR to match 312 upstream traffic to the downstream forwarding state. 314 For the setup of a HD-MP2MP LSP with LDP we expand the definition of 315 downstream FEC elements (as defined in [7]) to differentiate leaf 316 notes into servers and clients. Both elements will be used in the FEC 317 TLV. The descriptions of the HD-MP2MP FEC elements follow. 319 2.1. FEC elements for HD-MP2MP 321 HD-MP2MP leverages the structure, encoding and error handling of the 322 P2MP FEC elements as described in [7]. This means that the P2MP FEC 323 element, which consists of the address of the root of the P2MP LSP 324 and an opaque value are being used as defined in [7]. The opaque 325 value is unique within the context of the root node and can for 326 example be interpreted as a service instance identifier. The 327 combination of (Root Node Address, Opaque Value) uniquely identifies 328 a P2MP LSP within the MPLS network. 330 Four new FEC types are introduced for HD-MP2MP operation: 332 o C-FEC-UP: HD-MP2MP Client Upstream Type (TBD) 334 o C-FEC-DOWN: HD-MP2MP Client Downstream Type (TBD) 336 o S-FEC-UP: HD-MP2MP Server Upstream Type (TBD) 338 o S-FEC-DOWN: HD-MP2MP Server Downstream Type (TBD) 340 If a FEC TLV contains one of the HD-MP2MP FEC elements, the HD-MP2MP 341 FEC Element MUST be the only FEC Element in the FEC TLV. 343 2.2. Using the HD-MP2MP FEC elements: Notation 345 The following notation is used in the processing rules: 347 1. HD-MP2MP client downstream LSP (or simply client downstream 348 ): a MP LSP downstream path with root node address X and 349 opaque value I. 351 2. HD-MP2MP server downstream LSP (or simply server downstream 352 ): a MP LSP downstream path with root node address X and 353 opaque value I. 355 3. HD-MP2MP client upstream LSP (or simply client upstream 356 ): a MP LSP upstream path for downstream node D with root 357 node address X and opaque value I. 359 4. HD-MP2MP server upstream LSP (or simply server upstream 360 ): a MP LSP upstream path for downstream node D with root 361 node address X and opaque value I. 363 5. HD-MP2MP Client Downstream FEC element : a FEC element with 364 root node address X and opaque value I used for a client type 365 downstream HD-MP2MP LSP. 367 6. HD-MP2MP Server Downstream FEC element : a FEC element with 368 root node address X and opaque value I used for a server type 369 downstream HD-MP2MP LSP. 371 7. HD-MP2MP Client Upstream FEC element : a FEC element with 372 root node address X and opaque value I used for a client type 373 downstream HD-MP2MP LSP. 375 8. HD-MP2MP Server Upstream FEC element : a FEC element with 376 root node address X and opaque value I used for a server type 377 downstream HD-MP2MP LSP. 379 9. HD-MP2MP Client Downstream Label Map : A Label Map 380 message with a FEC TLV with a single HD-MP2MP Client Downstream 381 FEC element and label TLV with label L. 383 10.HD-MP2MP Server Downstream Label Map : A Label Map 384 message with a FEC TLV with a single HD-MP2MP Server Downstream 385 FEC element and label TLV with label L. 387 11.HD-MP2MP Client Upstream Label Map : A Label Map message 388 with a FEC TLV with a single HD-MP2MP Client Upstream FEC element 389 and label TLV with label L. 391 12.HD-MP2MP Server Upstream Label Map : A Label Map message 392 with a FEC TLV with a single HD-MP2MP Server Upstream FEC element 393 and label TLV with label Lu. 395 13.HD-MP2MP Client Downstream Label Withdraw : A Label 396 Withdraw message with a FEC TLV with a single HD-MP2MP Client 397 Downstream FEC element and label TLV with label L. 399 14.HD-MP2MP Server Downstream Label Withdraw : A Label 400 Withdraw message with a FEC TLV with a single HD-MP2MP Server 401 Downstream FEC element and label TLV with label L. 403 15.HD-MP2MP Client Upstream Label Withdraw : A Label 404 Withdraw message with a FEC TLV with a single HD-MP2MP Client 405 Upstream FEC element and label TLV with label L. 407 16.HD-MP2MP Server Upstream Label Withdraw : A Label 408 Withdraw message with a FEC TLV with a single HD-MP2MP Server 409 Upstream FEC element and label TLV with label Lu. 411 The procedures below are organized by the role which the node plays 412 in the HD-MP2MP LSP: Leaf nodes, transit nodes and server node. 414 A leaf node is identified by a discovery process which is outside the 415 scope of this document. During the course of the protocol operation, 416 the root node recognizes its role because it owns the root node 417 address. A transit node is any node (other then the root node) that 418 receives a HD-MP2MP Label Map message (i.e., one that has leaf nodes 419 downstream of it). 421 Note that a transit node (as well as the root node) may also be a 422 leaf node. 424 2.3. HD-MP2MP Label Mapping 426 The following lists procedures for generating and processing HD-MP2MP 427 Label Map messages for nodes that participate in a HD-MP2MP LSP. 428 Based on its role in the HD-MP2MP LSP a LSR should apply the 429 procedures associated to its role. 431 Optimization procedures for multiple receivers on a LAN are not 432 considered in this document. This is a subject for further study, see 433 [5]. 435 The following notation is used in the descriptions below: 437 U 438 | 439 | 440 Z (transit node) 441 | 442 | 443 D (e.g. leaf) 445 2.3.1. Determining one's upstream MP2MP LSR 447 Determining the upstream LDP peer U for a HD-MP2MP LSP follows 448 the procedure for a P2MP LSP described in [7]. 450 2.3.2. Determining one's downstream MP2MP LSR 452 A LDP peer U which receives a HD-MP2MP Label Map downstream from a 453 LDP peer D will treat D as downstream MP2MP LSR. 455 2.3.3. HD-MP2MP client leaf node operation 457 Generally speaking, a client LSR joins the server tree for receive 458 operations and the client tree for send operations. 460 A client leaf node D determines its upstream LSR Z for server 461 downstream as per the procedures described in [7], allocates a 462 label L, and sends a server downstream label map to Z. 464 Traffic received with Label L represents traffic which another server 465 had sent. 467 Leaf node D expects a client upstream label map from node 468 Z in response to the HD-MP2MP server label map downstream it sent to 469 node Z. This will allow the client to send data to servers. 471 In case D does not already have forwarding state for client upstream 472 , D creates forwarding state to push label Lz onto the traffic 473 that D wants to forward to servers. How it determines what traffic 474 to forward on this HD-MP2MP LSP is outside the scope of this 475 document. 477 In summary, a client uses 479 o Client upstream and label Lz to send data to servers 481 o Server downstream and label L to receive data from servers 483 2.3.4. HD-MP2MP server leaf node operation 485 Generally speaking, a server LSR joins the client tree for receive 486 operations and the server tree for send operations. Transit LSR and 487 the root LSR will perform appropriate label mappings to ensure that 488 traffic sourced by server LSR is received via the client tree. 490 A server leaf node D determines its upstream LSR Z for client 491 downstream as per the procedures described in [7], allocates a 492 label L, and sends a client downstream label map to Z. 493 Traffic received with Label L represents traffic which another server 494 or client had sent. 496 Leaf node D expects a server upstream label map from node 497 Z in response to the HD-MP2MP client label map downstream it sent to 498 node Z. This will allow the server to send data to servers and 499 clients. 501 In case D does not already have forwarding state for server upstream 502 , D creates forwarding state to push label Lz onto the traffic 503 that D wants to forward to servers and clients. How it determines 504 what traffic to forward on this HD-MP2MP LSP is outside the scope of 505 this document. 507 In summary, a server uses 509 o Server upstream and label Lz to send data to servers and 510 clients. 512 o Client downstream and label L to receive data from servers 513 and clients. 515 2.3.5. Transit node operation 517 2.3.5.1. Transit node operation overview 519 This section provides a high-level overview of the operation of a 520 transit node. 522 Label Map signaling: 524 o On receipt of a "client downstream" label map, transit nodes 525 respond with a "server upstream" label map. This is commonly the 526 case if a server joins the HD-MDT. If the transit node does not 527 have forwarding state towards the root for the corresponding HD- 528 MDT, it will also send a "client downstream" label map towards the 529 root. 531 o On receipt of a "server downstream" label map, transit nodes 532 respond with a "client upstream" label map. This is commonly the 533 case if a client joins the HD-MDT. If the transit node does not 534 have forwarding state for towards the root for the corresponding 535 HD-MDT, it will also send a "server downstream" label map towards 536 the root. 538 Forwarding state establishment: 540 o Transit nodes update their forwarding state according to the 541 client downstream / server downstream label map messages. 543 o In order to ensure that servers receive traffic from clients (i.e. 544 ensure that traffic from clients is sent down the tree towards 545 servers while omitting the interface the traffic is received on), 546 transit nodes copy forwarding state from client downstream to 547 client upstream state tables - except for the interfaces these 548 state tables are associated with. 550 o In order to ensure that clients receive traffic from servers (i.e. 551 ensure that traffic from servers is sent down the tree towards 552 clients while omitting the interface the traffic is received on), 553 transit nodes copy forwarding state from server downstream to 554 server upstream state tables - except for the interfaces these 555 state tables are associated with. 557 o In order to ensure that servers receive traffic from servers (i.e. 558 ensure that traffic from servers is sent down the tree towards 559 servers while omitting the interface the traffic is received on), 560 transit nodes copy forwarding state from client downstream to 561 server upstream state tables - except for the interfaces these 562 state tables are associated with. 564 2.3.5.2. Client Downstream Label Map received 566 Transit nodes receive a client downstream label map as the result of 567 a server joining the HD-MDT. 569 When node Z receives a HD-MP2MP client downstream label map 570 over interface Q from node D it checks whether it has forwarding 571 state for client downstream . If not, Z allocates a label L' 572 and installs downstream forwarding state to swap label L' with label 573 L over interface Q towards node D. Z also determines its upstream LSR 574 U for as per [7] and sends a client label map downstream , Z 578 needs to update its forwarding state. Assuming its old forwarding 579 state was L'-> { ..., }, its new forwarding 580 state becomes L'-> { ..., , }. 581 Node Z checks whether it has forwarding state(s) for client upstream 582 . If so node Z will update the forwarding state(s) for 583 client upstream to include the forwarding state from 584 client downstream omitting the swap on the interfaces 585 associated with node D(i). This allows client upstream traffic to 586 follow the client downstream tree to other servers while omitting the 587 case that traffic is sent out on the same interface it was received 588 from. 590 Node Z checks whether it already has forwarding state server upstream 591 over interface Q. If it does, no further action needs to 592 happen. Otherwise, Z allocates a label Lz and creates a new label 593 swap for Lz from the label swap(s) from the forwarding state for 594 server downstream , omitting the swap on interface Q for node 595 D. This allows server upstream traffic to follow the server 596 downstream tree down to other node(s) except the node from which Z 597 received the client downstream label map . 598 In addition Z will update the forwarding state(s) for server upstream 599 to include the forwarding state from client downstream 600 omitting label swaps on interfaces Q(i) for nodes D(i), i.e. 601 omitting receive and forwarding label swaps referring to the same 602 interface. This is to avoid traffic being sent out the same interface 603 it was received from. This allows server upstream traffic to follow 604 the client downstream tree to other servers. 605 Z sends a server upstream label map . This allows packets to go up the server tree towards the root 613 node. 615 2.3.5.3. Server Downstream Label Map received 617 Transit nodes receive a server downstream label map as the result of 618 a client joining the HD-MDT. 620 When node Z receives a HD-MP2MP server downstream label map 621 over Interface Q from node D it checks whether it has forwarding 622 state for server downstream . If not, Z allocates a label L' 623 and installs downstream forwarding state to swap label L' with label 624 L over interface Q. Z also determines its upstream LSR U for 625 as per [7] and sends a server label map downstream , all 629 that Z needs to do is to update its forwarding state. Assuming its 630 old forwarding state was L'-> { ..., }, its 631 new forwarding state becomes L'-> { ..., , 632 }. 634 Node Z checks whether it already has forwarding state for client 635 upstream over interface Q. If it does, no further action 636 needs to happen. Otherwise, Z allocates a label Lz and creates a new 637 label swap for Lz from the label swap(s) from the forwarding state 638 for client downstream , omitting the swap on interface Q for 639 node D. This allows client upstream traffic to follow the client 640 downstream tree down to other node(s) (i.e. servers) except to the 641 node from which Z received the server downstream label map . 642 In addition, Z sends a client upstream label map . If so node Z will update the forwarding state(s) for server 647 upstream to include the newly added forwarding state for 648 server downstream, i.e. to include , omitting the swap on 649 interface Q for node D. This allows server upstream traffic to follow 650 the server downstream tree down to other node(s) (i.e. clients). 652 Transit node Z will also receive a client upstream label map . 656 This allows packets to go up towards the root node. 658 2.3.6. HD-MP2MP root node operation 660 2.3.6.1. Client Downstream Label Map received 662 Operation of a root node is similar to the operation of a transit 663 node with the main difference that by definition the root node does 664 not have an upstream neighbor. As such there is no need for the root 665 to send any (client or server) downstream label map. 667 When root R receives a HD-MP2MP client downstream label map 668 over interface Q from node D it checks whether it has forwarding 669 state for client downstream . If not, R creates downstream 670 forwarding state and installs an outgoing label L over interface Q. 671 If R already has forwarding state for client downstream , R 672 needs to update its forwarding state. Assuming its old forwarding 673 state was L'-> { ..., }, its new forwarding 674 state becomes L'-> { ..., , }. 676 Root node R checks whether it has forwarding state for client 677 upstream . If so root node R will update the forwarding 678 state for client upstream to include the forwarding 679 state from client downstream omitting the swap on the 680 interfaces associated with node D(i). This allows client upstream 681 traffic to follow the client downstream tree to other servers while 682 omitting the case that traffic is sent out on the same interface it 683 was received on.Root node R checks whether it already has forwarding 684 state server upstream over interface Q. If it does, no 685 further action needs to happen. Otherwise, R allocates a label Lr and 686 creates a new label swap for Lr from the label swap(s) from the 687 forwarding state for server downstream , omitting the swap on 688 interface Q for node D. This allows server upstream traffic to follow 689 the server downstream tree down to other node(s) except the node from 690 which Z received the client downstream label map . In 691 addition Z will update the forwarding state(s) for server upstream 692 to include the forwarding state from client downstream 693 omitting label swaps on interfaces Q(i) for nodes D(i), i.e. 694 labels swaps referring to the same interface. This is to avoid 695 traffic being sent out the same interface it was received from. This 696 allows server upstream traffic to follow the client downstream tree 697 to other servers. 699 Root node R determines the downstream LSR D as per the procedures 700 described in [7], and sends a server upstream label map 709 over Interface Q from node D it checks whether it has forwarding 710 state for server downstream . If not, R creates server 711 downstream forwarding state and installs an outgoing label L over 712 interface Q. If R already has forwarding state for server downstream 713 , the R will add label L over interface Q to the existing 714 state. 716 Node R checks if it has forwarding state for server upstream . If not, R allocates a label Lu and creates forwarding state to 718 swap Lu with the label swap(s) from the forwarding state downstream 719 (X, I), except the swap for node D. This allows server upstream 720 traffic to go down the server tree to other node(s), except the node 721 it was received from. 723 When root node R receives a server downstream label map 724 over Interface Q from node D it checks whether it has forwarding 725 state for server downstream . If not, R creates server 726 downstream forwarding state and installs an outgoing label L over 727 interface Q. 729 If R already has forwarding state for server downstream , R 730 updates its forwarding state. Assuming its old forwarding state was 731 L'-> { ..., }, its new forwarding state 732 becomes L'-> { ..., , }. 734 Node R checks whether it already has forwarding state for client 735 upstream over interface Q. If it does, no further action 736 needs to happen. Otherwise, R allocates a label Lr and creates a new 737 label swap for Lr from the label swap(s) from the forwarding state 738 for client downstream , omitting the swap on interface Q for 739 node D. This allows client upstream traffic to follow the client 740 downstream tree down to other node(s) (i.e. servers) except to the 741 node from which R received the server downstream label map . 743 Root node R checks whether it has forwarding state for server 744 upstream . If so node R will update the forwarding state(s) 745 for server upstream to include the newly added 746 forwarding state for server downstream, i.e. to include , 747 omitting the swap on interface Q for node D. This allows server 748 upstream traffic to follow the server downstream tree down to other 749 node(s) (i.e. clients). 751 Root node R determines the downstream LSR D as per the procedures 752 described in [7], and sends a client upstream label map to its upstream LSR U for , 772 where L is the label it had previously advertised to U for . 774 Client node Z expects the upstream router U to respond by sending a 775 downstream label release for L and a client upstream label withdraw 776 to remove Lu from the upstream state. Node Z will remove 777 label Lu from its upstream state and send a label release message 778 with label Lu to U. 780 2.3.7.2. HD-MP2MP Server operation 782 If a server node Z discovers that it is no longer a server it SHOULD 783 send a client downstream label withdraw to its upstream LSR 784 U for , where L is the label it had previously advertised to U 785 for . 787 Server node Z expects the upstream router U to respond by sending a 788 downstream label release for L and a server upstream label withdraw 789 to remove Lu from the upstream state. Node Z will remove 790 label Lu from its upstream state and send a label release message 791 with label Lu to U. 793 2.3.7.3. HD-MP2MP transit node operation 795 Leaf label withdraw procedures are similar to those for MP2MP 796 operation, described in [7]. 798 If a transit node Z receives a server downstream label withdraw 799 message from node D, it deletes label L from its forwarding 800 state for server downstream and from all its upstream states 801 for . Node Z sends a label release message with label L to D. 802 Since D is no longer part of the server downstream forwarding state, 803 Z cleans up the forwarding state upstream and sends a 804 client upstream label withdraw for results in no state remaining for then Z propagates the 808 server downstream label withdraw to its upstream node U for 809 . 811 Similarly, if a transit node Z receives a client downstream label 812 withdraw message from node D, it deletes label L from its 813 forwarding state for client downstream and from all its 814 upstream states for . Node Z sends a label release message with 815 label L to D. Since D is no longer part of the client downstream 816 forwarding state, Z cleans up the forwarding state upstream 817 and sends a server upstream label withdraw for results in no state remaining for then Z propagates the 821 client downstream label withdraw to its upstream node U for 822 . 824 2.3.7.4. HD-MP2MP root node operation 826 The procedure when the root node of a MP2MP LSP receives a label 827 withdraw message is the same as for transit nodes, except that the 828 root node would not propagate the Label Withdraw upstream (as it has 829 no upstream). 831 2.3.7.5. HD-MP2MP Upstream LSR Change 833 The procedure for changing the upstream LSR is the same as documented 834 in [7], except it is applied to HD-MP2MP FECs using the procedures 835 described in the earlier sections of this document. 837 3. Security Considerations 839 The same security considerations apply as for the base LDP 840 specification, as described in [1]. 842 4. IANA Considerations 844 This document leverages the new name space (the LDP MP Opaque Value 845 Element type) introduced in [7] that is to be managed by IANA. 847 5. References 849 5.1. Normative References 851 [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 852 Thomas, "LDP Specification", RFC 3036, January 2001. 854 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 855 Levels", BCP 14, RFC 2119, March 1997. 857 [3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 858 October 1994. 860 [4] Roux, J., "Requirements for Point-To-Multipoint Extensions to 861 the Label Distribution Protocol ", draft-ietf-mpls-mp-ldp-reqs- 862 03 (work in progress), November 2007. 864 [5] Aggarwal, R., "MPLS Upstream Label Assignment and Context 865 Specific Label Space", draft-ietf-mpls-upstream-label-03 (work 866 in progress), November 2007. 868 [6] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for 869 RSVP-TE", draft-ietf-mpls-rsvp-upstream-02 (work in progress), 870 November 2007. 872 [7] Minei, I., "Label Distribution Protocol Extensions for Point- 873 to-Multipoint and Multipoint-to-Multipoint Label Switched 874 Paths", draft-ietf-mpls-ldp-p2mp-03 (work in progress), July 875 2007. 877 [8] Metro Ethernet Forum, Technical Specification MEF 10.1, 878 "Ethernet Services Attributes Phase 2", November 2006. 880 5.2. Informative References 882 [9] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 883 Private Networks (L2VPNs)", RFC 4664, September 2006. 885 [10] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE 886 LSPs", RFC 4875, May 2007. 888 [11] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", 889 draft-ietf-l3vpn-2547bis-mcast-06 (work in progress), January 890 2008. 892 Author's Addresses 894 Frank Brockners 895 Cisco Systems, Inc. 896 Hansaallee 249 897 40549 Duesseldorf 898 Germany 899 Email: fbrockne@cisco.com 901 Ijsbrand Wijnands 902 Cisco Systems, Inc. 903 Pegasus Parc, De Kleetlaan 6a 904 1831 Diegem 905 Belgium 906 Email: iwijnand@cisco.com 908 Ali Sajassi 909 Cisco Systems, Inc. 910 170 West Tasman Drive 911 San Jose, CA 95134 912 Email: sajassi@cisco.com 914 Intellectual Property Statement 916 The IETF takes no position regarding the validity or scope of any 917 Intellectual Property Rights or other rights that might be claimed to 918 pertain to the implementation or use of the technology described in 919 this document or the extent to which any license under such rights 920 might or might not be available; nor does it represent that it has 921 made any independent effort to identify any such rights. Information 922 on the procedures with respect to rights in RFC documents can be 923 found in BCP 78 and BCP 79. 925 Copies of IPR disclosures made to the IETF Secretariat and any 926 assurances of licenses to be made available, or the result of an 927 attempt made to obtain a general license or permission for the use of 928 such proprietary rights by implementers or users of this 929 specification can be obtained from the IETF on-line IPR repository at 930 http://www.ietf.org/ipr. 932 The IETF invites any interested party to bring to its attention any 933 copyrights, patents or patent applications, or other proprietary 934 rights that may cover technology that may be required to implement 935 this standard. Please address the information to the IETF at 936 ietf-ipr@ietf.org. 938 Disclaimer of Validity 940 This document and the information contained herein are provided on an 941 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 942 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 943 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 944 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 945 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 946 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 948 Copyright Statement 950 Copyright (C) The IETF Trust (2008). 952 This document is subject to the rights, licenses and restrictions 953 contained in BCP 78, and except as set forth therein, the authors 954 retain all their rights. 956 Acknowledgment 958 Funding for the RFC Editor function is currently provided by the 959 Internet Society.