--- 1/draft-ietf-ccamp-gmpls-ethernet-arch-02.txt 2008-10-27 14:12:19.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-ethernet-arch-03.txt 2008-10-27 14:12:19.000000000 +0100 @@ -1,19 +1,19 @@ Internet Draft Don Fedyk, Nortel Category: Informational Lou Berger, LabN -Expiration Date: January 13, 2009 Loa Andersson, Acreo AB +Expiration Date: April 27, 2009 Loa Andersson, Acreo AB - July 13, 2008 + October 27, 2008 GMPLS Ethernet Label Switching Architecture and Framework - draft-ietf-ccamp-gmpls-ethernet-arch-02.txt + draft-ietf-ccamp-gmpls-ethernet-arch-03.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 January 13, 2009. + This Internet-Draft will expire on April 27, 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 @@ -480,24 +480,24 @@ service types discussed in Section 2.1. In general, the header fields used in the forwarding/switching function, e.g. VID and DMAC, can be characterized as a data plane label. In some 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 interfaces only along the path. In the case where the "labels" must be forwarded unchanged, there are a few constraints on the label allocation that are similar to some other technologies such as lambda labels. The GMPLS architecture, per [RFC3945], allowed for control of - Ethernet bridges using the L2SC switching type. Although, it is - worth noting that the control of Ethernet switching was not - explicitly defined in [RFC3471], [RFC4202] or any other subsequent - GMPLS reference document. + Ethernet bridges and other layer 2 technologies using the L2SC + switching type. Although, it is worth noting that the control of + Ethernet switching was not explicitly defined in [RFC3471], [RFC4202] + or any other subsequent GMPLS reference document. The characteristics of the "transport" Ethernet data plane are not 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" pointing to a particular forwarding table, and if the DMAC is found in that forwarding table the forwarding decision is taken based on the DMAC. When forwarding using an Ethernet spanning tree, if the DMAC is not found the frame is broadcast over all outgoing interfaces for which that VID is defined. This valid MAC checking and broadcast supports Ethernet learning. The amendment to IEEE802.1Q that is @@ -520,27 +520,25 @@ necessary to provide a mechanism to identify the required Ethernet service type in signaling and a way to advertise the capabilities of Ethernet switches in the routing protocols. These mechanisms must make it possible to distinguish between requests for different paradigms including new, future, and existing paradigms. The Switching Type and Interface Switching Capability Descriptor share a common set of values and are defined in [RFC3945], [RFC3471], and [RFC4202] as indicators of the type of switching that should ([RFC3471]) and can ([RFC4202]) be performed on a particular link for - an LSP. The L2SC switching type is available for use by - implementations performing layer 2 switching including ATM and - Ethernet (as mentioned above). To support the continued use of that - switching type by existing implementations as well as to distinguish - between each new Ethernet switching paradigm, a new switching type is - expected to be needed for each new Ethernet switching paradigm that - is supported. + an LSP. The L2SC switching type may already be used by + implementations performing layer 2 switching including Ethernet. To + support the continued use of that switching type and those + implementations, a new switching type MUST be defined for each new + Ethernet switching paradigm that is supported. For discussion purposes, we decompose the problem of applying GMPLS into the functions of Routing, Signaling, Link Management and Path Selection. It is possible to use some functions of GMPLS alone or in partial combinations. In most cases using all functions of GMPLS leads to less operational overhead than partial combinations. 4. GMPLS Routing and Addressing Model The GMPLS Routing and Addressing Model is not modified by this @@ -560,23 +558,25 @@ 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. Interface Switching Capability specific TE information may - be defined as needed to support the requirements of a specific - Ethernet Switching Service Type. + 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. 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. @@ -857,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: Mon Jul 14 01:11:38 EDT 2008 +Generated on: Mon Oct 27 08:35:55 EDT 2008