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)
A. Takács (Ericsson)
D. Caviglia (Ericsson)
February 2006
Label Encoding Solution Decoder and Analysis
for GMPLS-controlled Ethernet Label Switching (GELS)
draft-dimitri-gels-solution-eval-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 document introduces the functional criteria as a decoder ring
for the selection of GELS label encoding. After detailing each
proposed label encoding, each solution is analyzed against these
criteria.
D.P. GELS Expires - July 2006 [Page 1]
Solution Decoder and Analysis for GELS 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 [i].
Reader is also assumed to be familiar with the GELS framework [GELS-
FRM].
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 customers 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 (ingress and egress) using GMPLS signaling
or between one ingress Ethernet LER and multiple egress LERs. In the
former case, one refers to a point-to-point Ethernet LSP and in the
latter to a point-to-multipoint Ethernet LSP.
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.
Connection Oriented Ethernet: defined by LSPs having a single source
(ingress Ethernet LERs) and one or multiple destinations (egress
Ethernet LERs). LSPs must be created before any Ethernet PDUs can be
sent, but exist independently of whether any PDUs are being sent.
There is no further routing choice within the LSP. These LSPs
maintain ordering of Ethernet PDUs sent from source.
D.P. GELS Expires - July 2006 [Page 2]
Solution Decoder and Analysis for GELS Feb 2006
2. Functional Criteria
This section attempts to set functional criteria for examining,
analyzing and comparing the optional solutions listed in Section 3.
Naturally, the first and the most important criterion should be
compliance with the GELS requirements [GELS-REQ].
At time of writing, this document was not finalized; hence, it may be
thus necessary to tune and adjust this section on completion of the
requirement draft.
A description of the criteria follows. These functional criteria are
solution independent and intended to simplify the GELS solution (in
terms of label encoding) selection process for implementing
connection-oriented Ethernet. Note that the order in which the
criteria are specified does not imply the order of importance.
2.1 Ethernet P2P and P2MP TE LSPs
Point-to-point (uni and bi-directional) and point-to-multipoint
(unidirectional) connections are defined by trails, which have the
property of being directed with a single source and one or multiple
destinations. Traffic flows should be identified by some connection
identifiers rather than by explicitly listing source and destination
addresses. This makes Ethernet frame switching substantially faster
(as FIDs are just simple look-up tables and are easy to implement in
the hardware).
In a connection-oriented Ethernet environment, p2p and p2mp
connections must be used to construct all other networking services
like mp2p and mp2mp services (see Section 2.3). That is, in
connection-oriented Ethernet, p2p and p2mp connections are the
primary focus that determines the underlying Ethernet label encoding
scheme.
Connection-oriented Ethernet enables the setting up of p2p and p2mp
LSPs based on the service definition and the enforcement of the SLA.
Connection oriented Ethernet also requires pre-provisioning of the
network connections and that the required resources are pre-allocated
and reserved. The solutions should enable realization of the Traffic
Engineering resource-oriented (to optimize the network resource
usage) and traffic-oriented (delay, jitter, loss, etc.) performance
objectives based on the service definition to enforce the SLA.
2.2 Ethernet LSP Merging and LSP Multiplexing
LSP merging is referred when at a network element multiple point-to-
point LSP segments are joined into a single point-to-point LSP
D.P. GELS Expires - July 2006 [Page 3]
Solution Decoder and Analysis for GELS Feb 2006
segment in a way that no further differentiation between the original
LSP segments is possible.
LSP multiplexing is the case when the joined point-to-point LSP
segments can be differentiated later on in particular at the common
receiver. There are two cases of multiplexing:
- a separate label is assigned on a per sender basis
- a common label is assigned independently of the sender
The GELS framework discusses local vs. domain-wide labels
(identifiers). While local labels provide simple method for LSP
merging and multiplexing, usage of domain-wide labels results in
dependence to the structure and the nature of the label.
It must be noted that merging in contrast to multiplexing does not
preserve the possibility to identify the source of the corresponding
LSP(s).
LSP merging and multiplexing deliver a way to provide mp2p services
but impact network operation and maintenance requirements:
(1) ability to identify specific faulty connections (using OAM
mechanisms)
(2) ability to police individual senders and connections.
Therefore, LSP merging and multiplexing are optional capabilities to
be supported by the solution.
2.3 Services
The solution should be capable of providing any connectivity service
that is supported by standard Ethernet encapsulation (such as
IP/MPLS, TDM, etc.).
The solution should not constraint the connectivity services delivery
by the network.
The solution should provide efficient means to simplify the
provisioning task in the following aspects:
1. The label distribution and allocation process should have a
minimum effect on the network so as to reduce provisioning overhead,
as well as to relieve the network synchronization process.
2. Network configuration, provisioning and adjustment should have a
minimum effect on the network and services it delivers.
3. The solution should support network trunks in order to simplify
the delivery of services.
D.P. GELS Expires - July 2006 [Page 4]
Solution Decoder and Analysis for GELS Feb 2006
2.4 OAM
The solutions should provide means to simplify the network operations
maintenance task.
The use Ethernet OAM is required to monitor the proper operation of
the network.
The solutions should provide a means to minimize the number of LSPs
that should be monitored. Only network trunks (nesting LSPs) should
be monitored and there is no specific requirement to monitor the
services within the tunnels. Services may be monitored according to
specific service requirements.
The solutions should enable the support for OAM (IEEE 802.1ag)
messages. The following mechanisms should be supported to detect
failures or problems in the network and to ensure the correct
operation of the network:
1) Connectivity verification
2) Alarm communication and handling
3) Loopback tests
4) Fault diagnosis (e.g. traceroute)
2.5 Resiliency
Network resiliency is the network's ability to restore traffic
following failure or attack, and is a critical factor in delivering
reliable services.
Guaranteed service in the form of SLAs requires a resilient network
that instantaneously detects facility or node failures and
immediately restores network operation to meet the terms of the SLA.
The solution should provide mechanisms
o) to match the sub 50 ms failover times required to maintain time-
bounded services. The solutions should also support recovery
mechanisms that save network resources, that is, without pre-
provisioning of bandwidth. For this kind of recovery mechanisms the
failover time can be higher that 50 ms.
o) to protect against any failure in the network (including failure
of boundary nodes in case of inter-domain operation).
The recovery mechanisms are categorized as end-to-end LSP recovery
(global protection), LSP segment recovery, and local LSP recovery.
The solutions should assure the correct inter-working between control
plane and data plane (e.g. port protection) recovery mechanism.
D.P. GELS Expires - July 2006 [Page 5]
Solution Decoder and Analysis for GELS Feb 2006
2.6 Inter-domain
The solutions should enable the provisioning of Ethernet LSPs over
inter-domains. The peering and the client/server interconnection
modes are considered, as follows:
(i) Peering mode: Peering is a way of interconnection, where the
interfacing between the domains/operators is defined by UNI/E-NNIs.
Moreover, peering networks exchange traffic at the same networking
layer, that is layer N traffic arriving for domain A will be
forwarded in domain B as layer N traffic as well. It is possible to
further subdivide this mode depending on which topology (addresses,
resources, etc.) information are exchanged across the UNI/E-NNI
interface.
(ii) Client-server mode: The client/server mode of interconnection,
the server operator provides a networking service that delivers the
clients traffic. Essentially, the clients traffic resides on layer
N and it transported transparently across the server layer N-1. The
identifiers from the client layer and the server are independent. A
natural example of this mode of operation is an Ethernet flow (layer
N) transported via an SDH/SONET circuit (layer N-1).
In certain scenarios, there may be a need to combine together
different LSPs such that in the data plane, a single end-to-end LSP
is realized and all traffic from one LSP is switched onto the other
LSP. This operation is called LSP stitching [STITCHING].
The solutions should support LSP stitching.
2.7 Scalability
2.7.1 MAC Address
By nature, a solution for connection-oriented Ethernet should be
agnostic with regard to MAC address learning such as to eliminate the
FIB flush associated with topology change and flooding operations,
which lead to slow recovery and convergence.
2.7.2 VLAN ID (VID)
The scalability of the solution should not be impacted by the limited
space of VLAN identifier (VID).
2.7.3 Ethernet Frame Switching
Ethernet frame switching should be independent of the destination MAC
address and SHOULD NOT rely on the customers' destination MAC
addresses.
D.P. GELS Expires - July 2006 [Page 6]
Solution Decoder and Analysis for GELS Feb 2006
2.7.4 Label
The scalability of the label value space (and hence its encoding)
constraints the number of LSPs that can be concurrently provisioned.
The solutions should therefore provide label value and encoding that
allow a satisfactory number of LSPs to be provisioned [GELS-REQ].
In addition, the Ethernet label is encoded in the Ethernet MAC frame
header. Therefore, the size of the label affects the frame and the
length of the payload.
Scalability also depends on the size of the label and its implication
on the Ethernet frame header size, e.g. MAC encapsulation (DA_B-MAC)
in combination with B-TAG etc. or S-TAG (S-VID).
2.7.5 LSP Hierarchy
LSP hierarchy can be used to improve the network scalability, the
solutions should assure that label encoding is not constraining
Forwarding adjacency LSP establishment [RFC 4206].
2.8 Backward compatibility with IEEE 802.1
The label encoding techniques MUST make use of the structure of the
standard IEEE 802.1 Ethernet frame and frame header.
The encoding solution should not modify the format of the standard
Ethernet frame or the standard Ethernet frame header but may add new
semantics to one or more fields.
Where the solution should co-exist with IEEE 802.1 bridge control and
management functionalities on the same network element it should be
backward compatible with legacy Ethernet bridges. In this case, GMPLS
Ethernet switches need to be capable of handling all types of
Ethernet MAC frames, including GMPLS-labeled frames, to ensure their
co-existence with legacy Ethernet switches.
2.9 Applicability
The solutions should be examined for each network scenario. It may be
that a specific solution is found to be more appropriate for a
certain network scenario while a different solution is more suitable
for another type of scenario.
The solutions should be examined with respect to their deployment in
the following types of networks:
1) Metro access and Metro aggregation networks
2) Metro core
D.P. GELS Expires - July 2006 [Page 7]
Solution Decoder and Analysis for GELS Feb 2006
3) Core and transport networks
These scenarios should enable services to scale effectively as the
customer base grows, in order to minimize capital expenditures and
drive down operational costs.
2.10 Security
The solution should provide a means to protect the network from the
following threats:
1) Vulnerability to unwanted connectivity (through malicious
attacks).
2) MAC spoofing and MAC attacks.
3) VLAN ID attacks.
The threats that concern the control plane are described in section
5.4.1 of [GELS-FRM] and are not relevant in the present context.
3. Solution Description
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.
+---------------------------+
| Payload |
+---------------------------+
| Ethernet |
+---------------------------+
| Physical |
+---------------------------+
Figure 4: Logical Protocol Layering Model
The Ethernet MAC frame header includes the EtherType, different VLAN
TAGs, as well as the destination and source MAC addresses.
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.
D.P. GELS Expires - July 2006 [Page 8]
Solution Decoder and Analysis for GELS Feb 2006
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.
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 following techniques are considered as candidate for the encoding
of the Ethernet label.
3.1 S-VID Translation
3.1.1 Label Encoding
This link-local label technique makes us of the IEEE 802.1ad S-VID
(amendment to IEEE Std 802.1Q-1998) S-VID translation mechanism.
The idea behind this solution is to prevent the control plane from
dealing with any MAC address space specifics such as to ensure
independence and transparency to the data plane addressing specifics.
This results in a straightforward re-use of the GMPLS Unified control
plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other
LSR currently manageable by a GMPLS-based control plane.
Figure 5 depicts the format of the standard IEEE 802.1ad Ethernet
frame.
TAG
---------
/ \
+-----------+------------+----+----+----+---------------+--------+
| | | | | | | |
| MAC Dest | MAC Src |TPID|TCI |LEN\| Payload | FCS |
| 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.
D.P. GELS Expires - July 2006 [Page 9]
Solution Decoder and Analysis for GELS Feb 2006
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.
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 PCP can be used in order to encode DiffServ parameters assuring
the DiffServ support for Ethernet LSP. In other words can be used as
the EXP filed of the MPLS shim header.
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.
3.1.2 Functional Behavior
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. The pre-processing operations may
include, for example, VID translation, VID insertion/stripping, etc.
These operations are beyond the scope of this document.
The pre-processed frame is then presented to the ingress E-LER
function. The latter takes an incoming pre-processed frame, 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.
Throughout the GMPLS-controlled Ethernet network, Ethernet LSRs
switches labeled Ethernet frames via the appropriate interface based
on the ingress port and the S-VID Ethernet label, which is encoded in
D.P. GELS Expires - July 2006 [Page 10]
Solution Decoder and Analysis for GELS Feb 2006
the standard IEEE 802.1 frame header. The switching operation
replaces the S-VID Ethernet label before the frame is transmitted.
Frames that are received with an unknown S-VID Ethernet label are
silently discarded. The forwarding decision is based on the
information residing in the FIB. This table may be configured by the
GMPLS control plane.
The egress E-LER terminates the Ethernet LSP by removing the S-VID
label from incoming frames received on a label-controlled interface,
if necessary extracts the payload, and presents the frame for
appropriate post-processing operations. Post-processing may include,
for example, VID translation, VID insertion/ stripping, etc. These
operations are beyond the scope of this specification. The frame is
then appropriately forwarded towards its destination via the
appropriate label-controlled interface.
The S-VID Ethernet label is part of the Ethernet MAC frame header and
has link local scope. The same S-VID Ethernet label can be reused on
different interface. The coding of the S-VID Ethernet label does not
modify the format of the standard Ethernet frame, although it may add
new semantics to one or more fields. No modification is made to the
layers over which the Ethernet payload may be transmitted.
The S-VID Ethernet labels are assigned and interpreted locally and
have local significance. This does not preclude the assignment of the
same S-VID Ethernet label value by consecutive hops. The S-VID
Ethernet labels can be used for the establishment and the support
of Ethernet LSPs over multiple domains and for the support of point-
to-multipoint Ethernet LSPs) to carry Ethernet multicast traffic.
End-to-end Ethernet connectivity can be used to provide any service
that is supported by standard Ethernet. These services are mapped in
the Ethernet LERs to an appropriate Ethernet LSP. The Ethernet frame
is extended with the S-VID Ethernet label when it is sent over the
Ethernet LSP. With Ethernet services, the C-VID (included in the C-
TAG) may, as an option, be transmitted transparently over the
Ethernet LSP (i.e. preserved over the network), depending on the
service definition.
3.1.3 Control Plane
GMPLS signaling is used to configure the S-VIDs along the nodes
traversed by the Ethernet point-to-point or point-to-multipoint LSP.
The idea behind this solution is to prevent the control plane from
dealing with any MAC address space specifics such as to ensure
independence and transparency to the data plane addressing specifics.
GMPLS is used to configure the 12-bit S-VID label during Ethernet LSP
provisioning.
D.P. GELS Expires - July 2006 [Page 11]
Solution Decoder and Analysis for GELS Feb 2006
This results in a straightforward re-use of the GMPLS unified control
plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other
LSR currently manageable by a GMPLS-based control plane.
This technique may coexist with Ethernet bridging in the same network
or on the same network element. On the same port, GMPLS controlled
Ethernet label switching method and Ethernet bridging may coexist as
long as the S-VID space is configurable (to discriminate between the
switching and bridging ranges). A future work will be undertaken to
automate this configuration process using RSVP-TE protocol (for inst.
by extending the capability of the label set object).
3.2 Stacked VLAN TAGs (QinQ) Translation
3.2.1 Label Encoding
Figure 7 depicts the format of the IEEE 802.1ad Ethernet frame with
Stacked VLAN TAGs (QinQ).
S-TAG C-TAG
-------- -------
/ \ / \
+----------+----------+----+----+----+----+----+---------------+---+
| | | | | | | | | |
| 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.
3.2.2 Functional Behavior
The Stacked VLAN TAG translation functional behavior is the same as
the S-VID translation functional behavior (see Section 3.1.1), except
for the label space, which is wider (24 bits). For details about the
functional behavior, refer to section 3.1.1 above, replacing the term
'S-VID Ethernet label' with the term 'Stacked VLAN TAG Ethernet
label'. In cases where the 4.096 link local S-VID label space is too
small, the stacked VLAN Ethernet label can be used.
D.P. GELS Expires - July 2006 [Page 12]
Solution Decoder and Analysis for GELS Feb 2006
Note that when the stacked VLAN Ethernet label is used for the
Ethernet LSP, only a small address range belonging to the outer VLAN
tag has to be assigned to the GMPLS-controlled Ethernet Label
switching. The available VLAN range for bridging services is
therefore hardly affected, while the GMPLS-controlled Ethernet Label
switching can use the full address range of the inner tag.
3.2.3 Control Plane
The idea behind this solution is to prevent the control plane from
dealing with any MAC address space specifics such as to ensure
independence and transparency to the data plane addressing specifics.
GMPLS is used to configure the 24-bit label during Ethernet LSP
provisioning.
This results in a straightforward re-use of the GMPLS unified control
plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other
LSR currently manageable by a GMPLS-based control plane.
3.3 Concatenated VID/MAC Domain-wide labels
3.3.1 Label Encoding
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. The control plane is
required to ensure loop freeness for the LSPs.
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.
3.3.2 Functional Behavior
Invariant VID/MAC domain-wide labels are proposed such as to enable
reuse the IEEE 802.1 compliant hardware and forwarding and provide
D.P. GELS Expires - July 2006 [Page 13]
Solution Decoder and Analysis for GELS Feb 2006
VLAN independent point-to-point LSPs. Aspects of the profile used
are:
1) That the ether-relay filter database (forwarding tables) can be
configured with static entries by a management system or control
plane
2) That static entries are not tied to any internal forwarding
identifier (FID) or spanning tree
3) That Ethernet LSRs may be VLAN partitioned such that a unique
topology per VLAN is possible a.k.a. independent VLAN learning (IVL)
4) The ability to disable MAC learning by VLAN ID
5) The ability to disable spanning tree by VLAN ID
6) The MAC addressed interfaces in the Ethernet frame header are
provider owned addresses and not related to customer MAC
terminations.
7) The VLAN ID space is the provider administered VLAN ID space
A pre-provisioned portion of the VLAN ID set (referred to as the
connection-oriented Ethernet VLAN ID subset) is decoupled from the
IEEE 802.1 spanning tree, and the use of the VIDs in this subset is
confined to unicast forwarding to guard against configuration errors
such that any loop free constraint for the connection-oriented
Ethernet VLAN ID subset has been removed. This subset is available
across the whole GMPLS-controlled Ethernet domain. The topology for
each of the delegated VIDs corresponds to the complete physical mesh
of the Ethernet subnetwork, and unique connectivity instance (P2P or
MP2P multiplex) to each MAC address is possible per VID.
One way to think of the meaning of a VID out of the pre-provisioned
VLAN ID subset is as an instance identifier for unique connectivity
to the specified MAC. This permits a plurality of uniquely routed
paths up to the connection-oriented Ethernet VLAN ID subset size to
any given MAC. Although VIDs are nominally thought of as global
identifiers for a VLAN, for the purposes of labeled Ethernet frame
forwarding, they behave as single modifiers bound to the destination
MAC address. Since MAC addresses are unique with in the scope of the
connected network, the VID-MAC tuple becomes a unique 60-bit label
that can be destination administered (see Label Encoding).
The ability to multiplex paths traveling to the same destination is a
desirable property to conserve forwarding state. This creates MP2P
connectivity as a tree of P2P connections rooted at a destination.
These multiplexed paths share a common VID-DA-MAC tuple yet retain
the identity of the source due to the inclusion of the SA-MAC. The
SA-MAC may be interpreted at the end of the path for additional
operations or when capturing packets at other points on the paths.
This is a useful property from the point of view of OAM fault and
performance management at the expense of performing SA-MAC address
lookup on a per-interface basis.
D.P. GELS Expires - July 2006 [Page 14]
Solution Decoder and Analysis for GELS Feb 2006
This technique is designed such as to relax a number of constraints
for the routing of MP2P connectivity:
- maintains the Ethernet encoding of priority information per-packet
permitting an Ethernet analogy to E-LSPs
- requires uni-directional paths which share the same physical
resources but allows independent VID assignments.
- allows resource reservation independently in both directions.
Provisioned LSPs are identified from originating to terminating
provider MAC interface. The service offered to the end points of an
Ethernet "connection" configured as outlined above is the ability to
transport any payload that can be identified via Ethernet LLC
multiplexing. A non exhaustive list would be:
- client Ethernet MAC frames (802.1ah, under IEEE 802.1 definition)
- MPLS
- IP, IPX, etc.
This technique mandates enforcement of unicast only traffic exchange
for the specified (pre-configured) VID range. Meaning that server
layer multicast replication of client multicast traffic is not
supported, although client multicast traffic may still be
encapsulated and transported P2P using this technique.
3.3.3 Control plane
GMPLS is used for the control of the point-to-point paths. We
recognize the requirement for a single control plane to manage the
point-to-multipoint paths as well (for multicast traffic). However
such objective is outside the scope of this document.
Using this label encoding technique, a portion of the VLAN ID space
in an IVL capable switch is delegated to a control or management
plane. The control plane is used to directly populate the filter
database with (VID)-(DA-MAC)-(egress port) tuples to configure
unicast forwarding of Ethernet frames. A given (VID)-(DA-MAC) tuple
resolving to a single egress port on a Ethernet LSR, and a connection
being composed of a contiguous set of Ethernet LSRs configured this
way.
The goal of bringing the work to the IETF is to use GMPLS as the
unified GMPLS control plane for point to point LSPs. GMPLS can take
the role of the control plane that populates the Ether-relay filter
database. The following GMPLS extensions are foreseen for GMPLS
support:
- use of the upstream label object to establish bi-directional paths
- optional use of suggested label
- use of the association object for signaling of protection switched
paths
D.P. GELS Expires - July 2006 [Page 15]
Solution Decoder and Analysis for GELS Feb 2006
- definition of a new label object C-type for the VID-MAC tuple
label
4. Comparison
Two techniques are currently proposed as solutions for the GELS,
VID/DA MAC switching (using VID/DA MAC domain wide invariant labels)
and VID switching (using VID/stacked VID link local labels).
The former (see Section 3.3) makes use of a 60-bit domain-wide label
which is built from the concatenation of the 48-bit destination MAC
address of the provider edge node (DA B-MAC) and the 12-bit provider
VID (B-VID). This solution is referred to as solution 1.
The latter (see section 3.1 and 3.2) makes use of one of the
following local labels: the 802.1ad 12-bit S-VID, and the 24-bit
label which is created from the 802.1ad stacked VLAN (Q-in-Q). The
characteristics of a domain-wide label and of a local scope label are
described and analyzed in the GELS framework. This solution is
referred to as solution 2.
This section attempts to examine, analyze and compare the candidate
solutions which are described in Section 3 according to the criteria
listed in Section 2. Note that for both techniques, the analysis and
comparison assume the use of GMPLS for enabling the provisioning and
maintenance of the Ethernet LSPs, in both techniques.
Note also that the third solution class (MAC-only labels) may be
considered in future version of this document.
4.1 Ethernet P2P and P2MP TE LSPs
Both solutions provide for Connection Oriented Ethernet. In both
techniques the network is pre-configured with the connections and the
resources are allocated and preserved. In both techniques the traffic
flow is identified by a connection identifier (label).
Solution 1 handles unidirectional and bi-directional point-to-point
Traffic Engineered Ethernet LSPs. However, it does not handle
unidirectional point-to-multipoint Traffic Engineered Ethernet LSPs.
The VID space is dedicated to unicast purposes due to the IVL
capability, which is based on unicast forwarding corroding to the B-
VID/B-MAC tuple. Note that while in general, VID spaces should be
independent of the type of the traffic, here, the VID dedicated space
is enforced for unicast purposes. So, multicast traffic support is to
provided by the legacy connectionless Ethernet forwarding.
D.P. GELS Expires - July 2006 [Page 16]
Solution Decoder and Analysis for GELS Feb 2006
Solution 2 handles unidirectional and bi-directional point-to-point
Traffic Engineered Ethernet LSPs and unidirectional point-to-
multipoint Traffic Engineered Ethernet LSPs.
Both solutions enable Traffic Engineering to optimize the network
resource usage.
4.2 Ethernet LSP Merging and LSP Multiplexing
In Solution 1 due to the nature of the label which is constructed
from the DA B-MAC address and the B-VID, connections may be
multiplexed along the way to the destination. However, due to the
label structure there is no possibility to avoid data plane merging
that violates the end-to-end guaranteed BW per LSP. Although the
Ethernet encoding of priority information is reserved per-packet, the
end-to-end guaranteed bandwidth for a specific LSP can be violated
and used by other LSPs multiplexed into the same path (for example
with higher priority packets). In order to avoid Ethernet LSP
multiplexing and in order to guarantee end-to-end bandwidth per LSP a
different label should be assigned to each LSP (e.g. either a
different DA B-MAC address should be assigned to each LSP or a
different B-VID should be assigned to each LSP).
Solution 2 provides end-to-end QoS with guaranteed bandwidth and
controlled jitter and delay based on the service definition to
enforce the SLA. Solution 2 provides a simple method for
multiplexing: each Ethernet LSR should assign a unique label to each
particular source (label assigned on a per sender basis).
4.3 Services
In Solution 1, frames are mapped at the Ethernet LER to LSPs
according to the port on which the frames were received or according
to the outer VID.
In Solution 2, frames are mapped at the Ethernet LER to LSPs
according to the port on which the frames were received and the VID
of the outer VID.
Both solutions are capable to provide any connectivity service that
is supported by standard Ethernet encapsulation (such as IP/MPLS,
TDM, etc.).
The solutions are positioned as follows for what it concerns service
provisioning and maintenance:
o) In Solution 1, a pool of unique MAC addresses and a range of VIDs
should be configured at the provider Ethernet LER. LERs should also
manage VID/MAC address relation. The label has a domain wide
D.P. GELS Expires - July 2006 [Page 17]
Solution Decoder and Analysis for GELS Feb 2006
significance. Any modification to a label or addition of a new label
is circulated across the network.
In Solution 2, only a range of VIDs that should be used for switching
purposes technique should be configured at each Ethernet LSR. When an
Ethernet LSP is provisioned across the network, each node along the
path arbitrarily allocates a free label for the LSP. The label has
only link local significance.
o) Both solutions provide network trunks (nesting LSPs) in order to
simplify the delivery of services across the network. Theoretically
the number of services that may be transmitted within the tunnels is
unlimited.
o) Both solutions employ OAM and provide a means to minimize the
number of LSPs to be monitored. Only network trunks should be
actively monitored. Services may be monitored according to specific
service requirements.
With Solution 2 (12-bit), up to 4K tunnels may be provisioned per
port. Within each port up to 4K services can be delivered. With
Solution 2 (24-bit), up to 16M tunnels may be provisioned per port.
Other combinations are possible as well. Using this solution, LSPs
can also be used to deliver services (with no tunneling). This
capability has a benefit in particular network scenarios, where there
is no need for the overhead of tunnel provisioning and superfluous
encapsulation.
4.4 OAM
Solution 1 requires unicast CC OAM messages which are currently not
defined or implemented. Moreover, when using this solution, the SA-
MAC can be captured at intermediate Ethernet LSRs or at the egress
Ethernet LER to detect misconnectivity where traffic from one LSP is
leaked into another LSP. Note that misconnectivity can occur due to
misconfigurations.
Solution 2 enables the support of OAM (IEEE 802.1ag) messages, to
ensure the correct operation of the network. CC OAM frames are
transmitted within the LSP and will reach their destination. Each LSP
is identified by an end-to-end connection identifier (5-tuple). The
customer's information may be interpreted to detect misconnectivity.
OAM messages are sent along the path to detect failures or problems
in the network.
4.5 Resiliency
Both Solutions provide mechanisms for matching the sub 50 ms failover
times required for maintaining time-bounded services.
D.P. GELS Expires - July 2006 [Page 18]
Solution Decoder and Analysis for GELS Feb 2006
Due to the domain-wide nature of the label used in Solution 1,
certain recovery mechanisms that are provided by the GMPLS can not be
applied in case of domain-wide VID/MAC label (e.g. 1:1 fast reroute
which apply two different labels for the protected and the detour
LSPs, etc.).
In case of LSPs over multiple domains (i.e. inter-domain), Solution 1
can not protect against a failure of an edge node (which connects to
other domains). This is true for each of the three recovery
techniques (unless dual homing is supported, but this complicated
solution should be proven to work).
Solution 2 supports all three LSP recovery techniques: global (end-
to-end), segment and local. This solution provides mechanism to
protect against any failure in the network (including failure of
boundary nodes in case of an inter-domain operation).
4.6 Inter-domain
Both solutions enable the provisioning Ethernet LSPs across multiple
domains (inter-domain). Both techniques support the peering and the
client/server interconnection modes.
In Solution 1, when peering is supported, the network trunk is
terminated at the edge of a domain. The services may be processed
according to one of the following VIDs: C-VID, or S-VID or I-SID. The
I-SID may be translated to S-TAG, limiting to 4094 service instances
across an E-NNI. It may be translated to a DMZ value, limiting to
2**24 service instances across an E-NNI. In any case, note that as
the 802.1ah is not final yet, the I-SID processing is not defined.
The [CCAMP-ID-FRM] defines three options for signaling TE LSPs across
multiple domains, as follows: LSP nesting (client/server mode),
contiguous LSP (peering mode) and LSP stitching (peering mode).
In Solution 1, the contiguous LSP option will probably not be
supported because of the domain-wide nature of the label. If
supported, the carriers' would have to offer each other globally
unique label. In such a case, the label would come from each
carrier's administrative space (MAC address of the terminating
interface).
In Solution 2, all the three signaling options are supported.
4.7 Scalability
4.7.1 MAC Address
D.P. GELS Expires - July 2006 [Page 19]
Solution Decoder and Analysis for GELS Feb 2006
Both solutions disable MAC learning for the VID range that is
supported for connection-oriented Ethernet purposes. Thus, the flush
FIB operation associated with topology change and flooding
operations, which leads to slow recovery and convergence, is
eliminated.
The switching operation in both techniques is independent of the
destination subscriber MAC address.
4.7.2 VLAN ID (VID)
In Solution 1, the VID in conjunction to the DA B-MAC is used as
domain-wide label. As specified above, in order to avoid the LSP
multiplexing and guarantee end-to-end BW per LSP, a different label
should be assigned to each LSP. Hence, either a different B-VID or a
different DA B-MAC address should be assigned to each LSP between a
particular pair of source and destination Ethernet LERs. In case of a
different DA B-MAC address, it requires the provisioning of a pool of
MAC addresses per pair (source and destination) of Ethernet LERs
dependent on the required number of LSPs that should be provisioned
between this pair of Ethernet LERs. In case of a different B-VID, it
violates the VLAN scalability. The space of the VID is limited per
node and a certain range of VIDs should be assigned to the bridging
function (in order to provide for example multicast services, etc.).
In Solution 2, the VID label has link local significance and can be
reused on different interface (per interface label spaces similar to
ATMs VCI/VPI or MPLSs label space). The label space can reach a
maximum of 4K VIDs per port if the 12_bit S-VID labels is used and a
maximum of 16M VIDs if 24-bit labels are used.
4.7.3 Ethernet Frame Switching
Both solutions do not rely on the customers' destination MAC
addresses.
4.7.4 Label
Both solutions encode the Ethernet label as part of the Ethernet MAC
frame header.
Solution 1 makes use of the 802.1ah frame format: 48 bits SA B-MAC
address, 48 bits DA B-MAC address, 32 bits B-TAG and 24-bit I-SID.
The label being a combination of the DA B-MAC and the B-VID is 60-
bits long.
Solution 2 makes use of the 802.1ad frame format. This requires a 32-
bit S-TAG to encode the S-VID label or 64-bit S-TAG + C-TAG to encode
the extended the 24-bit label (composed by the S-VID and C-VID).
D.P. GELS Expires - July 2006 [Page 20]
Solution Decoder and Analysis for GELS Feb 2006
In solution 1, the label space has a 60-bit length and has a domain
wide significance. The implication on the number of LSPs that can be
provisioned in the network is not trivial. Theoretically, this number
is 2^60. Practically, this requires a tedious provisioning effort.
Depending on the connectivity, a varying set of MAC addresses should
be manually configured.
In solution 2, the number of LSPs that can be provisioned depends on
the label type. With S-VIDs, up to 4K LSPs per port can be
provisioned. With 24-bit labels up to 16M LSPs per port can be
provisioned.
In addition, the label length and space size also affects the
implementation of the FID's lookup table. In Solution 1, the key to
the lookup table is 60-bits long. In Solution 2, it is either 12-bits
or 24-bits long.
4.7.5 LSP Hierarchy
TBD.
4.8 Backward compatibility with IEEE 802.1
Both label encoding techniques make use of the structure of the
standard IEEE 802.1 Ethernet frame. Both solutions do not modify the
format of the standard Ethernet frame, but do add new semantics to
one or more fields.
4.9 Applicability
1) Metro access and Metro aggregation networks
The Metro access and the metro aggregation networks by nature are
small networks which are characterized by having a small number of
nodes deployed at the network. The role of that metro access/metro
aggregation network is to provide connectivity between a user and a
service platform (e.g. BRAS, edge router, etc.).
Employing Solution 1 in such environment adds a lot of overhead in
the network (e.g. MAC encapsulation), and increases CAPEX, without
apparent benefits. The idea behind this solution is to increase CAPEX
at the edge of the network in order to reduce CAPEX at the core of
the network. In typical Metro access/Metro aggregation networks there
are hardly any core routers (if at all) while there are many edge
nodes.
In addition, both DSLAMs and BRAS do not handle IEEE 802.1ah frames.
They are only capable of extracting/adding one or two VLAN TAGs. It
D.P. GELS Expires - July 2006 [Page 21]
Solution Decoder and Analysis for GELS Feb 2006
is thus appropriate to make use of these VLAN TAGs and perform VID
switching using the same encapsulation than those provided by the
DSLAM and the BRAS. Solution 2 is more appropriate for residential
services, where the BRAS handle the two VLAN TAGs, which identify the
customer. Hence, Solution 2 is more suitable for metro access/metro
aggregation networks than Solution 1.
2) Metro-core
The metro core is a larger network and its role is to connect several
metro access/metro aggregation networks.
Both Solutions can be deployed at the metro-core networks. Both
provide connection-oriented Ethernet with tunneling mechanisms. The
selection of the specific technique that should be deployed should be
based on the solution analysis described in this document.
3) Core and Transport networks
Same observation as for Metro-core applies.
4.10 Security
In both techniques the number of network entry points is reduced.
Policing and filtering are provided on the provider edge nodes. Some
mechanisms may be provided at the network edges to rate limit the
amount of traffic that can be transmitted into a given Ethernet LSP.
Solution 1 switches on MAC addresses hence mandating the use of MAC-
in-MAC encapsulation to resolve issues associated with MAC addresses.
Solution 2 inherently eliminates security issues on MAC addresses
(MAC spoofing and MAC attack) because it is agnostic to MAC
addresses.
Both solutions eliminate security issues associated with VLAN TAGs.
At the provider edge, customers are attached to the provider network
via particular VLANs on a particular port. Frames with other VLANs
will be blocked. Across the network, only the VLAN Identifier(s)
added by the provider edge node is/are inspected. Any other nested
VLAN has no meaning across the provider network.
5. Conclusion
The proposed solutions have been analyzed and compared according to
the criteria, which were defined for this purpose.
D.P. GELS Expires - July 2006 [Page 22]
Solution Decoder and Analysis for GELS Feb 2006
According to the analysis, the solution that better complies to the
GELS requirements, as well as better addresses the GELS motivations
and objectives should be identifiable.
It may be that different solutions have to be selected for example to
satisfy different network scenarios or/and different applications. In
such a case, a specific label encoding technique should be selected
according to the capability of the GMPLS-enabled Ethernet network
element and/or the capability of the label-controlled Ethernet
interface. Hence, leaving the possibility for adopting different
solutions for GELS. It may also be that the solutions complement each
other, and for example should be deployed in different network areas.
In any case, it is recommended that the GELS define an extensible
solution which will leave room for future definitions, especially
since the Carrier Grade Ethernet solution is currently under
investigation by service providers.
Please comment on the <gels@rtg.ietf.org> mailing list.
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.
[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",
D.P. GELS Expires - July 2006 [Page 23]
Solution Decoder and Analysis for GELS Feb 2006
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
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
Don Fedyk
D.P. GELS Expires - July 2006 [Page 24]
Solution Decoder and Analysis for GELS Feb 2006
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
D.P. GELS Expires - July 2006 [Page 25]
Solution Decoder and Analysis for GELS 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 26]