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 <bandwidth,
jitter, delay> 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