draft-ietf-ccamp-gmpls-ethernet-arch-04.txt   draft-ietf-ccamp-gmpls-ethernet-arch-05.txt 
Internet Draft Don Fedyk, Nortel Internet Draft Don Fedyk, Alcatel-Lucent
Category: Informational Lou Berger, LabN Category: Informational Lou Berger, LabN
Expiration Date: August 13, 2009 Loa Andersson, Ericsson AB Expiration Date: March 1, 2010 Loa Andersson, Ericsson AB
February 13, 2009 September 1, 2009
Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Generalized Multi-Protocol Label Switching (GMPLS) Ethernet
Label Switching Architecture and Framework Label Switching Architecture and Framework
draft-ietf-ccamp-gmpls-ethernet-arch-04.txt draft-ietf-ccamp-gmpls-ethernet-arch-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 13, 2009. This Internet-Draft will expire on March 1, 2010.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
There has been significant recent work in increasing the capabilities There has been significant recent work in increasing the capabilities
of Ethernet switches and Ethernet forwarding models. As a of Ethernet switches and Ethernet forwarding models. As a
consequence, the role of Ethernet is rapidly expanding into consequence, the role of Ethernet is rapidly expanding into
"transport networks" that previously were the domain of other "transport networks" that previously were the domain of other
technologies such as Synchronous Optical Network (SONET)/Synchronous technologies such as Synchronous Optical Network (SONET)/Synchronous
Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and
Asynchronous Transfer Mode (ATM). This document defines an Asynchronous Transfer Mode (ATM). This document defines an
architecture and framework for a Generalized GMPLS based control architecture and framework for a Generalized GMPLS based control
plane for Ethernet in this "transport network" capacity. GMPLS has plane for Ethernet in this "transport network" capacity. GMPLS has
already been specified for similar technologies. Some additional already been specified for similar technologies. Some additional
extensions to the GMPLS control plane are needed and this document extensions to the GMPLS control plane are needed and this document
provides a framework for these extensions. provides a framework for these extensions.
Table of Contents Table of Contents
1 Introduction .............................................. 4 1 Introduction ........................................... 4
1.1 Terminology ............................................... 6 1.1 Terminology ............................................ 6
1.1.1 Concepts .................................................. 6 1.1.1 Concepts ............................................... 6
1.1.2 Abbreviations and Acronyms ................................ 7 1.1.2 Abbreviations and Acronyms ............................. 8
2 Background ................................................ 8 2 Background ............................................. 8
2.1 Ethernet Switching ........................................ 9 2.1 Ethernet Switching ..................................... 9
2.2 Operations, Administration, and Maintenance (OAM) ......... 11 2.2 Operations, Administration, and Maintenance (OAM) ...... 11
2.3 Ethernet Switching Characteristics ........................ 12 2.3 Ethernet Switching Characteristics ..................... 12
3 Framework ................................................. 12 3 Framework .............................................. 12
4 GMPLS Routing and Addressing Model ........................ 14 4 GMPLS Routing and Addressing Model ..................... 14
4.1 GMPLS Routing ............................................. 15 4.1 GMPLS Routing .......................................... 15
4.2 Control Plane Network ..................................... 15 4.2 Control Plane Network .................................. 15
5 GMPLS Signaling .......................................... 15 5 GMPLS Signaling ........................................ 16
6 Link Management .......................................... 16 6 Link Management ........................................ 16
7 Path Computation and Selection ............................ 17 7 Path Computation and Selection ......................... 18
8 Multiple VLANs ............................................ 18 8 Multiple VLANs ......................................... 18
9 Security Considerations ................................... 18 9 Security Considerations ................................ 18
10 IANA Considerations ....................................... 18 10 IANA Considerations .................................... 19
11 References ................................................ 18 11 References ............................................. 19
11.1 Normative References ...................................... 18 11.1 Normative References ................................... 19
11.2 Informative References .................................... 19 11.2 Informative References ................................. 19
12 Acknowledgments ........................................... 20 12 Acknowledgments ........................................ 21
13 Author's Addresses ........................................ 21 13 Author's Addresses ..................................... 21
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
document are to be interpreted as described in [RFC2119]. in this document are to be interpreted as described in [RFC2119].
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. This activity has taken place in the Institute of technology to support transport networks. This activity has taken
Electrical and Electronics Engineers (IEEE) 802.1 Working Group, the place in the Institute of Electrical and Electronics Engineers (IEEE)
International Telecommunication Union (ITU) and the Metro Ethernet 802.1 Working Group, the International Telecommunication Union (ITU)
Forum (MEF). These groups have been focusing on Ethernet forwarding, and the Metro Ethernet Forum (MEF). These groups have been focusing
Ethernet management plane extensions and the Ethernet Spanning Tree on Ethernet forwarding, Ethernet management plane extensions and the
Control Plane, but not on an explicitly routed, constraint based Ethernet Spanning Tree Control Plane, but not on an explicitly
control plane. routed, 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 Ethernet forwarding models, protection defined to support different transport Ethernet forwarding models,
modes and service interfaces. Examples of such extensions include protection modes, and service interfaces. Examples of such
[802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These extensions allow extensions include [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These
for greater flexibility in the forwarding plane and, in some cases, extensions allow for greater flexibility in the Ethernet forwarding
the extensions allow for a departure from forwarding based on plane and, in some cases, the extensions allow for a departure from
Ethernet spanning tree. In the 802.1Qay case, greater flexibility in forwarding based on Ethernet spanning tree. For example, in the
forwarding is achieved through the addition of a "provider" address [802.1Qah] case, greater flexibility in forwarding is achieved
space. through the addition of a "provider" address space. [802.1Qay]
supports the use of provisioning systems and network control
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). It will be followed by technology specific documents. GELS (GELS). GELS will likely require more than one switching type to
will likely require more than one switching type, and the GMPLS support the different models, and as the GMPLS procedures that will
procedures that will need to be changed are dependent on switching, need to be extended are dependent on switching type, these will be
and thus will be covered in the technology specific documents. covered in the technology specific documents.
In the new provider bridge model developed in the IEEE 802.1ad In the provider bridge model developed in the IEEE 802.1ad project
project and amended to the IEEE 802.1Q standard [802.1Q], an extra and amended to the IEEE 802.1Q standard [802.1Q], an extra Virtual
Virtual Local Area Network (VLAN) identifier (VID) is added. This Local Area Network (VLAN) identifier (VID) is added. This VLAN is
VLAN is referred to as the Service VID, (S-VID and is carried in a referred to as the Service VID, (S-VID and is carried in a Service
Service TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah] a TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah] a backbone
backbone VID (B-VID) and B-MAC header with a Service Instance (I-TAG) VID (B-VID) and B-MAC header with a Service Instance (I-TAG)
encapsulates a customer Ethernet frame or a service Ethernet frame. encapsulates a customer Ethernet frame or a service Ethernet frame.
An example of Ethernet protection extensions can be found in
[G.8031]. In the IEEE 802.1Q standard the terms Provider Backbone
Bridges (PBB) and Provider Backbone Bridged Network (PBBN) is used in
the context of these extensions.
Ethernet operations, administration, and maintenance (OAM) is another In the IEEE 802.1Q standard the terms Provider Backbone Bridges (PBB)
important area that is being extended to enable provider Ethernet and Provider Backbone Bridged Network (PBBN) are used in the context
services. Related extensions can be found in [802.1ag] and [Y.1731]. of these extensions.
An Ethernet based service model is also being defined within the An example of Ethernet protection extensions can be found in
context of the Metro Ethernet Forum (MEF) and International [G.8031]. Ethernet operations, administration, and maintenance (OAM)
Telecommunication Union (ITU). [MEF.6] and [G.8011] provide parallel is another important area that is being extended to enable provider
frameworks for defining network-oriented characteristics of Ethernet Ethernet services. Related extensions can be found in [802.1ag] and
services in transport networks. The framework discusses general [Y.1731].
An Ethernet based service model is being defined within the context
of the Metro Ethernet Forum (MEF) and International Telecommunication
Union (ITU). [MEF.6] and [G.8011] provide parallel frameworks for
defining network-oriented characteristics of Ethernet services in
transport networks. These framework documents discuss general
Ethernet connection characteristics, Ethernet User-Network Interfaces Ethernet connection characteristics, Ethernet User-Network Interfaces
(UNIs) and Ethernet Network-Network Interfaces (NNIs). Within this (UNIs) and Ethernet Network-Network Interfaces (NNIs). [G.8011.1]
framework, [G.8011.1] defines the Ethernet Private Line (EPL) service defines the Ethernet Private Line (EPL) service and [G.8011.2]
and [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) defines the Ethernet Virtual Private Line (EVPL) service. [MEF.6]
service. [MEF.6] covers both service types. These activities are covers both service types. These activities are consistent with the
consistent with the types of Ethernet switching defined in [802.1ah]. types of Ethernet switching defined in [802.1ah].
The Ethernet forwarding and management plane extensions explicitly The Ethernet forwarding and management plane extensions allow for the
allow for the disabling of standard Ethernet spanning tree but do not disabling of standard Ethernet spanning tree but do not define an
define an explicitly routed, constraint based control plane. The explicitly routed, constraint based control plane. For example
IEEE 802.1, in [802.1Qay], works on an new amendment that explicitly [802.1Qay] is an amendment to IEEE 802.1Q that explicitly allows for
allows for traffic engineering of Ethernet forwarding paths. traffic engineering of Ethernet forwarding paths.
The IETF chartered the GMPLS work to specify a common control plane The IETF's GMPLS work provides a common control plane for different
for physical path and core tunneling technologies for the Internet data plane technologies for Internet and telecommunication service
and telecommunication service providers. The GMPLS architecture is providers. The GMPLS architecture is specified in RFC3945 [RFC3945].
specified in RFC3945 [RFC3945]. The protocols specified for GMPLS The protocols specified for GMPLS can be used to control "Transport
have been used to control "Transport Networks", e.g. Optical and TDM Network" technologies, e.g. Optical and TDM networks. GMPLS can also
networks. 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 use of GMPLS to control
"transport" Ethernet. The GMPLS architecture already handles a number "transport" Ethernet Label Switched Paths (Eth-LSP). Transport
of transport technologies but "transport" Ethernet adds a few new Ethernet adds new constraints which require it to be distinguished
constraints that must be documented. Some additional extensions to from the previously specified technologies for GMPLS. Some additional
the GMPLS control plane are needed and this document provides a extensions to the GMPLS control plane are needed and this document
framework for these extensions. All extensions to support Eth-LSPs provides a framework for these extensions. All extensions to support
are also expected to build on the GMPLS Architecture and related Eth-LSPs will build on the GMPLS architecture and related
specifications. specifications.
This document introduces and explains GMPLS control plane deployment This document introduces and explains GMPLS control plane use for
for Ethernet and the concept of the Ethernet Label Switched Path transport Ethernet and the concept of the Ethernet Label Switched
(Eth-LSP). The data plane aspects of Eth-LSPs are outside the scope Path (Eth-LSP). The data plane aspects of Eth-LSPs are outside the
of this document and IETF activities. scope of this document and IETF 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 align with as much of the
GMPLS protocols as possible. For example reusing the IP control GMPLS protocols as possible. For example, reusing the IP control
plane addressing allows existing signaling, routing, LMP and path plane addressing allows existing signaling, routing, LMP and path
computation to be used as specified. The GMPLS protocols support a computation to be used as specified. The GMPLS protocols support
set of tools for hierarchical LSPs as well as contiguous LSPs. GMPLS hierarchical LSPs as well as contiguous LSPs. Also, GMPLS protocol
specific protocol mechanisms support a variety of networks from peer mechanisms support a variety of networks from peer to peer to UNIs
to peer to UNIs and NNIs. Additions to existing GMPLS capabilities and NNIs. Additions to existing GMPLS capabilities will only be made
will only be made to accommodate features unique to "transport" to accommodate features unique to transport Ethernet.
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
skipping to change at page 6, line 37 skipping to change at page 6, line 41
o Bidirectional Congruent LSP o Bidirectional Congruent LSP
This term refers to the property of a bi-directional LSP that This term refers to the property of a bi-directional LSP that
uses only the same nodes, ports, and links in both directions. uses only the same nodes, ports, and links in both directions.
Ethernet data planes are normally bi-directional or reverse path Ethernet data planes are normally bi-directional or reverse path
congruent. congruent.
o Contiguous Eth-LSP o Contiguous Eth-LSP
A contiguous Eth-LSP is an Eth-LSP that maps one to one with an A contiguous Eth-LSP is an Eth-LSP that maps one to one with an
another LSP at a VLAN boundary. Stitched LSP are contiguous LSPs. another LSP at a VLAN boundary. Stitched LSPs are contiguous
LSPs.
o Eth-LSP o Eth-LSP
This term refers to Ethernet switched paths that may be This term refers to Ethernet 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 aggregate Eth-LSPs by creating a hierarchy
of Eth-LSPs. of Eth-LSPs.
skipping to change at page 9, line 40 skipping to change at page 9, line 40
_.-' ``-.._ _.-' ``-.._
_.-' `-.. _.-' `-..
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 types are defined in Clause 25 of [802.1ah], and are consistent The switching types are defined in Clause 25 of [802.1ah]. While not
with the definitions of Ethernet services supported in [G.8011] and specifically described in [802.1ah], the Ethernet services being
[MEF.6]. To summarize the definitions: 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-
tagged service type).
[802.1ah] defines a new I-tagged service type but does not
specifically define the Ethernet services being defined in the
context of [MEF.6] and [G.8011] which are also illustrated in Figure
1.
To summarize the definitions:
o Port based o Port based
This is a frame based service that supports specific frame types, This is a frame based service that supports specific frame types,
no Service VLAN tagging, with MAC address based switching. no Service VLAN tagging, with MAC address based switching.
o S-tagged o S-tagged
There are multiple Service VLAN tag (S-tag) aware services, There are multiple Service VLAN tag (S-tag) aware services,
including: including:
+ one-to-one + one-to-one
skipping to change at page 10, line 37 skipping to change at page 10, line 47
markings as well as some other fields. An I-Tagged service is 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 I-
component relay involves a distinct relay, it is possible to have a component relay involves a distinct relay, it is possible to have a
visible I-Tagged Service by separating the I component relay from 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 to a customer's Provider Instance Port. attachment to a customer's Provider Instance Port.
In general, the different switching type determines 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 on a hop-by-hop basis. for UNIs tend to use the headers for requesting service (service
delimiter) and are relevant between the customer site and network
edge.
In most bridging cases, the header fields cannot be changed hop-by- In most bridging cases, the header fields cannot be changed, but some
hop, but some translations of VID field values are permitted, translations of VID field values are permitted, typically at the
typically at the edges. While not specifically described in network edges.
[802.1ah], the Ethernet services being defined in the context of
[MEF.6] and [G.8011] also fall into the types defined in Figure 1.
Across all service types, the Ethernet data plane is bi-directional Across all service types, the Ethernet data plane is bi-directional
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 bi-directional links. This exact same set of nodes, ports and bi-directional links. This
property is fundamental. The 802.1 group has maintained this bi- property is fundamental. The 802.1 group has maintained this bi-
directional congruent property in the definition of Connectivity directional 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 Operations
Administration and Management (OAM) capability. Administration and Management (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 identifiers are dependent on the data plane so it works equally These OAM message identifiers are dependent on the data plane so they
well for provisioned or GMPLS controlled paths. 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]: Defined in both [802.1ag & Y.1731]:
- CCM/RDI: Connectivity Check, Remote Defect Indication - CCM/RDI: Connectivity Check, Remote Defect Indication
- LBM/LBR: Loopback Message, Loopback Reply - LBM/LBR: Loopback Message, Loopback Reply
- LTM/LTR: Link trace Message, Link trace Reply - LTM/LTR: Link trace Message, Link trace Reply
- VSM/VSR: Vendor-specific extensions Message/Reply - VSM/VSR: Vendor-specific extensions Message/Reply
Additionally defined in [Y.1731]: Additionally defined in [Y.1731]:
- AIS: Alarm Indication Signal - AIS: Alarm Indication Signal
- LCK: Locked Signal - LCK: Locked Signal
- TST: Test - TST: Test
- LMM/LMR: Loss Measurement Message/Reply - LMM/LMR: Loss Measurement Message/Reply
- DM/DMM/DMR: Delay Measurement - DM/DMM/DMR: Delay Measurement
- EXM/EXR: Experimental - EXM/EXR: Experimental
- APS, MCC: Automatic Protection Switching, Maintenance - APS, MCC: Automatic Protection Switching, Maintenance
Communication Channel Communication Channel
With some Eth-LSP label formats bi-directional transactions (e.g. These functions are supported across all the Standardized Eth-LSP
LBM/LBR) and reverse direction transactions MAY have a different VID formats.
for each direction. Both Y.1731 & 802.1ag assumes that bi-
directional transactions (e.g., LBM/LBR) use the same VID in both
directions. However in some scenarios, especially with explicitly
routed paths [802.1Qay], it is possible that different VIDs are used
upstream and downstream. In the context of [802.1Qay] work is ongoing
to update [802.1ag] to support such scenarios."
2.3. Ethernet Switching Characteristics 2.3. Ethernet Switching Characteristics
Ethernet is similar to MPLS it encapsulates many packet and frame Ethernet is similar to MPLS it encapsulates different packet and
types for data transmission. In Ethernet the encapsulated data is frame types for data transmission. In Ethernet, the encapsulated
referred to as MAC client data. The encapsulation is an Ethernet MAC data is referred to as MAC client data. The encapsulation is an
frame with a header, a source address, destination address, optional Ethernet MAC frame with a header, a source address, destination
VLAN identifier, Type and length on the front of the MAC client data address, optional VLAN identifier, Type and length on the front of
with optional padding and a Frame Check Sequence at the end of the the MAC client data with optional padding and a Frame Check Sequence
frame. 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 supports
an implicit type indication. an implicit type indication.
Ethernet bridging switches Ethernet based on the Frame destination Ethernet bridging switches Ethernet based on the Frame destination
address and VLAN. The VLAN identifies an active topology. The MAC address and VLAN. The VLAN identifies a virtual set of Bridges
address is assumed to be unique and invariant within the VLAN. MAC and LANs. The address is assumed to be unique and invariant within
addresses are often globally unique but this is not necessary for the VLAN. MAC addresses are often globally unique but this is not
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 architecture and switching characteristics of that technology. The architecture
includes a clear separation between a control plane and a data plane. includes a clear separation between a control plane and a data plane.
Control plane and data plane separation allows the GMPLS control Control plane and data plane separation allows the GMPLS control
plane to remain architecturally and functionally unchanged while plane to remain architecturally and functionally unchanged while
controlling different technologies. The architecture also requires controlling different technologies. The architecture also requires
skipping to change at page 13, line 12 skipping to change at page 13, line 12
- bi-directional service; - bi-directional 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 committed information rate,
peak information rate, and policies based on either under- 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 MUST use a TSpec that follows the Ethernet Traffic framework MUST 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 may be extended to
work with the Ethernet data plane and switching functions. The
definition of GMPLS support for Ethernet is multi-faceted due to the
different forwarding/switching functions inherent in the different
service types discussed in Section 2.1. In general, the header fields
used in the forwarding/switching function, e.g. VID and DMAC, can be
characterized as a data plane label. In some circumstances these
fields will be constant along the path of 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 be forwarded unchanged,
there are a few constraints on the label allocation that are similar
to some other technologies such as lambda labels.
The GMPLS architecture, per [RFC3945], allowed for control of The GMPLS architecture, per [RFC3945], allowed for control of
Ethernet bridges and other layer 2 technologies using the L2SC Ethernet bridges and other layer 2 technologies using the Layer-2
switching type. Although, it is worth noting that the control of Switch Capable (L2SC) switching type. The control of Ethernet
Ethernet switching was not explicitly defined in [RFC3471], [RFC4202] switching was not explicitly defined in [RFC3471], [RFC4202] or any
or any other subsequent GMPLS reference document. other subsequent GMPLS reference document.
In applying GMPLS to "transport" Ethernet, GMPLS will need to be
extended to work with the Ethernet data plane and switching
functions. The definition of GMPLS support for Ethernet is multi-
faceted due to the different forwarding/switching functions inherent
in the different service types discussed in Section 2.1. In general,
the header fields used in the forwarding/switching function, e.g. VID
and DMAC, can be characterized as a data plane label. In some
circumstances these fields will be constant along the path of 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
be forwarded unchanged, there are a few constraints on the label
allocation that are similar to some other technologies such as lambda
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 taken based on
the DMAC. When forwarding using an Ethernet spanning tree, if the the DMAC. When forwarding using an Ethernet spanning tree, if the
DMAC is not found the frame is broadcast over all outgoing interfaces DMAC is not found the frame is broadcast over all outgoing interfaces
for which that VID is defined. This valid MAC checking and broadcast for which that VID is defined. This valid MAC checking and broadcast
supports Ethernet learning. A special case is when a VID is defined supports Ethernet learning. A special case is when a VID is defined
skipping to change at page 14, line 21 skipping to change at page 14, line 22
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. Since the L2SC switching type may already be used by
implementations performing layer 2 switching including Ethernet. To implementations performing layer 2 switching including Ethernet, to
support the continued use of that switching type and those support the continued use of that switching type and those
implementations, a new switching type MUST be defined for each new implementations, and to distinguish the different Ethernet switching
paradigms, a new Ethernet switching type MUST 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
skipping to change at page 15, line 7 skipping to change at page 15, line 7
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 Ethernet MUST strictly provide mapping to an IP address. Support of Ethernet MUST strictly
comply to the GMPLS protocol suite addressing as specific in RFC3471, comply to the GMPLS protocol suite addressing as specific in RFC3471,
RFC3473 and related. RFC3473 and related.
4.1. GMPLS Routing 4.1. GMPLS Routing
GMPLS routing as defined in [RFC4202] is IP routing with the opaque GMPLS routing as defined in [RFC4202] uses IP routing protocols with
TLV extensions for the purpose of distributing GMPLS related TE the opaque TLV extensions for the purpose of distributing GMPLS
(router and link) information. As is always the case with GMPLS, TE related TE (router and link) information. As is always the case with
information is populated with TE resources coordinated with LMP or GMPLS, TE information is populated with TE resources coordinated with
from configured information. The bandwidth resources of the links are LMP or from configured information. The bandwidth resources of the
tracked as Eth-LSPs are set up. Interfaces supporting the switching links are tracked as Eth-LSPs are set up. Interfaces supporting the
of Eth-LSPs are identified using the appropriate Interface Switching switching of Eth-LSPs are identified using the appropriate Interface
Capabilities. As mentioned in Section 3, the definition of one or Switching Capabilities Descriptor. As mentioned in Section 3, the
more new Interface Switching Capabilities to support Eth-LSPs is definition of one or more new Interface Switching Capabilities to
expected. The L2SC Interface Switching Capabilities MUST NOT be used support Eth-LSPs is expected. The L2SC Interface Switching
to represent interfaces capable of supporting Eth-LSPs. Interface Capabilities MUST NOT be used to represent interfaces capable of
Switching Capability specific TE information may be defined as needed supporting Eth-LSPs defined by this document and subsequent documents
to support the requirements of a specific Ethernet Switching Service in support of the transport Ethernet switching paradigms. In
Type. addition, Interface Switching Capability specific TE information may
be defined as needed to support the requirements of a specific
Ethernet Switching Service Type.
GMPLS Routing is an optional piece but it is highly valuable in GMPLS Routing is an optional functionality but it is highly valuable
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 network of In order for a GMPLS control plane to operate, an IP connectivity
sufficient capacity to handle the information exchange between the network of sufficient capacity to handle the information exchange
GMPLS routing and signaling protocols is necessary. between the GMPLS routing and signaling protocols is necessary.
One way to implement this is with an IGP that views each switch as a One way to implement this is with an IGP that views each switch as a
terminated IP adjacency. In other words, IP traffic and a simple terminated IP adjacency. In other words, IP traffic and a simple
routing table are available for the control plane but there is no routing table are available for the control plane but there is no
requirement for a high performance IP data plane. requirement for needing a high performance IP data plane.
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, see [RFC3471][RFC3473], is well suited to the
control of Eth-LSPs and Ethernet switches. Signaling enables the control of Eth-LSPs and Ethernet switches. Signaling enables 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
skipping to change at page 16, line 18 skipping to change at page 16, line 28
GMPLS signaling supports the establishment and control of bi- GMPLS signaling supports the establishment and control of bi-
directional and unidirectional data paths. Ethernet is bi-directional directional and unidirectional data paths. Ethernet is bi-directional
by nature and the CFM has been built to leverage this. Prior to CFM by nature and the CFM has been built to leverage this. Prior to CFM
the emulation of a physical wire and the learning requirements also the emulation of a physical wire and the learning requirements also
mandated bi-directional connections. Given this, Eth-LSPs MUST be bi- mandated bi-directional connections. Given this, Eth-LSPs MUST be bi-
directional congruent. Eth-LSPs may be either P2P or P2MP (see directional congruent. Eth-LSPs may be either P2P or P2MP (see
[RFC4875]). GMPLS signaling also allows for full and partial LSP [RFC4875]). GMPLS signaling also allows for full and partial LSP
protection; see [RFC4872] and [RFC4873]. 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 bi-directional LSP. See [GMPLS-ASYM] if asymmetric direction of a bi-directional LSP. [GMPLS-ASYM], an Experimental
bandwidth bi-directional LSPs are required. document, provides procedures if asymmetric bandwidth bi-directional
LSPs are required.
6. Link Management 6. Link Management
Link discovery has been specified for Ethernet in [802.1AB]. However Link discovery has been specified for Ethernet in [802.1AB]. The
the 802.1AB capability is an optional feature, is not necessarily benefits of running link discovery in large systems are significant.
operating before a link is operational, and it primarily supports the Link discovery may reduce configuration and reduce the possibility of
management plane. The benefits of running link discovery in large undetected errors in configuration as well as exposing
systems are significant. Link discovery may reduce configuration and misconnections. However the 802.1AB capability is an optional
reduce the possibility of undetected errors in configuration as well feature, it is not necessarily operating before a link is
as exposing misconnections. operational, and it primarily supports the management plane.
In the GMPLS context, LMP [RFC4204] has been defined to support link In the GMPLS context, LMP [RFC4204] has been defined to support GMPLS
management and discovery features. LMP also supports the automated control plane link management and discovery features. LMP also
creation of unnumbered interfaces. If LMP is not used there is an supports for the control plane the automated creation of unnumbered
additional configuration requirement to add GMPLS link identifiers. interfaces. If LMP is not used there is an additional configuration
For large-scale implementations LMP would be beneficial. LMP also has requirement for GMPLS link identifiers. For large-scale
fault management capabilities that overlap with CFM [802.1ag] and implementations LMP is beneficial. LMP also has optional fault
[Y.1731]. It is the goal of the architecture to allow the selection management capabilities, primarily for opaque and transparent network
of the best tool set for the user needs so full functionality of technology. With IEEE's newer CFM [802.1ag] and ITU's [Y.1731]
Ethernet CFM should be allowed. capabilities, this optional capability may not be needed. It is the
goal of the GMPLS Ethernet architecture to allow the selection of the
best tool set for the user
needs. The full 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 should
be sufficient to remove the need for 802.1AB but 802.1 AB can be run be sufficient to remove the need for 802.1AB but 802.1 AB can be run
in parallel or independently if desired. Figure 2 provides possible in parallel or independently if desired. Figure 2 provides possible
ways of using LMP, 802.1AB and 802.1ag in combination. 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 intended that LMP would use functions of and OAM schemes. It is expected that LMP would be used for control
link property correlation but that Ethernet mechanisms for OAM such plane functions of link property correlation but that Ethernet
as CFM, link trace etc would be used for fault management and fault mechanisms for OAM such as CFM, link trace etc would be used for data
trace. plane fault management and fault trace.
+-------------+ +-------------+ +-------------+ +-------------+
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
| | | | | | | |GMPLS | | | | | | | |GMPLS
| | LMP |-|<------>|-| LMP | |Link Property | | LMP |-|<------>|-| LMP | |Link Property
| | | | | | | |Correlation | | | | | | | |Correlation
| | (opt) | |IP | | (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
skipping to change at page 18, line 17 skipping to change at page 18, line 36
This document allows for the support the signaling of Ethernet This document allows for the support 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
The architecture for GMPLS controlled "transport" Ethernet assumes The architecture for GMPLS controlled "transport" Ethernet assumes
that the network consists of trusted devices, but does not require that the network consists of trusted devices, but does not require
that the ports over which a UNI are defined are trusted, nor does that the ports over which a UNI are defined are trusted, nor does
equipment connected to these ports need to be trusted. Access to the equipment connected to these ports trusted. In general, these
trusted network SHALL only occur through the protocols defined in the requirements are no different from the security requirements for
UNI or NNI or through protected management interfaces. operating any GMPLS network. Access to the trusted network SHALL only
occur through the protocols defined for the UNI or NNI or through
protected management 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 the control plane other. When out-of-band GMPLS signaling is used the control plane
the data plane security is decoupled from the control plane and the data plane security is decoupled from the control plane and
therefore the security of the data plane has less impact on overall therefore the security of the data plane has less impact on overall
security. 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 DOS attacks may be
required on UNI ports. 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]. MPLS and GMPLS Security Framework [SECURITY]. It is expected that
solution documents will include a full analysis of the security
issues that any protocol extensions introduce.
10. IANA Considerations 10. IANA Considerations
No new values are specified in this document. No new values are specified in this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 21, line 8 skipping to change at page 21, line 23
acknowledge the work of these authors of these initial drafts: acknowledge the work of these authors of these initial drafts:
Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan, Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan,
Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia, Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia,
Himanshu Shah, Greg Sunderwood, Alan McGuire, Nabil Bitar. Himanshu Shah, Greg Sunderwood, Alan McGuire, Nabil Bitar.
George Swallow contributed significantly to this document. George Swallow contributed significantly to this document.
13. Author's Addresses 13. Author's Addresses
Don Fedyk Don Fedyk
Nortel Networks Alcatel-Lucent
600 Technology Park Drive Groton, MA, 01450
Billerica, MA, 01821 Phone: +1-978-467-5645
Phone: +1-978-288-3041 Email: donald.fedyk@alcatel-lucent.com
Email: dwfedyk@nortel.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 AB
Phone:+46 8 632 77 14 Phone: +46 10 717 52 13
Email: loa@pi.nu Email: loa.andersson@ericsson.com
Generated on: Fri Feb 13 11:56:46 EST 2009 Generated on: Tue Sep 1 11:27:49 EDT 2009
 End of changes. 49 change blocks. 
212 lines changed or deleted 230 lines changed or added

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