draft-ietf-ccamp-gmpls-ethernet-arch-01.txt   draft-ietf-ccamp-gmpls-ethernet-arch-02.txt 
Internet Draft Don Fedyk, Nortel Internet Draft Don Fedyk, Nortel
Category: Informational Lou Berger, LabN Category: Informational Lou Berger, LabN
Expiration Date: August 25, 2008 Loa Andersson, Acreo AB Expiration Date: January 13, 2009 Loa Andersson, Acreo AB
February 25, 2008 July 13, 2008
GMPLS Ethernet Label Switching Architecture and Framework GMPLS Ethernet Label Switching Architecture and Framework
draft-ietf-ccamp-gmpls-ethernet-arch-01.txt draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 25, 2008. This Internet-Draft will expire on January 13, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 13, line 31 skipping to change at page 13, line 31
GMPLS routing as defined in [RFC4202] is IP routing with the opaque GMPLS routing as defined in [RFC4202] is IP routing with the opaque
TLV extensions for the purpose of distributing GMPLS related TE 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 with TE resources coordinated with LMP or information is populated with TE resources coordinated with LMP or
from configured information. The bandwidth resources of the links are from configured information. The bandwidth resources of the links are
tracked as Eth-LSPs are set up. Interfaces supporting the switching tracked as Eth-LSPs are set up. Interfaces supporting the switching
of Eth-LSPs are identified using the appropriate Interface Switching of Eth-LSPs are identified using the appropriate Interface Switching
Capabilities. As mentioned in Section 3, the definition of one or Capabilities. As mentioned in Section 3, the definition of one or
more new Interface Switching Capabilities to support Eth-LSPs is more new Interface Switching Capabilities to support Eth-LSPs is
expected. The L2SC Interface Switching Capabilities MUST NOT be used expected. Interface Switching Capability specific TE information may
to represent interfaces capable of supporting Eth-LSPs. Interface be defined as needed to support the requirements of a specific
Switching Capability specific TE information may be defined as needed Ethernet Switching Service Type.
to support the requirements of a specific Ethernet Switching Service
Type.
GMPLS Routing is an optional piece but it is highly valuable in GMPLS Routing is an optional piece but it is highly valuable in
maintaining topology and distributing the TE database for path maintaining topology and distributing the TE database for path
management and dynamic path computation. management and dynamic path computation.
4.2. Control Plane Network 4.2. Control Plane Network
In order for a GMPLS control plane to operate, an IP network of In order for a GMPLS control plane to operate, an IP network of
sufficient capacity to handle the information exchange between the sufficient capacity to handle the information exchange between the
GMPLS routing and signaling protocols is necessary. GMPLS routing and signaling protocols is necessary.
skipping to change at page 14, line 37 skipping to change at page 14, line 35
LSPs may be either P2P or P2MP (see [RFC4875]). GMPLS signaling also LSPs may be either P2P or P2MP (see [RFC4875]). GMPLS signaling also
allows for full and partial LSP protection; see [RFC4872] and allows for full and partial LSP protection; see [RFC4872] and
[RFC4873]. [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. See [GMPLS-ASYM] if asymmetric direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric
bandwidth bidirectional LSPs are required. bandwidth bidirectional LSPs are required.
6. Link Management 6. Link Management
Link discovery has been specified for Ethernet in [IEEE802.1AB]. Link discovery has been specified for Ethernet in [802.1AB]. However
However the 802.1AB capability is an optional feature, is not the 802.1AB capability is an optional feature, is not necessarily
necessarily operating before a link is operational, and it primarily operating before a link is operational, and it primarily supports the
supports the management plane. The benefits of running link discovery management plane. The benefits of running link discovery in large
in large systems are significant. Link discovery may reduce systems are significant. Link discovery may reduce configuration and
configuration and reduce the possibility of undetected errors in reduce the possibility of undetected errors in configuration as well
configuration as well as exposing misconnections. as exposing misconnections.
In the GMPLS context, LMP [RFC4204] has been defined to support link In the GMPLS context, LMP [RFC4204] has been defined to support link
management and discovery features. LMP also supports the automated management and discovery features. LMP also supports the automated
creation of unnumbered interfaces. If LMP is not used there is an creation of unnumbered interfaces. If LMP is not used there is an
additional configuration requirement to add GMPLS link identifiers. additional configuration requirement to add GMPLS link identifiers.
For large-scale implementations LMP would be beneficial. LMP also has For large-scale implementations LMP would be beneficial. LMP also has
fault management capabilities that overlap with [IEEE802.1ag] and fault management capabilities that overlap with [802.1ag] and
[Y.1731]. It is RECOMMENDED that LMP not be used for Fault [Y.1731]. It is RECOMMENDED that LMP not be used for Fault
management and instead the native Ethernet methods be used. management and instead the native Ethernet methods be used.
LMP and 802.1AB are relatively independent. The LMP capability should LMP and 802.1AB are relatively independent. The LMP capability should
be sufficient to remove the need for 802.1AB but 802.1 AB can be run be sufficient to remove the need for 802.1AB but 802.1 AB can be run
in parallel or independently if desired. Figure 2 provides possible in parallel or independently if desired. Figure 2 provides possible
ways of using LMP, 802.1AB and 802.1ag in combination. ways of using LMP, 802.1AB and 802.1ag in combination.
Figure 2 illustrates the functional relationship of link management Figure 2 illustrates the functional relationship of link management
and OAM schemes. It is intended that LMP would use functions of and OAM schemes. It is intended that LMP would use functions of
skipping to change at page 16, line 21 skipping to change at page 16, line 21
are required. Path computation can take the form of paths being are required. Path computation can take the form of paths being
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 [PATH- the emerging path computation element and selection work; see
COMP] [RFC4655]
8. Multiple Domains 8. Multiple Domains
This document allows for the support the signaling of Ethernet This document allows for the support the signaling of Ethernet
parameters across multiple domains supporting both contiguous Eth-LSP parameters across multiple domains 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.
More detail will be added to the section in a later revision. More detail will be added to the section in a later revision.
skipping to change at page 17, line 33 skipping to change at page 17, line 33
[G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection [G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection
Switching. Switching.
[G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over [G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over
Transport - Ethernet services framework. Transport - Ethernet services framework.
[RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3495. Switching (GMPLS) Architecture", RFC 3495.
[IEEE802.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". Connectivity Discovery" (2004).
[IEEE802.1ag] "IEEE Draft Standard for Connectivity Fault [802.1ag] "IEEE Standard for Local and Metropolitan Area
Management", work in progress. Networks - Virtual Bridged Local Area Networks
- Amendment 5:Connectivity Fault Management",
(2007).
[802.1ah] "IEEE standard for Provider Backbone Bridges", work in [802.1ah] "IEEE Standard for Local and Metropolitan Area
progress. Networks - Virtual Bridged Local Area Networks
- 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
skipping to change at page 18, line 14 skipping to change at page 18, line 18
[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
[PATH-COMP] Farrel, A. et.al., "Path Computation Element (PCE) [RFC4655] Farrel, A. et.al., "Path Computation Element (PCE)
Architecture", work in progress. Architecture", RCF 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 page 19, line 22 skipping to change at page 19, line 22
Email: dwfedyk@nortel.com Email: dwfedyk@nortel.com
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
Loa Andersson Loa Andersson
Acreo, AB Acreo, AB
Phone:+46 8 632 77 14 Phone:+46 8 632 77 14
Email: loa@pi.se Email: loa@pi.nu
14. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at line 865 skipping to change at line 867
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Generated on: Sun Feb 24 19:22:09 EST 2008 Generated on: Mon Jul 14 01:11:38 EDT 2008
 End of changes. 16 change blocks. 
28 lines changed or deleted 30 lines changed or added

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