CCAMP Working Group D. Papadimitriou (Editor) Internet Draft Jaihyung Choi (Editor) Expiration Date: November 2005 June 2005 A Framework for Generalized MPLS (GMPLS) Ethernet draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Most efforts on Generalized MPLS (GMPLS) have been focused on environments covering Circuit oriented LSPs (Sonet/SDH, OTH, etc.) and IP/MPLS Packet switched networks. However, 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 provides a framework for GMPLS in support of L2 LSPs in several network environments, in particular, Ethernet. D.Papadimitriou et al. - Expires November 2005 1 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 1. Contributors This document is the result of the CCAMP Working Group GMPLS for Ethernet design team joint effort. The following are the authors that contributed to the present document: Dimitri Papadimitriou (Alcatel, Team Leader and Editor) dimitri.papadimitriou@alcatel.be Jaihyung Cho (ETRI, Co-Editor) jaihyung@etri.re.kr Loa Andersson (Acreo) loa@pi.se Arthi Ayyangar (Juniper) arthi@juniper.net Deborah Brungard (ATT) dbrungard@att.com Simon Delord (France Telecom) simon.delord@francetelecom.com Avri Doria (ETRI) avri@psg.com Anders Gavler (Acreo) anders.gavler@acreo.se Jean-Louis Le Roux (France Telecom) jeanlouis.leroux@francetelecom.com Tomohiro Otani (KDDI) otani@kddilabs.jp Martin Vigoureux (Alcatel) martin.vigoureux@alcatel.fr 2. 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. 3. Introduction Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] 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. 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]), OTH (see [G.709]) transport networks or Lambda. However, while being introduced in [RFC3945], [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 L2LSP is defined D.Papadimitriou et al. - Expires November 2005 2 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 as a LSP being established between intermediate L2SC interfaces. These interfaces are defined in [RFC3945] 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). Note that there is a difference between GMPLS control of Ethernet switches (as described in this document) and MPLS transport over Ethernet links as described in [RFC3032] or MPLS transport of Ethernet [RFC3916]. In [RFC3032], packets are labeled using MPLS shim headers and these are encapsulated in Ethernet frames targeted at the next IP/MPLS LSR along the path. At the LSRs, the Ethernet header is stripped and forwarding takes place based on the encapsulated MPLS label. In [RFC3916], Ethernet frames are encapsulated and transported over a packet-switched (e.g. MPLS) network. For both [RFC3032] and [RFC3916], forwarding is based on packet headers, whereas GMPLS control of L2LSPs is based on the Layer-2 frame header. 4. Objectives and Rationales Service providers are extending the use of Ethernet beyond LAN networks with the objective to provide more flexible capacity management and simplified network management, as well as reduce capital expenditure for network buildouts. However, Ethernet 802.1 bridges have limited scalability and network security support, and do not provide the traffic engineering (TE) capabilities of (G)MPLS such as DiffServ-TE (DS-TE). It also lacks scalable recovery mechanisms for meshed networks e.g. re-routing. This framework focuses on GMPLS usage with IEEE 802.3 Ethernet networks. The scope of this document not only covers metro-core network but also metro-access and aggregation networks. Motivations for considering GMPLS control of L2 LSPs: - automates the provisioning of Ethernet services such as (virtual) private line and LAN services over GMPLS-capable networks - facilitates the transport of client Ethernet flows without requiring introducing additional intermediate packet layer LSPs, that require themselves pre-provisioning actions as network trunks - delivers a range of control plane driven recovery capabilities. For instance, Ethernet Spanning Tree Protocol is less suitable in meshed environments, whereas GMPLS control plane driven recovery mechanisms are applicable - 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). - uses IP based addressing that removes the scaling issues generated by the non-hierarchical MAC addressing scheme. This GMPLS capability allows constructing large scale, secure networks taking advantage of IP addressing properties (at the control plane level). - delivers a homogeneous set of signaling and TE mechanisms for controlling L2 technologies to ease integration towards a common D.Papadimitriou et al. - Expires November 2005 3 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 L1/L2/L3 control infrastructure capable of supporting various trust models (e.g. overlay, unified) 5. Deployment Scenarios 5.1 Scenario 1: Access/Aggregation Networks ISPs who deployed ATM based ADSL equipment are gradually replacing them for reasons of capacity upgrade and CAPEX/OPEX reduction. While Ethernet access technology facilitates simple installation as well as easy configuration of Internet access with flexible usage demands, some tradeoffs are the difficulties in providing QoS, user authentication, and management. |---RSVP--->| | | |---- RSVP-TE Path ----> | | | <--- RSVP-TE Resv ---| | | |<-- RSVP --> | |<====(L2 LSP Established)====>| |<--RSVP----| | +--------+ +-----------+ / [H1]------| | =| | +-----------+ | Metro [H2]-[L2]-|Ethernet|======|Aggregation|===|Edge Router|---| or Core [H3]------| DSLAM | =| Switch | +-----------+ | Network [H4]-[L2]-| | =| | GMPLS \ +--------+ +-----------+ GMPLS (GMPLS) ==== L2SC Link Figure 1. GMPLS enabled L2SC switches in Aggregation Networks For this scenario, an access aggregation network is a collection of ISP devices that provides connectivity between a user terminal and core network. Fig. 1 shows such a network where the access switch (e.g. DSLAM) and edge router implement GMPLS L2SC capability. The Aggregation switches may be Ethernet 802.1 or GMPLS L2SC capable switches. Note, there can be a number of Ethernet 802.1 switches between the end-hosts (H1 ~ H4) and the Access (e.g. DSLAM) switch, between the access and the aggregation switch, and between the aggregation switch and the edge router. The devices and aggregation network elements may/may not be physically co-located, and different ownership models may be applicable e.g. the access switch and edge router may be owned by the service provider, whereas the aggregation switch is owned by an independent access provider. In Fig 1., a possible signaling scenario would entail an RSVP Path message (RFC2205) initiated from customer premise via an access line to the access switch. Policy can be imposed at the access switch to examine the user's request. This triggers GMPLS RSVP-TE (RFC3473) for L2LSP setup from the access switch towards the edge router. The GMPLS RSVP-TE Path message is processed and forwarded until reaching the edge router that is GMPLS L2SC capable. The GMPLS RSVP-TE message may be forwarded without the aid of link-state routing protocols in the access network (e.g. proxy). The edge router replies with a GMPLS D.Papadimitriou et al. - Expires November 2005 4 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 RSVP-TE Resv message back to the access switch to complete establishment of the L2LSP. As a result, an L2 LSP is established between the access switch and the edge router. The initial RSVP Path message may be tunneled and further processed beyond the edge router. Otherwise, upon L2LSP completion, the access switch replies with a RSVP Resv message to the initial RSVP request. When the customer initiates data transmission, the access switch maps the user flow into the L2 LSP. Mapping procedure is subject to implementation choices, and is out of the scope of this document. 5.2 Scenario 2: Metro/Metro-core Networks A metro-core network is a backbone that provides for Layer 2 and/or Layer 3 connectivity across access and core networks. Currently, in such environments, when an end-to-end "Ethernet connection" is created based on a VLAN tag, their setting on each user port as well as trunk port must be manually configured on each switch as shown in Fig. 2. +------+ +------+ +------+ VLAN 1-+ L2SW | | L2SW | | L2SW +---VLAN1 | +---(VLAN1,2)---+ +---(VLAN1)---+ | VLAN 2-+ #1 | | #2 | | #3 | +---+--+ +---+--+ +---+--+ | | | | (VLAN2) | | | | +---+--+ +---+--+ +---+--+ | L2SW | | L2SW | | L2SW +---VLAN2 | +---------------+ +---(VLAN2)---+ | | #4 | | #5 | | #6 | +------+ +------+ +------+ Fig. 2: End-to-end connection based on VLAN in Ethernet network In addition, the path may be manually selected and may be neither shortest, nor optimal. To solve these issues, GMPLS label control would be used for assigning VLAN tags to Ethernet ports and trunks, so that the "connection" can be established as a VLAN-based label switched path (LSP). The latter may be mapped on a lower layer LSP. GMPLS RSVP-TE is used to support the Ethernet "connection" i.e. L2LSP setup. OSPF-TE/IS-IS TE is used to disseminate TE routing information about ports. Bandwidth of each VLAN "connection" or the bandwidth of each port can be treated as a constraint of CSPF for path computation. GMPLS traffic engineering can be applied, and multiple ownership/trust models (e.g. overlay, peer) may be applied. 5.3 Scenario 3: Unified Network This scenario depicts the integration of packet, Ethernet and circuit switching under a unified GMPLS control plane. In Fig 3, a "PSC LSR" D.Papadimitriou et al. - Expires November 2005 5 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 is a packet based MPLS LSR, "L2SC LSR Ethernet" a GMPLS controlled Ethernet switch, "LSC LSR Lambda" a GMPLS controlled optical switch. In Fig 3, L2/L1 LSP refer to a Layer 2 LSP (L2LSP) over L1 LSP. A L2 LSP B L2/L1 LSP C +-------+ +---------+ +---------+ | PSC | | L2SC | | LSC | | LSR |--------| LSR |---------| LSR |------+ | | |Ethernet | | lambda | | +-------+ +---------+ +---------+ | | L2/L1 LSP +-------+ +---------+ +---------+ | | PSC | | L2SC | | LSC | | | LSR |--------| LSR |---------| LSR |------+ | | |Ethernet | | lambda | +-------+ +---------+ +---------+ F L2 LSP E L2/L1 LSP D Figure 3: Data plane Fig.4 shows the relationships between the control and data plane entities in a GMPLS enabled network where the three data planes are controlled by the same GMPLS control plane instance. +-----------+ +-------------+ +-------------+ | A | | B | | C | | +-------+ | | +---------+ | | +---------+ | | | PSC | |OSPF-TE| | L2SC | |OSPF-TE| | LSC | | | | LSR |<--------->| LSR |<--------->| LSR | | control | | | |RSVP-TE| |Ethernet | |RSVP-TE| | CP | | plane | +-------+ | | +---------+ | | +---------+ | """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" | +-------+ | | | | | | | PSC | | | | | | | | LSR |----+ | | | | IP/MPLS | | | | | | | | | | +-------+ | | | | | | +-----------+ | | | | | .................................................................... | | +---------+ | | | | | | L2SC | | | | +------| LSR |----+ | |Ethernet | |Ethernet | | | | | | +---------+ | | | | +-------------+ | | | .................................................................... | | +---------+ | | | | LSC | | +------| LSR | |lambda | | lambda | | | +---------+ | +-------------+ D.Papadimitriou et al. - Expires November 2005 6 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 Figure 4. Data plane and control plane In this multi-region scheme, aggregation of traffic onto the same LSP is possible. In analogy with having packet coming in to an LER (ingress LSR) with the same Forwarding Equivalence Class (FEC) mapped on to the same MPLS LSP, it possible to select one or several of these LSPs onto the same L2LSP if the are to be forwarded to the same egress point in the Ethernet network. In a further step, nesting of LSP e.g. Packet LSPs into an Ethernet L2LSP can be considered. Ethernet L2LSPs can also be nested into lambda LSPs. In Figure 5 a through j are different types of LSPs. a, b and c are packet switched LSPs entering the packet switch capable LSR (A), those LSPs are carried on the L2LSP e from node A to B. d, e and f are Ethernet LSPs entering the L2 switch capable LSR (B), those LSPs are carried over a lambda LSP h from node B to C. g, h and i are lambda LSPs entering the lambda switch capable LSR (C), those LSPs are carried over a lambda LSP j from node C. a A d B g C | +-------+ | +---------+ | +---------+ +--| | +-->| | +-->| | | PSC | | L2SC | | LSC | b----| LSR |e------>| LSR |h------->| LSR |j-----> | | |Ethernet | | lambda | +--| | +-->| | +-->| | | +-------+ | +---------+ | +---------+ c f i Figure 5: LSPs in LSPs The routing protocol envisaged for this type of network is OSPF-TE, some extension to OSPF-TE MAY be required (the same applies when considering ISIS-TE). The signaling protocol is RSVP-TE that needs to be extended by a definition of an Ethernet label space (see Section 6.2). 5.4 Scenario 4: Transport Networks In this scenario, the network is constituted by a core network including core-nodes (CN) surrounded by edge nodes (EN) that form the overlay (control plane) networks. This scenario supports various trust models and signaling models. An overlay trusted model may be supported, allowing the core to hide its topology from the edge-nodes and permitting the core restrictive actions towards the edge nodes (e.g. filtering out specific RSVP objects). In addition, this scenario supports networks where the core uses a non-GMPLS based control plane (or no control plane e.g. management plane). EN-CN (and CN-EN) TE links are of type [X,L2SC], ([L2SC,X] resp.), where X is any ISC whose switched payload can be carried over L2SC TE links. Within the network, TE links interconnecting CNs can be either [L2SC,L2SC] or any other technology that can carry Layer-2 payload. D.Papadimitriou et al. - Expires November 2005 7 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 B---C F---G UNI / \ E-NNI / \ UNI EN1-----A 1 CN1-------CN2 2 H-----EN2 \ / \ / E---D J---I Figure 6: GMPLS Ethernet in Overlay Transport Networks The core networks 1 and 2 are interconnected by two CNs (CN1 and CN2), that define an external network-network interface (E-NNI). Within core network 1, [A,B] and [A,E] are [L2SC,Y] TE links. Within core network 2, [G,H] and [I,H] are [Y,L2SC] TE links. - When [C,CN1] and [D,CN1] are [Y,L2SC] TE Links, [CN2,F] and [CN2,J] are [L2SC,Y] TE Links, and [CN1,CN2] is a [L2SC,L2SC] TE link, the L2 LSP that can be setup between node EN1 (ingress) and node EN2 (egress) is constituted by two LSP segments of type Y. The first LSP segment between A and CN1 and the second between CN2 and H. These segments are inter-connected by the [L2SC,L2SC] TE link defined at the E-NNI. The intermediate GMPLS L2SC hops for this L2 LSP are thus A, CN1, CN2 and H. - When these conditions are not met, in particular, when the [CN1,CN2] link is of type e.g. [Y,Y], the L2 LSP that can be setup between node EN1 (ingress) and node EN2 (egress) is constituted by one LSP segment of type Y defined between A and H. The intermediate GMPLS L2SC hops for this L2 LSP are thus A and H. 6. Requirements 6.1 Control plane scope Nodes playing an active role in signaling and routing MUST support the GMPLS capabilities required by the present section. Their implementation SHOULD minimize overhead and manual configuration. The IP control channel between GMPLS L2SC nodes can be out-of-band or in-band. Signaling and routing information exchange between adjacent GMPLS nodes and processing MUST be strictly independent of the control channel implementation. 6.2 Labeling and Label scope requirements A GMPLS labeled frame is an Ethernet frame whose header encodes the label value. GMPLS Ethernet switches SHOULD be able to correctly handle all types of Ethernet MAC frames, including the GMPLS labeled frames, to ensure inter-working with 802.1 bridges. The label's interpretation depends on the type of the link over which the label is used. Labels are locally assigned, interpreted and have local significance. This does not preclude that the same label value can be assigned by consecutive hops (e.g. as it is the case in Scenario 2). D.Papadimitriou et al. - Expires November 2005 8 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 Label value space is assumed to be independent of the implementation of the Ethernet frame forwarding/switching. 6.4 Link Discovery Nodes are inter-connected by point-to-point L2SC links. GMPLS L2SC nodes MUST support discovery of per TE link capabilities. In addition, GMPLS link discovery SHOULD provide - data link property correlation to support aggregating multiple data links into a single TE Link and to synchronize their properties - data link verification to verify the data links physical connectivity and verify the mapping of the Interface ID to Link ID and their local-remote associations Optionally, fault management MAY be provided to suppress alarms and localize failures. Extensions to LMP MAY be required to deliver this functionality. 6.5 Routing Advertisement and Traffic Engineering To facilitate IGP operations such as forming neighbor adjacencies, flooding link state database packets, and representing topology, routing SHOULD treat the broadcast point-to-point control channel between adjacent LSRs as a point-to-point circuit [IGP-LAN]. The solution MUST support the exchange of TE (intra-domain) and reachability (intra and inter-domain) information across the GMPLS Ethernet network(s). Scenario 3 that relies on a unified TE control plane SHALL be able to take TE decisions such as congestion avoidance and recovery actions at the optimal layer. 6.6 Implication(s) on Signaling Signaling mechanisms MUST apply to bi-directional L2LSP setup and where appropriate unidirectional L2LSP setup. Interface identification MUST follow the rules defined in [RFC3473], Section 8.1 and [RFC3477]. 6.6.1 RSVP Signaling GMPLS RSVP-TE signaling for setup/teardown of L2LSP (across GMPLS Ethernet switches) MUST keep RSVP sessions end-to-end significant. L2LSP notification and graceful deletion procedures [RFC3473] SHOULD be supported. Graceful Restart upon control channel and node failure SHOULD also be supported. D.Papadimitriou et al. - Expires November 2005 9 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 Scenarios providing aggregation capability SHOULD support nesting of L2LSPs or PSC LSPs into a FA (L2) LSP when the head/tail end-nodes provide de/multiplexing capabilities. L2LSP splicing (see [RFC3471]) and L2LSP stitching [RSVP-ID] MUST be envisioned in the context of multi-domain L2LSP environments. The solution MUST support both overlay [GMPLS-UNI] and inter-domain [framework] signaling models. 6.6.2 L2 Label Request The Generalized Label Request is defined in [RFC3471], Section 3.1. The LSP Encoding Type and Switching Type to be used for requesting L2 LSP label are Ethernet and L2SC respectively. Generalized PID (G- PID) that identifies the payload carried by Ethernet L2LSPs MUST use standard Ethertype values. 6.6.3 L2 Traffic Parameters Per [RFC3471], GMPLS allows the inclusion of technology specific parameters in signaling. These parameters MUST include the L2 link type that comprises the requested LSP e.g. Ethernet Port and the MTU value. They MUST also be capable to describe traffic parameters for this L2LSP such as the Peak Rate (PIR and PBS), the Committed Rate (CIR and CBS), and the Excess Rate (EIR and EBS). 6.6.4 L2 Label L2 Label follows the rules defined in [RFC3471]. 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). Bi-directional L2 LSPs are indicated by the presence of an upstream label in the Path message. 6.6.5 Explicit Routing support Explicit and Record routing MUST be supported for scenarios making use of source routing such as to provide constraint based routing (for resource and/or data traffic oriented TE) and loop avoidance. Explicit routing, when used, MUST follow the procedures defined in [RFC3209], [RFC3473], and [RFC3477]. Record routing, when used, MUST follow the procedures defined in [RFC3209], [RFC3473], and [RFC3477]. Explicit label control SHOULD be supported (see [RFC4003]) at least in scenario 2 and 4. D.Papadimitriou et al. - Expires November 2005 10 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 7. Reference other SDOs 7.1 IEEE 802.1 The IEEE specifies elements of switching in Ethernet networks. They should be consulted on the scenarios and framework proposed in this document and any solutions developed in the IETF context should be reviewed by the appropriate IEEE working groups to ensure the solution is not harmful to 802.1 networks. There have been several approaches specified by IEEE to overcome the Scaling limitations and to extend service of Ethernet LAN across MAN and WAN, such as IEEE Provider Bridge [802.1ad] and Provider Backbone Bridge [802.1ah]. 7.2 ITU-T SG15 SG15 is currently defining Ethernet Transport Network architecture and services e.g. EPL, EVPL, EPLan and EVPLan. Specific work items are also dedicated to the definition of Ethernet OAM, traffic management and performance as well as the definition of Ethernet UNI and NNI. During revision of the Recommendation G.8010 on defining Ethernet transport network, the IETF ASON/GMPLS control plane definition (including Point-to-point and multi-point ETH VC set up, modification, teardown, etc.) should be positioned as another operation mode analogous to IEEE 802.1 PB and PBB. 8. Security considerations The introduction of L2 LSP, particularly in Ethernet networks, raises similar security issues such as with L1 LSPs and additional L2-specific security issues that need to be solved. The solution MUST protect against the following security threats: - Possibility for the network to control the traffic injected by the client in the data plane (BPDU, Multicast, Broadcasts, etc.) or in the control plane (RSVP-TE signaling messages) - 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. 8.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 D.Papadimitriou et al. - Expires November 2005 11 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 - 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 mechanisms MUST be provided at the network edges (on the head-end LSRs) to rate limit the amount of traffic that can transit into a given L2 LSP. 8.2 Attacks on the Control Plane There are two threats concerning the control plane. The first one corresponds to the support of 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 cannot be used to fail the entire network. Different trust models MUST be supported. There MUST be a way to limit, by configuration, the number of L2LSPs that can be signaled by a particular client, also there must be a way to rate limit RSVP-TE client control plane traffic (mainly refresh interval). Also the operator MUST be able to rate limit, by configuration, the total amount of memory and/or CPU allocated to the RSVP engine, and react appropriately when such bound is reached. Another threat comes from the introduction of IP control functions in L2 equipments (such as the handling of multicast). GMPLS Ethernet networks will inherit the security issues of IP networks similar to other GMPLS client networks, and the appropriate trust models MUST be supported. 8.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 the different traffics, with different VLAN semantics, do not get mixed for example. 9. Acknowledgments The authors would like to thank X, Y and Z. 10. References 10.1 Normative References [RFC2205] R.Braden (Editor) et al., "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. D.Papadimitriou et al. - Expires November 2005 12 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 [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. [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. 10.2 Informative References [BUNDLE] K.Kompella et al., "Link Bundling in MPLS Traffic Engineering", Internet Draft, Work in Progress, draft- ietf-mpls-bundle-06.txt, July 2005. [GMPLS-UNI] G.Swallow et al., "GMPLS UNI: RSVP Support for the Overlay Model", Internet Draft, Work in Progress, draft- ietf-ccamp-gmpls-overlay-06.txt, October 2004. D.Papadimitriou et al. - Expires November 2005 13 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 [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. [IGP-LAN] N.Shen and A.Zinin, "Point-to-point operation over LAN in link-state routing protocols", Internet draft, Work in progress, draft-ietf-isis-igp-p2p-over-lan- 05.txt, July 2004. 11. Author's addresses Dimitri Papadimitriou (Alcatel) Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel.be Jaihyung Choi (ETRI) Email: jaihyung@etri.re.kr D.Papadimitriou et al. - Expires November 2005 14 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. D.Papadimitriou et al. - Expires November 2005 15 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt June 2005 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 November 2005 16