draft-ietf-ccamp-gmpls-ethernet-arch-06.txt   draft-ietf-ccamp-gmpls-ethernet-arch-07.txt 
Internet Draft Don Fedyk, Alcatel-Lucent Internet Draft Don Fedyk, Alcatel-Lucent
Category: Informational Lou Berger, LabN Category: Informational Lou Berger, LabN
Expiration Date: April 14, 2010 Loa Andersson, Ericsson AB Expiration Date: June 2, 2010 Loa Andersson, Ericsson AB
October 14, 2009 December 2, 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-06.txt draft-ietf-ccamp-gmpls-ethernet-arch-07.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.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 14, 2010. This Internet-Draft will expire on June 2, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 15 skipping to change at page 2, line 7
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 MPLS based control plane
plane for Ethernet in this "transport network" capacity. GMPLS has for Ethernet in this "transport network" capacity. GMPLS has already
already been specified for similar technologies. Some additional been specified for similar technologies. Some additional extensions
extensions to the GMPLS control plane are needed and this document to the GMPLS control plane are needed and this document provides a
provides a framework for these extensions. 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 ............................. 7
2 Background ............................................. 8 2 Background ............................................. 8
2.1 Ethernet Switching ..................................... 8 2.1 Ethernet Switching ..................................... 8
2.2 Operations, Administration, and Maintenance (OAM) ...... 11 2.2 Operations, Administration, and Maintenance (OAM) ...... 11
skipping to change at page 3, line 29 skipping to change at page 3, line 29
5 GMPLS Signaling ........................................ 15 5 GMPLS Signaling ........................................ 15
6 Link Management ........................................ 16 6 Link Management ........................................ 16
7 Path Computation and Selection ......................... 17 7 Path Computation and Selection ......................... 17
8 Multiple VLANs ......................................... 18 8 Multiple VLANs ......................................... 18
9 Security Considerations ................................ 18 9 Security Considerations ................................ 18
10 IANA Considerations .................................... 18 10 IANA Considerations .................................... 18
11 References ............................................. 18 11 References ............................................. 18
11.1 Normative References ................................... 18 11.1 Normative References ................................... 18
11.2 Informative References ................................. 19 11.2 Informative References ................................. 19
12 Acknowledgments ........................................ 20 12 Acknowledgments ........................................ 20
13 Author's Addresses ..................................... 20 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 support transport networks. This activity has taken place Technology to support transport networks. This activity has taken
in the Institute of Electrical and Electronics Engineers (IEEE) 802.1 place in the Institute of Electrical and Electronics Engineers (IEEE)
Working Group, the International Telecommunication Union (ITU) and 802.1 Working Group, the International Telecommunication Union -
the Metro Ethernet Forum (MEF). These groups have been focusing on Telecommunication Standardization Sector (ITU-T) and the Metro
Ethernet forwarding, Ethernet management plane extensions and the Ethernet Forum (MEF). These groups have been focusing on Ethernet
Ethernet Spanning Tree Control Plane, but not on an explicitly forwarding, Ethernet management plane extensions and the Ethernet
routed, constraint based control plane. Spanning Tree Control Plane, but not on an explicitly 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 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]. These
extensions allow for greater flexibility in the Ethernet forwarding extensions allow for greater flexibility in the Ethernet forwarding
plane and, in some cases, the extensions allow for a departure from plane and, in some cases, the extensions allow for a departure from
forwarding based on Ethernet spanning tree. For example, in the forwarding based on Ethernet spanning tree. For example, in the
[802.1Qah] case, greater flexibility in forwarding is achieved [802.1Qah] case, greater flexibility in forwarding is achieved
through the addition of a "provider" address space. [802.1Qay] through the addition of a "provider" address space. [802.1Qay]
supports the use of provisioning systems and network control supports the use of provisioning systems and network control
protocols that explicitly 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 VLAN 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 (PBB) [802.1ah], a 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.
In the IEEE 802.1Q standard the terms Provider Backbone Bridges (PBB) In the IEEE 802.1Q standard the terms Provider Backbone Bridges (PBB)
and Provider Backbone Bridged Network (PBBN) are used in the context and Provider Backbone Bridged Network (PBBN) are used in the context
of these extensions. 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 Metro Ethernet Forum (MEF) and International Telecommunication of the MEF and ITU-T. [MEF.6] and [G.8011] provide parallel
Union (ITU). [MEF.6] and [G.8011] provide parallel frameworks for frameworks for defining network-oriented characteristics of Ethernet
defining network-oriented characteristics of Ethernet services in services in transport networks. These framework documents discuss
transport networks. These framework documents discusses general general Ethernet connection characteristics, Ethernet User-Network
Ethernet connection characteristics, Ethernet User-Network Interfaces Interfaces (UNIs) and Ethernet Network-Network Interfaces (NNIs).
(UNIs) and Ethernet Network-Network Interfaces (NNIs). [G.8011.1] [G.8011.1] defines the Ethernet Private Line (EPL) service and
defines the Ethernet Private Line (EPL) service and [G.8011.2] [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service.
defines the Ethernet Virtual Private Line (EVPL) service. [MEF.6] [MEF.6] covers both service types. These activities are consistent
covers both service types. These activities are consistent with the 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 allow for the The Ethernet forwarding and management plane extensions allow for the
disabling of standard Ethernet spanning tree but do not define an disabling of standard Ethernet spanning tree but do not define an
explicitly routed, constraint based control plane. For example explicitly routed, constraint-based control plane. For example
[802.1Qay] is an amendment to IEEE 802.1Q that explicitly allows for [802.1Qay] is an amendment to IEEE 802.1Q that explicitly allows for
traffic engineering of Ethernet forwarding paths. 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 RFC3945 [RFC3945].
The protocols specified for GMPLS can be used to control "Transport The protocols specified for GMPLS can be used to control "Transport
Network" technologies, e.g. Optical and TDM networks. GMPLS can also Network" technologies, e.g. Optical and TDM networks. GMPLS can also
be used for packet and Layer 2 Switching (frame/cell based 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 Label Switched Paths (Eth-LSP). Transport "transport" Ethernet Label Switched Paths (Eth-LSP). Transport
Ethernet adds new constraints which require it to be distinguished Ethernet adds new constraints which require it to be distinguished
from the previously specified technologies for GMPLS. Some additional from the previously specified technologies for GMPLS. 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. All extensions to support provides a framework for these extensions. All extensions to support
Eth-LSPs will build on the GMPLS architecture and related Eth-LSPs will build on the GMPLS architecture and related
specifications. specifications.
skipping to change at page 6, line 19 skipping to change at page 6, line 18
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 may have differing bandwidth allocation in each instance 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 data planes are normally bidirectional or reverse path Ethernet data planes are normally bidirectional congruent
congruent. (sometimes known as reverse path 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 end-to-end Eth-LSP that is formed from
another LSP at a VLAN boundary. Stitched LSPs are contiguous multiple Eth-LSPs each operating within a VLAN and that are
LSPs. mapped one-to-one at the VLAN boundaries. Stitched LSPs form
contiguous LSPs.
o Eth-LSP o Eth-LSP
This term refers to Ethernet 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 aggregate Eth-LSPs by creating 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 IP based control messages which are
skipping to change at page 7, line 12 skipping to change at page 7, line 13
Ethernet header. Logical links that use a dedicated VID on the Ethernet header. Logical links that use a dedicated VID on the
same physical links would be considered In-band signaling. 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 P2P unidirectional Eth-LSPs. two 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 which comprises
one P2MP LSP from a root to n leaves plus a Bidirectional one P2MP LSP from a root to n leaves plus a Bidirectional
Congruent point-to-point (P2P) LSP from each of the leaves to the Congruent 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 + DMAC) may be used for frames from
multiple sources (SMAC). Shared forwarding does not change any multiple sources (SMAC). Shared forwarding does not change any
data plane behavior. Shared forwarding saves forwarding database data plane behavior. Shared forwarding saves forwarding database
(FDB) entries only. Shared forwarding offers similar benefits to (FDB) entries only. Shared forwarding offers similar benefits to
merging in the data plane. However in shared forwarding the merging in the data plane. However in shared forwarding the
Ethernet data packets are unchanged when using shared forwarding. Ethernet data packets are unchanged when using shared forwarding.
With shared forwarding dedicated control plane states for all With shared forwarding dedicated control plane states for all
Eth-LSP are maintained regardless of shared forwarding entries. 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 Service Identifier I-SID Service Identifier
skipping to change at page 8, line 31 skipping to change at page 8, line 33
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 this
document to allow for all standard forms of Ethernet switching and document to allow for all standard forms of Ethernet switching and
services. 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 on-going 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 description of that work. authoritative 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 (VID) and Destination Media Access Control
skipping to change at page 10, line 50 skipping to change at page 11, line 5
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 Operations
Administration and Management (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 they
skipping to change at page 13, line 43 skipping to change at page 13, line 47
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 key a 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
skipping to change at page 14, line 22 skipping to change at page 14, line 26
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 specific in
RFC3471, RFC3473 and related documents. [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 Descriptor. As mentioned in Section
3, the definition of one or more new Interface Switching Capabilities 3, the definition of one or more new Interface Switching Capabilities
to support Eth-LSPs is expected. Again, the L2SC Interface Switching to support Eth-LSPs is expected. Again, the L2SC Interface Switching
Capabilities will not be used to represent interfaces capable of Capabilities will not be used to represent interfaces capable of
supporting Eth-LSPs defined by this document and subsequent documents supporting Eth-LSPs defined by this document and subsequent documents
in support of the transport Ethernet switching paradigms. In in support of the transport Ethernet switching paradigms. In
addition, Interface Switching Capability specific TE information may addition, Interface Switching Capability specific TE information may
be defined as needed to support the requirements of a specific be defined as needed to support the requirements of a specific
Ethernet 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 network of sufficient capacity to handle the information exchange of
between 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 needing a high
performance IP data plane, or for forwarding user traffic over this performance IP 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-
skipping to change at page 16, line 4 skipping to change at page 16, line 8
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. [GMPLS-ASYM], 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 Ethernet in [802.1AB]. The Link discovery has been specified for Ethernet in [802.1AB]. The
benefits of running link discovery in large systems are significant. benefits of running link discovery in large systems are significant.
Link discovery may reduce configuration and reduce the possibility of Link discovery may reduce configuration and reduce the possibility of
undetected errors in configuration as well as exposing undetected errors in configuration as well as exposing
misconnections. However the 802.1AB capability is an optional misconnections. However the 802.1AB capability is an optional
feature, it is not necessarily operating before a link is feature, it is not necessarily operating before a link is
operational, and it primarily supports the management plane. operational, and it primarily supports the 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 for the control plane the automated creation of unnumbered
interfaces. If LMP is not used there is an additional configuration interfaces. If LMP is not used there is an additional configuration
requirement for GMPLS link identifiers. For large-scale requirement for GMPLS link identifiers. For large-scale
implementations LMP is beneficial. LMP also has optional fault implementations LMP is beneficial. LMP also has optional fault
management capabilities, primarily for opaque and transparent network management capabilities, primarily for opaque and transparent network
technology. With IEEE's newer CFM [802.1ag] and ITU's [Y.1731] technology. With IEEE's newer CFM [802.1ag] and ITU-T's [Y.1731]
capabilities, this optional capability may not be needed. It is the capabilities, this optional capability may not be needed. It is the
goal of the GMPLS Ethernet architecture to allow the selection of 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 best tool set for the user needs. The full functionality of Ethernet
CFM should be supported when using a GMPLS control plane. 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.
skipping to change at page 17, line 48 skipping to change at page 17, line 48
computed in a fully distributed fashion, on a management station with computed in a fully distributed fashion, on a management station with
local computation for rerouting, or on more sophisticated path local computation for rerouting, or on more sophisticated path
computation servers. 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, and
common to all path selection mechanisms, the path selection process common to all path selection mechanisms, the path selection process
should take into consideration Switching Capabilities and Encoding should take into consideration Switching Capabilities and Encoding
advertised for a particular interface. Eth-LSPs may also make use of advertised for a particular interface. Eth-LSPs may also make use of
the emerging path computation element and selection work; see the emerging path computation element and selection work; see
[RFC4655] [RFC4655].
8. Multiple VLANs 8. Multiple VLANs
This document allows for the support 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
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 trusted. In general, these equipment connected to these ports require to be trusted. In
requirements are no different from the security requirements for general, these requirements are no different from the security
operating any GMPLS network. Access to the trusted network will only requirements for operating any GMPLS network. Access to the trusted
occur through the protocols defined for the UNI or NNI or through network will only occur through the protocols defined for the UNI or
protected management interfaces. 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 for the control
the data plane security is decoupled from the control plane and plane 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]. It is expected that MPLS and GMPLS Security Framework [SECURITY]. It is expected that
solution documents will include a full analysis of the security solution documents will include a full analysis of the security
skipping to change at page 19, line 13 skipping to change at page 19, line 13
Functional Description", January 2003, RFC3471. Functional Description", January 2003, RFC3471.
[RFC3473] Berger, L. (editor), "Generalized Multi-Protocol Label [RFC3473] Berger, L. (editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
January 2003, RFC3473. January 2003, RFC3473.
[RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in
Support of Generalized MPLS", RFC 4202, October 2005 Support of Generalized MPLS", RFC 4202, October 2005
11.2. Informative References [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3495.
[G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection 11.2. Informative References
Switching.
[G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over [G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection
Transport - Ethernet services framework. Switching.
[RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label [G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over
Switching (GMPLS) Architecture", RFC 3495. Transport - Ethernet services framework.
[802.1AB] "IEEE Standard for Local and Metropolitan Area [802.1AB] "IEEE Standard for Local and Metropolitan Area
Networks, Station and Media Access Control Networks, Station and Media Access Control
Connectivity Discovery" (2004). Connectivity Discovery" (2004).
[802.1ag] "IEEE Standard for Local and Metropolitan Area [802.1ag] "IEEE Standard for Local and Metropolitan Area
Networks - Virtual Bridged Local Area Networks Networks - Virtual Bridged Local Area Networks
- Amendment 5:Connectivity Fault Management", - Amendment 5:Connectivity Fault Management",
(2007). (2007).
[802.1ah] "IEEE Standard for Local and Metropolitan Area [802.1ah] "IEEE Standard for Local and Metropolitan Area
Networks - Virtual Bridged Local Area Networks Networks - Virtual Bridged Local Area Networks
- Amendment 6: Provider Backbone Bridges", (2008) - Amendment 6: Provider Backbone Bridges", (2008)
[802.1Qay] "IEEE standard for Provider Backbone Bridge Traffic [802.1Qay] "IEEE standard for Provider Backbone Bridge Traffic
Engineering", work in progress. Engineering", work in progress.
[802.1Q] "IEEE standard for Virtual Bridged Local Area Networks [802.1Q] "IEEE standard for Virtual Bridged Local Area Networks
802.1Q-2005", May 19, 2006 802.1Q-2005", May 19, 2006
[RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)"
RFC4204, October 2005 RFC4204, October 2005
[MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services
Definitions - Phase I". Definitions - Phase I".
[MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet
Services Attributes Phase 1". Services Attributes Phase 1".
[RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to
Multipoint TE LSPs", IETF RFC 4875, May 2007 Multipoint TE LSPs", IETF RFC 4875, May 2007
[RFC4655] Farrel, A. et.al., "Path Computation Element (PCE) [RFC4655] Farrel, A. et.al., "Path Computation Element (PCE)
Architecture", RFC 4655, August 2006. Architecture", RFC 4655, August 2006.
[RFC4872] Lang et.al., "RSVP-TE Extensions in support of [RFC4872] Lang et.al., "RSVP-TE Extensions in support of
End-to-End Generalized Multi-Protocol Label Switching End-to-End Generalized Multi-Protocol Label Switching
(GMPLS)-based Recovery ", RFC 4872, May 2007. (GMPLS)-based Recovery ", RFC 4872, May 2007.
[RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May
2007. 2007.
[Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM
Functions and Mechanisms for Ethernet based Networks ", Functions and Mechanisms for Ethernet based Networks ",
work in progress. work in progress.
[GMPLS-ASYM] Berger, L. et al., "GMPLS Asymmetric Bandwidth [RFC5467] Berger, L. et al., "GMPLS Asymmetric Bandwidth
Bidirectional LSPs", work in progress. Bidirectional LSPs", RFC5467, March 2009.
[ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", work [ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters",
in progress. draft-ietf-ccamp-ethernet-traffic-parameters-09.txt,
work in progress.
[SECURITY] Luyuan Fang, Ed., " Security Framework for MPLS [SECURITY] Luyuan Fang, Ed., "Security Framework for MPLSand GMPLS
and GMPLS Networks", work in progress. Networks", draft-ietf-mpls-mpls-and-gmpls-security-
framework-07.txt, work in progress.
12. Acknowledgments 12. 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 draft and the PBB-TE extensions
drafts were two drafts the helped shape and justify this work. We drafts were two drafts the helped shape and justify this work. We
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, and 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
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
skipping to change at line 888 skipping to change at line 887
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 10 717 52 13 Phone: +46 10 717 52 13
Email: loa.andersson@ericsson.com Email: loa.andersson@ericsson.com
Generated on: Wed Oct 14 14:54:18 EDT 2009 Generated on: Wed Dec 2 12:35:33 EST 2009
 End of changes. 51 change blocks. 
101 lines changed or deleted 99 lines changed or added

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