draft-ietf-ccamp-gmpls-ethernet-arch-05.txt   draft-ietf-ccamp-gmpls-ethernet-arch-06.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: March 1, 2010 Loa Andersson, Ericsson AB Expiration Date: April 14, 2010 Loa Andersson, Ericsson AB
September 1, 2009 October 14, 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-05.txt draft-ietf-ccamp-gmpls-ethernet-arch-06.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 March 1, 2010. This Internet-Draft will expire on April 14, 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 3, line 10 skipping to change at page 3, line 10
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 ............................. 8 1.1.2 Abbreviations and Acronyms ............................. 7
2 Background ............................................. 8 2 Background ............................................. 8
2.1 Ethernet Switching ..................................... 9 2.1 Ethernet Switching ..................................... 8
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 ..................... 11
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 .......................................... 14
4.2 Control Plane Network .................................. 15 4.2 Control Plane Network .................................. 15
5 GMPLS Signaling ........................................ 16 5 GMPLS Signaling ........................................ 15
6 Link Management ........................................ 16 6 Link Management ........................................ 16
7 Path Computation and Selection ......................... 18 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 .................................... 19 10 IANA Considerations .................................... 18
11 References ............................................. 19 11 References ............................................. 18
11.1 Normative References ................................... 19 11.1 Normative References ................................... 18
11.2 Informative References ................................. 19 11.2 Informative References ................................. 19
12 Acknowledgments ........................................ 21 12 Acknowledgments ........................................ 20
13 Author's Addresses ..................................... 21 13 Author's Addresses ..................................... 20
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [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 to support transport networks. This activity has taken Technology support transport networks. This activity has taken place
place in the Institute of Electrical and Electronics Engineers (IEEE) in the Institute of Electrical and Electronics Engineers (IEEE) 802.1
802.1 Working Group, the International Telecommunication Union (ITU) Working Group, the International Telecommunication Union (ITU) and
and the Metro Ethernet Forum (MEF). These groups have been focusing the Metro Ethernet Forum (MEF). These groups have been focusing on
on Ethernet forwarding, Ethernet management plane extensions and the Ethernet forwarding, Ethernet management plane extensions and the
Ethernet Spanning Tree Control Plane, but not on an explicitly Ethernet Spanning Tree Control Plane, but not on an explicitly
routed, constraint based 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 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
skipping to change at page 5, line 22 skipping to change at page 5, line 15
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 Metro Ethernet Forum (MEF) and International Telecommunication
Union (ITU). [MEF.6] and [G.8011] provide parallel frameworks for Union (ITU). [MEF.6] and [G.8011] provide parallel frameworks for
defining network-oriented characteristics of Ethernet services in defining network-oriented characteristics of Ethernet services in
transport networks. These framework documents discuss general transport networks. These framework documents discusses general
Ethernet connection characteristics, Ethernet User-Network Interfaces Ethernet connection characteristics, Ethernet User-Network Interfaces
(UNIs) and Ethernet Network-Network Interfaces (NNIs). [G.8011.1] (UNIs) and Ethernet Network-Network Interfaces (NNIs). [G.8011.1]
defines the Ethernet Private Line (EPL) service and [G.8011.2] defines the Ethernet Private Line (EPL) service and [G.8011.2]
defines the Ethernet Virtual Private Line (EVPL) service. [MEF.6] defines the Ethernet Virtual Private Line (EVPL) service. [MEF.6]
covers both service types. These activities are consistent with the covers both service types. These activities are 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 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
skipping to change at page 6, line 15 skipping to change at page 6, line 6
This document introduces and explains GMPLS control plane use for This document introduces and explains GMPLS control plane use for
transport Ethernet and the concept of the Ethernet Label Switched transport Ethernet and the concept of the Ethernet Label Switched
Path (Eth-LSP). The data plane aspects of Eth-LSPs are outside the Path (Eth-LSP). The data plane aspects of Eth-LSPs are outside the
scope 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 computation to be used as specified. The GMPLS protocols support
hierarchical LSPs as well as contiguous LSPs. Also, GMPLS protocol hierarchical LSPs as well as contiguous LSPs. Also, GMPLS protocol
mechanisms support a variety of networks from peer to peer to UNIs mechanisms support a variety of network reference points from UNIs to
and NNIs. Additions to existing GMPLS capabilities will only be made NNIs. Additions to existing GMPLS capabilities will only be made to
to accommodate features unique to transport Ethernet. accommodate features unique to transport Ethernet.
1.1. Terminology 1.1. Terminology
1.1.1. Concepts 1.1.1. Concepts
The following are basic Ethernet and GMPLS terms: The following are basic Ethernet and GMPLS terms:
o Asymmetric Bandwidth o Asymmetric Bandwidth
This term refers to a property of a Bidirectional service This term refers to a property of a Bidirectional service
instance may have differing bandwidth allocation in each instance may have differing bandwidth allocation in each
direction. direction.
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 bidirectional LSP that uses
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 bi-directional or reverse path Ethernet data planes are normally bidirectional 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 LSPs are contiguous another LSP at a VLAN boundary. Stitched LSPs are contiguous
LSPs. LSPs.
o Eth-LSP o Eth-LSP
skipping to change at page 7, line 19 skipping to change at page 7, line 7
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
sent on the native Ethernet links encapsulated by a single hop sent on the native Ethernet links encapsulated by a single hop
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 IP based control messages which Out-of-band GMPLS Signaling is composed of IP based control
are sent between Ethernet switches that uses some other links messages that are sent between Ethernet switches over links other
other than the Ethernet data plane links. Out of band signaling than the links used by the Ethernet data plane. Out of band
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
An TE service instance made up from two P2P unidirectional Eth- A TE service instance made up of a single bidirectional P2P or
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
An 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
skipping to change at page 10, line 7 skipping to change at page 9, line 41
[802.1ah] defines a new I-tagged service type but does not [802.1ah] defines a new I-tagged service type but does not
specifically define the Ethernet services being defined in the specifically define the Ethernet services being defined in the
context of [MEF.6] and [G.8011] which are also illustrated in Figure context of [MEF.6] and [G.8011] which are also illustrated in Figure
1. 1.
To summarize the definitions: To summarize the definitions:
o Port based o Port based
This is a frame based service that supports specific frame types, This is a frame based service that supports specific frame types,
no Service VLAN tagging, with MAC address based switching. no Service VLAN tagging or MAC address based switching.
o S-tagged o S-tagged
There are multiple Service VLAN tag (S-tag) aware services, There are multiple Service VLAN tag (S-tag) aware services,
including: including:
+ one-to-one + one-to-one
In this service, each VLAN identifier (VID) is mapped into a In this service, each VLAN identifier (VID) is mapped into a
different service. different service.
+ Bundled + Bundled
skipping to change at page 11, line 11 skipping to change at page 10, line 44
e.g. VID only or VID and DMACs. The switching type may also require e.g. VID only or VID and DMACs. The switching type may also require
the use of additional Ethernet headers or fields. Services defined the use of additional Ethernet headers or fields. Services defined
for UNIs tend to use the headers for requesting service (service for UNIs tend to use the headers for requesting service (service
delimiter) and are relevant between the customer site and network delimiter) and are relevant between the customer site and network
edge. edge.
In most bridging cases, the header fields cannot be changed, but some In most bridging cases, the header fields cannot be changed, but some
translations of VID field values are permitted, typically at the translations of VID field values are permitted, typically at the
network edges. network edges.
Across all service types, the Ethernet data plane is bi-directional 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 bi-directional links. This exact same set of nodes, ports and bidirectional links. This
property is fundamental. The 802.1 group has maintained this bi- property is fundamental. The 802.1 group has maintained this
directional 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 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
skipping to change at page 12, line 7 skipping to change at page 11, line 38
- 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
These functions are supported across all the Standardized Eth-LSP These functions are supported across all the Standardized Eth-LSP
formats. formats.
2.3. Ethernet Switching Characteristics 2.3. Ethernet Switching Characteristics
Ethernet is similar to MPLS it encapsulates different packet and Ethernet is similar to MPLS as it encapsulates different packet and
frame types for data transmission. In Ethernet, the encapsulated frame types for data transmission. In Ethernet, the encapsulated
data is referred to as MAC client data. The encapsulation is an data is referred to as MAC client data. The encapsulation is an
Ethernet MAC frame with a header, a source address, destination Ethernet MAC frame with a header, a source address, destination
address, optional VLAN identifier, Type and length on the front of address, optional VLAN identifier, Type and length on the front of
the MAC client data with optional padding and a Frame Check Sequence the MAC client data with optional padding and a Frame Check Sequence
at the end of the 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 based on a frame's destination MAC address
MAC address and VLAN. The VLAN identifies a virtual set of Bridges and VLAN. The VLAN identifies a virtual active set of Bridges and
and LANs. The address is assumed to be unique and invariant within LANs. The address is assumed to be unique and invariant within the
the VLAN. MAC addresses are often globally unique but this is not VLAN. MAC addresses are often globally unique but this is not
necessary for bridging. necessary for bridging.
3. Framework 3. Framework
As defined in the GMPLS Architecture [RFC3945], the GMPLS control As defined in the GMPLS Architecture [RFC3945], the GMPLS control
plane can be applied to a technology by controlling the data plane plane can be applied to a technology by controlling the data plane
and switching characteristics of that technology. The architecture and switching characteristics of that technology. The GMPLS
includes a clear separation between a control plane and a data plane. architecture, per [RFC3945], allowed for control of Ethernet bridges
Control plane and data plane separation allows the GMPLS control and other layer 2 technologies using the Layer-2 Switch Capable
plane to remain architecturally and functionally unchanged while (L2SC) switching type. But, the control of Ethernet switching was
controlling different technologies. The architecture also requires not explicitly defined in [RFC3471], [RFC4202] or any other
IP connectivity for the control plane to exchange information, but subsequent GMPLS reference document.
does not otherwise require an IP data plane.
The GMPLS architecture includes a clear separation between a control
plane and a data plane. Control plane and data plane separation
allows the GMPLS control plane to remain architecturally and
functionally unchanged while controlling different technologies. The
architecture also requires IP connectivity for the control plane to
exchange information, but does not otherwise require an IP data
plane.
All aspects of GMPLS, i.e., addressing, signaling, routing and link All aspects of GMPLS, i.e., addressing, signaling, routing and link
management, may be applied to Ethernet switching. GMPLS can provide management, may be applied to Ethernet switching. GMPLS can provide
control for traffic engineered and protected Ethernet service paths. control for traffic engineered and protected Ethernet service paths.
This document defines the term "Eth-LSP" to refer to Ethernet service This document defines the term "Eth-LSP" to refer to Ethernet service
paths that are controlled via GMPLS. As is the case with all GMPLS paths that are controlled via GMPLS. As is the case with all GMPLS
controlled services, Eth-LSPs can leverage common traffic engineering controlled services, Eth-LSPs can leverage common traffic engineering
attributes such as: attributes such as:
- bandwidth profile; - bandwidth profile;
- forwarding priority level; - forwarding priority level;
- connection preemption characteristics; - connection preemption characteristics;
- protection/resiliency capability; - protection/resiliency capability;
- routing policy, such as an explicit route; - routing policy, such as an explicit route;
- bi-directional service; - bidirectional service;
- end-to-end and segment protection; - end-to-end and segment protection;
- hierarchy - hierarchy
The bandwidth profile may be used to set committed information rate, The bandwidth profile may be used to set 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 will use a TSpec that follows the Ethernet Traffic
parameters defined in [ETH-TSPEC]. parameters defined in [ETH-TSPEC].
The GMPLS architecture, per [RFC3945], allowed for control of
Ethernet bridges and other layer 2 technologies using the Layer-2
Switch Capable (L2SC) switching type. The control of Ethernet
switching was not explicitly defined in [RFC3471], [RFC4202] or any
other subsequent GMPLS reference document.
In applying GMPLS to "transport" Ethernet, GMPLS will need to be In applying GMPLS to "transport" Ethernet, GMPLS will need to be
extended to work with the Ethernet data plane and switching extended to work with the Ethernet data plane and switching
functions. The definition of GMPLS support for Ethernet is multi- functions. The definition of GMPLS support for Ethernet is multi-
faceted due to the different forwarding/switching functions inherent faceted due to the different forwarding/switching functions inherent
in the different service types discussed in Section 2.1. In general, in the different service types discussed in Section 2.1. In general,
the header fields used in the forwarding/switching function, e.g. VID the header fields used in the forwarding/switching function, e.g. VID
and DMAC, can be characterized as a data plane label. In some and DMAC, can be characterized as a data plane label. In some
circumstances these fields will be constant along the path of the 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 Eth-LSP, and in others they may vary hop-by-hop or at certain
interfaces only along the path. In the case where the "labels" must interfaces only along the path. In the case where the "labels" must
skipping to change at page 13, line 42 skipping to change at page 13, line 27
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
for only two ports on one bridge, effectively resulting in a p2p for only two ports on one bridge, effectively resulting in a p2p
forwarding constraint, in this case all frames tagged with that VID forwarding constraint. In this case all frames tagged with that VID
received over one of these ports are forward over the other port received over one of these ports are forward over the other port
without address learning. without address learning.
[802.1Qay]allows for turning off learning and hence the broadcast [802.1Qay] allows for turning off learning and hence the broadcast
mechanism providing means to create explicitly routed Ethernet mechanism providing means to create explicitly routed Ethernet
connections. connections.
This document does not define any specific format for an Eth-LSP This document does not define any specific format for an Eth-LSP
label. Rather, it is expected that service specific documents will label. Rather, it is expected that service specific documents will
define any signaling and routing extensions needed to support a define any signaling and routing extensions needed to support a
specific Ethernet service. Depending on the requirements of a specific Ethernet service. Depending on the requirements of a
service, it may be necessary to define multiple GMPLS protocol service, it may be necessary to define multiple GMPLS protocol
extensions and procedures. It is expected that all such extensions extensions and procedures. It is expected that all such extensions
will be consistent with this document. will be consistent with this document.
skipping to change at page 14, line 22 skipping to change at page 14, line 7
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. Since the L2SC switching type may already be used by an LSP. The L2SC switching type may already be used by
implementations performing layer 2 switching including Ethernet, to implementations performing layer 2 switching including Ethernet. As
support the continued use of that switching type and those such, and to allow the continued use of that switching type and those
implementations, and to distinguish the different Ethernet switching implementations, and to distinguish the different Ethernet switching
paradigms, a new Ethernet switching type MUST be defined for each new paradigms, a new switching type needs to be defined for each new
Ethernet switching paradigm that is supported. Ethernet switching paradigm that is supported.
For discussion purposes, we decompose the problem of applying GMPLS For discussion purposes, we decompose the problem of applying GMPLS
into the functions of Routing, Signaling, Link Management and Path into the functions of Routing, Signaling, Link Management and Path
Selection. It is possible to use some functions of GMPLS alone or in Selection. It is possible to use some functions of GMPLS alone or in
partial combinations. In most cases using all functions of GMPLS partial combinations. In most cases using all functions of GMPLS
leads to less operational overhead than partial combinations. leads to less operational overhead than partial combinations.
4. GMPLS Routing and Addressing Model 4. GMPLS Routing and Addressing Model
The GMPLS Routing and Addressing Model is not modified by this The GMPLS Routing and Addressing Model is not modified by this
document. GMPLS control for Eth-LSPs uses the Routing and Addressing document. GMPLS control for Eth-LSPs uses the Routing and Addressing
Model described in [RFC3945]. Most notably this includes the use of Model described in [RFC3945]. Most notably this includes the use of
IP addresses to identify interfaces and LSP end-points. It also IP addresses to identify interfaces and LSP end-points. It also
includes support for both numbered and unnumbered interfaces. includes support for both numbered and unnumbered interfaces.
In the case where another address family or type of identifier is In the case where another address family or type of identifier is
required to support an Ethernet service, extensions may be defined to required to support an Ethernet service, extensions may be defined to
provide mapping to an IP address. Support of Ethernet MUST strictly provide mapping to an IP address. Support of Eth-LSPs is expected to
comply to the GMPLS protocol suite addressing as specific in RFC3471, strictly comply to the GMPLS protocol suite addressing as specific in
RFC3473 and related. 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
the opaque TLV extensions for the purpose of distributing GMPLS opaque TLV extensions for the purpose of distributing GMPLS related
related TE (router and link) information. As is always the case with TE (router and link) information. As is always the case with GMPLS,
GMPLS, TE information is populated with TE resources coordinated with TE information is populated based on resource information obtained
LMP or from configured information. The bandwidth resources of the from LMP or from configured information. The bandwidth resources of
links are tracked as Eth-LSPs are set up. Interfaces supporting the the links are tracked as Eth-LSPs are set up. Interfaces supporting
switching of Eth-LSPs are identified using the appropriate Interface the switching of Eth-LSPs are identified using the appropriate
Switching Capabilities Descriptor. As mentioned in Section 3, the Interface Switching Capabilities Descriptor. As mentioned in Section
definition of one or more new Interface Switching Capabilities to 3, the definition of one or more new Interface Switching Capabilities
support Eth-LSPs is expected. The L2SC Interface Switching to support Eth-LSPs is expected. Again, the L2SC Interface Switching
Capabilities MUST 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
between the 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 IP routed network supported by
terminated IP adjacency. In other words, IP traffic and a simple an IGP that views each switch as a terminated IP adjacency. In other
routing table are available for the control plane but there is no words, IP traffic and a simple routing table are available for the
requirement for needing a high performance IP data plane. control plane but there is no requirement for needing a high
performance IP data plane, or for forwarding user traffic over this
IP network.
This IP connectivity can be provided as a separate independent This IP connectivity can be provided as a separate independent
network (out of band) or integrated with the Ethernet switches (in- network (out of band) or integrated with the Ethernet switches (in-
band). band).
5. GMPLS Signaling 5. GMPLS Signaling
GMPLS signaling, see [RFC3471][RFC3473], is well suited to the GMPLS signaling, 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 provides the
ability to dynamically establish a path from an ingress node to an ability to dynamically establish a path from an ingress node to an
egress node. The signaled path may be completely static and not egress node. The signaled path may be completely static and not
change for the duration of its lifetime. However, signaling also has change for the duration of its lifetime. However, signaling also has
the capability to dynamically adjust the path in a coordinated the capability to dynamically adjust the path in a coordinated
fashion after the path has been established. The range of signaling fashion after the path has been established. The range of signaling
options from static to dynamic are under operator control. options from static to dynamic are under operator control.
Standardized signaling also improves multi-vendor interoperability Standardized signaling also improves multi-vendor interoperability.
over simple management.
GMPLS signaling supports the establishment and control of bi- GMPLS signaling supports the establishment and control of
directional and unidirectional data paths. Ethernet is bi-directional bidirectional and unidirectional data paths. Ethernet is
by nature and the CFM has been built to leverage this. Prior to CFM bidirectional by nature and CFM has been built to leverage this.
the emulation of a physical wire and the learning requirements also Prior to CFM, the emulation of a physical wire and the learning
mandated bi-directional connections. Given this, Eth-LSPs MUST be bi- requirements also mandated bidirectional connections. Given this,
directional congruent. Eth-LSPs may be either P2P or P2MP (see Eth-LSPs need to be bidirectional congruent. Eth-LSPs may be either
[RFC4875]). GMPLS signaling also allows for full and partial LSP P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full
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 bi-directional LSP. [GMPLS-ASYM], an Experimental direction of a bidirectional LSP. [GMPLS-ASYM], an Experimental
document, provides procedures if asymmetric bandwidth bi-directional 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
skipping to change at page 17, line 4 skipping to change at page 16, line 28
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'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 best tool set for the user needs. The full functionality of Ethernet
needs. The full functionality of Ethernet CFM should be supported CFM should be supported when using a GMPLS control plane.
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 expected that LMP would be used for control and OAM schemes. It is expected that LMP would be used for control
plane functions of link property correlation but that Ethernet plane functions of link property correlation but that Ethernet
mechanisms for OAM such as CFM, link trace etc would be used for data mechanisms for OAM such as CFM, link trace, etc. would be used for
plane fault management and fault trace. data plane fault management and fault trace.
+-------------+ +-------------+ +-------------+ +-------------+
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
| | | | | | | |GMPLS | | | | | | | |GMPLS
| | LMP |-|<------>|-| LMP | |Link Property | | LMP |-|<------>|-| LMP | |Link Property
| | | | | | | |Correlation | | | | | | | |Correlation
| | (opt) | |GMPLS | | (opt) | | | | (opt) | |GMPLS | | (opt) | |
| | | | | | | | Bundling | | | | | | | | Bundling
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
| +---------+ | | +---------+ | | +---------+ | | +---------+ |
skipping to change at page 18, line 38 skipping to change at page 18, line 19
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 trusted. In general, these
requirements are no different from the security requirements for requirements are no different from the security requirements for
operating any GMPLS network. Access to the trusted network SHALL only operating any GMPLS network. Access to the trusted network will only
occur through the protocols defined for the UNI or NNI or through occur through the protocols defined for the UNI or NNI or through
protected management interfaces. 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.
skipping to change at page 19, line 19 skipping to change at page 18, line 47
issues that any protocol extensions introduce. 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
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L. (editor), "Generalized MPLS Signaling [RFC3471] Berger, L. (editor), "Generalized MPLS Signaling
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
skipping to change at page 20, line 33 skipping to change at page 20, line 9
[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", RCF 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 ",
skipping to change at line 892 skipping to change at line 888
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: Tue Sep 1 11:27:49 EDT 2009 Generated on: Wed Oct 14 14:54:18 EDT 2009
 End of changes. 46 change blocks. 
111 lines changed or deleted 108 lines changed or added

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