CCAMP Working Group D. Papadimitriou (Alcatel) Internet Draft D. Brungard (ATT) Expiration Date: April 2005 M. Vigoureux (Alcatel) A. Ayyangar (Juniper) October 2004 Generalized MPLS (GMPLS) RSVP-TE Signaling in support of Layer-2 Label Switched Paths (L2 LSP) draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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, D.Papadimitriou et al. - Expires April 2005 1 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 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)). 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 [RFC3945], [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) capable, 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 D.Papadimitriou et al. - Expires April 2005 2 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 resources and recovery techniques (including protection and re- routing). 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 pre-provisioning actions as network trunks that can not be triggered from external traffic demands. - 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 (at the control plane level). - 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 D.Papadimitriou et al. - Expires April 2005 3 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 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 [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 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 D.Papadimitriou et al. - Expires April 2005 4 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 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. 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] including Graceful Restart upon control channel and node failure, [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 i.e. the tail-end of the incoming LSP is attached to the head-end of the outgoing LSP (see [RFC3471]) 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. D.Papadimitriou et al. - Expires April 2005 5 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 Value LSP Encoding type Value Switching Type ----- ----------------- ----- -------- 2 Ethernet 51 L2SC 14 (new) ATM 51 L2SC 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. 5.2.1 L2 SENDER_TSPEC object The L2 SENDER_TSPEC 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 D.Papadimitriou et al. - Expires April 2005 6 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 ----- ------------------------ 1 Ethernet Port 2 Ethernet VLAN 3 ATM Port 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. Note: the notion of MTU does not apply to ATM LSPs (fixed cell size of 53 bytes) and MUST thus be set to 53. TLV: The L2 SENDER_TSPEC object MUST include at least one (i.e. the Type 1 TLV) and MAY include more than one optional TLV (for which the Type is > 1). Type 1 TLV MAY appear at most once per SENDER_TSPEC object. 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 Defined values are: Type Length Format Description -------------------------------------------------- 1 20 See below L2_QoS D.Papadimitriou et al. - Expires April 2005 7 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 Types 128 through 255 are reserved for vendor specific TLVs. Additional L2 technology specific TLVs MAY be defined in future revision of this document. Type 1 TLV (L2 QoS) Indicates the QoS type of the traffic. This 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Class | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Jitter (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Class: 8 bits Identifies the service class i.e. the tuples that can be constructed using this TLV. Default value is 0x0001. Value range 0x0000 to 0x0008 is reserved as part of this document. 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. D.Papadimitriou et al. - Expires April 2005 8 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 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 and delivered unchanged to both intermediate and egress nodes. 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 "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. 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 specific 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 D.Papadimitriou et al. - Expires April 2005 9 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 ----------------- -------------- ----------------------------- 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 labels are encoded per [RFC3036] Section 3.4.2.2. Frame-Relay DLCI label values are encoded per [RFC3036] Section 3.4.2.3. Note that the VLAN label space should be applicable on per port basis, otherwise the number of LSP per node is limited to 4096. This applies also most likely to ATM and FR nodes. 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 TE links, [RFC3477] for unnumbered 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 TE links and labels, [RFC3477] for unnumbered 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. See [EGRESS-CONTROL] for procedural details. D.Papadimitriou et al. - Expires April 2005 10 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 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 The introduction of layer-2 label switched path, particularly in Ethernet networks may raise some security issues that need to be solved. The solution MUST protect against the traditional following security threats: - Possibility for the network to control the traffic injected by the client in the data plane (BPDU, Multicast, Broadcasts, etc.) or the control plane (using RSVP-TE signaling for setting-up or tearing down the L2 LSPs) - All usual threats brought by IP functionalities (control and data plane) - Entry points induced by the possible coexistence of the two technologies (L2LSPs and usual Broadcast Ethernet mode) Current RSVP security mechanisms [RFC2207], [RFC3097] should also be analyzed/evaluated in the context of L2 LSPs. 7.1 Attacks on the Data Plane This category encompasses attacks on the Data Plane. Attacks on the data plane can be of the following form: - modification of data traffic - insertion of non-authentic data traffic - Denial of Service (DoS) attacks - traffic snooping Introduction of L2 LSP signaling MUST prevent these attacks by offering adequate filters (like ACLs or some new means). L2 LSP SHOULD reduce data plane threats, as the number of network entry points to control is reduced. A L2 LSP is by nature a hermetic tunnel, with a single entry point (head-end LSR). Policing and filtering is required only on the head-end LSR. Moreover, some mechanism MUST be provided at the network edges (on the head-end LSRs), in order to rate limit the amount of traffic that can transit into a given L2 LSP. 7.2 Attacks on the Control Plane There are two threats concerning the control plane. The first one corresponds to the potential initiation of the signaling by the client side. As LSP tunnels MAY be signaled from the client site using RSVP-TE, control of such activity MUST be provided so that it D.Papadimitriou et al. - Expires April 2005 11 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 cannot be used to fail the entire network. Note that this applies generally to any client signaling approach. There MUST be a way to limit, by configuration, the number of TE- LSPs that can be signaled by a particular client, also there must be a way to rate limit RSVP client control plane traffic (mainly refresh interval). Also the operator MUST be able to rate limit, by configuration, the total amount of memory and CPU allocated to the RSVP process on a given LSR, and react appropriately when such bound is reached (see [SHORT]) Another threat with regards to the Control Plane comes from the introduction of IP functions in L2 equipments (such as the handling of multicast and so on). Indeed L2 networks will inherit all security issue of IP networks. 7.3 Security problems induced by the migration If both L2 LSPs and classical Ethernet are used on the same network, then different ranges of VLANs must be considered so that different traffics, with different VLAN semantics do not get mixed for example. 8. IANA Considerations Two values have to be defined by IANA for this document. 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. The author would like to thank Jean-Louis Leroux, Simon Delord and Romain Insler for their contribution on the security section. 10. References D.Papadimitriou et al. - Expires April 2005 12 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 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-ENNI]D.Papadimitriou et al., "Generalized MPLS (GMPLS) RSVP- TE Signalling in support of Automatically Switched Optical Network (ASON)." Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt, July 2004. [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 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. D.Papadimitriou et al. - Expires April 2005 13 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 [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. [RFC3945] E.Mannie (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [SHORT] Le Roux, J.L., Mazeas, J.Y, "Procedure to handle RSVP- TE control resources shortages", Work in progress, draft-leroux-mpls-rsvp-rsc-shortage-00.txt, October 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 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 D.Papadimitriou et al. - Expires April 2005 14 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 EMail: arthi@juniper.net D.Papadimitriou et al. - Expires April 2005 15 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. D.Papadimitriou et al. - Expires April 2005 16 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt October 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 April 2005 17