Network Working Group Rahul Aggarwal Internet Draft Kireeti Kompella Expiration Date: August 2005 Arthi Ayyangar Juniper Networks Dimitri Papadimitriou Alcatel Peter Busschbach Lucent Nurit Sprecher Siemens Setup and Maintenance of Pseudowires using RSVP-TE draft-raggarwa-rsvpte-pw-01.txt Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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. draft-raggarwa-rsvpte-pw-01.txt [Page 1] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 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. 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 [KEYWORDS]. 1. Terminology This document follows the terminology in [PW-ARCH] and [PWMH-REQ]. The following terminology is specified here. Single-hop PW: A PW that comprises only two PW demultiplexor allocation nodes. Multi-hop PW: A PW that comprises more than two PW demultiplexor allocation nodes. 2. Introduction A PW is a mechanism that carries the essential elements of an emulated service from one PE to another over a PSN [PW-ARCH]. A point to point PW is bi-directional. A "PW header", consisting of a (PW) demultiplexor field is prepended to the encapsulated PDU. The resulting 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 draft-raggarwa-rsvpte-pw-01.txt [Page 2] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 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 Protocol [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. 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 basic demultiplexor exchange). This is because RSVP-TE has the mechanisms for signaling QoS and for explicit routing. RSVP-TE extensions described in [RFC3473] also provide 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 document assumes familiarity with [RFC3209] and [RFC3473]. 3. Motivation This section describes the motivations behind this document. Some of these motivations are also discussed in [PWMH-REQ]. 3.1. PW QoS A PW is a mechanism that carries the essential elements of an emulated service from one PE to another over a PSN [PW-ARCH]. The emulated 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 Agreement (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 draft-raggarwa-rsvpte-pw-01.txt [Page 3] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 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 associated with the same QoS parameters. In current PW deployments this is achieved using configuration. However it is desirable to signal 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. 3.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 allocation nodes and are connected by a single PSN domain. This is a single-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 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. [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 draft-raggarwa-rsvpte-pw-01.txt [Page 4] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 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. 3.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. 4. Motivation for using RSVP-TE This section describes why RSVP-TE is an appropriate fit for addressing 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 identified using a SESSION object and a SENDER_TEMPLATE object. The SESSION 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. draft-raggarwa-rsvpte-pw-01.txt [Page 5] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 [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 signaling messages can be exchanged between adjacent or non- adjacent nodes [LSP-HIER]. 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 refers to a bidirectional LSP. 4.1. QoS Signaling RSVP-TE is designed to setup LSPs that are signaled with QoS Parameters. These parameters may include diffserv parameters. The Path message 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 carries 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. 4.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. 4.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 common 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]. draft-raggarwa-rsvpte-pw-01.txt [Page 6] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 4.4. Bidirectional Label Allocation RSVP-TE [RFC3209] sets up unidirectional LSPs and provides the mechanism 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 will be used for PW label exchange with a single signaling session. 4.5. LSP Hierarchy [RFC3209] has the notion of LSP hierarchy. A LSP can be advertised 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 traffic engineer the path of the multi-hop PW, which is the inner LSP. 5. Design Overview This section gives an overview of how RSVP-TE can be used for addressing the motivations described in section 3. 5.1. Mapping RSVP-TE LSPs to PWs This document maps a PW to 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 5.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. 5.3. Single-Hop PW Label Signaling This document proposes that RSVP-TE can also be used for signaling single-hop PW demultiplexors. This is done using bidirectional label allocation mechanisms. It is conceivable that a different protocol can be used for signaling single-hop PW demultiplexors when RSVP-TE draft-raggarwa-rsvpte-pw-01.txt [Page 7] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 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 network has currently deployed LDP for single-hop PW setup with or without QoS and wishes to setup multi-hop PWs. In that case a PW association is needed between LDP and RSVP-TE. This is for further study. 5.4. Single Sided Signaling RSVP-TE PW sessions are originated by one end of the PW. 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. 6. Procedures 6.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 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. A different TLV type is used for both these cases. The generalized PW TLV will be specified in the next revision. The encoding when the PW TLV contains a 32 bit number follows. 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 TSPEC. Details will be specified in the next revision. draft-raggarwa-rsvpte-pw-01.txt [Page 8] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 6.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 bidirectional label allocation mechanisms. The PW is signaled as a bidirectional LSP by the ingress of the PW using a non-adjacent i.e. targeted Path message. The remote PE can associate PW semantics with the LSP based on the PW parameters carried in the SENDER_TSPEC object including the PW TLV. The remote PE adds 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. When a Path message containing an upstream_PW label is received by the remote PE, the latter first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable PW label value" indication. The remote PE also adds a MPLS route for the received PW label with the AC as the next- hop. The remote PE then generates a Resv message and sends it to the local PE along with a PW label (i.e. the downstream label). The local PE 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]. The SENDER_TSPEC object that carries the traffic specification generated by the RSVP session sender MUST be delivered unchanged to the egress PE. The FLOWSPEC object that carries reservation request information generated by receivers. The information content of the FLOWSPEC object flows upstream towards ingress PE. For a particular sender PE, for a single-hop PW, the contents of the FLOWSPEC object received in a Resv message SHOULD be identical (or lower, for the QoS parameters, see Section 6.3) to the contents of the SENDER_TSPEC object sent in the corresponding Path message. If the objects do not match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. 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. The outer label can be the transport LSP label when using MPLS tunnels. It can also be any other PSN tunnel encapsulation: eg. IP or GRE. Refresh reduction [RFC2961] can be used to reduce the refresh and processing overhead of RSVP-TE control messages. draft-raggarwa-rsvpte-pw-01.txt [Page 9] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 6.3. Single-Hop PW QoS Signaling A RSVP-TE LSP is established for the PW between the two PEs using non-adjacent signaling. This is a bidirectional LSP. This LSP is signaled with the QoS parameters 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 parameters can be supported for the requested LSP. If the requested 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 administering 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. 6.4. Multi-Hop PW Signaling A multi-hop PW that requires explicit routing is signaled using a RSVP-TE bidirectional 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 allocation hop and propagated in the Path message. The SENDER_TSPEC object is propagated unchanged to the draft-raggarwa-rsvpte-pw-01.txt [Page 10] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 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. In addition to the processing of the SENDER_TSPEC and FLOWSPEC object described in Section 6.3 at the ingress and egress LSR, here, intermediate 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 supported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]). 6.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 different PEs will be described in the next revision. 7. Security Considerations Security considerations from [RFC3209] and [RFC3473] apply to this document. 8. IANA Considerations TBD draft-raggarwa-rsvpte-pw-01.txt [Page 11] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 9. Acknowledgments Thanks to Chaitanya Kodeboyina and Sasha Vainshtein for discussing the ideas presented here. 10. References 10.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. [PW-ARCH] "PWE3 Architecture" Bryant, et al., draft-ietf-pwe3-arch-07.txt, March 2003. [PWMH-REQ] "Requirements for inter domain Pseudo-Wires", L. Martini et.al., draft-martini-pwe3-MH-PW-requirements-00.txt 10.2. Informative References [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 draft-raggarwa-rsvpte-pw-01.txt [Page 12] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 [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 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 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 draft-raggarwa-rsvpte-pw-01.txt [Page 13] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 Email: nurit.sprecher@seabridgenetworks.com 11. Intellectual Property 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 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. 12. Full Copyright Statement Copyright (C) The Internet Society (2004). 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, INCLUNG 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. draft-raggarwa-rsvpte-pw-01.txt [Page 14] Internet Draft draft-raggarwa-rsvpte-pw-01.txt February 2005 13. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-raggarwa-rsvpte-pw-01.txt [Page 15]