draft-ietf-ccamp-gmpls-ethernet-arch-09.txt   rfc5828.txt 
Internet Draft Don Fedyk, Alcatel-Lucent
Category: Informational Lou Berger, LabN
Expiration Date: July 14, 2010 Loa Andersson, Ericsson AB
January 14, 2010 Internet Engineering Task Force (IETF) D. Fedyk
Request for Comments: 5828 Alcatel-Lucent
Category: Informational L. Berger
ISSN: 2070-1721 LabN
L. Andersson
Ericsson
March 2010
Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Generalized Multiprotocol Label Switching (GMPLS) Ethernet
Label Switching Architecture and Framework Label Switching Architecture and Framework
draft-ietf-ccamp-gmpls-ethernet-arch-09.txt Abstract
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering There has been significant recent work in increasing the capabilities
Task Force (IETF), its areas, and its working groups. Note that of Ethernet switches and Ethernet forwarding models. As a
other groups may also distribute working documents as Internet- consequence, the role of Ethernet is rapidly expanding into
Drafts. "transport networks" that previously were the domain of other
technologies such as Synchronous Optical Network (SONET) /
Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing
(TDM), and Asynchronous Transfer Mode (ATM). This document defines
an architecture and framework for a Generalized-MPLS-based control
plane for Ethernet in this "transport network" capacity. GMPLS has
already been specified for similar technologies. Some additional
extensions to the GMPLS control plane are needed, and this document
provides a framework for these extensions.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/1id-abstracts.html published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on July 14, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5828.
Copyright and License Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
There has been significant recent work in increasing the capabilities described in the Simplified BSD License.
of Ethernet switches and Ethernet forwarding models. As a
consequence, the role of Ethernet is rapidly expanding into
"transport networks" that previously were the domain of other
technologies such as Synchronous Optical Network (SONET)/Synchronous
Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and
Asynchronous Transfer Mode (ATM). This document defines an
architecture and framework for a Generalized MPLS based control plane
for Ethernet in this "transport network" capacity. GMPLS has already
been specified for similar technologies. Some additional extensions
to the GMPLS control plane are needed and this document provides a
framework for these extensions.
Table of Contents Table of Contents
1 Introduction ........................................... 4 1. Introduction ....................................................3
1.1 Terminology ............................................ 6 1.1. Terminology ................................................5
1.1.1 Concepts ............................................... 6 1.1.1. Concepts ............................................5
1.1.2 Abbreviations and Acronyms ............................. 7 1.1.2. Abbreviations and Acronyms ..........................6
2 Background ............................................. 8 2. Background ......................................................7
2.1 Ethernet Switching ..................................... 8 2.1. Ethernet Switching .........................................7
2.2 Operations, Administration, and Maintenance (OAM) ...... 11 2.2. Operations, Administration, and Maintenance (OAM) .........10
2.3 Ethernet Switching Characteristics ..................... 11 2.3. Ethernet Switching Characteristics ........................10
3 Framework .............................................. 12 3. Framework ......................................................11
4 GMPLS Routing and Addressing Model ..................... 14 4. GMPLS Routing and Addressing Model .............................13
4.1 GMPLS Routing .......................................... 14 4.1. GMPLS Routing .............................................13
4.2 Control Plane Network .................................. 15 4.2. Control Plane Network .....................................14
5 GMPLS Signaling ........................................ 15 5. GMPLS Signaling ................................................14
6 Link Management ........................................ 16 6. Link Management ................................................15
7 Path Computation and Selection ......................... 17 7. Path Computation and Selection .................................16
8 Multiple VLANs ......................................... 18 8. Multiple VLANs .................................................17
9 Security Considerations ................................ 18 9. Security Considerations ........................................17
10 IANA Considerations .................................... 19 10. References ....................................................18
11 References ............................................. 19 10.1. Normative References .....................................18
11.1 Normative References ................................... 19 10.2. Informative References ...................................18
11.2 Informative References ................................. 19 11. Acknowledgments ...............................................20
12 Acknowledgments ........................................ 21
13 Author's Addresses ..................................... 21
1. Introduction 1. Introduction
There has been significant recent work in increasing the capabilities There has been significant recent work in increasing the capabilities
of Ethernet switches. As a consequence, the role of Ethernet is of Ethernet switches. As a consequence, the role of Ethernet is
rapidly expanding into "transport networks" that previously were the rapidly expanding into "transport networks" that previously were the
domain of other technologies such as SONET/SDH, TDM and ATM. The domain of other technologies such as SONET/SDH, TDM, and ATM. The
evolution and development of Ethernet capabilities in these areas is evolution and development of Ethernet capabilities in these areas is
a very active and ongoing process. a very active and ongoing process.
Multiple organizations have been active in extending Ethernet Multiple organizations have been active in extending Ethernet
Technology to support transport networks. This activity has taken technology to support transport networks. This activity has taken
place in the Institute of Electrical and Electronics Engineers (IEEE) place in the Institute of Electrical and Electronics Engineers (IEEE)
802.1 Working Group, the International Telecommunication Union - 802.1 Working Group, the International Telecommunication Union -
Telecommunication Standardization Sector (ITU-T) and the Metro Telecommunication Standardization Sector (ITU-T) and the Metro
Ethernet Forum (MEF). These groups have been focusing on Ethernet Ethernet Forum (MEF). These groups have been focusing on Ethernet
forwarding, Ethernet management plane extensions and the Ethernet forwarding, Ethernet management plane extensions, and the Ethernet
Spanning Tree Control Plane, but not on an explicitly routed, Spanning Tree Control Plane, but not on an explicitly routed,
constraint-based control plane. constraint-based control plane.
In the forwarding plane context, extensions have been, or are being, In the forwarding-plane context, extensions have been, or are being,
defined to support different transport Ethernet forwarding models, defined to support different transport Ethernet forwarding models,
protection modes, and service interfaces. Examples of such protection modes, and service interfaces. Examples of such
extensions include [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These extensions include [802.1ah], [802.1Qay], [G.8011], and [MEF.6].
extensions allow for greater flexibility in the Ethernet forwarding These extensions allow for greater flexibility in the Ethernet
plane and, in some cases, the extensions allow for a departure from forwarding plane and, in some cases, the extensions allow for a
forwarding based on Spanning tree. For example, in the [802.1Qah] departure from forwarding based on a spanning tree. For example, in
case, greater flexibility in forwarding is achieved through the the [802.1ah] case, greater flexibility in forwarding is achieved
addition of a "provider" address space. [802.1Qay] supports the use through the addition of a "provider" address space. [802.1Qay]
of provisioning systems and network control protocols that explicitly supports the use of provisioning systems and network control
select traffic engineered paths. protocols that explicitly select traffic-engineered paths.
This document provides a framework for GMPLS Ethernet Label Switching This document provides a framework for GMPLS Ethernet Label Switching
(GELS). GELS will likely require more than one switching type to (GELS). GELS will likely require more than one switching type to
support the different models, and as the GMPLS procedures that will support the different models, and as the GMPLS procedures that will
need to be extended are dependent on switching type, these will be need to be extended are dependent on switching type, these will be
covered in the technology specific documents. covered in the technology-specific documents.
In the provider bridge model developed in the IEEE 802.1ad project In the provider bridge model developed in the IEEE 802.1ad project
and amended to the IEEE 802.1Q standard [802.1Q], an extra Virtual and amended to the IEEE 802.1Q standard [802.1Q], an extra Virtual
Local Area Network (VLAN) identifier (VID) is added. This VLAN is Local Area Network (VLAN) identifier (VID) is added. This VID is
referred to as the Service VID, (S-VID) and is carried in a Service referred to as the Service VID (S-VID) and is carried in a Service
TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah], a backbone TAG (S-TAG). In Provider Backbone Bridges (PBBs) [802.1ah], a
VID (B-VID) and B-MAC header with a service instance (I-TAG) Backbone VID (B-VID) and B-MAC header with a service instance (I-TAG)
encapsulates a customer Ethernet frame or a service Ethernet frame. encapsulate a customer Ethernet frame or a service Ethernet frame.
In the IEEE 802.1Q standard the terms Provider Backbone Bridges (PBB) In the IEEE 802.1Q standard, the terms Provider Backbone Bridges
and Provider Backbone Bridged Network (PBBN) are used in the context (PBBs) and Provider Backbone Bridged Network (PBBN) are used in the
of these extensions. context of these extensions.
An example of Ethernet protection extensions can be found in An example of Ethernet protection extensions can be found in
[G.8031]. Ethernet operations, administration, and maintenance (OAM) [G.8031]. Ethernet operations, administration, and maintenance (OAM)
is another important area that is being extended to enable provider is another important area that is being extended to enable provider
Ethernet services. Related extensions can be found in [802.1ag] and Ethernet services. Related extensions can be found in [802.1ag] and
[Y.1731]. [Y.1731].
An Ethernet based service model is being defined within the context An Ethernet-based service model is being defined within the context
of the MEF and ITU-T. [MEF.6] and [G.8011] provide parallel of the MEF and ITU-T. [MEF.6] and [G.8011] provide parallel
frameworks for defining network-oriented characteristics of Ethernet frameworks for defining network-oriented characteristics of Ethernet
services in transport networks. These framework documents discuss services in transport networks. These framework documents discuss
general Ethernet connection characteristics, Ethernet User-Network general Ethernet connection characteristics, Ethernet User-Network
Interfaces (UNIs) and Ethernet Network-Network Interfaces (NNIs). Interfaces (UNIs), and Ethernet Network-Network Interfaces (NNIs).
[G.8011.1] defines the Ethernet Private Line (EPL) service and [G.8011.1] defines the Ethernet Private Line (EPL) service, and
[G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service. [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service.
[MEF.6] covers both service types. These activities are consistent [MEF.6] covers both service types. These activities are consistent
with the types of Ethernet switching defined in [802.1ah]. with the types of Ethernet switching defined in [802.1ah].
The Ethernet forwarding and management plane extensions allow for the The Ethernet forwarding-plane and management-plane extensions allow
disabling of standard Spanning tree but do not define an explicitly for the disabling of standard Spanning Tree Protocols but do not
routed, constraint-based control plane. For example [802.1Qay] is an define an explicitly routed, constraint-based control plane. For
amendment to IEEE 802.1Q that explicitly allows for traffic example, [802.1Qay] is an amendment to IEEE 802.1Q that explicitly
engineering of Ethernet forwarding paths. allows for traffic engineering of Ethernet forwarding paths.
The IETF's GMPLS work provides a common control plane for different The IETF's GMPLS work provides a common control plane for different
data plane technologies for Internet and telecommunication service data-plane technologies for Internet and telecommunication service
providers. The GMPLS architecture is specified in RFC3945 [RFC3945]. providers. The GMPLS architecture is specified in RFC 3945
The protocols specified for GMPLS can be used to control "Transport [RFC3945]. The protocols specified for GMPLS can be used to control
Network" technologies, e.g. Optical and TDM networks. GMPLS can also "Transport Network" technologies, e.g., optical and TDM networks.
be used for packet and Layer 2 Switching (frame/cell based networks). GMPLS can also be used for packet and Layer 2 Switching (frame/cell-
based networks).
This document provides a framework for use of GMPLS to control This document provides a framework for the use of GMPLS to control
"transport" Ethernet Label Switched Paths (Eth-LSP). Transport "transport" Ethernet Label Switched Paths (Eth-LSPs). Transport
Ethernet adds new constraints which require it to be distinguished Ethernet adds new constraints that require it to be distinguished
from the previously specified technologies for GMPLS. Some additional from the previously specified technologies for GMPLS. Some
extensions to the GMPLS control plane are needed and this document additional extensions to the GMPLS control plane are needed, and this
provides a framework for these extensions. All extensions to support document provides a framework for these extensions. All extensions
Eth-LSPs will build on the GMPLS architecture and related to support Eth-LSPs will build on the GMPLS architecture and related
specifications. specifications.
This document introduces and explains GMPLS control plane use for This document introduces and explains GMPLS control plane use for
transport Ethernet and the concept of the Ethernet Label Switched transport Ethernet and the concept of the Eth-LSP. The data-plane
Path (Eth-LSP). The data plane aspects of Eth-LSPs are outside the aspects of Eth-LSPs are outside the scope of this document and IETF
scope of this document and IETF activities. activities.
The intent of this document is to reuse and align with as much of the The intent of this document is to reuse and be aligned with as much
GMPLS protocols as possible. For example, reusing the IP control of the GMPLS protocols as possible. For example, reusing the IP
plane addressing allows existing signaling, routing, LMP and path control-plane addressing allows existing signaling, routing, Link
computation to be used as specified. The GMPLS protocols support Management Protocol (LMP), and path computation to be used as
hierarchical LSPs as well as contiguous LSPs. Also, GMPLS protocol specified. The GMPLS protocols support hierarchical LSPs as well as
mechanisms support a variety of network reference points from UNIs to contiguous LSPs. Also, GMPLS protocol mechanisms support a variety
NNIs. Additions to existing GMPLS capabilities will only be made to of network reference points from UNIs to NNIs. Additions to existing
accommodate features unique to transport Ethernet. GMPLS capabilities will only be made to accommodate features unique
to transport Ethernet.
1.1. Terminology 1.1. Terminology
1.1.1. Concepts 1.1.1. Concepts
The following are basic Ethernet and GMPLS terms: The following are basic Ethernet and GMPLS terms:
o Asymmetric Bandwidth o Asymmetric Bandwidth
This term refers to a property of a Bidirectional service This term refers to a property of a bidirectional service instance
instance that has differing bandwidth allocation in each that has differing bandwidth allocation in each direction.
direction.
o Bidirectional Congruent LSP o Bidirectional congruent LSP
This term refers to the property of a bidirectional LSP that uses This term refers to the property of a bidirectional LSP that uses
only the same nodes, ports, and links in both directions. only the same nodes, ports, and links in both directions. Ethernet
Ethernet data planes are normally bidirectional congruent data planes are normally bidirectional congruent (sometimes known
(sometimes known as reverse path congruent). as reverse path congruent).
o Contiguous Eth-LSP o Contiguous Eth-LSP
A contiguous Eth-LSP is an end-to-end Eth-LSP that is formed from A contiguous Eth-LSP is an end-to-end Eth-LSP that is formed from
multiple Eth-LSPs each operating within a VLAN and that are multiple Eth-LSPs, each of which is operating within a VLAN and is
mapped one-to-one at the VLAN boundaries. Stitched LSPs form mapped one-to-one at the VLAN boundaries. Stitched LSPs form
contiguous LSPs. contiguous LSPs.
o Eth-LSP o Eth-LSP
This term refers to Ethernet label switched paths that may be This term refers to Ethernet Label Switched Paths that may be
controlled via GMPLS. controlled via GMPLS.
o Hierarchical Eth-LSP o Hierarchical Eth-LSP
Hierarchical Eth-LSPs aggregate Eth-LSPs by creating a hierarchy Hierarchical Eth-LSPs create a hierarchy of Eth-LSPs.
of Eth-LSPs.
o In-band GMPLS Signaling o In-band GMPLS signaling
In-band GMPLS Signaling is IP based control messages which are In-band GMPLS signaling is composed of IP-based control messages
sent on the native Ethernet links encapsulated by a single hop that are sent on the native Ethernet links encapsulated by a
Ethernet header. Logical links that use a dedicated VID on the single-hop Ethernet header. Logical links that use a dedicated VID
same physical links would be considered In-band signaling. on the same physical links would be considered in-band signaling.
o Out-of-band GMPLS Signaling o Out-of-band GMPLS signaling
Out-of-band GMPLS Signaling is composed of IP based control Out-of-band GMPLS signaling is composed of IP-based control
messages that are sent between Ethernet switches over links other messages that are sent between Ethernet switches over links other
than the links used by the Ethernet data plane. Out of band than the links used by the Ethernet data plane. Out-of-band
signaling typically shares a different fate from the data links. signaling typically shares a different fate from the data links.
o Point-to-point (P2P) Traffic Engineering (TE) service instance o Point-to-point (P2P) Traffic Engineering (TE) service instance
A TE service instance made up of a single bidirectional P2P or A TE service instance made up of a single bidirectional P2P or two
two P2P unidirectional Eth-LSPs. P2P unidirectional Eth-LSPs.
o Point-to-multipoint (P2MP) Traffic Engineering (TE) service o Point-to-multipoint (P2MP) Traffic Engineering (TE) service
instance instance
A TE service instance supported by a set of LSPs which comprises A TE service instance supported by a set of LSPs that comprises one
one P2MP LSP from a root to n leaves plus a Bidirectional P2MP LSP from a root to n leaves, plus a bidirectional congruent
Congruent point-to-point (P2P) LSP from each of the leaves to the point-to-point (P2P) LSP from each of the leaves to the root.
root.
o Shared forwarding o Shared forwarding
Shared forwarding is a property of a data path where a single Shared forwarding is a property of a data path where a single
forwarding entry (VID + DMAC) may be used for frames from forwarding entry (VID + Destination MAC address) may be used for
multiple sources (SMAC). Shared forwarding does not change any frames from multiple sources (Source MAC addresses). Shared
data plane behavior. Shared forwarding saves forwarding database forwarding does not change any data-plane behavior. Shared
(FDB) entries only. Shared forwarding offers similar benefits to forwarding saves forwarding database (FDB) entries only. Shared
merging in the data plane. However in shared forwarding the forwarding offers similar benefits to merging in the data plane.
Ethernet data packets are unchanged when using shared forwarding. However, in shared forwarding, the Ethernet data packets are
With shared forwarding dedicated control plane states for all unchanged. With shared forwarding, dedicated control-plane states
Eth-LSPs are maintained regardless of shared forwarding entries. for all Eth-LSPs are maintained regardless of shared forwarding
entries.
1.1.2. Abbreviations and Acronyms 1.1.2. Abbreviations and Acronyms
The following abbreviations and acronyms are used in this document: The following abbreviations and acronyms are used in this document:
CCM Continuity Check Message CCM Continuity Check Message
CFM Connectivity Fault Management CFM Connectivity Fault Management
DMAC Destination MAC Address DMAC Destination MAC Address
Eth-LSP Ethernet Label Switched Path Eth-LSP Ethernet Label Switched Path
I-SID Backbone Service Identifier carried in the I-TAG I-SID Backbone Service Identifier carried in the I-TAG
I-TAG A Backbone Service Instance TAG defined in the I-TAG A Backbone Service Instance TAG defined in the
IEEE 802.1ah Standard [802.1ah] IEEE 802.1ah Standard [802.1ah]
LMP Link Management Protocol LMP Link Management Protocol
MAC Media Access Control MAC Media Access Control
MP2MP Multipoint to multipoint MP2MP Multipoint to multipoint
NMS Network Management System NMS Network Management System
OAM Operations, Administration and Maintenance OAM Operations, Administration, and Maintenance
PBB Provider Backbone Bridges [802.1ah] PBB Provider Backbone Bridges [802.1ah]
PBB-TE Provider Backbone Bridges Traffic Engineering PBB-TE Provider Backbone Bridges Traffic Engineering
[802.1Qay] [802.1Qay]
P2P Point to Point P2P Point to Point
P2MP Point to Multipoint P2MP Point to Multipoint
QoS Quality of Service QoS Quality of Service
SMAC Source MAC Address SMAC Source MAC Address
S-TAG A Service TAG defined in the IEEE 802.1 Standard S-TAG A Service TAG defined in the IEEE 802.1 Standard
[802.1Q] [802.1Q]
TE Traffic Engineering TE Traffic Engineering
TAG An Ethernet short form for a TAG Header TAG An Ethernet short form for a TAG Header
TAG Header An extension to an Ethernet frame carrying TAG Header An extension to an Ethernet frame carrying
priority and other information. priority and other information
TSpec Traffic specification TSpec Traffic specification
VID VLAN Identifier VID VLAN Identifier
VLAN Virtual LAN VLAN Virtual LAN
2. Background 2. Background
This section provides background to the types of switching and This section provides background to the types of switching and
services that are supported within the defined framework. The former services that are supported within the defined framework. The former
is particularly important as it identifies the switching functions is particularly important as it identifies the switching functions
that GMPLS will need to represent and control. The intent is for this that GMPLS will need to represent and control. The intent is for
document to allow for all standard forms of Ethernet switching and this document to allow for all standard forms of Ethernet switching
services. and services.
The material presented in this section is based on both finished and The material presented in this section is based on both finished and
on-going work taking place in the IEEE 802.1 Working Group, the ITU-T ongoing work taking place in the IEEE 802.1 Working Group, the ITU-T,
and the MEF. This section references and, to some degree, summarizes and the MEF. This section references and, to some degree, summarizes
that work. This section is not a replacement for, or an that work. This section is not a replacement for or an authoritative
authoritative description of that work. description of that work.
2.1. Ethernet Switching 2.1. Ethernet Switching
In Ethernet switching terminology, the bridge relay is responsible In Ethernet switching terminology, the bridge relay is responsible
for forwarding and replicating the frames. Bridge relays forward for forwarding and replicating the frames. Bridge relays forward
frames based on the Ethernet header fields: Virtual Local Area frames based on the Ethernet header fields: Virtual Local Area
Network (VLAN) Identifiers (VID) and Destination Media Access Control Network (VLAN) Identifiers (VIDs) and Destination Media Access
(DMAC) address. PBB [802.1ah] has also introduced a Service Instance Control (DMAC) address. PBB [802.1ah] has also introduced a Service
tag (I-TAG). Across all the Ethernet extensions (already referenced Instance tag (I-TAG). Across all the Ethernet extensions (already
in the Introduction), multiple forwarding functions, or service referenced in the Introduction), multiple forwarding functions, or
interfaces, have been defined using the combination of VIDs, DMACs, service interfaces, have been defined using the combination of VIDs,
and I-TAGs. PBB [802.1ah] provides a breakdown of the different DMACs, and I-TAGs. PBB [802.1ah] provides a breakdown of the
types of Ethernet switching services. Figure 1 reproduces this different types of Ethernet switching services. Figure 1 reproduces
breakdown. this breakdown.
PBB Network PBB Network
Service Types Service Types
_,,-' | '--.._ _,,-' | '--.._
_,.-'' | `'--.._ _,.-'' | `'--.._
_,.--' | `'--.. _,.--' | `'--..
Port based S-tagged I-tagged Port based S-tagged I-tagged
_,- -. _,- -.
_.' `. _.' `.
_,' `. _,' `.
one-to-one bundled one-to-one bundled
_.- =. _.- =.
_.-' ``-.._ _.-' ``-.._
_.-' `-.. _.-' `-..
many-to-one all-to-one many-to-one all-to-one
| |
| |
| |
Transparent Transparent
Figure 1: Ethernet Switching Service Types Figure 1: Ethernet Switching Service Types
The switching types are defined in Clause 25 of [802.1ah]. While not The switching types are defined in Clause 25 of [802.1ah]. While not
specifically described in [802.1ah], the Ethernet services being specifically described in [802.1ah], the Ethernet services being
defined in the context of [MEF.6] and [G.8011] also fall into the defined in the context of [MEF.6] and [G.8011] also fall into the
types defined in Figure 1 (with the exception of the newly defined I- types defined in Figure 1 (with the exception of the newly defined
tagged service type). I-tagged service type).
[802.1ah] defines a new I-tagged service type but does not [802.1ah] defines a new I-tagged service type but does not
specifically define the Ethernet services being defined in the specifically define the Ethernet services being defined in the
context of [MEF.6] and [G.8011] which are also illustrated in Figure context of [MEF.6] and [G.8011], which are also illustrated in Figure
1. 1.
To summarize the definitions: To summarize the definitions:
o Port based o Port based
This is a frame based service that supports specific frame types,
no Service VLAN tagging or MAC address based switching. This is a frame-based service that supports specific frame types;
no Service VLAN tagging or MAC-address-based switching.
o S-tagged o S-tagged
There are multiple Service VLAN tag (S-tag) aware services,
including: There are multiple S-TAG-aware services, including:
+ one-to-one + one-to-one
In this service, each VLAN identifier (VID) is mapped into a In this service, each VLAN identifier (VID) is mapped into a
different service. different service.
+ Bundled + bundled
Bundled S-tagged service supports the mapping of multiple VIDs Bundled S-tagged service supports the mapping of multiple VIDs
into a single service and include: into a single service and includes:
* many-to-one * many-to-one
In this frame based service, multiple VIDs are mapped into the
In this frame-based service, multiple VIDs are mapped into the
same service. same service.
* all-to-one * all-to-one
In this frame based service, all VIDs are mapped into the same
In this frame-based service, all VIDs are mapped into the same
service. service.
- transparent - transparent
This is a special case, all frames are mapped from a single This is a special case, all frames are mapped from a single
incoming port to a single destination Ethernet port. incoming port to a single destination Ethernet port.
o I-tagged o I-tagged
The edge of a PBBN consists of a combined backbone relay (B-
component relay) and service instance relay (I-component relay). The edge of a PBBN consists of a combined backbone relay
An I-Tag contains a service identifier (24 bit I-SID) and priority (B-component relay) and service instance relay (I-component relay).
markings as well as some other fields. An I-Tagged service is An I-TAG contains a service identifier (24-bit I-SID) and priority
markings as well as some other fields. An I-tagged service is
typically between the edges of the PBBN and terminated at each edge typically between the edges of the PBBN and terminated at each edge
on an I-component that faces a customer port so the service is on an I-component that faces a customer port so the service is
often not visible except at the edges. However, since the I- often not visible except at the edges. However, since the
component relay involves a distinct relay, it is possible to have a I-component relay involves a distinct relay, it is possible to have
visible I-Tagged Service by separating the I component relay from a visible I-tagged Service by separating the I-component relay from
the B-component relay. Two examples where it makes sense to do the B-component relay. Two examples where it makes sense to do
this are: an I-Tagged service between two PBBNs and as an this are an I-tagged service between two PBBNs and as an attachment
attachment to a customer's Provider Instance Port. to a customer's Provider Instance Port.
In general, the different switching types determine which of the In general, the different switching types determine which of the
Ethernet header fields are used in the forwarding/switching function, Ethernet header fields are used in the forwarding/switching function,
e.g. VID only or VID and DMACs. The switching type may also require e.g., VID only or VID and DMACs. The switching type may also require
the use of additional Ethernet headers or fields. Services defined the use of additional Ethernet headers or fields. Services defined
for UNIs tend to use the headers for requesting service (service for UNIs tend to use the headers for requesting service (service
delimiter) and are relevant between the customer site and network delimiter) and are relevant between the customer site and network
edge. edge.
In most bridging cases, the header fields cannot be changed, but some In most bridging cases, the header fields cannot be changed, but some
translations of VID field values are permitted, typically at the translations of VID field values are permitted, typically at the
network edges. network edges.
Across all service types, the Ethernet data plane is bidirectional Across all service types, the Ethernet data plane is bidirectional
congruent. This means that the forward and reverse paths share the congruent. This means that the forward and reverse paths share the
exact same set of nodes, ports and bidirectional links. This exact same set of nodes, ports, and bidirectional links. This
property is fundamental. The 802.1 group has maintained this property is fundamental. The 802.1 group has maintained this
bidirectional congruent property in the definition of Connectivity bidirectional congruent property in the definition of Connectivity
Fault Management (CFM) which is part of the overall Operations Fault Management (CFM), which is part of the overall OAM capability.
Administration and Maintenance (OAM) capability.
2.2. Operations, Administration, and Maintenance (OAM) 2.2. Operations, Administration, and Maintenance (OAM)
Robustness is enhanced with the addition of data plane OAM to provide Robustness is enhanced with the addition of data-plane OAM to provide
both fault and performance management. both fault and performance management.
Ethernet OAM messages [802.1ag] and [Y.1731], rely on data plane Ethernet OAM messages ([802.1ag] and [Y.1731]) rely on data-plane
forwarding for both directions. Determining a broken path or forwarding for both directions. Determining a broken path or
misdirected packet in this case relies on OAM following the Eth-LSP. misdirected packet in this case relies on OAM following the Eth-LSP.
These OAM message identifiers are dependent on the data plane so they These OAM message identifiers are dependent on the data plane, so
work equally well for provisioned or GMPLS controlled paths. they work equally well for provisioned or GMPLS-controlled paths.
Ethernet OAM currently consists of: Ethernet OAM currently consists of:
Defined in both [802.1ag & Y.1731]:
- CCM/RDI: Connectivity Check, Remote Defect Indication
- LBM/LBR: Loopback Message, Loopback Reply
- LTM/LTR: Link trace Message, Link trace Reply
- VSM/VSR: Vendor-specific extensions Message/Reply
Additionally defined in [Y.1731]: Defined in both [802.1ag] and [Y.1731]:
- AIS: Alarm Indication Signal - CCM/RDI: Continuity Check Message / Remote Defect Indication
- LCK: Locked Signal - LBM/LBR: Loopback Message/Reply
- TST: Test - LTM/LTR: Link Trace Message/Reply
- LMM/LMR: Loss Measurement Message/Reply - VSM/VSR: Vendor-Specific Message/Reply
- DM/DMM/DMR: Delay Measurement
- EXM/EXR: Experimental
- APS, MCC: Automatic Protection Switching, Maintenance
Communication Channel
These functions are supported across all the Standardized Eth-LSP Additionally defined in [Y.1731]:
- AIS: Alarm Indication Signal
- LCK: Locked Signal
- TST: Test
- LMM/LMR: Loss Measurement Message/Reply
- DM: Delay Measurement
- DMM/DMR: Delay Measurement Message/Reply
- EXM/EXR: Experimental Message/Reply
- APS, MCC: Automatic Protection Switching, Maintenance
Communication Channel
These functions are supported across all the standardized Eth-LSP
formats. formats.
2.3. Ethernet Switching Characteristics 2.3. Ethernet Switching Characteristics
Ethernet is similar to MPLS as it encapsulates different packet and Ethernet is similar to MPLS as it encapsulates different packet and
frame types for data transmission. In Ethernet, the encapsulated frame types for data transmission. In Ethernet, the encapsulated
data is referred to as MAC client data. The encapsulation is an data is referred to as MAC client data. The encapsulation is an
Ethernet MAC frame with a header, a source address, destination Ethernet MAC frame with a header, a source address, a destination
address, optional VLAN identifier, Type and length on the front of address, and an optional VLAN identifier, type, and length on the
the MAC client data with optional padding and a Frame Check Sequence front of the MAC client data with optional padding and a Frame Check
at the end of the frame. Sequence at the end of the frame.
The type of MAC client data is typically identified by an "Ethertype" The type of MAC client data is typically identified by an "Ethertype"
value. This is an explicit type indication but Ethernet also supports value. This is an explicit type indication, but Ethernet also
an implicit type indication. supports an implicit type indication.
Ethernet bridging switches based on a frame's destination MAC address Ethernet bridging switches based on a frame's destination MAC address
and VLAN. The VLAN identifies a virtual active set of Bridges and and VLAN. The VLAN identifies a virtual active set of bridges and
LANs. The address is assumed to be unique and invariant within the LANs. The address is assumed to be unique and invariant within the
VLAN. MAC addresses are often globally unique but this is not VLAN. MAC addresses are often globally unique, but this is not
necessary for bridging. necessary for bridging.
3. Framework 3. Framework
As defined in the GMPLS Architecture [RFC3945], the GMPLS control As defined in the GMPLS architecture [RFC3945], the GMPLS control
plane can be applied to a technology by controlling the data plane plane can be applied to a technology by controlling the data-plane
and switching characteristics of that technology. The GMPLS and switching characteristics of that technology. The GMPLS
architecture, per [RFC3945], allowed for control of Ethernet bridges architecture, per [RFC3945], allowed for control of Ethernet bridges
and other layer 2 technologies using the Layer-2 Switch Capable and other Layer 2 technologies using the Layer-2 Switch Capable
(L2SC) switching type. But, the control of Ethernet switching was (L2SC) switching type. But, the control of Ethernet switching was
not explicitly defined in [RFC3471], [RFC4202] or any other not explicitly defined in [RFC3471], [RFC4202], or any other
subsequent GMPLS reference document. subsequent GMPLS reference document.
The GMPLS architecture includes a clear separation between a control The GMPLS architecture includes a clear separation between a control
plane and a data plane. Control plane and data plane separation plane and a data plane. Control plane and data plane separation
allows the GMPLS control plane to remain architecturally and allows the GMPLS control plane to remain architecturally and
functionally unchanged while controlling different technologies. The functionally unchanged while controlling different technologies. The
architecture also requires IP connectivity for the control plane to architecture also requires IP connectivity for the control plane to
exchange information, but does not otherwise require an IP data exchange information, but does not otherwise require an IP data
plane. plane.
All aspects of GMPLS, i.e., addressing, signaling, routing and link All aspects of GMPLS, i.e., addressing, signaling, routing and link
management, may be applied to Ethernet switching. GMPLS can provide management, may be applied to Ethernet switching. GMPLS can provide
control for traffic engineered and protected Ethernet service paths. control for traffic-engineered and protected Ethernet service paths.
This document defines the term "Eth-LSP" to refer to Ethernet service This document defines the term "Eth-LSP" to refer to Ethernet service
paths that are controlled via GMPLS. As is the case with all GMPLS paths that are controlled via GMPLS. As is the case with all GMPLS
controlled services, Eth-LSPs can leverage common traffic engineering controlled services, Eth-LSPs can leverage common traffic engineering
attributes such as: attributes such as:
- bandwidth profile; - bandwidth profile;
- forwarding priority level; - forwarding priority level;
- connection preemption characteristics; - connection preemption characteristics;
- protection/resiliency capability; - protection/resiliency capability;
- routing policy, such as an explicit route; - routing policy, such as an explicit route;
- bidirectional service; - bidirectional service;
- end-to-end and segment protection; - end-to-end and segment protection;
- hierarchy - hierarchy
The bandwidth profile may be used to set committed information rate, The bandwidth profile may be used to set the committed information
peak information rate, and policies based on either under- rate, peak information rate, and policies based on either under-
subscription or over-subscription. Services covered by this subscription or over-subscription. Services covered by this
framework will use a TSpec that follows the Ethernet Traffic framework will use a TSpec that follows the Ethernet Traffic
parameters defined in [ETH-TSPEC]. parameters defined in [ETH-TSPEC].
In applying GMPLS to "transport" Ethernet, GMPLS will need to be In applying GMPLS to "transport" Ethernet, GMPLS will need to be
extended to work with the Ethernet data plane and switching extended to work with the Ethernet data plane and switching
functions. The definition of GMPLS support for Ethernet is multi- functions. The definition of GMPLS support for Ethernet is
faceted due to the different forwarding/switching functions inherent multifaceted due to the different forwarding/switching functions
in the different service types discussed in Section 2.1. In general, inherent in the different service types discussed in Section 2.1. In
the header fields used in the forwarding/switching function, e.g. VID general, the header fields used in the forwarding/switching function,
and DMAC, can be characterized as a data plane label. In some e.g., VID and DMAC, can be characterized as a data-plane label. In
circumstances these fields will be constant along the path of the some circumstances, these fields will be constant along the path of
Eth-LSP, and in others they may vary hop-by-hop or at certain the Eth-LSP, and in others they may vary hop-by-hop or at certain
interfaces only along the path. In the case where the "labels" must interfaces only along the path. In the case where the "labels" must
be forwarded unchanged, there are a few constraints on the label be forwarded unchanged, there are a few constraints on the label
allocation that are similar to some other technologies such as lambda allocation that are similar to some other technologies such as lambda
labels. labels.
The characteristics of the "transport" Ethernet data plane are not The characteristics of the "transport" Ethernet data plane are not
modified in order to apply GMPLS control. For example, consider the modified in order to apply GMPLS control. For example, consider the
IEEE 802.1Q [802.1Q] data plane: The VID is used as a "filter" IEEE 802.1Q [802.1Q] data plane: The VID is used as a "filter"
pointing to a particular forwarding table, and if the DMAC is found pointing to a particular forwarding table, and if the DMAC is found
in that forwarding table the forwarding decision is taken based on in that forwarding table, the forwarding decision is made based on
the DMAC. When forwarding using an Spanning tree, if the DMAC is not the DMAC. When forwarding using a spanning tree, if the DMAC is not
found the frame is broadcast over all outgoing interfaces for which found, the frame is broadcast over all outgoing interfaces for which
that VID is defined. This valid MAC checking and broadcast supports that VID is defined. This valid MAC checking and broadcast supports
Ethernet learning. A special case is when a VID is defined for only Ethernet learning. A special case is when a VID is defined for only
two ports on one bridge, effectively resulting in a p2p forwarding two ports on one bridge, effectively resulting in a P2P forwarding
constraint. In this case all frames tagged with that VID received constraint. In this case, all frames that are tagged with that VID
over one of these ports are forward over the other port without and received over one of these ports are forwarded over the other
address learning. port without address learning.
[802.1Qay] allows for turning off learning and hence the broadcast [802.1Qay] allows for turning off learning and hence the broadcast
mechanism providing means to create explicitly routed Ethernet mechanism that provides means to create explicitly routed Ethernet
connections. connections.
This document does not define any specific format for an Eth-LSP This document does not define any specific format for an Eth-LSP
label. Rather, it is expected that service specific documents will label. Rather, it is expected that service-specific documents will
define any signaling and routing extensions needed to support a define any signaling and routing extensions needed to support a
specific Ethernet service. Depending on the requirements of a specific Ethernet service. Depending on the requirements of a
service, it may be necessary to define multiple GMPLS protocol service, it may be necessary to define multiple GMPLS protocol
extensions and procedures. It is expected that all such extensions extensions and procedures. It is expected that all such extensions
will be consistent with this document. will be consistent with this document.
It is expected that a key requirement for service specific documents It is expected that a key requirement for service-specific documents
will be to describe label formats and encodings. It may also be will be to describe label formats and encodings. It may also be
necessary to provide a mechanism to identify the required Ethernet necessary to provide a mechanism to identify the required Ethernet
service type in signaling and a way to advertise the capabilities of service type in signaling and a way to advertise the capabilities of
Ethernet switches in the routing protocols. These mechanisms must Ethernet switches in the routing protocols. These mechanisms must
make it possible to distinguish between requests for different make it possible to distinguish between requests for different
paradigms including new, future, and existing paradigms. paradigms including new, future, and existing paradigms.
The Switching Type and Interface Switching Capability Descriptor The Switching Type and Interface Switching Capability Descriptor
share a common set of values and are defined in [RFC3945], [RFC3471], share a common set of values and are defined in [RFC3945], [RFC3471],
and [RFC4202] as indicators of the type of switching that should and [RFC4202] as indicators of the type of switching that should
([RFC3471]) and can ([RFC4202]) be performed on a particular link for ([RFC3471]) and can ([RFC4202]) be performed on a particular link for
an LSP. The L2SC switching type may already be used by an LSP. The L2SC switching type may already be used by
implementations performing layer 2 switching including Ethernet. As implementations performing Layer 2 Switching including Ethernet. As
such, and to allow the continued use of that switching type and those such, and to allow the continued use of that switching type and those
implementations, and to distinguish the different Ethernet switching implementations, and to distinguish the different Ethernet switching
paradigms, a new switching type needs to be defined for each new paradigms, a new switching type needs to be defined for each new
Ethernet switching paradigm that is supported. Ethernet switching paradigm that is supported.
For discussion purposes, we decompose the problem of applying GMPLS For discussion purposes, we decompose the problem of applying GMPLS
into the functions of Routing, Signaling, Link Management and Path into the functions of routing, signaling, link management, and path
Selection. It is possible to use some functions of GMPLS alone or in selection. It is possible to use some functions of GMPLS alone or in
partial combinations. In most cases using all functions of GMPLS partial combinations. In most cases, using all functions of GMPLS
leads to less operational overhead than partial combinations. leads to less operational overhead than partial combinations.
4. GMPLS Routing and Addressing Model 4. GMPLS Routing and Addressing Model
The GMPLS routing and addressing model is not modified by this The GMPLS routing and addressing model is not modified by this
document. GMPLS control for Eth-LSPs uses the routing and Addressing document. GMPLS control for Eth-LSPs uses the routing and addressing
Model described in [RFC3945]. Most notably this includes the use of model described in [RFC3945]. Most notably, this includes the use of
IP addresses to identify interfaces and LSP end-points. It also IP addresses to identify interfaces and LSP end-points. It also
includes support for both numbered and unnumbered interfaces. includes support for both numbered and unnumbered interfaces.
In the case where another address family or type of identifier is In the case where another address family or type of identifier is
required to support an Ethernet service, extensions may be defined to required to support an Ethernet service, extensions may be defined to
provide mapping to an IP address. Support of Eth-LSPs is expected to provide mapping to an IP address. Support of Eth-LSPs is expected to
strictly comply to the GMPLS protocol suite addressing as specific in strictly comply to the GMPLS protocol suite addressing as specified
[RFC3471], [RFC3473] and related documents. in [RFC3471], [RFC3473], and related documents.
4.1. GMPLS Routing 4.1. GMPLS Routing
GMPLS routing as defined in [RFC4202] uses IP routing protocols with GMPLS routing as defined in [RFC4202] uses IP routing protocols with
opaque TLV extensions for the purpose of distributing GMPLS related opaque TLV extensions for the purpose of distributing GMPLS-related
TE (router and link) information. As is always the case with GMPLS, TE (router and link) information. As is always the case with GMPLS,
TE information is populated based on resource information obtained TE information is populated based on resource information obtained
from LMP or from configured information. The bandwidth resources of from LMP or from configured information. The bandwidth resources of
the links are tracked as Eth-LSPs are set up. Interfaces supporting the links are tracked as Eth-LSPs are set up. Interfaces supporting
the switching of Eth-LSPs are identified using the appropriate the switching of Eth-LSPs are identified using the appropriate
Interface Switching Capabilities Descriptor. As mentioned in Section Interface Switching Capabilities (ISC) Descriptor. As mentioned in
3, the definition of one or more new Interface Switching Capabilities Section 3, the definition of one or more new ISCs to support Eth-LSPs
to support Eth-LSPs is expected. Again, the L2SC Interface Switching is expected. Again, the L2SC ISCs will not be used to represent
Capabilities will not be used to represent interfaces capable of interfaces capable of supporting Eth-LSPs defined by this document
supporting Eth-LSPs defined by this document and subsequent documents and subsequent documents in support of the transport Ethernet
in support of the transport Ethernet switching paradigms. In switching paradigms. In addition, ISC-specific TE information may be
addition, Interface Switching Capability specific TE information may defined as needed to support the requirements of a specific Ethernet
be defined as needed to support the requirements of a specific Switching Service Type.
Ethernet Switching Service Type.
GMPLS routing is an optional functionality but it is highly valuable GMPLS routing is an optional functionality but it is highly valuable
in maintaining topology and distributing the TE database for path in maintaining topology and distributing the TE database for path
management and dynamic path computation. management and dynamic path computation.
4.2. Control Plane Network 4.2. Control Plane Network
In order for a GMPLS control plane to operate, an IP connectivity In order for a GMPLS control plane to operate, an IP connectivity
network of sufficient capacity to handle the information exchange of network of sufficient capacity to handle the information exchange of
the GMPLS routing and signaling protocols is necessary. the GMPLS routing and signaling protocols is necessary.
One way to implement this is with an IP routed network supported by One way to implement this is with an IP-routed network supported by
an IGP that views each switch as a terminated IP adjacency. In other an IGP that views each switch as a terminated IP adjacency. In other
words, IP traffic and a simple routing table are available for the words, IP traffic and a simple routing table are available for the
control plane but there is no requirement for needing a high control plane, but there is no requirement for a high-performance IP
performance IP data plane, or for forwarding user traffic over this data plane, or for forwarding user traffic over this IP network.
IP network.
This IP connectivity can be provided as a separate independent This IP connectivity can be provided as a separate independent
network (out of band) or integrated with the Ethernet switches (in- network (out-of-band) or integrated with the Ethernet switches (in-
band). band).
5. GMPLS Signaling 5. GMPLS Signaling
GMPLS signaling, see [RFC3471][RFC3473], is well suited to the GMPLS signaling ([RFC3471] and [RFC3473]) is well suited to the
control of Eth-LSPs and Ethernet switches. Signaling provides the control of Eth-LSPs and Ethernet switches. Signaling provides the
ability to dynamically establish a path from an ingress node to an ability to dynamically establish a path from an ingress node to an
egress node. The signaled path may be completely static and not egress node. The signaled path may be completely static and not
change for the duration of its lifetime. However, signaling also has change for the duration of its lifetime. However, signaling also has
the capability to dynamically adjust the path in a coordinated the capability to dynamically adjust the path in a coordinated
fashion after the path has been established. The range of signaling fashion after the path has been established. The range of signaling
options from static to dynamic are under operator control. options from static to dynamic are under operator control.
Standardized signaling also improves multi-vendor interoperability. Standardized signaling also improves multi-vendor interoperability.
GMPLS signaling supports the establishment and control of GMPLS signaling supports the establishment and control of
bidirectional and unidirectional data paths. Ethernet is bidirectional and unidirectional data paths. Ethernet is
bidirectional by nature and CFM has been built to leverage this. bidirectional by nature and CFM has been built to leverage this.
Prior to CFM, the emulation of a physical wire and the learning Prior to CFM, the emulation of a physical wire and the learning
requirements also mandated bidirectional connections. Given this, requirements also mandated bidirectional connections. Given this,
Eth-LSPs need to be bidirectional congruent. Eth-LSPs may be either Eth-LSPs need to be bidirectional congruent. Eth-LSPs may be either
P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full
and partial LSP protection; see [RFC4872] and [RFC4873]. and partial LSP protection; see [RFC4872] and [RFC4873].
Note that standard GMPLS does not support different bandwidth in each Note that standard GMPLS does not support different bandwidth in each
direction of a bidirectional LSP. [RFC5467], an Experimental direction of a bidirectional LSP. [RFC5467], an Experimental
document, provides procedures if asymmetric bandwidth bidirectional document, provides procedures if asymmetric bandwidth bidirectional
LSPs are required. LSPs are required.
6. Link Management 6. Link Management
Link discovery has been specified for links interconnecting IEEE Link discovery has been specified for links interconnecting IEEE
802.1 bridges in [802.1AB]. The benefits of running link discovery 802.1 bridges in [802.1AB]. The benefits of running link discovery
in large systems are significant. Link discovery may reduce in large systems are significant. Link discovery may reduce
configuration and reduce the possibility of undetected errors in configuration and reduce the possibility of undetected errors in
configuration as well as exposing misconnections. However the 802.1AB configuration as well as exposing misconnections. However, the
capability is an optional feature, it is not necessarily operating 802.1AB capability is an optional feature, so it is not necessarily
before a link is operational, and it primarily supports the operating before a link is operational, and it primarily supports the
management plane. management plane.
In the GMPLS context, LMP [RFC4204] has been defined to support GMPLS In the GMPLS context, LMP [RFC4204] has been defined to support GMPLS
control plane link management and discovery features. LMP also control-plane link management and discovery features. LMP also
supports for the control plane the automated creation of unnumbered supports the automated creation of unnumbered interfaces for the
interfaces. If LMP is not used there is an additional configuration control plane. If LMP is not used, there is an additional
requirement for GMPLS link identifiers. For large-scale configuration requirement for GMPLS link identifiers. For large-
implementations LMP is beneficial. LMP also has optional fault scale implementations, LMP is beneficial. LMP also has optional
management capabilities, primarily for opaque and transparent network fault management capabilities, primarily for opaque and transparent
technology. With IEEE's newer CFM [802.1ag] and ITU-T's [Y.1731] network technology. With IEEE's newer CFM [802.1ag] and ITU-T's
capabilities, this optional capability may not be needed. It is the capabilities [Y.1731], this optional capability may not be needed.
goal of the GMPLS Ethernet architecture to allow the selection of the It is the goal of the GMPLS Ethernet architecture to allow the
best tool set for the user needs. The full functionality of Ethernet selection of the best tool set for the user needs. The full
CFM should be supported when using a GMPLS control plane. functionality of Ethernet CFM should be supported when using a GMPLS
control plane.
LMP and 802.1AB are relatively independent. The LMP capability should LMP and 802.1AB are relatively independent. The LMP capability
be sufficient to remove the need for 802.1AB but 802.1 AB can be run should be sufficient to remove the need for 802.1AB, but 802.1 AB can
in parallel or independently if desired. Figure 2 provides possible be run in parallel or independently if desired. Figure 2 provides
ways of using LMP, 802.1AB and 802.1ag in combination. possible ways of using LMP, 802.1AB, and 802.1ag in combination.
Figure 2 illustrates the functional relationship of link management Figure 2 illustrates the functional relationship of link management
and OAM schemes. It is expected that LMP would be used for control and OAM schemes. It is expected that LMP would be used for control-
plane functions of link property correlation but that Ethernet plane functions of link property correlation, but that Ethernet
mechanisms for OAM such as CFM, link trace, etc. would be used for mechanisms for OAM such as CFM, link trace, etc., would be used for
data plane fault management and fault trace. data-plane fault management and fault trace.
+-------------+ +-------------+ +-------------+ +-------------+
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
| | | | | | | |GMPLS | | | | | | | |GMPLS
| | LMP |-|<------>|-| LMP | |Link Property | | LMP |-|<------>|-| LMP | |Link Property
| | | | | | | |Correlation | | | | | | | |Correlation
| | (opt) | |GMPLS | | (opt) | | | | (opt) | |GMPLS | | (opt) | |
| | | | | | | | Bundling | | | | | | | | Bundling
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
| | | | | | | | | | | | | | | |
| | 802.1AB |-|<------>|-| 802.1AB | |P2P | | 802.1AB |-|<------>|-| 802.1AB | |P2P
| | (opt) | |Ethernet| | (opt) | |link identifiers | | (opt) | |Ethernet| | (opt) | |link identifiers
| | | | | | | | | | | | | | | |
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
| | | | | | | |End to End | | | | | | | |End-to-End
-----|-| 802.1ag |-|<------>|-| 802.1ag |-|------- -----|-| 802.1ag |-|<------>|-| 802.1ag |-|-------
| | Y.1731 | |Ethernet| | Y.1731 | |Fault Management | | Y.1731 | |Ethernet| | Y.1731 | |Fault Management
| | (opt) | | | | (opt) | |Performance | | (opt) | | | | (opt) | |Performance
| | | | | | | |Management | | | | | | | |Management
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
+-------------+ +-------------+ +-------------+ +-------------+
Switch 1 link Switch 2 Switch 1 link Switch 2
Figure 2: Logical Link Management Options Figure 2: Logical Link Management Options
7. Path Computation and Selection 7. Path Computation and Selection
GMPLS does not specify a specific method for selecting paths or GMPLS does not identify a specific method for selecting paths or
supporting path computation. GMPLS allows for a wide range of supporting path computation. GMPLS allows for a wide range of
possibilities supported from very simple path computation to very possibilities to be supported, from very simple path computation to
elaborate path coordination where a large number of coordinated paths very elaborate path coordination where a large number of coordinated
are required. Path computation can take the form of paths being paths are required. Path computation can take the form of paths
computed in a fully distributed fashion, on a management station with being computed in a fully distributed fashion, on a management
local computation for rerouting, or on more sophisticated path station with local computation for rerouting, or on more
computation servers. sophisticated path computation servers.
Eth-LSPs may be supported using any path selection or computation Eth-LSPs may be supported using any path selection or computation
mechanism. As is the case with any GMPLS path selection function, and mechanism. As is the case with any GMPLS path selection function,
common to all path selection mechanisms, the path selection process and common to all path selection mechanisms, the path selection
should take into consideration Switching Capabilities and Encoding process should take into consideration Switching Capabilities and
advertised for a particular interface. Eth-LSPs may also make use of Encoding advertised for a particular interface. Eth-LSPs may also
the emerging path computation element and selection work; see make use of the emerging path computation element and selection work;
[RFC4655]. see [RFC4655].
8. Multiple VLANs 8. Multiple VLANs
This document allows for the support of the signaling of Ethernet This document allows for the support of the signaling of Ethernet
parameters across multiple VLANs supporting both contiguous Eth-LSP parameters across multiple VLANs supporting both contiguous Eth-LSP
and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS
hierarchy for the support of Peer to Peer models, UNIs and NNIs. hierarchy for the support of peer-to-peer models, UNIs, and NNIs.
9. Security Considerations 9. Security Considerations
A GMPLS controlled "transport" Ethernet system should assume that A GMPLS-controlled "transport" Ethernet system should assume that
users and devices attached to UNIs may behave maliciously, users and devices attached to UNIs may behave maliciously,
negligently, or incorrectly. Intra-provider control traffic is negligently, or incorrectly. Intra-provider control traffic is
trusted to not be malicious. In general, these requirements are no trusted to not be malicious. In general, these requirements are no
different from the security requirements for operating any GMPLS different from the security requirements for operating any GMPLS
network. Access to the trusted network will only occur through the network. Access to the trusted network will only occur through the
protocols defined for the UNI or NNI or through protected management protocols defined for the UNI or NNI or through protected management
interfaces. interfaces.
When in-band GMPLS signaling is used for the control plane the When in-band GMPLS signaling is used for the control plane, the
security of the control plane and the data plane may affect each security of the control plane and the data plane may affect each
other. When out-of-band GMPLS signaling is used for the control other. When out-of-band GMPLS signaling is used for the control
plane the data plane security is decoupled from the control plane and plane, the data-plane security is decoupled from the control plane,
therefore the security of the data plane has less impact on overall and therefore the security of the data plane has less impact on
security. overall security.
Where GMPLS is applied to the control of VLAN only, the commonly Where GMPLS is applied to the control of VLAN only, the commonly
known techniques for mitigation of Ethernet DOS attacks may be known techniques for mitigation of Ethernet denial-of-service attacks
required on UNI ports. may be required on UNI ports.
For a more comprehensive discussion on GMPLS security please see the For a more comprehensive discussion on GMPLS security please see the
MPLS and GMPLS Security Framework [SECURITY]. Cryptography can be MPLS and GMPLS Security Framework [SECURITY]. Cryptography can be
used to protect against many attacks described in [SECURITY]. One used to protect against many attacks described in [SECURITY]. One
option for protecting "transport" Ethernet is the use of 802.1AE option for protecting "transport" Ethernet is the use of 802.1AE
Media Access Control Security, [MACSEC] which provides encryption and Media Access Control Security [802.1AE], which provides encryption
authentication." and authentication. It is expected that solution documents will
include a full analysis of the security issues that any protocol
It is expected that solution documents will include a full analysis extensions introduce.
of the security issues that any protocol extensions introduce.
10. IANA Considerations
No new values are specified in this document. 10. References
11. References 10.1. Normative References
11.1. Normative References [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3471] Berger, L. (editor), "Generalized MPLS Signaling [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Functional Description", January 2003, RFC3471. Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3473] Berger, L. (editor), "Generalized Multi-Protocol Label [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Architecture", RFC 3945, October 2004.
Protocol-Traffic Engineering (RSVP-TE) Extensions",
January 2003, RFC3473.
[RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Support of Generalized MPLS", RFC 4202, October 2005 Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label 10.2. Informative References
Switching (GMPLS) Architecture", RFC 3495.
11.2. Informative References [802.1AB] "IEEE Standard for Local and Metropolitan Area Networks,
Station and Media Access Control Connectivity Discovery",
IEEE 802.1AB, 2009.
[G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection [802.1AE] "IEEE Standard for Local and metropolitan area networks
Switching. Media Access Control (MAC) Security", IEEE 802.1AE-2006,
August 2006.
[G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over [802.1ag] "IEEE Standard for Local and Metropolitan Area Networks -
Transport - Ethernet services framework. Virtual Bridged Local Area Networks - Amendment 5:
Connectivity Fault Management", IEEE 802.1ag, 2007.
[802.1AB] "IEEE Standard for Local and Metropolitan Area [802.1ah] "IEEE Standard for Local and Metropolitan Area Networks -
Networks, Station and Media Access Control Virtual Bridged Local Area Networks - Amendment 6:
Connectivity Discovery" (2004). Provider Backbone Bridges", IEEE Std 802.1ah-2008, August
2008.
[802.1ag] "IEEE Standard for Local and Metropolitan Area [802.1Q] "IEEE standard for Virtual Bridged Local Area Networks",
Networks - Virtual Bridged Local Area Networks IEEE 802.1Q-2005, May 2006.
- Amendment 5:Connectivity Fault Management",
(2007).
[802.1ah] "IEEE Standard for Local and Metropolitan Area [802.1Qay] "IEEE Standard for Local and Metropolitan Area Networks -
Networks - Virtual Bridged Local Area Networks Virtual Bridged Local Area Networks - Amendment 10:
- Amendment 6: Provider Backbone Bridges", Provider Backbone Bridge Traffic Engineering", IEEE Std
IEEE Std 802.1Qah-2008, 14 August 2008. 802.1Qay-2009, August 2009.
[802.1Qay] "IEEE Standard for Local and Metropolitan Area [ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", Work in
Networks - Virtual Bridged Local Area Networks Progress, January 2010.
Provider Backbone Bridge Traffic Engineering
- Amendment 10: ", IEEE Std 802.1Qay-2009,
August 5th, 2009.
[802.1Q] "IEEE standard for Virtual Bridged Local Area Networks [G.8011] ITU-T Recommendation G.8011, "Ethernet over Transport -
802.1Q-2005", May 19, 2006. Ethernet services framework", January 2009.
[RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" [G.8011.1] ITU-T Recommendation G.8011.1/Y.1307.1, "Ethernet private
RFC4204, October 2005. line service", January 2009.
[MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services [G.8011.2] ITU-T Recommendation G.8011.2/Y.1307.2, "Ethernet virtual
Definitions - Phase I". private line service", January 2009.
[MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet [G.8031] ITU-T Recommendation G.8031, "Ethernet linear protection
Services Attributes Phase 1". switching", November 2009.
[RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to [MEF.6] The Metro Ethernet Forum MEF 6, "Ethernet Services
Multipoint TE LSPs", IETF RFC 4875, May 2007. Definitions - Phase I", 2004.
[RFC4655] Farrel, A. et.al., "Path Computation Element (PCE) [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
Architecture", RFC 4655, August 2006. 4204, October 2005.
[RFC4872] Lang et.al., "RSVP-TE Extensions in support of [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
End-to-End Generalized Multi-Protocol Label Switching Yasukawa, Ed., "Extensions to Resource Reservation
(GMPLS)-based Recovery ", RFC 4872, May 2007. Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
2007.
[RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
2007. Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Functions and Mechanisms for Ethernet based Networks ", Ed., "RSVP-TE Extensions in Support of End-to-End
work in progress. Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[RFC5467] Berger, L. et al., "GMPLS Asymmetric Bandwidth [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Bidirectional LSPs", RFC5467, March 2009. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", [RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
draft-ietf-ccamp-ethernet-traffic-parameters-09.txt, Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
work in progress. Switched Paths (LSPs)", RFC 5467, March 2009.
[SECURITY] Luyuan Fang, Ed., "Security Framework for MPLSand GMPLS [SECURITY] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", draft-ietf-mpls-mpls-and-gmpls-security- Networks", Work in Progress, October 2009.
framework-07.txt, work in progress.
[MACSEC] "IEEE Standard for Local and metropolitan area networks [Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and
Media Access Control (MAC) Security Mechanisms for Ethernet based Networks", February 2008.
IEEE 802.1AE-2006", August 18, 2006.
12. Acknowledgments 11. Acknowledgments
There were many people involved in the initiation of this work prior There were many people involved in the initiation of this work prior
to this document. The GELS framework draft and the PBB-TE extensions to this document. The GELS framework document and the PBB-TE
drafts were two drafts the helped shape and justify this work. We extensions document were two documents that helped shape and justify
acknowledge the work of these authors of these initial drafts: this work. We acknowledge the work of the authors of these initial
Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan, documents: Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave
Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia, Allan, Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego
Himanshu Shah, Greg Sunderwood, Alan McGuire, and Nabil Bitar. Caviglia, Himanshu Shah, Greg Sunderwood, Alan McGuire, and Nabil
Bitar.
George Swallow contributed significantly to this document. George Swallow contributed significantly to this document.
13. Author's Addresses Authors' Addresses
Don Fedyk Don Fedyk
Alcatel-Lucent Alcatel-Lucent
Groton, MA, 01450 Groton, MA, 01450
Phone: +1-978-467-5645 Phone: +1-978-467-5645
Email: donald.fedyk@alcatel-lucent.com EMail: donald.fedyk@alcatel-lucent.com
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net EMail: lberger@labn.net
Loa Andersson Loa Andersson
Ericsson AB Ericsson
Phone: +46 10 717 52 13 Phone: +46 10 717 52 13
Email: loa.andersson@ericsson.com EMail: loa.andersson@ericsson.com
Generated on: Thu Jan 14 15:15:38 EST 2010
 End of changes. 177 change blocks. 
495 lines changed or deleted 500 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/