Network Working Group F. Brockners I. Wijnands A. Sajassi Internet Draft Cisco Systems Intended status: Standards Track September 18, 2007 Expires: March 19, 2008 Label Distribution Protocol Extensions for Half-Duplex Multipoint-to-Multipoint Label Switched Paths draft-brockners-ldp-half-duplex-mp2mp-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Brockners Expires March 18, 2008 [Page 1] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 Abstract This document describes a mechanism to construct Label Switched Paths (LSP) over MPLS using an extended version of the Label Distribution Protocol (LDP) between a set of clients and servers. This communication mechanism has the capability that servers can communicate with other servers and clients, whereas clients can only communicate with servers but not with other clients. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction...................................................3 1.1. Service Connectivity Categorization.......................3 1.2. Problem Statement and Motivation..........................4 1.3. Terminology (for reference only)..........................5 2. Half duplex MP2MP (HD-MP2MP) Service with LDP..................6 2.1. FEC elements for HD-MP2MP.................................7 2.2. Using the HD-MP2MP FEC elements: Notation.................8 2.3. HD-MP2MP Label Mapping...................................10 2.3.1. Determining one's upstream MP2MP LSR................10 2.3.2. Determining one's downstream MP2MP LSR..............10 2.3.3. HD-MP2MP client leaf node operation.................10 2.3.4. HD-MP2MP server leaf node operation.................11 2.3.5. Transit node operation..............................12 2.3.5.1. Transit node operation overview................12 2.3.5.2. Client Downstream Label Map received...........13 2.3.5.3. Server Downstream Label Map received...........14 2.3.6. HD-MP2MP root node operation........................15 2.3.6.1. Client Downstream Label Map received...........15 2.3.6.2. Server Downstream Label Map received...........16 2.3.7. HD-MP2MP Label Withdraw.............................17 2.3.7.1. HD-MP2MP Client operation......................17 2.3.7.2. HD-MP2MP Server operation......................17 2.3.7.3. HD-MP2MP transit node operation................18 2.3.7.4. HD-MP2MP root node operation...................18 2.3.7.5. HD-MP2MP Upstream LSR Change...................18 3. Security Considerations.......................................19 4. IANA Considerations...........................................19 5. References....................................................19 5.1. Normative References.....................................19 Brockners Expires March 18, 2008 [Page 2] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 5.2. Informative References...................................19 Author's Addresses...............................................20 Intellectual Property Statement..................................20 Disclaimer of Validity...........................................21 1. Introduction The LDP protocol is described in [1]. It defines mechanisms for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs in the network. This document describes a mechanism to construct Half-Duplex Multipoint to Multipoint LSPs (HD-MP2MP LSPs) over an MPLS infrastructure using LDP. 1.1. Service Connectivity Categorization The following general types of connectivity using some transport vehicle (e.g. a LSP) are acknowledged within the industry (see e.g. [8]) between a set of User to Network (UNI) interfaces: o Point to Point Connectivity: For Point-to-Point connectivity, exactly two UNIs are associated with one another. An ingress service frame mapped to the transport vehicle at one UNI shall not result in an egress service frame at a UNI other than the other UNI associated with the transport vehicle. o Multipoint Connectivity: For Multipoint connectivity two or more UNIs are associated with one another. An ingress service frame mapped to the transport vehicle at one of the UNIs shall not result in an egress service frame at a UNI that is not associated with the transport vehicle. Multipoint connectivity can further be differentiated into multipoint to multipoint connectivity as well as rooted-multipoint connectivity. * Multipoint to Multipoint Connectivity: An ingress service frame at a given UNI would be replicated in the network and a single copy would be delivered to each of the other UNIs associated with the transport vehicle. * Rooted-Multipoint Connectivity: For rooted multipoint connectivity, one or more of the UNIs shall be designated as a servers and each of the other UNIs shall be designated as a clients. An ingress service frame mapped to the transport vehicle at a server UNI should be delivered to one or more of the other UNIs. An ingress service frame mapped to the transport vehicle at a client UNI shall not result in an egress service frame at another client UNI but can result in an egress service frame at some or all of the server UNIs. Brockners Expires March 18, 2008 [Page 3] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 Using the LDP Protocol [1], one can establish point to point as well as multipoint connectivity using LSPs. For multipoint operation, multipoint to multipoint, point to multipoint as well as multipoint to point connectivity models are supported. While rooted-multipoint connectivity can be established by combining point to multipoint with multipoint to point LSPs, a more efficient mechanism to establish rooted-multipoint connectivity (which could be understood as a generalized version of point to multipoint connectivity) is desirable. Half-Duplex MDT with LDP can be leveraged to establish rooted multipoint connectivity. 1.2. Problem Statement and Motivation Some deployment scenarios, such as broadcast TV delivery over aggregation networks or broadcast/multicast wholesale require efficient mechanisms to transport multicast/broadcast type of data from a set of sources to many receivers over an MPLS network, while isolating the receivers from each other. Achieving such a connectivity model with a limited amount of configuration on the leaf nodes is seen as beneficial. The desired behavior is as follows: o The set of users can be divided into two non-overlapping sets: Client nodes (or short "Clients") and server nodes (or short "Servers"). o Servers can communicate with each other and with the clients, i.e. Servers can send data to each other as well as to clients and can receive data from each other as well as from clients. o Clients can only communicate with servers, i.e. Clients can send data to servers and can receive data from servers but cannot send data to other clients nor can receive data from other clients. o All data is transported as broadcast: Any data sent by a server is received by all other servers and all clients. Any data sent by a client is received by all servers. o The setup of the forwarding behavior between clients and servers should be automatic, i.e. should not require any configuration on network elements other than the client and server nodes. Provisioning a new client should not require any manual reconfiguration but on the client itself. As a result of this behavior, a local connectivity between clients is prevented and it is ensured that connectivity between clients can Brockners Expires March 18, 2008 [Page 4] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 only be provided through server sites. This ensures that in a broadband aggregation deployment case, individual subscribers cannot directly connect with each other, bypassing functions implemented on the edge router such as accounting or admission control. One way to achieve the desired communication behavior with restricted connectivity between clients is to use a combination of LDP P2MP LSPs and LDP MP2P LSPs: One P2MP LSP per server (with the server forming the root of the P2MP LSP and the clients other servers forming the leaves) would be established for server to client (and other servers) communication. One MP2P LSP per server (forming the root of the MP2P tree) would be used to enable clients and other servers to communicate with the server forming the root. As a result, each client is connected to N P2MP LSPs and N MP2P LSPs, with N representing the number of servers. The major advantage of this approach is that no further protocol mechanisms beyond the ones already defined in [1] and [7] would be required. A property of this approach is that clients need to handle send and receive operations across multiple LSPs for the same service instance. Clients wishing to send traffic to the set of servers are required to send the data multiple times (once per server, or in other words once per MP2P LSP). Furthermore, the addition or removal of a server from the overall configuration would also require configuration changes on all connected servers and clients. HD-MP2MP LSP described here aim at reducing the configuration requirements on the leaf nodes, so that clients or servers can be added without a reconfiguration on other clients or servers and at simplifying traffic handling by using only a single LSP to send data to and a single LSP to receive data from. 1.3. Terminology (for reference only) The following terminology is taken from [4] and is repeated here to ease readability of the document. o P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. o P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs. o MP2P LSP: A LSP that has one or more Ingress LSRs and one unique o Egress LSR. Brockners Expires March 18, 2008 [Page 5] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 o MP2MP LSP: A LSP that connects a set of leaf nodes, acting indifferently as ingress or egress. o MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. o Ingress LSR: Source of the P2MP LSP, also referred to as root node. o Egress LSR: One of potentially many destinations of an LSP, also referred to as leaf node in the case of P2MP and MP2MP LSPs. o Transit LSR: An LSR that has one or more directly connected downstream LSRs. o Bud LSR: An LSR that is an egress but also has one or more directly connected downstream LSRs. To ease readability of this document this section briefly lists the notation for the P2MP FEC element as they are described in [7]. Please refer to [7] for a comprehensive description. o P2MP FEC Element : a FEC Element with Root Node Address X and Opaque Value Y. o P2MP Label Map : a Label Map message with a FEC TLV with a single P2MP FEC Element and Label TLV with label L. o P2MP Label Withdraw : a Label Withdraw message with a FEC TLV with a single P2MP FEC Element and Label TLV with label L. o P2MP LSP (or simply ): a P2MP LSP with Root Node Address X and Opaque Value Y. o The notation L' -> { ..., } on LSR X means that on receiving a packet with label L', X makes n copies of the packet. For copy i of the packet, X swaps L' with Li and sends it out over interface Ii. 2. Half duplex MP2MP (HD-MP2MP) Service with LDP An HD-MP2MP combines two LSPs. The LSPs used to construct a HD-MP2MP service are similar to a MP2MP LSP in that it consists of a single root node, zero or more transit nodes and one or more leaf LSRs acting equally as Ingress or Egress LSR. Leaf LSRs fulfill either the Brockners Expires March 18, 2008 [Page 6] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 role of a client or a server. Correspondingly they are called "Client LSR" and "Server LSR". For HD-MP2MP operation, two trees will be combined: A "Client Tree" which allows communication from all Clients to all Servers and a "Server Tree" allows communication from all servers to all clients and all servers. A leaf node participates in the setup of a HD-MP2MP LSP by establishing both a downstream LSP, which is much like a P2MP LSP from the root, and an upstream LSP which is used to send traffic toward the root and other leaf nodes. Depending on the type of the leaf (Client or Server), traffic sent by a leaf will either be forwarded to all leafs (which means clients and servers - this is in case of a leaf being a server), or only to servers (in case of a leaf being a client). Transit nodes support the setup by propagating the upstream and downstream LSP setup toward the root and installing the necessary MPLS forwarding state. Traffic from a client leaf node follows the upstream LSP towards the root node and branches downward along the downstream LSP as required to reach other server nodes (but no other client nodes). Similarly, traffic from a server leaf node follows the upstream LSP toward the root node and branches downward along the downstream LSP as required to reach client nodes and server nodes. Mapping traffic to the HD-MP2MP LSP may happen at any leaf node (the root may be a leaf node as well). How that mapping is established is outside the scope of this document. Due to how a HD-MP2MP LSP is built a leaf LSR that is sending packets on the HD-MP2MP LSP does not receive its own packets. There is also no additional mechanism needed on the root or transit LSR to match upstream traffic to the downstream forwarding state. For the setup of a HD-MP2MP LSP with LDP we expand the definition of downstream FEC elements (as defined in [7]) to differentiate leaf notes into servers and clients. Both elements will be used in the FEC TLV. The descriptions of the HD-MP2MP FEC elements follow. 2.1. FEC elements for HD-MP2MP HD-MP2MP leverages the structure, encoding and error handling of the P2MP FEC elements as described in [7]. This means that the P2MP FEC element, which consists of the address of the root of the P2MP LSP Brockners Expires March 18, 2008 [Page 7] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 and an opaque value are being used as defined in [7]. The opaque value is unique within the context of the root node and can for example be interpreted as a service instance identifier. The combination of (Root Node Address, Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. Four new FEC types are introduced for HD-MP2MP operation: o C-FEC-UP: HD-MP2MP Client Upstream Type (TBD) o C-FEC-DOWN: HD-MP2MP Client Downstream Type (TBD) o S-FEC-UP: HD-MP2MP Server Upstream Type (TBD) o S-FEC-DOWN: HD-MP2MP Server Downstream Type (TBD) If a FEC TLV contains one of the HD-MP2MP FEC elements, the HD-MP2MP FEC Element MUST be the only FEC Element in the FEC TLV. 2.2. Using the HD-MP2MP FEC elements: Notation The following notation is used in the processing rules: 1. HD-MP2MP client downstream LSP (or simply client downstream ): a MP LSP downstream path with root node address X and opaque value I. 2. HD-MP2MP server downstream LSP (or simply server downstream ): a MP LSP downstream path with root node address X and opaque value I. 3. HD-MP2MP client upstream LSP (or simply client upstream ): a MP LSP upstream path for downstream node D with root node address X and opaque value I. 4. HD-MP2MP server upstream LSP (or simply server upstream ): a MP LSP upstream path for downstream node D with root node address X and opaque value I. 5. HD-MP2MP Client Downstream FEC element : a FEC element with root node address X and opaque value I used for a client type downstream HD-MP2MP LSP. 6. HD-MP2MP Server Downstream FEC element : a FEC element with root node address X and opaque value I used for a server type downstream HD-MP2MP LSP. Brockners Expires March 18, 2008 [Page 8] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 7. HD-MP2MP Client Upstream FEC element : a FEC element with root node address X and opaque value I used for a client type downstream HD-MP2MP LSP. 8. HD-MP2MP Server Upstream FEC element : a FEC element with root node address X and opaque value I used for a server type downstream HD-MP2MP LSP. 9. HD-MP2MP Client Downstream Label Map : A Label Map message with a FEC TLV with a single HD-MP2MP Client Downstream FEC element and label TLV with label L. 10.HD-MP2MP Server Downstream Label Map : A Label Map message with a FEC TLV with a single HD-MP2MP Server Downstream FEC element and label TLV with label L. 11.HD-MP2MP Client Upstream Label Map : A Label Map message with a FEC TLV with a single HD-MP2MP Client Upstream FEC element and label TLV with label L. 12.HD-MP2MP Server Upstream Label Map : A Label Map message with a FEC TLV with a single HD-MP2MP Server Upstream FEC element and label TLV with label Lu. 13.HD-MP2MP Client Downstream Label Withdraw : A Label Withdraw message with a FEC TLV with a single HD-MP2MP Client Downstream FEC element and label TLV with label L. 14.HD-MP2MP Server Downstream Label Withdraw : A Label Withdraw message with a FEC TLV with a single HD-MP2MP Server Downstream FEC element and label TLV with label L. 15.HD-MP2MP Client Upstream Label Withdraw : A Label Withdraw message with a FEC TLV with a single HD-MP2MP Client Upstream FEC element and label TLV with label L. 16.HD-MP2MP Server Upstream Label Withdraw : A Label Withdraw message with a FEC TLV with a single HD-MP2MP Server Upstream FEC element and label TLV with label Lu. The procedures below are organized by the role which the node plays in the HD-MP2MP LSP: Leaf nodes, transit nodes and server node. A leaf node is identified by a discovery process which is outside the scope of this document. During the course of the protocol operation, the root node recognizes its role because it owns the root node address. A transit node is any node (other then the root node) that Brockners Expires March 18, 2008 [Page 9] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 receives a HD-MP2MP Label Map message (i.e., one that has leaf nodes downstream of it). Note that a transit node (as well as the root node) may also be a leaf node. 2.3. HD-MP2MP Label Mapping The following lists procedures for generating and processing HD-MP2MP Label Map messages for nodes that participate in a HD-MP2MP LSP. Based on its role in the HD-MP2MP LSP a LSR should apply the procedures associated to its role. Optimization procedures for multiple receivers on a LAN are not considered in this document. This is a subject for further study, see [5]. The following notation is used in the descriptions below: U | | Z (transit node) | | D (e.g. leaf) 2.3.1. Determining one's upstream MP2MP LSR Determining the upstream LDP peer U for a HD-MP2MP LSP follows the procedure for a P2MP LSP described in [7]. 2.3.2. Determining one's downstream MP2MP LSR A LDP peer U which receives a HD-MP2MP Label Map downstream from a LDP peer D will treat D as downstream MP2MP LSR. 2.3.3. HD-MP2MP client leaf node operation Generally speaking, a client LSR joins the server tree for receive operations and the client tree for send operations. A client leaf node D determines its upstream LSR Z for server downstream as per the procedures described in [7], allocates a label L, and sends a server downstream label map to Z. Brockners Expires March 18, 2008 [Page 10] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 Traffic received with Label L represents traffic which another server had sent. Leaf node D expects a client upstream label map from node Z in response to the HD-MP2MP server label map downstream it sent to node Z. This will allow the client to send data to servers. In case D does not already have forwarding state for client upstream , D creates forwarding state to push label Lz onto the traffic that D wants to forward to servers. How it determines what traffic to forward on this HD-MP2MP LSP is outside the scope of this document. In summary, a client uses o Client upstream and label Lz to send data to servers o Server downstream and label L to receive data from servers 2.3.4. HD-MP2MP server leaf node operation Generally speaking, a server LSR joins the client tree for receive operations and the server tree for send operations. Transit LSR and the root LSR will perform appropriate label mappings to ensure that traffic sourced by server LSR is received via the client tree. A server leaf node D determines its upstream LSR Z for client downstream as per the procedures described in [7], allocates a label L, and sends a client downstream label map to Z. Traffic received with Label L represents traffic which another server or client had sent. Leaf node D expects a server upstream label map from node Z in response to the HD-MP2MP client label map downstream it sent to node Z. This will allow the server to send data to servers and clients. In case D does not already have forwarding state for server upstream , D creates forwarding state to push label Lz onto the traffic that D wants to forward to servers and clients. How it determines what traffic to forward on this HD-MP2MP LSP is outside the scope of this document. In summary, a server uses o Server upstream and label Lz to send data to servers and clients. Brockners Expires March 18, 2008 [Page 11] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 o Client downstream and label L to receive data from servers and clients. 2.3.5. Transit node operation 2.3.5.1. Transit node operation overview This section provides a high-level overview of the operation of a transit node. Label Map signaling: o On receipt of a "client downstream" label map, transit nodes respond with a "server upstream" label map. This is commonly the case if a server joins the HD-MDT. If the transit node does not have forwarding state towards the root for the corresponding HD- MDT, it will also send a "client downstream" label map towards the root. o On receipt of a "server downstream" label map, transit nodes respond with a "client upstream" label map. This is commonly the case if a client joins the HD-MDT. If the transit node does not have forwarding state for towards the root for the corresponding HD-MDT, it will also send a "server downstream" label map towards the root. Forwarding state establishment: o Transit nodes update their forwarding state according to the client downstream / server downstream label map messages. o In order to ensure that servers receive traffic from clients (i.e. ensure that traffic from clients is sent down the tree towards servers while omitting the interface the traffic is received on), transit nodes copy forwarding state from client downstream to client upstream state tables - except for the interfaces these state tables are associated with. o In order to ensure that clients receive traffic from servers (i.e. ensure that traffic from servers is sent down the tree towards clients while omitting the interface the traffic is received on), transit nodes copy forwarding state from server downstream to server upstream state tables - except for the interfaces these state tables are associated with. Brockners Expires March 18, 2008 [Page 12] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 o In order to ensure that servers receive traffic from servers (i.e. ensure that traffic from servers is sent down the tree towards servers while omitting the interface the traffic is received on), transit nodes copy forwarding state from client downstream to server upstream state tables - except for the interfaces these state tables are associated with. 2.3.5.2. Client Downstream Label Map received Transit nodes receive a client downstream label map as the result of a server joining the HD-MDT. When node Z receives a HD-MP2MP client downstream label map over interface Q from node D it checks whether it has forwarding state for client downstream . If not, Z allocates a label L' and installs downstream forwarding state to swap label L' with label L over interface Q towards node D. Z also determines its upstream LSR U for as per [7] and sends a client label map downstream , Z needs to update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. Node Z checks whether it has forwarding state(s) for client upstream . If so node Z will update the forwarding state(s) for client upstream to include the forwarding state from client downstream omitting the swap on the interfaces associated with node D(i). This allows client upstream traffic to follow the client downstream tree to other servers while omitting the case that traffic is sent out on the same interface it was received from. Node Z checks whether it already has forwarding state server upstream over interface Q. If it does, no further action needs to happen. Otherwise, Z allocates a label Lz and creates a new label swap for Lz from the label swap(s) from the forwarding state for server downstream , omitting the swap on interface Q for node D. This allows server upstream traffic to follow the server downstream tree down to other node(s) except the node from which Z received the client downstream label map . In addition Z will update the forwarding state(s) for server upstream to include the forwarding state from client downstream omitting label swaps on interfaces Q(i) for nodes D(i), i.e. omitting receive and forwarding label swaps referring to the same interface. This is to avoid traffic being sent out the same interface it was received from. This allows server upstream traffic to follow Brockners Expires March 18, 2008 [Page 13] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 the client downstream tree to other servers. Z sends a server upstream label map . This allows packets to go up the server tree towards the root node. 2.3.5.3. Server Downstream Label Map received Transit nodes receive a server downstream label map as the result of a client joining the HD-MDT. When node Z receives a HD-MP2MP server downstream label map over Interface Q from node D it checks whether it has forwarding state for server downstream . If not, Z allocates a label L' and installs downstream forwarding state to swap label L' with label L over interface Q. Z also determines its upstream LSR U for as per [7] and sends a server label map downstream , all that Z needs to do is to update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. Node Z checks whether it already has forwarding state for client upstream over interface Q. If it does, no further action needs to happen. Otherwise, Z allocates a label Lz and creates a new label swap for Lz from the label swap(s) from the forwarding state for client downstream , omitting the swap on interface Q for node D. This allows client upstream traffic to follow the client downstream tree down to other node(s) (i.e. servers) except to the node from which Z received the server downstream label map . In addition, Z sends a client upstream label map . If so node Z will update the forwarding state(s) for server upstream to include the newly added forwarding state for server downstream, i.e. to include , omitting the swap on interface Q for node D. This allows server upstream traffic to follow the server downstream tree down to other node(s) (i.e. clients). Brockners Expires March 18, 2008 [Page 14] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 Transit node Z will also receive a client upstream label map . This allows packets to go up towards the root node. 2.3.6. HD-MP2MP root node operation 2.3.6.1. Client Downstream Label Map received Operation of a root node is similar to the operation of a transit node with the main difference that by definition the root node does not have an upstream neighbor. As such there is no need for the root to send any (client or server) downstream label map. When root R receives a HD-MP2MP client downstream label map over interface Q from node D it checks whether it has forwarding state for client downstream . If not, R creates downstream forwarding state and installs an outgoing label L over interface Q. If R already has forwarding state for client downstream , R needs to update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. Root node R checks whether it has forwarding state for client upstream . If so root node R will update the forwarding state for client upstream to include the forwarding state from client downstream omitting the swap on the interfaces associated with node D(i). This allows client upstream traffic to follow the client downstream tree to other servers while omitting the case that traffic is sent out on the same interface it was received on.Root node R checks whether it already has forwarding state server upstream over interface Q. If it does, no further action needs to happen. Otherwise, R allocates a label Lr and creates a new label swap for Lr from the label swap(s) from the forwarding state for server downstream , omitting the swap on interface Q for node D. This allows server upstream traffic to follow the server downstream tree down to other node(s) except the node from which Z received the client downstream label map . In addition Z will update the forwarding state(s) for server upstream to include the forwarding state from client downstream omitting label swaps on interfaces Q(i) for nodes D(i), i.e. labels swaps referring to the same interface. This is to avoid traffic being sent out the same interface it was received from. This allows server upstream traffic to follow the client downstream tree Brockners Expires March 18, 2008 [Page 15] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 to other servers. Root node R determines the downstream LSR D as per the procedures described in [7], and sends a server upstream label map over Interface Q from node D it checks whether it has forwarding state for server downstream . If not, R creates server downstream forwarding state and installs an outgoing label L over interface Q. If R already has forwarding state for server downstream , the R will add label L over interface Q to the existing state. Node R checks if it has forwarding state for server upstream . If not, R allocates a label Lu and creates forwarding state to swap Lu with the label swap(s) from the forwarding state downstream (X, I), except the swap for node D. This allows server upstream traffic to go down the server tree to other node(s), except the node it was received from. When root node R receives a server downstream label map over Interface Q from node D it checks whether it has forwarding state for server downstream . If not, R creates server downstream forwarding state and installs an outgoing label L over interface Q. If R already has forwarding state for server downstream , R updates its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. Node R checks whether it already has forwarding state for client upstream over interface Q. If it does, no further action needs to happen. Otherwise, R allocates a label Lr and creates a new label swap for Lr from the label swap(s) from the forwarding state for client downstream , omitting the swap on interface Q for node D. This allows client upstream traffic to follow the client downstream tree down to other node(s) (i.e. servers) except to the node from which R received the server downstream label map . Brockners Expires March 18, 2008 [Page 16] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 Root node R checks whether it has forwarding state for server upstream . If so node R will update the forwarding state(s) for server upstream to include the newly added forwarding state for server downstream, i.e. to include , omitting the swap on interface Q for node D. This allows server upstream traffic to follow the server downstream tree down to other node(s) (i.e. clients). Root node R determines the downstream LSR D as per the procedures described in [7], and sends a client upstream label map to its upstream LSR U for , where L is the label it had previously advertised to U for . Client node Z expects the upstream router U to respond by sending a downstream label release for L and a client upstream label withdraw to remove Lu from the upstream state. Node Z will remove label Lu from its upstream state and send a label release message with label Lu to U. 2.3.7.2. HD-MP2MP Server operation If a server node Z discovers that it is no longer a server it SHOULD send a client downstream label withdraw to its upstream LSR U for , where L is the label it had previously advertised to U for . Server node Z expects the upstream router U to respond by sending a downstream label release for L and a server upstream label withdraw to remove Lu from the upstream state. Node Z will remove Brockners Expires March 18, 2008 [Page 17] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 label Lu from its upstream state and send a label release message with label Lu to U. 2.3.7.3. HD-MP2MP transit node operation Leaf label withdraw procedures are similar to those for MP2MP operation, described in [7]. If a transit node Z receives a server downstream label withdraw message from node D, it deletes label L from its forwarding state for server downstream and from all its upstream states for . Node Z sends a label release message with label L to D. Since D is no longer part of the server downstream forwarding state, Z cleans up the forwarding state upstream and sends a client upstream label withdraw for results in no state remaining for then Z propagates the server downstream label withdraw to its upstream node U for . Similarly, if a transit node Z receives a client downstream label withdraw message from node D, it deletes label L from its forwarding state for client downstream and from all its upstream states for . Node Z sends a label release message with label L to D. Since D is no longer part of the client downstream forwarding state, Z cleans up the forwarding state upstream and sends a server upstream label withdraw for results in no state remaining for then Z propagates the client downstream label withdraw to its upstream node U for . 2.3.7.4. HD-MP2MP root node operation The procedure when the root node of a MP2MP LSP receives a label withdraw message is the same as for transit nodes, except that the root node would not propagate the Label Withdraw upstream (as it has no upstream). 2.3.7.5. HD-MP2MP Upstream LSR Change The procedure for changing the upstream LSR is the same as documented in [7], except it is applied to HD-MP2MP FECs using the procedures described in the earlier sections of this document. Brockners Expires March 18, 2008 [Page 18] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 3. Security Considerations The same security considerations apply as for the base LDP specification, as described in [1]. 4. IANA Considerations This document leverages the new name space (the LDP MP Opaque Value Element type) introduced in [7] that is to be managed by IANA. 5. References 5.1. Normative References [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [4] Roux, J., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", draft-leroux-mpls-mp-ldp- reqs-03 (work in progress), February 2006. [5] Aggarwal, R., "MPLS Upstream Label Assignment and Context Specific Label Space", draft-raggarwa-mpls-upstream-label-01 (work in progress), October 2005. [6] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for RSVP-TE and LDP", draft-raggarwa-mpls-rsvp-ldp-upstream-00 (work in progress), July 2005. [7] Minei, I., "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-03 (work in progress), July 2007. [8] Metro Ethernet Forum, Technical Specification MEF 10.1, "Ethernet Services Attributes Phase 2", November 2006. 5.2. Informative References [9] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. Brockners Expires March 18, 2008 [Page 19] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 [10] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875, May 2007. [11] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-05 (work in progress), July 2007. Author's Addresses Frank Brockners Cisco Systems, Inc. Hansaallee 249 40549 Duesseldorf Germany Email: fbrockne@cisco.com Ijsbrand Wijnands Cisco Systems, Inc. Pegasus Parc, De Kleetlaan 6a 1831 Diegem Belgium Email: iwijnand@cisco.com Ali Sajassi Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of Brockners Expires March 18, 2008 [Page 20] Internet-Draft Half-Duplex Multipoint LSPs with LDP September 2007 such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Brockners Expires March 18, 2008 [Page 21]