CCAMP Working Group D. Papadimitriou (Alcatel) Internet Draft D. Brungard (ATT) Expiration Date: December 2004 M. Vigoureux (Alcatel) A. Ayyangar (Juniper) June 2004 Generalized MPLS (GMPLS) RSVP-TE Signaling in support of Layer-2 Label Switched Paths (L2 LSP) draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 Abstract Most efforts on Generalized MPLS (GMPLS) have been focused on environments covering Circuit oriented LSPs (Sonet/SDH, OTH, etc.). There is minimal documentation on GMPLS support of Layer-2 Label Switched Paths (L2 LSPs), e.g. native Ethernet LSPs, Asynchronous Transfer Mode (ATM) LSPs and Frame Relay (FR) LSPs. This document details GMPLS capabilities for supporting L2 LSPs in several network environments including overlays. As such, it provides a reference detailing the applicability of GMPLS for Layer- 2 switching environments in support of various deployment scenarios, including the integrated (e.g. multi LSP-region networks), the augmented/peer and the overlay model (e.g. Generalized VPN (GVPN) and user-network interfaces (GMPLS UNI)). D.Papadimitriou et al. - Expires December 2004 1 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 1. 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. In addition the reader is assumed to be familiar with the terms and concepts developed in [GMPLS-ARCH], [RFC3471], [RFC3473], [RFC3477], and [GMPLS-UNI], [GMPLS-ENNI] as well as [HIER] and [BUNDLE]. The following abbreviations are used in this document: CN: Core node DLCI: Data Link Connection Identifier EN: Edge node ICN: Ingress core node ECN: Egress core node FA: Forwarding Adjacency FR: Frame Relay FSC: Fiber-Switch Capable HOVC: Higher order virtual container ISC: Interface Switching Capability L2-LSP: Layer-2 Label Switched Path L2SC: Layer-2 Switch Capable LOVC: Lower order virtual container LSC: Lambda Switch Capable PSC: Packet Switch Capable OTH: Optical transport hierarchy SDH: Synchronous digital hierarchy. SONET: Synchronous Optical Network. TDM: Time-Division Multiplex VCI: Virtual Channel Identifier VPI: Virtual Path Identifier 2. Introduction Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to support four new classes of interfaces Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC) in addition to Packet Switch Capable (PSC) already supported by MPLS. All these interface classes have been considered in [GMPLS-ARCH], [GMPLS-RTG] and [RFC3471]. However, most of the efforts have been concentrated in facilitating the realization of seamless control integration of IP/MPLS networks with SONET/SDH (see [T1.105]/[G.707]) or OTH (see [G.709]) transport networks. The integration of packet and circuit switching technologies under a unified GMPLS control plane provides an homogeneous control management approach for both provisioning resources and recovery techniques (including protection and re- routing). D.Papadimitriou et al. - Expires December 2004 2 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 While being introduced in [GMPLS-ARCH], [GMPLS-RTG] and [RFC3471], the GMPLS capability to control L2SC TE links and L2 LSPs has received very little attention. [RFC3471] defines the Ethernet encoding types (i.e. the encoding of the LSP being requested) and Layer-2 as switching capability (i.e. the type of switching to be performed on a particular link). In this document, a L2 LSP is defined as a LSP being established between intermediate L2SC interfaces. These interfaces are defined as being capable of recognizing frame/cell boundaries and can switch data based on the content of the frame/cell header (example: interfaces on Ethernet switches that switch data based on the content of the MAC header). The motivation for considering GMPLS control of L2 LSPs can be summarized as follows: - it automates the provisioning of transparent LAN services. Today, the delivery of such services can not be automated due to the control plane/topology driven nature of GMPLS that precludes the automated triggering of the server layer LSP from an incoming data flow. - it facilitates the transport of Ethernet flows without introducing additional intermediate packet layer LSPs that require themselves manual provisioning actions. - it delivers control plane driven recovery capabilities for a range of technologies (e.g. Ethernet) making classically usage of mechanisms adapted only for environments where these data plane technologies had been initially introduced. For instance, Ethernet Spanning Tree Protocol is less suitable in meshed environments where control plane driven fast recovery is required and available - it simplifies the carrier network operations by avoiding dedicated control protocols for managing Ethernet environments that are not adapted for large scale environments and for which an IP-based protocol counter-part exists (e.g. OSPF). - the use of an IP based addressing scheme elevates the scaling issues generated by the non-hierarchical MAC addressing scheme. This capability allows constructing large scale networks taking advantage of the IP addressing properties. - it delivers an homogeneous set of signaling mechanisms for controlling L2 technologies for which integration in common infrastructure is made difficult due to their particularities (e.g. ATM and FR). 3. Context The reference network considered (but not restricted to) in this document is provided in [GMPLS-UNI], [GMPLS-ENNI] and [RFC3473]. 3.1 GMPLS UNI This network is constituted by a core network including core-nodes (CN) surrounded by edge nodes (EN) that form the overlay networks. In addition, the present document assumes the Traffic Engineering (TE) links inter-connecting the edge and the core nodes are of type D.Papadimitriou et al. - Expires December 2004 3 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 [X,L2SC], where X is any ISC whose switched payload can be carried over L2SC TE links. Within the network, the links interconnecting the core nodes can be either [L2SC,L2SC] or any other technology that can carry Layer-2 Ethernet payload, in particular [TDM,TDM] and [LSC,LSC]. Note also that in the first case, the EN-CN interface defines an LSP region boundary (see [HIER]). In the second case, this boundary may be found within the network. As defined in [HIER], a (data plane) switching layer is mapped to a (control plane) LSP region. Following this approach, TE links have been extended to non adjacent nodes by the introduction of Forwarding Adjacency (FA). Using this concept, a node may (under the control of its local policy configuration) advertise an LSP as a TE link into the same IGP routing instance as the one that induces this LSP. Such a link is referred to as a Forwarding Adjacency (FA) and the corresponding LSP to a Forwarding Adjacency LSP (FA-LSP). Since the advertised entity appears as a TE link, both end-point nodes of the FA-LSP must belong to the same OSPF area/IS-IS level. Afterwards, OSPF/IS-IS floods the link-state information about FAs just as it floods the information about any other TE link. This allows other nodes to use FAs as any other TE links for path computation purposes. 3.2 GMPLS E-NNI When two core networks (1 and 2) are interconnected by two core nodes (CN1 and CN2), they define an external network-network interface, as illustrated by the following (simplified) topology: B---C F---G / \ / \ --A 1 CN1---CN2 2 H-- \ / \ / E---D J---I In this topology, [A,B], [A,E] and their network 2 counter part are [L2SC,Y] TE links. Then, the first possibility is that [C,CN1], [D,CN1] TE links and their network 2 counter part are [Y,L2SC] TE Links, and [CN1,CN2] is a [L2SC,L2SC] TE link. Therefore, the L2 LSP that can be setup between node A (ingress) and node H (egress) may be constituted by two FA LSPs (the first between A and CN1 and the second between CN2 and H) interconnected by the [L2SC,L2SC] TE link defined at the E-NNI. The other possibility is that the [CN1,CN2] TE link is not a [L2SC,L2SC] TE link. For example, this could be a multi-AS transport scenario where [CN1,CN2] TE link cannot terminate the L2 LSP. In this case, CN1 and CN2 would only be transporting the L2 LSP from A to H on top of some other LSP. So, the TE link between [CN1,CN2] would then have to be [Y,Y] in which case there would be a single FA-LSP from A to H. D.Papadimitriou et al. - Expires December 2004 4 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 Applicability of GMPLS RSVP-TE signaling [RFC-3473] at the E-NNI is detailed in [GMPLS-ENNI]. 3.3 GMPLS Signaling Channel For nodes inter-connected by point-to-point native L2 interfaces, the signaling channel may be out-of-band or in-band. In the latter case, several implementation choices are possible for the GMPLS signaling channel: 1) specific Ethertype that allows discrimination between data and control traffic (that may be directed towards a dedicated destination MAC address), 2) dedicated VLAN ID, VPI/VCI (see [RFC3035], Section 7) or DLCI (see [RFC3034], Section 6) for the control traffic, and 3) use of a dedicated destination MAC address for reaching the peering GMPLS controller. Nevertheless, the signaling transport implementation MUST be strictly independent of the signaling transport mechanism used between peering GMPLS nodes. 4. Addressing Addressing follows the rules defined in [GMPLS-UNI] and [GMPLS- ENNI]. The SESSION and SENDER_TEMPLATE/FILTER_SPEC objects are end- to-end significant i.e. a single end-to-end RSVP session is defined (in compliance with the RSVP paradigm). 5. Signaling L2 LSP setup, notification, graceful and non-graceful deletion procedures follow [RFC3471], [RFC3473], [GMPLS-UNI] and [GMPLS- ENNI]. Signaling mechanisms applies to both uni- and bi-directional L2 LSP. Translation of the L2 LSP request at the edge CN can make use of one of the following method: 1) direct end-to-end LSP [RFC3473], 2) LSP splicing [RFC3473] and stitching, 3) LSP nesting into a FA-LSP [HIER]. Note that techniques for automated LSP stitching are described in [MPLS-IRN]. Also, in the overlay context, L2 LSPs nesting into a FA-LSP can be used when the ingress/egress edge CN provides (flow) multiplexing capabilities. 5.1 L2 Generalized Label Request The Generalized Label Request is defined in [RFC3471], Section 3.1. The different LSP Encoding Type and Switching Type (of the GENERALIZED_LABEL REQUEST object) that can be used for requesting L2 LSP label is detailed in Table 1. Value LSP Encoding type Value Switching Type ----- ----------------- ----- -------- 2 Ethernet 51 L2SC 14 (new) ATM 51 L2SC D.Papadimitriou et al. - Expires December 2004 5 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 15 (new) Frame-Relay 51 L2SC Table 1: LSP Encoding Type and Switching Type code-points for Ethernet, ATM and FR LSPs For the Generalized PID (G-PID) that identifies the payload carried by an LSP, standard Ethertype values are used for Ethernet LSPs. 5.2 L2 SENDER_TSPEC and FLOWSPEC New L2 SENDER_TSPEC and FLOWSPEC objects are introduced to describe bandwidth and delay/jitter characteristics for the L2 LSP as well as any such L2 traffic specific characteristics. As per [RFC3471], GMPLS allows the inclusion of technology specific parameters in signaling. The intent is for all technology specific parameters to be carried, when using RSVP-TE, in the SENDER_TSPEC and other related objects. So new L2 SENDER_TSPEC and FLOWSPEC objects are defined as follows. These traffic parameters MUST be used when L2SC is specified in the LSP Switching Type field of a Generalized Label Request (see [RFC3471]) and the LSP encoding type is Ethernet, ATM or Frame-Relay. The TLVs in the traffic parameters are optional. 5.2.1 L2 SENDER_TSPEC object The L2 SENDER_SPEC object (Class-Num = 12, Class-Type = 6) has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (12)| C-Type (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Granularity | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Switching Granularity (SG): 16 bits This field indicates the type of L2 link that comprises the requested LSP. The permitted L2 Link Type values: Value Switching Granularity ----- ------------------------ 1 Ethernet Port 2 Ethernet VLAN 3 ATM Port D.Papadimitriou et al. - Expires December 2004 6 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 4 ATM VP Bundle 5 ATM VP 6 ATM VC 7 Frame Relay Port 8 Frame Relay DLCI Value 0 is reserved. Values 128 through 255 are reserved for vendor specific usage. MTU: 16 bits This is a two-octet value indicating the MTU in octets TLV: The L2 SENDER_TSPEC object MUST include at least one and MAY include more than one TLV. Each TLV has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 16 bits Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned. Type: 16 bits Indicates QoS type of the traffic. Defined values are: Type Length Format Description -------------------------------------------------- 1 20 See below L2_QoS Types 128 through 255 are reserved for vendor specific TLVs. Type 1 TLV (L2 QoS) has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Class | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth (32-bit IEEE floating point number) | D.Papadimitriou et al. - Expires December 2004 7 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Jitter (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Traffic Class: 8 bits Identifies the traffic class, default value is 0x0001. Value 0x0000 is reserved. Reserved: 24 bits These bits SHOULD be set to zero when sent and MUST be ignored when received. Bandwidth: 32 bits The requested bandwidth for the L2 LSP. The unit is bytes per second. For instance, a 1Gbps Ethernet LSP will have a value of 0x4CEE6B28. Jitter: 32 bits Indicates the maximum acceptable jitter (in microseconds) for this LSP. If unspecified, this value is set to 0x00000000. Delay: 32 bits Indicates the maximum acceptable delay (in microseconds) for this LSP. If unspecified, this value is set to 0x00000000. 5.2.2 L2 FLOWSPEC object The L2 FLOWSPEC object (Class-Num = 12, Class-Type = 6) has the same format as the L2 SENDER_TSPEC object. 5.2.3 Processing The L2 SENDER_TSPEC object carries the traffic specification generated by RSVP session sender. The L2 SENDER_TSPEC object SHOULD be forwarded unchanged and delivered to both intermediate and egress nodes and MAY be updated on a per-hop basis by adding or removing TLVs. The L2 FLOWSPEC object carries reservation request information generated by receivers. As any FLOWSPEC object, the information content of the L2 FLOWSPEC object flows upstream towards ingress node. For a particular sender in a RSVP session the contents of the FLOWSPEC object received in a Resv message SHOULD be identical 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 D.Papadimitriou et al. - Expires December 2004 8 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. Intermediate and egress nodes MUST verify that the node itself and the interfaces on which the LSP will be established can support the requested Switching Granularity, MTU and values included in sub- object TLVs. For instance, intermediate and egress nodes processing MUST ensure they do not reach the delay or the jitter maximum acceptable value as indicated in the corresponding TLV. 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]). In addition, if the MTU field is received with a value smaller than the minimum transfer unit size of the L2 specific technology (e.g. 46 bytes for Ethernet, 38 bytes for IEEE 802.3), the node MUST generate a PathErr message with a "Traffic Control Error/ Bad Tspec value" indication (see [RFC2205]). There is no Adspec associated with the L2 SENDER_TSPEC. Either the Adspec is omitted or an Int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment is used, see [RFC2210]. 5.3 L2 Label L2 LABEL object follows the generic rules of the GENERALIZED_LABEL object (Class-Num = 16) defined in [RFC3471] for the C-Type 2. This is a 32-bit label value that allows the sending and receiving node performing the link local operations for the requested L2 LSP. The interpretation of the received label depends on the type of the link over which the label is used. The received label MUST be interpreted according the requestor traffic parameters, i.e. a label by itself does not allow knowing the detailed properties of the L2 LSP being requested (i.e. L2 labels are context sensitive). Table 2 summarizes the L2 labels representation (that can be supported over [X,L2SC], [L2SC,L2SC] and [L2SC,X] TE links) and assigned upon reception of the LSP Encoding and Switching Types: LSP Encoding type Switching Type Label ----------------- -------------- ----------------------------- Ethernet L2SC Port, VLAN ID ATM L2SC Port, VPI, VCI, VP Bundle ID Frame-Relay L2SC Port, DLCI Table 2. L2 Labels Ethernet Port, ATM Port and Frame Relay Port labels are encoded right justified aligned in 32 bits (4 octets). Ethernet VLAN ID labels are encoded with the VLAN ID value (12 bits) right justified in bits 20-31 (and preceding bits must be set to 0). ATM VPI/VCI D.Papadimitriou et al. - Expires December 2004 9 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 labels are encoded per [RFC3036] Section 3.4.2.2. Frame-Relay DLCI label values are encoded per [RFC3036] Section 3.4.2.3. Bi-directional L2 LSPs are indicated by the presence of an upstream label in the Path message. Upstream label assignment follows the format of the UPSTREAM LABEL object and the procedures defined in [RFC3473]. 5.4 Interface Identification Interface identification follows the rules defined in [RFC3473], Section 8.1 and [RFC3477]. 6. Explicit Routing 6.1 EXPLICIT_ROUTE Object (ERO) Processing EXPLICIT ROUTE objects can make use of the subobjects defined in [RFC3209] for numbered interfaces and TE links, [RFC3477] for unnumbered interfaces and TE links and finally [RFC3473] for labels. EXPLICIT ROUTE objects processing MUST follow the procedures defined in [RFC3209], [RFC3473], [RFC3477], and [GMPLS-UNI] and [GMPLS-ENNI] when applicable. 6.2 RECORD_ROUTE Object (RRO) Processing RECORD ROUTE objects can make use of the subobjects defined in [RFC3209] for numbered interfaces, TE links and labels, [RFC3477] for unnumbered interfaces and TE links. RECORD ROUTE objects processing MUST follow the procedures defined in [RFC3209], [RFC3473], [RFC3477], and [GMPLS-UNI], [GMPLS-ENNI] when applicable. 6.3 Explicit Label Control Explicit label control refers to the label identification of the egress TE link. An ingress node may include an ERO for which the last hop includes the node_ID of the egress node and any other sub- objects necessary to uniquely identify the TE link, component link and labels for the requested Ethernet LSP. Note: in the overlay context, when the L-bit is set, this last-hop may be the only hop included in the ERO (see [GMPLS-UNI]). 7. Security considerations In its current version, this memo does not introduce new security consideration from the ones already detailed in [RFC3471] and [RFC3473]. 8. IANA Considerations Two values have to be defined by IANA for this document. D.Papadimitriou et al. - Expires December 2004 10 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 Two RSVP C-Types in registry: http://www.iana.org/assignments/rsvp-parameters - L2 SENDER_TSPEC object: Class = 12, C-Type = 6 (Suggested value) - L2 FLOWSPEC object: Class = 9, C-Type = 6 (Suggested value) IANA is also requested to track the code-point spaces extended and/or updated by this document. That is: - LSP Encoding Type - Generalized PID (G-PID) 9. Acknowledgments The authors would like to acknowledge Emmanuel Dotaro for the fruitful discussions and Mastuura Nobuaki for his useful comments to this document. 10. References 10.1 Normative References [BUNDLE] K.Kompella et al., "Link Bundling in MPLS Traffic Engineering", Internet Draft, Work in Progress, draft- ietf-mpls-bundle-04.txt, July 2002. [GMPLS-ARCH]E.Mannie (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-architecture- 07.txt, May 2003. [GMPLS-UNI] G.Swallow et al., "GMPLS UNI: RSVP Support for the Overlay Model", Internet Draft, Work in Progress, draft- ietf-ccamp-gmpls-overlay-04.txt, April 2004. [GMPLS-RTG] K.Kompella and Y.Rekhter (Editors) et al., "Routing Extensions in Support of Generalized MPLS", Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-routing- 09.txt, October 2003. [HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with Generalized MPLS TE", Internet Draft, Work in Progress, draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002. [RFC2205] R.Braden (Editor) et al., "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] J.Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2961] L.Berger et al., "RSVP Refresh Overhead Reduction D.Papadimitriou et al. - Expires December 2004 11 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 Extensions", RFC 2961, April 2001. [RFC3034] A.Conta et al., "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. [RFC3035] B.Davie et al., "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001. [RFC3036] L.Andersson et al., "LDP Specification", RFC 3036, January 2001. [RFC3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] L.Berger (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) - Signaling Functional Description", RFC 3471, January 2003. [RFC3473] L.Berger (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered Links in Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 10.2 Informative References [MPLS-IRN] A.Ayyangar et al., "Inter-region MPLS Traffic Engineering", Internet Draft, Work in progress, draft- ayyangar-inter-region-te-01.txt, October 2003. 11. Author's addresses Dimitri Papadimitriou (Alcatel) Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel.be Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 420 1573 EMail: dbrungard@att.com D.Papadimitriou et al. - Expires December 2004 12 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 Martin Vigoureux (Alcatel) Route de Nozay, 91461 Marcoussis cedex, France Phone: +33 1 6963 1852 EMail: martin.vigoureux@alcatel.fr Arthi Ayyangar (Juniper) 1194 N.Mathilda Ave Sunnyvale, CA 94089, USA EMail: arthi@juniper.net 12. Intellectual Property Notice 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.1 IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. D.Papadimitriou et al. - Expires December 2004 13 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt June 2004 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, 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. D.Papadimitriou et al. - Expires December 2004 14