Network Working Group R. Aggarwal Internet Draft K. Kompella Expiration Date: April 2006 A. Ayyanger Juniper Networks D. Papadimitriou Alcatel P. Busschbach Lucent N. Sprecher Siemens L. Y. Jie China Unicom October 2005 Setup and Maintenance of Pseudowires using RSVP-TE draft-raggarwa-rsvpte-pw-03.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. 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. Raggarwa, et al. [Page 1] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 Abstract This document describes procedures for using Resource Reservation Protocol-Traffic Engineering (RSVP-TE) for signaling Pseudowires (PWs). One motivation is the signaling of PW QoS. The other is the setup of a multi-hop PW, for example, to span multiple domains. RSVP-TE provides mechanisms for QoS signaling and these can be leveraged for signaling PW QoS. It also provides the ability to signal bi-directional MPLS Label Switched Paths (LSP) with explicit routes. This can be used for signaling multi-hop PWs that require explicit routing. RSVP-TE also provides the ability to establish non- adjacent or targeted signaling sessions. Raggarwa, et al. [Page 2] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 Table of Contents 1 Specification of requirements ......................... 4 2 Terminology ........................................... 4 3 Introduction .......................................... 4 4 Motivation ............................................ 5 4.1 PW QoS ................................................ 5 4.2 Multi-Hop PWs ......................................... 6 4.3 PW Redundancy ......................................... 7 5 Motivation for using RSVP-TE .......................... 7 5.1 QoS Signaling ......................................... 8 5.2 Explicit Routing ...................................... 8 5.3 Sharing QoS Resources between LSPs .................... 8 5.4 Bidirectional Label Allocation ........................ 9 5.5 LSP Hierarchy ......................................... 9 6 Design Overview ....................................... 9 6.1 Mapping RSVP-TE LSPs to PWs ........................... 9 6.2 Non-Adjacent Signaling ................................ 9 6.3 Single-Hop PW Label Signaling ......................... 10 6.4 Asynchronous Signaling and Single Sided Signaling ..... 10 7 Procedures ............................................ 10 7.1 RSVP-TE PW Identification ............................. 10 7.2 Single-Hop PW Setup ................................... 11 7.2.1 PW Signaling using Unidirectional LSPs ................ 11 7.2.2 PW Signaling using Bidirectional LSPs ................. 12 7.3 Single-Hop PW QoS Signaling ........................... 12 7.4 Multi-Hop PW Signaling ................................ 13 7.5 Redundant PWs ......................................... 14 8 OAM Mechanisms ........................................ 14 9 Security Considerations ............................... 15 10 IANA Considerations ................................... 15 11 Acknowledgments ....................................... 15 12 References ............................................ 15 12.1 Normative References .................................. 15 12.2 Informative References ................................ 16 13 Author Information .................................... 16 14 Intellectual Property Statement ....................... 17 15 Full Copyright Statement .............................. 18 Raggarwa, et al. [Page 3] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 1. Specification of requirements 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 [RFC2119]. 2. Terminology This document follows the terminology in [RFC3985] and [PWMH-REQ]. The following terminology is specified here. Single-hop PW: A PW that comprises only two PW demultiplexor alloca- tion nodes. Multi-hop PW: A PW that comprises more than two PW demultiplexor allocation nodes. In addition the reader is expected to be familiar with the terminol- ogy and mechanisms described in [RFC3209] and [RFC3473]. 3. Introduction A PW is a mechanism that carries the essential elements of an emu- lated service from one PE to another over a PSN [RFC3985]. A point to point PW is bi-directional. A "PW header", consisting of a (PW) demultiplexor field is prepended to the encapsulated PDU. The result- ing packet is then transmitted to the remote endpoint of the PW over one or more "PSN tunnels"; this may require an additional header to be prepended to the packet. When the packet arrives at the remote endpoint of the PW, the PW demultiplexor is what enables the receiver to identify the particular PW on which the packet has arrived. In the case that it is not desirable to establish a single PSN tunnel between the two endpoints of a PW or the PW needs to be explicitly routed across multiple hops for QoS provisioning or administrative reasons, a multi-hop PW is needed [PWMH-REQ]. In this case each PW hop uses a separate PSN tunnel. The PW demultiplexor may have to be changed at each hop. An example scenario where a multi-hop PW is needed is one that spans multiple domains, where edge-to-edge PSNs may not be possible for scaling or administrative reasons. Each domain may have a different PSN technology. [LDP-PW] describes procedures for using the Label Distribution Proto- col [LDP] for the setup and maintenance of single-hop PWs. The PW demultiplexor field is a MPLS label, and PW demultiplexor signaling performs label exchange between two PEs. Raggarwa, et al. [Page 4] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 If one wants to signal multi-hop, explicitly routed PWs and/or PWs with QoS characteristics, new mechanisms are required [PWMH-REQ]. The protocol architecture of RSVP-TE is an appropriate fit for these applications (as well as demultiplexor exchange). This is because RSVP-TE [RFC3209] has the mechanisms for signaling QoS and for explicit routing. RSVP-TE extensions described in [RFC3473] also pro- vide mechanisms to setup bi-directional LSPs. It also has mechanisms that can be used for PW identification, setup and maintenance. Multi-hop PWs traverse multiple PSN tunnels and the PSN tunnels may be setup using Generalized MPLS (GMPLS) signaling [RFC3473]. Hence another useful applicability scope of the proposed approach is PWs over MPLS PSNs supporting GMPLS RSVP-TE [RFC 3473] as well as other switching technologies within the scope of GMPLS. This document describes procedures for using RSVP-TE for PW signaling motivated by the goals mentioned in the previous paragraph. This doc- ument assumes familiarity with [RFC3209] and [RFC3473]. 4. Motivation This section describes the motivations behind this document. Some of these motivations are also discussed in [PWMH-REQ]. 4.1. PW QoS A PW is a mechanism that carries the essential elements of an emu- lated service from one PE to another over a PSN [RFC3985]. The emu- lated service is offered by a SP to a customer over an attachment circuit (AC). Hence a PW can also be considered as a mechanism that is used to inter-connect two ACs over a PSN. A Service Level Agree- ment (SLA) is often associated with such an emulated service. Packet loss and delay bounds in a given time interval are examples of a SLA that a SP may provide to a customer. Such a SLS translates into QoS, for example bandwidth, that is associated with the PW. Providing this QoS on the PW requires the following: a) Assigning QoS parameters to each AC in conformance with the SLA. These QoS parameters get associated with the PW that is used to carry traffic from the AC. b) Policing on the AC on both the PEs based on the QoS parameters c) Call admission control (CAC) of the PW into the PSN tunnel which is used to transmit the PW packets. This assumes that the PSN tunnel can be signaled with QoS. To achieve this RSVP-TE can be used as the PSN tunnel signaling protocol. The procedures described above require that the two ends of a PW be Raggarwa, et al. [Page 5] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 associated with the same QoS parameters. In current PW deployments this is achieved using configuration. However it is desirable to sig- nal this QoS information from one end of the PW to another. This is beneficial for PW operation and management. This is also desirable for multi-hop PWs described in the next section. It should also be possible to change the QoS characteristics of a PW without any packet loss on the PW. 4.2. Multi-Hop PWs A PW by default inter-connects the ACs between two PEs that exchange the PW demultiplexor. These two PEs are the PW demultiplexor alloca- tion nodes and are connected by a single PSN domain. This is a sin- gle-hop PW. A multi-hop PW inter-connects the ACs between two PEs across multiple PSN domains [MHPW-REQ]. Hence a multi-hop PW refers to a PW that comprises more than two PW demultiplexor allocation nodes. One way to conceptualize this is as multiple PWs that are stitched together and are still part of the same end to end PW. A multi-hop PW is needed when it is not desirable to establish a sin- gle PSN tunnel between the two endpoints of a PW or the PW needs to be explicitly routed across multiple hops for QoS provisioning or administrative reasons. [PWMH-REQ]. The PW demultiplexor allocation nodes along a multi-hop PW need to be explicitly specified. This requires a PW explicit route. Some of the hops in the explicit route may be strict while others may be loose. A practical application of a multi-hop PWs is the setup of a PW across multiple domains. For instance across multiple IGP domains or ASs or domains with different PSN technologies. Consider an inter-AS PW that is set up by PE1 in AS1 to PE2 in AS2. It may be desirable to control the exit point of this PW in AS1 and select the entry point of the PW in AS2. Traffic accounting per PW is one motivation for this. Another motivation is security. Yet another motivation is to avoid setting up a full mesh of end-to-end PWs between ASs. The inter-AS PW may be explicitly routed through ASBR1 in AS1, which is PE1's next-hop to reach PE2. ASBR1 in turn may explicitly route the PW through ASBR2 which is its next-hop to reach PE2. ASBR2 will complete the PW signaling. In this case there is one signaling protcol adjacency to signal the PW between PE1 and ASBR1; one between ASBR1 and ASBR2; and one between ASBR2 and PE2. PE1, ASBR1, ASBR2 and PE2 are PW demultiplexor allocation points. Raggarwa, et al. [Page 6] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 4.3. PW Redundancy It may be desirable to backup one PW with another. A CE may be dual homed to two different PEs. Or a CE may be dual homed to a PE using two different ACs. One AC is the primary while the other is the backup. Both these ACs are attached to the same remote AC. The remote PE can setup a PW for each of the two local ACs. One of these PWs is the primary PW while the other is the backup PW. The backup PW is setup apriori and is in standby mode incase the primary PW fails. The primary and backup PWs may also be multi-hop PWs and may be signaled with QoS. The multi-hop primary and backup PWs may be routed over different PW demultiplexor allocation points. For example, it may be desired that they enter an AS via different ASBRs to avoid a single point of failure. If they pass through the same PW demultiplexor points QoS double booking must be avoided between these two PWs, when they are transported over the same tunnel, as only one of them is active at a given time. It should also be possible to use fast protection mechanisms for the PW and for the tunnel used to transport the PW. These two mechanisms can co-exist. 5. Motivation for using RSVP-TE This section describes why RSVP-TE is an appropriate fit for address- ing the motivations described in section 3. RSVP-TE is used to setup explicitly routed Label Switched Paths (LSPs). Multiple LSPs may belong to the same tunnel. A LSP is iden- tified using a SESSION object and a SENDER_TEMPLATE object. The SES- SION object carries a tunnel identifier (TUNNEL_ID) to identify a tunnel. It also carries the tunnel destination. The SENDER_TEMPLATE carries the source of the tunnel and a LSP_ID to identify a specific LSP. An ingress LSR is defined as the LSR that originates the LSP. An egress LSR is defined as the endpoint of the LSP. LSP setup consists of signaling in the forward and the reverse direction. The ingress LSR originates a Path message to the egress LSR and the egress LSR responds with a Resv message. The LSP is successfully established when the ingress LSR receives the Resv message. [RFC3209] defines the setup of unidirectional LSPs. [RFC3473] extends this to bidirectional LSPs. Hence a Path message sent by the ingress LSR can be used to signal a bidirectional LSP. RSVP-TE signaling messages can be exchanged between adjacent or non- adjacent nodes [LSP-HIER]. RSVP-TE siginaling messages between non- adjacent nodes are essentially targeted signaling messages. Raggarwa, et al. [Page 7] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 The specific building blocks of RSVP-TE that make it an appropriate fit for solving the problems addressed by this document are discussed below. In the following discussion a LSP may bea unidirectional LSP or a bidirectional LSP. 5.1. QoS Signaling RSVP-TE is designed to setup LSPs that are signaled with QoS Parame- ters. These parameters may include diffserv parameters. The Path mes- sage carries the QoS specification that is requested by the ingress LSR in the SENDER_TSPEC object. The SENDER_TSPEC object carries the traffic specification generated by RSVP session sender i.e the ingress LSR. The SENDER_TSPEC object is forwarded unchanged and delivered to both transit and egress LSRs. The FLOWSPEC object car- ries reservation request information generated by receivers i.e. the QoS desired by egress LSRs. The information content of the FLOWSPEC object flows upstream towards the ingress LSR. Each transit LSR uses the FLOWSPEC object for CAC and to setup the LSP QoS in hardware in the direction from the ingress LSR to the egress LSR and also in the reverse direction. This mechanism can be used for signaling PW QoS. Differentiated (Diffserv) Services is supported using procedures defined in [RFC3270] and Diffserv aware MPLS TE (DS-TE) QoS signaling is sup- ported as defined in [RFC4124]. 5.2. Explicit Routing As discussed in section 3 one of the requirements of signaling multi- hop PWs is the specification of an explicit route. RSVP-TE allows a LSP to be setup using an EXPLICIT_ROUTE_OBJECT (ERO). An ERO contains a sequence of hops that the LSP must be routed through. The semantics allow an intermediate hop to insert hops in the ERO. 5.3. Sharing QoS Resources between LSPs RSVP-TE allows multiple LSPs to belong to the same tunnel. These LSPs can be signaled such that they share QoS resources with each other between common hops. This can be used for PW redundancy. A backup PW can be setup to share QoS resources with the primary PW between com- mon hops, when the primary and backup PWs are transported over the same tunnel. It can also be used for modifying the QoS of a PW using RSVP-TE make-before-break [RFC3209]. Raggarwa, et al. [Page 8] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 5.4. Bidirectional Label Allocation RSVP-TE [RFC3209] sets up unidirectional LSPs and provides the mecha- nism to signal the downstream label in the Resv message. [RFC3473] extends this to signal bidirectional LSPs allowing the upstream label to be carried in the Path message. A PW is bidirectional and RSVP-TE bidirectional label allocation mechanisms MAY be used for PW label exchange with a single signaling session. 5.5. LSP Hierarchy [RFC3209] supports the notion of LSP hierarchy. A LSP can be adver- tised as a Forwarding Adjacency (FA) to rest of the domain, allowing other nodes in the domain to use the FA LSP as a link for computing traffic engineered paths for other LSPs [LSP-HIER]. One or more LSPs (inner LSPs) can be carried over the FA LSP (outer LSP). When RSVP-TE is used for PW signaling and PSN tunnels are also setup using RSVP- TE, the PSN tunnels may be advertised as FA LSPs. If this is the case the multi-hop PW origination point can use the FA LSPs to traf- fic engineer the path of the multi-hop PW, which is the inner LSP. 6. Design Overview This section gives an overview of how RSVP-TE can be used for addressing the motivations described in section 3. 6.1. Mapping RSVP-TE LSPs to PWs This document maps a PW to either two unidirectiona LSPs, one in each direction between the ingress and egress LSRs or a bidirectional LSP. A PW is identified by the SESSION object, SENDER_TEMPLATE object and a new PW TLV that is carried in a new SENDER_TSPEC C-Type. The PW TLV is discussed in section 6.1. Mapping a PW to a LSP allows the use of QoS signaling, explicit and record routing, resource sharing as well as as any other RSVP capability that can be mapped to an LSP 6.2. Non-Adjacent Signaling Non-adjacent signaling between PW demultiplexor allocation points is used for signaling PWs with RSVP-TE. This allows RSVP-TE signaling messages to be exchanged between hops that are not directly adjacent [LSP-HIER]. Targeted RSVP-TE signaling messages are signaled using procedures specified in [LSP-HIER]. This implies that RSVP-TE mes- sages used to setup the MS-PW are completely transparent to each PSN Raggarwa, et al. [Page 9] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 i.e. they are not intercepted and processed by any of the intermedi- ate nodes (as the IP header of the MS-PW RSVP-TE message MUST NOT have the Router Alert option set). 6.3. Single-Hop PW Label Signaling This document proposes that RSVP-TE can also be used for signaling single-hop PW demultiplexors. This MAY be done using bidirectional label allocation mechanisms. It is conceivable that a different pro- tocol can be used for signaling single-hop PW demultiplexors when RSVP-TE is used for multi-hop PW signaling or PW QoS signaling. LDP [LDP-PW] can be used for this purpose. This may be useful if a net- work has currently deployed LDP for single-hop PW setup with or with- out QoS and wishes to setup multi-hop PWs. In that case a PW associ- ation is needed between LDP and RSVP-TE. This is for further study. 6.4. Asynchronous Signaling and Single Sided Signaling There are two models of signaling RSVP-TE multi-hop PWs. In the first model both the ends of the PW signal the PW using unidirectional LSPs. Thus both ends exchange asynchronous signaling messages. Both unidirectional LSPs are signaled using the same PW TLV. Each end MUST use this PW TLV to associate the unidirectional LSPs with each other and complete the PW setup. In the second model RSVP-TE PW sessions are originated by one end of the PW using a bidirectional LSP. The other end of the PW completes the signaling by responding to this request. This follows the single sided signaling concept that has been proposed earlier in [LDP-PW]. In this model both the PW ends do not initiate asynchronous signaling messages. It is only one end that initiates the PW setup. Note that the use of bidrectional LSPs for signaling RSVP-TE MH PWs does not imply the use of bidirectional RSVP-TE tunnel LSPs. Unidirectional RSVP-TE tunnel LSPs can be used. 7. Procedures 7.1. RSVP-TE PW Identification A LSP is mapped to a PW. A PW is identified by the SESSION object, the SENDER_TEMPLATE object and a new PSEUDOWIRE TLV (PW TLV) included as part of a new SENDER_TSPEC/FLOWSPEC object. Details of the SENDER_TSPEC/FLOWSPEC object encoding carried in the Path and Resv message, respectively, will be specified in the next revision. The PW TLV identifies the individual PW. It also allows the receiver of the Raggarwa, et al. [Page 10] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 RSVP-TE Path message to realize that the signaled session is being used to setup a PW. This identifier can either be a 32 bit number or it can have generalized semantics. The encoding of this identifier follows that specified in [LDP-PW]. A different TLV type is used for both these cases. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | | ... | +---------------------------------------------------------------+ The PW type, presence of the control word and any other PW specific parameters are signaled in the SENDER_TSPEC. Details will be speci- fied along with the SENDER_TSPEC encoding in the next revision. 7.2. Single-Hop PW Setup This document proposes the use of RSVP-TE for exchanging single-hop PW labels when RSVP-TE is used for addressing the motivations described in Section 3. This is accomplished by using either two uni- directional LSPs and associating them with the PW using PW-TLV or bidirectional label allocation mechanisms. The PW MUST be signaled as a LSP by the ingress of the PW using a non-adjacent i.e. targeted Path message. The remote PE MUST associate PW semantics with the LSP based on the PW parameters carried in the SENDER_TSPEC object includ- ing the PW TLV. The outer label can be the transport LSP label when using MPLS tunnels. It can also be any other PSN tunnel encapsula- tion: eg. IP or GRE. Refresh reduction [RFC2961] SHOULD be used to reduce the refresh and processing overhead of RSVP-TE control messages. 7.2.1. PW Signaling using Unidirectional LSPs Consider that both ends of the MH PW, PE1 and PE2, use asynchronous signaling using unidirectional LSPs. When PE2 receives a Path message for the PW LSP, it MUST respond with a Resv message that carries a PW label allocated by the PE2. If PE2 is unable to allocate a PW label, it MUST return a PathError message as specified in [RFC3209]. If PE2 has not yet generated a PW LSP Path message to PE1, it MUST generate Raggarwa, et al. [Page 11] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 this message. This message MUST carry the same PW ID that was present in the received Path message. Note that this assumes that both ends of the PW are configured with the same PW ID. PE2 MUST add a MPLS route for the PW label, that it allocated and returned in the Resv message in response to the Path message from PE1, with the AC as the next-hop. When PE1 receives the Path message from PE2, it MUST respond with a Resv message. When PE2 receives this Resv message with a PW label in the upstream direction it MUST add a route that is used to map traffic from the AC into the PW. The inner label of the route's next-hop is the PW label (i.e. the upstream label) received from the PE that signaled the PW. 7.2.2. PW Signaling using Bidirectional LSPs Consider that the MH PW is setup using single sided signaling and bidirectional LSPs with PE1 intiating the bidirectional LSP Path mes- sage to PE2. PE2 MUST add a route that is used to map traffic from the AC into the PW. The inner label of the route's next-hop is the PW label (i.e. the upstream label) received from PE1 that signaled the PW. When a Path message containing an upstream PW label is received by PE2, it first verifies that the upstream label is accept- able. If the label is not acceptable, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable PW label value" indication. PE2 then generates a Resv message and sends it to PE1 along with a PW label (i.e. the downstream label). PE2 MUST add a MPLS route fro the PW downstream label, with the AC as next-hop. PE1 completes the PW setup by adding the local AC route and the MPLS PW label route. Contention resolution for bi-directional LSPs follows rules specified in Section 3.2 of [RFC3473]. When a bidirectional LSP is torn down, both upstream and downstream labels are invalidated and it is no longer valid to send data using the associated labels. 7.3. Single-Hop PW QoS Signaling A RSVP-TE LSP is established for the PW between the two PEs using non-adjacent signaling. The PW LSP is signaled with the QoS parame- ters desired by the local PE for the PW. These parameters are carried in the SENDER_TSPEC object in the Path Message and in the FLOWSPEC object in the Resv message. The SENDER_TSPEC object MUST be delivered unchanged to the egress PE. This object also includes the PW TLV used to identify the PW. The egress PE MUST verify that the incoming SENDER_TSPEC QoS parame- ters can be supported for the requested LSP. If the requested Raggarwa, et al. [Page 12] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 value(s) can not be supported, the egress PE MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]). The remote PE responds with a Resv message that contains in the FLOWSPEC object the QoS parameters desired by the remote PE. This value is either the same as the QoS requested in the SENDER_TSPEC or lower. Both the local and the remote PE use the FLOWSPEC for adminis- tering PW QoS. If the objects do not match the PW TLV or the QoS requested parameters are larger, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. QoS signaling mechanisms in RSVP-TE are fairly mature. They have been defined for various QoS service models. Also RSVP-TE [RFC3209] and various extensions to it [RFC3473] describe mechanisms for signaling QoS for different media such as ATM, Frame Relay, optical interfaces etc. Based on the AC being inter-connected, the PW LSP is signaled with an appropriate SENDER_TSPEC/FLOWSPEC object. RSVP-TE make-before-break procedures can be used to modify PW QoS or the PW explicit route without impacting PW traffic. 7.4. Multi-Hop PW Signaling A multi-hop PW that requires explicit routing is signaled using a RSVP-TE LSP with a PW TLV in the SENDER_TSPEC object and an explicit route encoded in the EXPLICIT_ROUTE object. The ingress LSR sends a Path message with the destination address being the multi-hop PW end point. The explicit route specifies the hops that the PW must be routed through. Intermediate nodes may insert hops in the explicit route as the ingress LSR may specify the explicit route partially. PW labels that are used to send data in the direction from the egress LSR to the ingress LSR are allocated by each PW demultiplexor alloca- tion hop and propagated in the Path message, if the LSP is a bidirec- tional LSP. The SENDER_TSPEC object is propagated unchanged to the multi-hop PW endpoint which uses the PW TLV to identify the PW. The egress of the multi-hop PW responds with a Resv message. This message contains the FLOWSPEC object, which is used to administer the QoS at each intermediate node as the Resv message is propagated to the ingress LSR. PW labels that are used to send data in the direction from the ingress LSR to the egress LSR are allocated by each PW demultiplexor allocation hop and propagated in the Resv message. If asynchronus signaling is used, the egress LSR also generates a Path message for traffic in the direction from the egress LSR to the ingress LSR and the ingress LSR responds to this Path message with a Resv message. Raggarwa, et al. [Page 13] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 In addition to the processing of the SENDER_TSPEC and FLOWSPEC object described in Section 6.3 at the ingress and egress LSR, here, inter- mediate PW demultiplexors MUST verify that the node itself and the interfaces on which the LSP will be established can support the requested QoS parameters. If the requested value(s) can not be sup- ported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]). 7.5. Redundant PWs A local PE can signal a redundant PW using the same SESSION object as the primary PW and by varying the LSP-ID in the SENDER_TEMPLATE object. This allows intermediate hops to share QoS between the two. In the case of failure of the primary PW the local PE can try to switch traffic to the backup PW. Note that the procedures described in this document allow a CE to be dual homed to the same PE. Procedures for dual homing a CE to differ- ent PEs will be described in the next revision. 8. OAM Mechanisms Requirements on MH PW OAM are detailed in [MHPW-REQ]. This section details realization of these requirements through the use of Bi- directional Forwarding Detection (BFD) and Virtual Circuit Connection Verification (VCCV). Per [BFD-MPLS], BFD in conjunction with LSP-Ping can be used for scalable MPLS LSP OAM, when the LSP is associated with a RSVP IPv4/IPv6 Session [RSVP-TE]. BFD for MPLS LSPs can be used for MH PWs signaled using RSVP-TE. The recommended method is to use BFD for MPLS using in-band [VCCV] encap- sulation. In this case, the use of BFD is independent from the PSN Tunnel technology. BFD PDUs must be forwarded transparently by S-PEs to allow monitoring of the MH-PW end-to-end. This results in estab- lishing a BFD session from a U-PE to another U-PE for the MH PW. This may have scalability limitations depending on the number of MH PWs. Raggarwa, et al. [Page 14] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 9. Security Considerations Security considerations from [RFC3209] and [RFC3473] apply to this document. 10. IANA Considerations TBD 11. Acknowledgments Thanks to Chaitanya Kodeboyina and Sasha Vainshtein for discussing the ideas presented here. Thanks to Nabil Bitar for his comments. 12. References 12.1. Normative References [RFC3209] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC 3209, December 2001. [RFC3473] L. Berger, Ed.. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions, RFC 3473 January 2003. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3985] "PWE3 Architecture" Bryant, et al., draft-ietf-pwe3-arch-07.txt, March 2003. [PWMH-REQ] "Requirements for inter domain Pseudo-Wires", L. Martini, N. Bitar, M. Bocci [Editors], draft-ietf-pwe3-ms-pw-require- ments-00.txt, Raggarwa, et al. [Page 15] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 [RFC3270] F. L. Faucheur et. al., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270 [RFC4124] F. L. Faucheur [Editor], "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124 12.2. Informative References [BFD-MPLS] R. Aggarwal et. al., "BFD for MPLS LSPs", draft-ietf-bfd- mpls-02.txt [LSP-Ping] K. Kompella et. al., "Detecting MPLS Data Plane Failures", draft-ietf-mpls-lsp-ping-03.txt [VCCV] T. Nadeau, R. Aggarwal, "Pseudo Wire (PW) Virtual Circuit Connection Verification ((VCCV)", draft-ietf-pwe3-vccv-03.txt [LDP] Andersson, L., et al, "LDP Specification", RFC 3036 [LDP-PW] L. Martini et. al.,"Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-08.txt [MPLS-ST] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 13. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Kireeti Kompella Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: kireeti@juniper.net Arthi Ayyangar Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Raggarwa, et al. [Page 16] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 Email: arthi@juniper.net Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Peter Busschbach Lucent Technologies 67 Whippany Road Whippany, NJ 07981 email: busschbach@lucent.com Nurit Sprecher Siemens Communications Seabridge 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@seabridgenetworks.com Liu Yun Jie China Unicom No.133A,XiDan North Street, XiCheng District, BeiJing,100032,P.R.China Eail: liuyj@chinaunicom.com.cn 14. 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 assur- ances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of 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. Raggarwa, et al. [Page 17] Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005 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. 15. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Raggarwa, et al. [Page 18]