draft-ietf-ccamp-gmpls-ethernet-arch-08.txt   draft-ietf-ccamp-gmpls-ethernet-arch-09.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: June 18, 2010 Loa Andersson, Ericsson AB Expiration Date: July 14, 2010 Loa Andersson, Ericsson AB
December 18, 2009 January 14, 2010
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-08.txt draft-ietf-ccamp-gmpls-ethernet-arch-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 18, 2010. This Internet-Draft will expire on July 14, 2010.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents 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
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 4, line 30 skipping to change at page 4, line 30
forwarding, Ethernet management plane extensions and the Ethernet forwarding, Ethernet management plane extensions and the Ethernet
Spanning Tree Control Plane, but not on an explicitly routed, Spanning Tree Control Plane, but not on an explicitly routed,
constraint-based control plane. constraint-based control plane.
In the forwarding plane context, extensions have been, or are being, In the forwarding plane context, extensions have been, or are being,
defined to support different transport Ethernet forwarding models, defined to support different transport Ethernet forwarding models,
protection modes, and service interfaces. Examples of such protection modes, and service interfaces. Examples of such
extensions include [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These extensions include [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. 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 Spanning tree. For example, in the [802.1Qah]
[802.1Qah] case, greater flexibility in forwarding is achieved case, greater flexibility in forwarding is achieved through the
through the addition of a "provider" address space. [802.1Qay] addition of a "provider" address space. [802.1Qay] supports the use
supports the use of provisioning systems and network control of provisioning systems and network control protocols that explicitly
protocols that explicitly select traffic engineered paths. 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
skipping to change at page 5, line 23 skipping to change at page 5, line 23
frameworks for defining network-oriented characteristics of Ethernet frameworks for defining network-oriented characteristics of Ethernet
services in transport networks. These framework documents discuss services in transport networks. These framework documents discuss
general Ethernet connection characteristics, Ethernet User-Network general Ethernet connection characteristics, Ethernet User-Network
Interfaces (UNIs) and Ethernet Network-Network Interfaces (NNIs). Interfaces (UNIs) and Ethernet Network-Network Interfaces (NNIs).
[G.8011.1] defines the Ethernet Private Line (EPL) service and [G.8011.1] defines the Ethernet Private Line (EPL) service and
[G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service. [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service.
[MEF.6] covers both service types. These activities are consistent [MEF.6] covers both service types. These activities are consistent
with the types of Ethernet switching defined in [802.1ah]. with the types of Ethernet switching defined in [802.1ah].
The Ethernet forwarding and management plane extensions allow for the The Ethernet forwarding and management plane extensions allow for the
disabling of standard Ethernet spanning tree but do not define an disabling of standard Spanning tree but do not define an explicitly
explicitly routed, constraint-based control plane. For example routed, constraint-based control plane. For example [802.1Qay] is an
[802.1Qay] is an amendment to IEEE 802.1Q that explicitly allows for amendment to IEEE 802.1Q that explicitly allows for traffic
traffic engineering of Ethernet forwarding paths. 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
skipping to change at page 7, line 46 skipping to change at page 7, line 46
Eth-LSPs 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 Backbone Service Identifier carried in the I-TAG
I-TAG A Backbone Service Instance TAG defined in the
IEEE 802.1ah Standard [802.1ah]
LMP Link Management Protocol LMP Link Management Protocol
MAC Media Access Control MAC Media Access Control
MP2MP Multipoint to multipoint MP2MP Multipoint to multipoint
NMS Network Management System NMS Network Management System
OAM Operations, Administration and Maintenance OAM Operations, Administration and Maintenance
PBB Provider Backbone Bridges [802.1ah] PBB Provider Backbone Bridges [802.1ah]
PBB-TE Provider Backbone Bridges Traffic Engineering PBB-TE Provider Backbone Bridges Traffic Engineering
[802.1Qay] [802.1Qay]
P2P Point to Point P2P Point to Point
P2MP Point to Multipoint P2MP Point to Multipoint
QoS Quality of Service QoS Quality of Service
SMAC Source MAC Address SMAC Source MAC Address
S-TAG A service TAG defined in the 802.1 Standard S-TAG A Service TAG defined in the IEEE 802.1 Standard
[802.1Q] [802.1Q]
TE Traffic Engineering TE Traffic Engineering
TAG An Ethernet short form for a TAG Header TAG An Ethernet short form for a TAG Header
TAG Header An extension to an Ethernet frame carrying TAG Header An extension to an Ethernet frame carrying
priority and other information. priority and other information.
TSpec Traffic specification TSpec Traffic specification
VID VLAN Identifier VID VLAN Identifier
VLAN Virtual LAN VLAN Virtual LAN
2. Background 2. Background
skipping to change at page 13, line 26 skipping to change at page 13, line 28
interfaces only along the path. In the case where the "labels" must interfaces only along the path. In the case where the "labels" must
be forwarded unchanged, there are a few constraints on the label be forwarded unchanged, there are a few constraints on the label
allocation that are similar to some other technologies such as lambda allocation that are similar to some other technologies such as lambda
labels. labels.
The characteristics of the "transport" Ethernet data plane are not The characteristics of the "transport" Ethernet data plane are not
modified in order to apply GMPLS control. For example, consider the modified in order to apply GMPLS control. For example, consider the
IEEE 802.1Q [802.1Q] data plane: The VID is used as a "filter" IEEE 802.1Q [802.1Q] data plane: The VID is used as a "filter"
pointing to a particular forwarding table, and if the DMAC is found pointing to a particular forwarding table, and if the DMAC is found
in that forwarding table the forwarding decision is taken based on in that forwarding table the forwarding decision is taken based on
the DMAC. When forwarding using an Ethernet spanning tree, if the the DMAC. When forwarding using an Spanning tree, if the DMAC is not
DMAC is not found the frame is broadcast over all outgoing interfaces found the frame is broadcast over all outgoing interfaces for which
for which that VID is defined. This valid MAC checking and broadcast that VID is defined. This valid MAC checking and broadcast supports
supports Ethernet learning. A special case is when a VID is defined Ethernet learning. A special case is when a VID is defined for only
for only two ports on one bridge, effectively resulting in a p2p two ports on one bridge, effectively resulting in a p2p forwarding
forwarding constraint. In this case all frames tagged with that VID constraint. In this case all frames tagged with that VID received
received over one of these ports are forward over the other port over one of these ports are forward over the other port without
without address learning. 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
skipping to change at page 16, line 14 skipping to change at page 16, line 16
P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full
and partial LSP protection; see [RFC4872] and [RFC4873]. and partial LSP protection; see [RFC4872] and [RFC4873].
Note that standard GMPLS does not support different bandwidth in each Note that standard GMPLS does not support different bandwidth in each
direction of a bidirectional LSP. [RFC5467], an Experimental direction of a bidirectional LSP. [RFC5467], an Experimental
document, provides procedures if asymmetric bandwidth bidirectional document, provides procedures if asymmetric bandwidth bidirectional
LSPs are required. LSPs are required.
6. Link Management 6. Link Management
Link discovery has been specified for Ethernet in [802.1AB]. The Link discovery has been specified for links interconnecting IEEE
benefits of running link discovery in large systems are significant. 802.1 bridges in [802.1AB]. The benefits of running link discovery
Link discovery may reduce configuration and reduce the possibility of in large systems are significant. Link discovery may reduce
undetected errors in configuration as well as exposing configuration and reduce the possibility of undetected errors in
misconnections. However the 802.1AB capability is an optional configuration as well as exposing misconnections. However the 802.1AB
feature, it is not necessarily operating before a link is capability is an optional feature, it is not necessarily operating
operational, and it primarily supports the management plane. before a link is 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-T'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
skipping to change at page 19, line 46 skipping to change at page 19, line 46
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",
IEEE Std 802.1Qah-2008, 14 August 2008.
[802.1Qay] "IEEE standard for Provider Backbone Bridge Traffic [802.1Qay] "IEEE Standard for Local and Metropolitan Area
Engineering", work in progress. Networks - Virtual Bridged Local Area Networks
Provider Backbone Bridge Traffic Engineering
- Amendment 10: ", IEEE Std 802.1Qay-2009,
August 5th, 2009.
[802.1Q] "IEEE standard for Virtual Bridged Local Area Networks [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.
skipping to change at page 20, line 47 skipping to change at page 21, line 7
[ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", [ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters",
draft-ietf-ccamp-ethernet-traffic-parameters-09.txt, draft-ietf-ccamp-ethernet-traffic-parameters-09.txt,
work in progress. work in progress.
[SECURITY] Luyuan Fang, Ed., "Security Framework for MPLSand GMPLS [SECURITY] Luyuan Fang, Ed., "Security Framework for MPLSand GMPLS
Networks", draft-ietf-mpls-mpls-and-gmpls-security- Networks", draft-ietf-mpls-mpls-and-gmpls-security-
framework-07.txt, work in progress. framework-07.txt, work in progress.
[MACSEC] "IEEE Standard for Local and metropolitan area networks [MACSEC] "IEEE Standard for Local and metropolitan area networks
Media Access Control (MAC) Security Media Access Control (MAC) Security
802.1AE-2006", August 18, 2006. IEEE 802.1AE-2006", August 18, 2006.
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, and Nabil Bitar. Himanshu Shah, Greg Sunderwood, Alan McGuire, and Nabil Bitar.
skipping to change at line 896 skipping to change at line 903
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: Fri Dec 18 15:20:53 EST 2009 Generated on: Thu Jan 14 15:15:38 EST 2010
 End of changes. 18 change blocks. 
38 lines changed or deleted 45 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/