Internet DRAFT - draft-papadimitriou-ccamp-gmpls-ethernet-framework
draft-papadimitriou-ccamp-gmpls-ethernet-framework
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
