Internet DRAFT - draft-dimitri-gels-framework
draft-dimitri-gels-framework
Network Working Group D. Papadimitriou (Alcatel)
Internet Draft N. Sprecher (Siemens)
J. Cho (ETRI)
Expires: July 2006 L. Andersson (Acreo AB)
D. Fedyk, D.Allan (Nortel)
P. Busschbach (Lucent)
A. Takács (Ericsson)
T. Eriksson (TeliaSonera)
D. Caviglia (Marconi)
February 2006
A Framework for GMPLS-controlled Ethernet Label Switching
draft-dimitri-gels-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.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Abstract
This framework introduces the service models that should be
supported. It describes the architecture and the information exchange
between the different elements that sustain the reference models. It
defines the Ethernet label. The framework also specifies the changes/
extensions that are required to the GMPLS in order to support the
service models.
D.P. GELS Expires - July 2006 [Page 1]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
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 [1].
1. Terminology
L2SC Label Switch Router (LSR): LSR whose interfaces are capable to
recognize Layer 2 frame boundaries and can switch data based on the
content of the Layer 2 frame header. In the context of this document,
L2SC interfaces are limited to Ethernet interfaces.
Ethernet Label Edge Router (E-LER): LER that resides either at the
edge of the provider's GMPLS network (a.k.a. Provider Edge or PE) or
at the edge to customer's network (a.k.a. Customer Edge or CE). In
the former case, the Ethernet LER interfaces the customer’s network
equipment. The E-LER has the functionality required for initiating
and terminating point-to-point and point-to-multipoint Ethernet
connectivity across the GMPLS network.
Ethernet Label Switching Router (E-LSR): LSR that either resides at
the core of the provider's GMPLS network (a.k.a. Provider node or P)
or at the edge to provider's GMPLS network (a.k.a. Provider Edge or
PE). In the former case, the Ethernet LSRs have no direct interfaces
towards the customers' networks. The Ethernet LSR performs Ethernet
label switching operation by means of a LIB configured by GMPLS.
Ethernet Label Switched Path (LSP): Label Switched Path established
between two Ethernet LERs using GMPLS signaling.
Label Information Base (LIB): table that specifies associations
between incoming and outgoing Ethernet Labels included in Layer 2
frame headers and outgoing ports. If different to the incoming label
it also specifies the outgoing label.
2. Motivations
2.1 Motivation for connection-oriented Ethernet
Ethernet has become widely used within the Service Provider networks,
in particular as part of their metro/aggregation infrastructure. The
Ethernet brings high-speed interfaces, cost-saving efficiency and
flexibility to the carrier market, together with a reduction in CAPEX
(Capital Expenditure).
While the traditional Ethernet, which is a connectionless, broadcast
technology that relies on Spanning Tree Protocols (and variations
such as Rapid Spanning Tree Protocol, RSTP) to create loop free
D.P. GELS Expires - July 2006 [Page 2]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
topologies, is appropriate for services like Residential Multicast
(Broadband TV), and Ethernet Transparent LAN services, it does not
properly address the increasing demand of the service providers for
scalability, fast recovery time, Traffic Engineering and end-to-end
QoS for the different service requirements. These are required for
business-critical services associated with stringent Service Level
Agreements (SLAs). The deployment of Ethernet in the core and in the
transport networks changes the intrinsic nature of Ethernet
technology, from a connectionless to a connection-oriented
technology.
For example, with traditional/legacy IEEE 802.1 bridged Ethernet
equipment, service providers can implement traffic differentiation on
a per-switch basis. However, due to the Spanning Tree topology and
reconfiguration upon failures, it is difficult to predict the exact
traffic flows and to manage QoS on an end-to-end basis. Service
providers require advanced traffic management capabilities to enforce
and guarantee the QoS parameters of customers’ SLAs. Service
providers can increase profitability with an assortment of higher
margin differentiated services. With "connection-oriented" Ethernet
(CO-Ethernet), it is possible to set up paths based on the service
definition, and to enforce the SLAs. Apart from its cost-saving
effects and flexibility, service providers will allow network
providers to offer new services that can be tailored to the
individual needs of the customer.
By eliminating the need for Spanning Tree Protocol and gaining route
freedom for configured Ethernet paths, service providers can use more
comprehensive forms of traffic engineering to optimize network usage
through load sharing and switching paths around bottlenecks to less
congested links.
Network resiliency plays a critical factor in delivering reliable
services. Network availability is a significant contributor to
revenue and profit. Service guarantee in the form of SLAs requires a
resilient network that instantaneously detects facility or node
failures and restores network operation immediately to meet the terms
of the SLA. Network restoration through the use of IEEE
Rapid/Spanning Tree Protocol 802.1d/w – being a Distance Vector
protocol – has inherent limitations that make fast restoration time
performance objectives difficult to accomplish. Connection-oriented
Ethernet can provide the required availability to ensure guaranteed
services. Through mechanisms like OAM, dedicated backup routes and/or
fast reroute mechanisms, the transport Ethernet network can provide
the tens of milliseconds fail over times needed to meet stringent SLA
obligations. Connection-oriented Ethernet also addresses the
carriers' needs for MAC scalability and VLAN scalability. It
eliminates the MAC scalability problem in case switching operation is
independent of the destination MAC address.
D.P. GELS Expires - July 2006 [Page 3]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
In addition, service providers require network architectures that
enable services to scale effectively as the customer base grows, in
order to minimize capital expenditures and drive down operational
costs.
Scalable services require the separation of traffic from different
users, with no limitations on the number or locations of customers
connected to the network. With connection-oriented Ethernet the cost
effectiveness is achieved.
Due to its connectionless nature, especially its use of self-learning
bridges, traditional Ethernet is vulnerable to unwanted connectivity
(either through mis-configuration or malicious attacks). In the case
of connection-oriented Ethernet switches are explicitly provisioned
and therefore provide enhanced security.
2.2 Motivation to improve Ethernet Control Plane
In order to enable fast, dynamic and reliable service provisioning in
multi-vendor and multi-domain environments through standardized
protocols that guarantee interoperability, a control plane is
required. Managed by a standard-based distributed control plane and
augmented with Ethernet specific data plane OAM features currently
being specified by the IEEE (see 802.1ag), the dynamic transport
network will support Ethernet traffic with carrier-grade reliability,
optimal network efficiency, multiple QoS levels, cross-vendor
provisioning and scalability. The control plane will facilitate the
service goal of providing seamless connectivity and service assurance
end-to-end.
Using the control plane the reliable service provisioning and
management will be automatic. The control-plane protocols will make
the provisioning and the management operations more efficient,
thereby offering the potential of lowering network operation
expenses, or at least limiting their rate of increase as the size of
the service provider’s network increases. As the networks change, and
get larger and more complex with increased dynamics, the network
operation becomes increasingly complex and resource intensive to
operate.
The control plane can also optimize network usage through load
sharing by switching paths around bottlenecks to less congested
links. Using a control plane that provides Traffic Engineering,
constraint based routing and explicit path control will minimize
capital expense by making efficient use of network resources, hence
helping to avoid unnecessary additional investments. These are
requirements of the core/transport networks.
D.P. GELS Expires - July 2006 [Page 4]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
The use of a control plane that has the inherent ability to setup
paths based on the service definition, with capabilities for quality-
of-service (QoS) and Traffic Engineering will enforce the SLAs.
Traffic Engineering is accomplished by addressing traffic oriented
performance requirements (like throughput, delay, packet loss, etc.),
while utilizing network resources economically and reliably.
The control plane can enable resiliency and reliability to be built
into service providers’ networks, increasing the availability and
value of the network to their customers. When outages occur, traffic
can be automatically rerouted around failed facilities.
This framework proposes to use the Generalized Multi-Protocol Label
Switching (GMPLS) as the control plane of choice for the Ethernet
networks. The GMPLS protocol suite [RFC3945] has been standardized by
the IETF CCAMP WG. GMPLS extends MPLS to support four new classes of
interfaces including L2SC (L2 Switch Capable) interfaces. It
facilitates the transport of client Ethernet flows without additional
intermediate packet layer LSPs (which require pre-provisioning as
network trunks).
The GMPLS control plane provides Traffic Engineering (including
support for Differentiated service-TE), provisioning and maintenance
of (unidirectional and bi-directional) Ethernet LSPs in core and
transport networks including multi-layer networks (MLNs).
GMPLS has inherent support for fast recovery mechanisms. It delivers
a range of control plane driven recovery capabilities. GMPLS
protection and re-routing techniques (both end-to-end and segment)
and can be reused for GMPLS Ethernet LSPs and LSP segments.
GMPLS capabilities support the carriers' requirements for control
plane resiliency, like graceful restart of the control plane (with no
traffic interruption) and graceful deletion of Ethernet LSPs.
Having a homogenous/unified set of signaling and Traffic Engineering
mechanisms for controlling Ethernet network resources, will ease the
integration towards a common carrier-grade network control
infrastructure. The CCAMP WG is currently envisaging a single
instance of control plane between IP/MPLS, Ethernet, SDH/SONET and
optical networks. Henceforth, GMPLS controlled Ethernet label
switching approach positions Ethernet as a carrier-grade packet-
switching connection-oriented technology.
4. Architecture
This section presents the architectural framework for GMPLS-
controlled Ethernet Label Switching. It defines the reference model
for the GMPLS-enabled Ethernet network, the various protocol elements
and their functions.
D.P. GELS Expires - July 2006 [Page 5]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
Generalized Multi-Protocol Label Switching (GMPLS) is a suite of
protocol extensions to MPLS. The purpose of these extensions is to
broaden the scope of MPLS applications, and to support multiple
network layers and new services. Specifically, this specification
describes how GMPLS can be used to dynamically setup, delete,
maintain and operate Point-to-Point Traffic Engineered Ethernet LSPs.
The specification must be extensible such as to support Point-to-
Multipoint Traffic Engineered Ethernet LSPs [P2MP] and to include the
extension of the Traffic Engineered Ethernet LSPs over multiple
domains [ID-FRM].
4.1 GMPLS-controlled Ethernet Network Elements
The GMPLS-controlled Ethernet network consists of the following
network elements:
o) Ethernet Label Edge Router (E-LER)
The Ethernet LER either resides at the edge of the provider's GMPLS
network (PE role) or at the edge to customer's network (CE role). In
the former case, the Ethernet LER interfaces the customer's network
equipment.
The E-LER has the functionality required for initiating and
terminating point-to-point and point-to-multipoint Ethernet
connectivity across the GMPLS network.
At the ingress to the GMPLS network, the Ethernet LER takes an
incoming native frame from a non-label controlled interface, if
necessary adapts it to an Ethernet frame, adds an Ethernet label and
forwards it via the appropriate label-controlled interface over a
Ethernet point-to-point or point-to-multipoint LSP.
At the egress to the GMPLS network, the Ethernet LER removes the
Ethernet label from a frame received on a label-controlled interface,
if necessary extracts the payload, and forwards the native frame
appropriately towards its destination via a non-labeled-controlled
interface.
o) Ethernet Label Switching Router (E-LSR)
The Ethernet LSR either resides at the core of the provider's GMPLS
network (P role) or at the edge to provider's GMPLS network (PE
role). In the former case, the Ethernet LSRs have no direct
interfaces towards the customers' networks. The Ethernet LSR takes an
incoming labeled Ethernet frame from a labeled-controlled interface,
switch the frame using the Ethernet label and forwards the frame
D.P. GELS Expires - July 2006 [Page 6]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
towards its destination via the appropriate label-controlled
interface.
Each GMPLS-enabled network element may function as an Ethernet LER
and/or as an Ethernet LSR. This means that the path from the Ethernet
ingress LER to the Ethernet LER might pass through another Ethernet
LER.
4.2 Ethernet LSP
An Ethernet point-to-point LSP is defined as an LSP established
between two Ethernet label-controlled interfaces of E-LERs. These
interfaces are capable of recognizing the Ethernet frame boundaries
and can switch data based on the content of the standard IEEE 802.1
Ethernet frame. The Ethernet LSP originates on an ingress Ethernet
LER and terminates on an egress Ethernet LER. For a point-to-point
bi-directional LSP, the same pair of E-LERs acts as both ingress and
egress E-LERs.
An Ethernet point-to-multipoint LSP is defined as a unidirectional
LSP terminating on more than one Ethernet label-controlled interfaces
of E-LERs.
At the E-LER, the frame is assigned to an LSP tunnel, and no further
header analysis is required by subsequent Ethernet LSRs. Throughout
the GMPLS-enabled Ethernet network, the forwarding operation is
driven by the labels which are encoded in the standard IEEE 802.1
frame header (either 802.1ad or 802.1ah).
4.3 Reference Architectures
o) Edge-to-edge Reference model
Figure 1depicts the "edge-to-edge" network reference model for a
point-to-point Ethernet LSP across a GMPLS-enabled Ethernet network.
In this model, the CE (Customer Edge) network element is attached to
a PE (Provider Edge) network element via a CE-PE interface. The PE
network element functions as an E-LER. The Ethernet LSP is
established between a pair of directly connected E-LERs across the
GMPLS-enabled Ethernet network, or via a set of P (Provider) network
elements which function as Ethernet LSR (E-LSR) nodes.
----GMPLS Ethernet Network----
| |
PE P PE
+------+ +------+-------+ +-------+ +------+-----+ +------+
| | | | | | | | | | | |
| CE |---| Pre |Ingress|---| E-LSR |---|Egress| Post|---| CE |
D.P. GELS Expires - July 2006 [Page 7]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
| | | Proc.| E-LER | | | |E-LER | Proc| | |
| | | | | | | | | | | |
+------+ +------+-------+ +-------+ +------+-----+ +------+
Figure 1: Edge-to-edge Reference Model
A point-to-point/point-to-multipoint Ethernet LSP is established to
provide point-to-point/point-to-multipoint data path between E-LERs.
When a frame/packet enters an ingress PE via a CE-PE interface, the
PE processes the incoming traffic flow by performing a number of pre-
processing operations on the frame. Detailed description of the pre-
processing operations that may include, for example, VID translation,
VID insertion/ stripping, etc. are beyond the scope of this
specification. Note that the CE-PE interface is not restricted to any
kind of specific interface (hence, not restricted to interfaces
carrying Ethernet frames) and this, in order to enable to Ethernet to
be a transport layer for multiple services.
The pre-processed frame is then presented to the ingress E-LER
function that 1) maps the corresponding incoming frame to a
particular Ethernet LSP according to different criteria such as the
destination, the class of service, etc. and 2) adds an Ethernet label
to the frame and forwards it via the appropriate label-controlled
interface along the Ethernet LSP.
The egress E-LER terminates the Ethernet LSP by removing the Ethernet
label on incoming frames. The PE then performs post-processing
operations on the incoming frame and forwards it on the appropriate
CE-PE interface. Detailed description of these post-processing
operations that may include, for example, VID translation, VID
insertion/ stripping, etc. are beyond the scope of this
specification.
o) "End-to-end" Reference Model
Figure 2 depicts the "end-to-end" network reference model for a
point-to-point Ethernet LSP across a GMPLS-enabled Ethernet network.
In this model, the CE (Customer Edge) network element is attached to
a PE (Provider Edge) network element via a CE-PE interface. The CE
network element functions as an E-LER. The Ethernet LSP is
established between a pair of directly connected E-LERs across the
GMPLS-enabled Ethernet network, or via a set of P (Provider) network
elements which function as Ethernet LSR (E-LSR) nodes.
---------------GMPLS Ethernet Network----------------
| |
CE PE P PE CE
+------+-------+ +-------+ +-------+ +-------+ +------+-----+
| | | | | | | | | | | |
D.P. GELS Expires - July 2006 [Page 8]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
| Pre |Ingress|---| E-LSR |---| E-LSR |---| E-LSR |---|Egress| Post|
| Proc.| E-LER | | | | | | | |E-LER | Proc|
| | | | | | | | | | | |
+------+-------+ +-------+ +-------+ +-------+ +------+-----+
Figure 2: End-to-end Reference Model
Operations driving pre-processing/ingress E-LER function (at ingress
CE-side), E-LSR function (at PE and P-side) and Egress E-LER/post-
processing function (at egress CE-side) are identical of those of the
edge-to-edge model.
The GMPLS-enabled Ethernet network may be part of a Multi-Layer
Network (MLN) where multiple switching technologies are supported,
i.e. multiple regions are supported [MLN_REQ]. Figure 3 presents an
example of a multi-regional scheme and indicates 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. In this figure, node A corresponds to the CE
and node B to the PE (as depicted in Figure 2).
+-----------+ +-------------+ +-------------+
| 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 | |
D.P. GELS Expires - July 2006 [Page 9]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
lambda | | | |
| | lambda | |
| +---------+ |
+-------------+
Figure 3: Data plane and control plane
The aggregation of traffic into the same LSP is possible in this
multi-regional scheme. LSP nesting may be supported as well, for
example, packet LSPs may be nested into an Ethernet LSP and Ethernet
LSPs may be nested into lambda LSPs.
4.4 GMPLS Control Plane Elements
The E-LER and the E-LSR network elements implement the GMPLS control
protocol to enable constraint-based routing and explicit routing, and
to automatically configure the Forwarding Information Base (FIB) with
the forwarding state.
IPv4 and/or IPv6 addressing are used to identify the Ethernet L2SC
interfaces. Unnumbered links and bundled links should be used to
enhance the addressing scalability and to eliminate the need to apply
an IP address to each Ethernet L2SC interface.
The OSPF-TE/IS-IS TE routing protocols can be used to distribute the
network element capabilities and to disseminate TE routing
information over the interfaces. The bandwidth, as well as the other
TE attributes, of each port/bundled link, or the bandwidth of each
Ethernet LSP, can be treated as a constraint during path computation.
The GMPLS RSVP-TE is used to support Ethernet point-to-point LSP
setup, maintenance and tear down. In order to be compatible with the
global GMPLS framework and provide a global unified TE framework,
multiple switching layers may be supported and ownership/trust models
(e.g. overlay, peer) may be applied. For details, see below the
Multi-Layer Network (MLN) model.
4.5 Ethernet Label
GMPLS makes use of the structure of the standard IEEE 802.1 Ethernet
frame. The Ethernet label is inserted in the Ethernet encapsulation
and is part of the Ethernet MAC frame header. A GMPLS Ethernet-
labeled frame is defined as an Ethernet MAC frame whose header
encodes the label value. The coding of the Ethernet label does not
modify the format of the standard Ethernet frame, although it may add
new semantics to one or more fields. The switching decision is based
on the label part of the Ethernet frame header. Figure 4 depicts a
logical view of the protocol layers.
D.P. GELS Expires - July 2006 [Page 10]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
+---------------------------+
| Payload |
+---------------------------+
| Ethernet |
+---------------------------+
| Physical |
+---------------------------+
Figure 4: Logical Protocol Layering Model
The Ethernet MAC frame header includes the EtherType, different VLAN
TAGs, and the destination and source MAC addresses.
GMPLS Ethernet switches need to be able to correctly handle all types
of Ethernet MAC frames, including GMPLS-labeled frames, to ensure co-
existence with legacy Ethernet switches. GMPLS functionality can co-
exist with IEEE 802.1 bridge control and management functionalities
on the same network element. The common network resources should be
either pre-partitioning or dynamically selected.
The architecture allows different label encoding techniques. A
specific encoding technique may be selected according to the
capability of the GMPLS-enabled Ethernet network element and/or to
the capability of the label-controlled Ethernet interface, etc.
Labels are locally assigned, interpreted and have local significance.
This does not preclude that the same label value can be assigned by
consecutive hops. Also Ethernet label and label switching technique
must be extensible for the establishment and support of multiple-
domain Ethernet LSP, point-to-multipoint LSPs (carrying Ethernet
multicast traffic) and easily support exchange of Ethernet broadcast
traffic.
The techniques are considered as candidate for the encoding of the
Ethernet label.
o) Link-local label: IEEE 802.1ad S-VID (amendment to IEEE Std
802.1Q-1998)
Figure 5 depicts the format of the standard IEEE 802.1ad Ethernet
frame.
TAG
---------
/ \
+-----------+------------+----+----+----+---------------+--------+
| | | | | | | |
| MAC Dest | MAC Src |TPID|TCI |LEN\| Payload | FCS |
D.P. GELS Expires - July 2006 [Page 11]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
| Address | Address | | |Type| | |
| | | | | | | |
+-----------+------------+----+----+----+---------------+--------+
Figure 5: Standard IEEE 802.1Q Frame Format
The TAG protocol Identifier (TPID) is a 16-bit length field which is
set a value of 0x88a8 to identify the frame as an IEEE 802.1ad tagged
frame. The TAG Control Information (TCI) is a 16-bit length field.
In this technique, the Ethernet label is encoded in the TCI field of
the S-VLAN TCI (see Figure 6). The length of the Ethernet label is 12
bits providing for a label space of 4k values per link.
S-VID translation is used in this technique. S-VID processing is
supported on most Ethernet switches. MAC address learning may be
inhibited, depending on the behavior of the forwarding entity.
GMPLS signaling is used to configure the S-VIDs along the nodes
traversed by the Ethernet LSP.
Figure 6 depicts the S-VLAN TAG Control Information (TCI)
Oct: 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCP |D| VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
bit: 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Figure 6: TCI Format
The Priority Code Point (PCP) is a 3-bit length field, which is used
to convey priority and drop eligibility parameters. This 3-bit field
refers to the 802.1p priority.
The D bit (1 bits) is the Drop Eligible Indicator (DEI) bit.
The VLAN Identifier (VID) is a 12-bit length field uniquely
identifying the VLAN to which the frame belongs. Its value can be
between 0 and 4,095.
o) Link-local label: IEEE 802.1ad Stacked VLAN (QinQ)
Figure 7 depicts the format of the IEEE 802.1ad Ethernet frame with
Stacked VLAN (QinQ).
S-TAG C-TAG
-------- -------
/ \ / \
D.P. GELS Expires - July 2006 [Page 12]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
+----------+----------+----+----+----+----+----+---------------+---+
| | | | | | | | | |
| MAC Dest | MAC Src |TPID|TCI |TPID|TCI |LEN\| Payload |FCS|
| Address | Address | | | | |Type| | |
| | | | | | | | | |
+----------+----------+----+----+----+----+----+---------------+---+
Figure 7: Standard IEEE 802.1ad Format with Stacked VLAN.
In this technique the concatenation of the S-VID (i.e. the VID of the
S-TAG) and the C-VID (i.e. the VID of the C-TAG) is used as the
Ethernet label, resulting in a unique 24-bit length label.
This technique makes use of VID translation. Neither MAC learning nor
flooding for the range of VIDs are required. GMPLS is used to
configure the 24-bit label.
o) Domain-wide label: IEEE 802.1ah B-VID concatenated with B-MAC DA
In this technique, the concatenation of the VID (encoded in the TCI
immediately following the DA and SA MACs) and the Destination MAC
Address (DA MAC) is used as the Ethernet label, resulting in a unique
60-bit label. The VID can be a Q-TAG (Ethertype for TCI=0x8100), a
802.1ad S-TAG (Ethertype for TCI=0x8a88) or a 802.1ah B-TAG
(Ethertype TBD) depending on the network context. This technique
provides for a private sub-network labeling solution as the MAC
address space is "sub-network specific". This solution mandates
enforcement of unicast only traffic exchange for the specified (pre-
configured) VID range.
In order to use the unique 60-bit label, the normal mechanisms by
which Ethernet populates the forwarding table for the allocated range
of VIDs should be disabled, for example, MAC learning and flooding
are disabled for an allocated VID range, blocking is disabled, etc.
GMPLS is used to configure the 60-bit label.
Note that having a label encoding technique which uses a network wide
label space definition requires that the support of the whole network
in this technique, even in case of multiple domains.
5. Control Plane Operations
The IP control channel between GMPLS L2SC nodes can be out-of-band or
in-band. The exchange of signaling and routing information between
adjacent GMPLS nodes and processing MUST be strictly independent of
the control channel implementation.
5.1. TE/Routing information distribution
D.P. GELS Expires - July 2006 [Page 13]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
To facilitate IGP operations, such as forming neighbor adjacencies,
flooding link state database packets, and representing topology,
routing should treat the Ethernet broadcast point-to-point control
channel between adjacent E-LSRs as a point-to-point circuit.
The routing distribution must support the exchange of TE (intra-
domain) and reachability (intra and inter-domain) information across
the GMPLS Ethernet network(s).
In order to support different label-encoding techniques, it may be
necessary to extend the TE information distribution protocols (OSPF-
TE [RFC3630]/ISIS-TE [RFC3784]) with the following capabilities:
Label-controlled Ethernet Interface Switching Capability Descriptors
as an label-controlled Ethernet interface may support more than label
switching technique.
These capabilities will be distributed as part of the routing
distribution and will be considered as constraints during path
selection.
5.2. Signaling
The signaling protocol utilizes downstream-on-demand label allocation
and distribution, with ingress-initiated ordered control. The
signaling mechanisms MUST apply to both the bi-directional and
unidirectional Ethernet LSP setup.
GMPLS RSVP-TE [RFC3473] signaling for setup/teardown of Ethernet LSPs
(across GMPLS-enabled Ethernet network elements) should be supported
and it must keep RSVP sessions significant on an end-to-end basis.
The Generalized Label Request is defined in [RFC3471]. The Ethernet
LSP encoding type and switching type to be used for requesting an
Ethernet label are "Ethernet" and "L2SC" respectively. In order to
support different label-encoding techniques, it may be necessary to
extend possible values for the LSP encoding type.
The specific label-controlled Ethernet LSP parameters should be
described in the signaled traffic parameters (t_spec/r_spec). These
parameters must include the L2 link type that comprises the requested
Ethernet LSP, for example, the Ethernet port and the MTU value. They
MUST also be capable of describing the traffic parameters for this
Ethernet LSP, such as the Peak Rate (PIR and PBS), the Committed Rate
(CIR and CBS), and the Excess Rate (EIR and EBS).
Explicit and record routing must be supported for scenarios making
use of source routing, for example, for those that provide
constraint-based routing (for resource and/or data traffic oriented
TE) and loop avoidance. Explicit routing, when used, must follow the
D.P. GELS Expires - July 2006 [Page 14]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
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
during provisioning of Ethernet LSPs.
The GMPLS re-routing mechanisms should be usable for the recovery of
Ethernet LSPs, including, end-to-end and segment LSPs. Ethernet LSP
notification and graceful deletion procedures [RFC3473] should be
supported. Graceful restart upon a control channel and node failure
should also be supported.
Nesting of Ethernet LSPs or PSC LSPs into an FA LSP should be
supported when the head/tail end-nodes provide de/multiplexing
capabilities.
Ethernet LSP splicing [RFC3471] and Ethernet LSP stitching [RSVP-ID]
must be envisioned in the context of multi-domain environments. The
solution must support both edge-to-edge and end-to-end models and
their specific signaling operations.
5.3. 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 the following:
- Data link property correlation to support the aggregation of
multiple data links into a single TE link and the synchronization of
their properties
- Data link verification to check the data links' physical
connectivity and to 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. It may be required to extend the LMP in order to
provide this functionality for GMPLS-controlled Ethernet networks.
5.4. Security
The introduction of Ethernet LSP signaling MUST prevent attacks by
offering adequate filters (like ACLs or other new systems).
The Ethernet LSP SHOULD reduce data plane threats, as the number of
network entry points to control is reduced. An Ethernet LSP is by
nature a hermetic tunnel with a single entry point (ingress E-LER).
Policing and filtering is required only on the ingress E-LER.
D.P. GELS Expires - July 2006 [Page 15]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
Some mechanisms MUST be provided at the network edges (on the ingress
E-LERs) to rate limit the amount of traffic that can transit into a
given Ethernet LSP.
5.4.1 Attacks on the Control Plane
There are two threats that concern the control plane. The first
relates to signaling support by the client side. As LSP tunnels MAY
be signaled from the client site using RSVP-TE, control of such
activity MUST be provided to prevent it from being used to fail the
entire network. Different trust models MUST be supported.
There MUST be a way to limit, by configuration, the number of
Ethernet LSPs that can be signaled by a particular client. In
addition, there must be a way to rate limit RSVP-TE client-control
plane traffic (mainly via the refresh interval). Moreover, the
operator MUST be able to rate limit, by configuration, the total
amount of memory and/or CPU allocated to the RSVP engine, and to
react appropriately when this limit is reached.
The second threat derives from the introduction of IP control
functions in Ethernet equipment (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.
6. Security Considerations
See Section 5.4.1
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP
for LSP Tunnels", RFC 3209, December 2001.
[RFC3477] K.Kompella et al. "Signalling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to
OSPF Version 2", RFC 3630, September 2003.
D.P. GELS Expires - July 2006 [Page 16]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
[RFC3784] H.Smit and T.Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic
Engineering (TE)," RFC 3784, June 2004.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October
2004.
7.2. Informative References
[MRN-REQ] K.Shiomoto et al., "Requirements for GMPLS-based
Multi-Region Networks (MRN)", Work in Progress, draft-
ietf-ccamp-gmpls-mrn-reqs-00.txt.
8. Acknowledgments
9. Author's Addresses
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 2408491
Email: dimitri.papadimitriou@alcatel.be
Nurit Sprecher
Siemens AG (Seabridge Networks)
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Israel
Email: nurit.sprecher@seabridgenetworks.com
Jaihyung Cho
Electronics and Telecommunications Research Institute (ETRI)
161 Gajung-dong, Yuseong-gu
Daejeon 305-350, Korea
Phone: +82 42 860 5514
Email: jaihyung@etri.re.kr
Loa Andersson
D.P. GELS Expires - July 2006 [Page 17]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
Acreo AB
Email: loa@pi.se
Attila Takács
Traffic Lab, Ericsson Research
Ericsson Hungary Ltd.
Laborc 1.
Budapest, Hungary, H-1037
Email: attila.takacs@ericsson.com
Peter Busschbach
Lucent Technologies
67 Whippany Rd
Whippany, NJ 07981, USA
Phone: +1 973 386 8244
Email: busschbach@lucent.com
Don Fedyk
Nortel Networks
600 Technology Park
Billerica, Massachusetts
01821 U.S.A
Phone: +1 (978) 288 3041
Email: dwfedyk@nortel.com
Dave Allan
Nortel
3500 Carling Ave.
Ottawa, Ontario
K1Y 4H7
Phone: (613) 763-6362
Email: dallan@nortel.com
Thomas Eriksson
TeliaSonera AB
Vitsandsgatan 9, Pv2
12386 Farsta Sweden
Email: thomas.a.eriksson@teliasonera.com
Diego Caviglia
Email: diego.caviglia@ericsson.com
D.P. GELS Expires - July 2006 [Page 18]
A Framework for GMPLS-controlled Ethernet Label Switching Feb 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
Intellectual Property
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.
D.P. GELS Expires - July 2006 [Page 19]
