draft-ietf-ccamp-gmpls-ethernet-arch-02.txt   draft-ietf-ccamp-gmpls-ethernet-arch-03.txt 
Internet Draft Don Fedyk, Nortel Internet Draft Don Fedyk, Nortel
Category: Informational Lou Berger, LabN 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 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 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 January 13, 2009. This Internet-Draft will expire on April 27, 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 11, line 44 skipping to change at page 11, line 44
service types discussed in Section 2.1. In general, the header fields 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 used in the forwarding/switching function, e.g. VID and DMAC, can be
characterized as a data plane label. In some circumstances these characterized as a data plane label. In some circumstances these
fields will be constant along the path of the Eth-LSP, and in others 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 they may vary hop-by-hop or at certain interfaces only along the
path. In the case where the "labels" must be forwarded unchanged, path. In the case where the "labels" must be forwarded unchanged,
there are a few constraints on the label allocation that are similar there are a few constraints on the label allocation that are similar
to some other technologies such as lambda labels. to some other technologies such as lambda labels.
The GMPLS architecture, per [RFC3945], allowed for control of The GMPLS architecture, per [RFC3945], allowed for control of
Ethernet bridges using the L2SC switching type. Although, it is Ethernet bridges and other layer 2 technologies using the L2SC
worth noting that the control of Ethernet switching was not switching type. Although, it is worth noting that the control of
explicitly defined in [RFC3471], [RFC4202] or any other subsequent Ethernet switching was not explicitly defined in [RFC3471], [RFC4202]
GMPLS reference document. or any other subsequent GMPLS reference document.
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. The amendment to IEEE802.1Q that is supports Ethernet learning. The amendment to IEEE802.1Q that is
skipping to change at page 12, line 36 skipping to change at page 12, line 36
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. The L2SC switching type is available for use by an LSP. The L2SC switching type may already be used by
implementations performing layer 2 switching including ATM and implementations performing layer 2 switching including Ethernet. To
Ethernet (as mentioned above). To support the continued use of that support the continued use of that switching type and those
switching type by existing implementations as well as to distinguish implementations, a new switching type MUST be defined for each new
between each new Ethernet switching paradigm, a new switching type is Ethernet switching paradigm that is supported.
expected to be needed for each new 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
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. Interface Switching Capability specific TE information may expected. The L2SC Interface Switching Capabilities MUST NOT be used
be defined as needed to support the requirements of a specific to represent interfaces capable of supporting Eth-LSPs. Interface
Ethernet Switching Service Type. 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 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 line 867 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: Mon Jul 14 01:11:38 EDT 2008 Generated on: Mon Oct 27 08:35:55 EDT 2008
 End of changes. 8 change blocks. 
18 lines changed or deleted 18 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/