--- 1/draft-ietf-ccamp-gmpls-ethernet-arch-01.txt 2008-07-14 15:12:16.000000000 +0200 +++ 2/draft-ietf-ccamp-gmpls-ethernet-arch-02.txt 2008-07-14 15:12:16.000000000 +0200 @@ -1,19 +1,19 @@ Internet Draft Don Fedyk, Nortel 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 - draft-ietf-ccamp-gmpls-ethernet-arch-01.txt + draft-ietf-ccamp-gmpls-ethernet-arch-02.txt Status of this Memo 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 Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The IETF Trust (2008). Abstract There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into @@ -560,25 +560,23 @@ GMPLS routing as defined in [RFC4202] is IP routing with the opaque TLV extensions for the purpose of distributing GMPLS related TE (router and link) information. As is always the case with GMPLS, TE information is populated with TE resources coordinated with LMP or from configured information. The bandwidth resources of the links are tracked as Eth-LSPs are set up. Interfaces supporting the switching of Eth-LSPs are identified using the appropriate Interface Switching Capabilities. As mentioned in Section 3, the definition of one or more new Interface Switching Capabilities to support Eth-LSPs is - expected. The L2SC Interface Switching Capabilities MUST NOT be used - to represent interfaces capable of supporting Eth-LSPs. Interface - Switching Capability specific TE information may be defined as needed - to support the requirements of a specific Ethernet Switching Service - Type. + expected. Interface Switching Capability specific TE information may + be defined as needed to support the requirements of a specific + Ethernet Switching Service Type. GMPLS Routing is an optional piece but it is highly valuable in maintaining topology and distributing the TE database for path management and dynamic path computation. 4.2. Control Plane Network In order for a GMPLS control plane to operate, an IP network of sufficient capacity to handle the information exchange between the GMPLS routing and signaling protocols is necessary. @@ -613,34 +611,34 @@ LSPs may be either P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full and partial LSP protection; see [RFC4872] and [RFC4873]. Note that standard GMPLS does not support different bandwidth in each direction of a bidirectional LSP. See [GMPLS-ASYM] if asymmetric bandwidth bidirectional LSPs are required. 6. Link Management - Link discovery has been specified for Ethernet in [IEEE802.1AB]. - However the 802.1AB capability is an optional feature, is not - necessarily operating before a link is operational, and it primarily - supports the management plane. The benefits of running link discovery - in large systems are significant. Link discovery may reduce - configuration and reduce the possibility of undetected errors in - configuration as well as exposing misconnections. + Link discovery has been specified for Ethernet in [802.1AB]. However + the 802.1AB capability is an optional feature, is not necessarily + operating before a link is operational, and it primarily supports the + management plane. The benefits of running link discovery in large + systems are significant. Link discovery may reduce configuration and + reduce the possibility of undetected errors in configuration as well + as exposing misconnections. In the GMPLS context, LMP [RFC4204] has been defined to support link management and discovery features. LMP also supports the automated creation of unnumbered interfaces. If LMP is not used there is an additional configuration requirement to add GMPLS link identifiers. 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 management and instead the native Ethernet methods be used. 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 in parallel or independently if desired. Figure 2 provides possible ways of using LMP, 802.1AB and 802.1ag in combination. Figure 2 illustrates the functional relationship of link management and OAM schemes. It is intended that LMP would use functions of @@ -683,22 +681,22 @@ are required. Path computation can take the form of paths being computed in a fully distributed fashion, on a management station with local computation for rerouting, or on more sophisticated path computation servers. Eth-LSPs may be supported using any path selection or computation mechanism. As is the case with any GMPLS path selection function, and common to all path selection mechanisms, the path selection process should take into consideration Switching Capabilities and Encoding advertised for a particular interface. Eth-LSPs may also make use of - the emerging path computation element and selection work; see [PATH- - COMP] + the emerging path computation element and selection work; see + [RFC4655] 8. Multiple Domains This document allows for the support the signaling of Ethernet parameters across multiple domains supporting both contiguous Eth-LSP and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS hierarchy for the support of Peer to Peer models, UNIs and NNIs. More detail will be added to the section in a later revision. @@ -734,35 +732,39 @@ [G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection Switching. [G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over Transport - Ethernet services framework. [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label 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 - Connectivity Discovery". + Connectivity Discovery" (2004). - [IEEE802.1ag] "IEEE Draft Standard for Connectivity Fault - Management", work in progress. + [802.1ag] "IEEE Standard for Local and Metropolitan Area + Networks - Virtual Bridged Local Area Networks + - Amendment 5:Connectivity Fault Management", + (2007). - [802.1ah] "IEEE standard for Provider Backbone Bridges", work in - progress. + [802.1ah] "IEEE Standard for Local and Metropolitan Area + Networks - Virtual Bridged Local Area Networks + - Amendment 6: Provider Backbone Bridges", (2008) [802.1Qay] "IEEE standard for Provider Backbone Bridge Traffic Engineering", work in progress. [802.1Q] "IEEE standard for Virtual Bridged Local Area Networks 802.1Q-2005", May 19, 2006 + [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204, October 2005 [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services Definitions - Phase I". [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services Attributes Phase 1". [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to @@ -759,22 +761,22 @@ [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204, October 2005 [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services Definitions - Phase I". [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services Attributes Phase 1". [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to - [PATH-COMP] Farrel, A. et.al., "Path Computation Element (PCE) - Architecture", work in progress. + [RFC4655] Farrel, A. et.al., "Path Computation Element (PCE) + Architecture", RCF 4655, August 2006. [RFC4872] Lang et.al., "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery ", RFC 4872, May 2007. [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May 2007. [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions and Mechanisms for Ethernet based Networks ", @@ -808,21 +810,21 @@ Email: dwfedyk@nortel.com Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net Loa Andersson Acreo, AB Phone:+46 8 632 77 14 - Email: loa@pi.se + Email: loa@pi.nu 14. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an @@ -855,11 +857,11 @@ any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). -Generated on: Sun Feb 24 19:22:09 EST 2008 +Generated on: Mon Jul 14 01:11:38 EDT 2008