--- 1/draft-ietf-ccamp-gmpls-ethernet-arch-00.txt 2008-02-25 15:12:14.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-ethernet-arch-01.txt 2008-02-25 15:12:14.000000000 +0100 @@ -1,19 +1,19 @@ Internet Draft Don Fedyk, Nortel Category: Informational Lou Berger, LabN -Expiration Date: August 6, 2008 Loa Andersson, Acreo AB +Expiration Date: August 25, 2008 Loa Andersson, Acreo AB - February 6, 2008 + February 25, 2008 GMPLS Ethernet Label Switching Architecture and Framework - draft-ietf-ccamp-gmpls-ethernet-arch-00.txt + draft-ietf-ccamp-gmpls-ethernet-arch-01.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,53 +24,54 @@ 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 6, 2008. + This Internet-Draft will expire on August 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract There has been significant recent work in increasing the capabilities - of Ethernet switches. As a consequence, the role of Ethernet is - rapidly expanding into "transport networks" that previously were the - domain of other technologies such as SONET/SDH TDM and ATM. This - document defines an architecture and framework for a GMPLS based - control plane for Ethernet in this "transport network" capacity. - GMPLS has already been specified for similar technologies. Some - additional extensions to the GMPLS control plane are needed and this - document provides a framework for these extensions. + of Ethernet switches and Ethernet forwarding models. As a + consequence, the role of Ethernet is rapidly expanding into + "transport networks" that previously were the domain of other + technologies such as SONET/SDH TDM and ATM. This document defines an + architecture and framework for a GMPLS based control plane for + Ethernet in this "transport network" capacity. GMPLS has already been + specified for similar technologies. Some additional extensions to the + GMPLS control plane are needed and this document provides a framework + for these extensions. Contents 1 Introduction .............................................. 3 2 Background ................................................ 5 2.1 Ethernet Switching ........................................ 5 2.2 Operations, Administration, and Maintenance (OAM) ......... 7 2.3 Terminology ............................................... 8 2.3.1 Concepts .................................................. 8 - 2.3.2 Acronyms .................................................. 9 + 2.3.2 Abbreviations and Acronyms ................................ 9 2.4 Ethernet and MPLS similarities and differences ............ 10 3 Framework ................................................. 10 4 GMPLS Routing and Addressing Model ........................ 13 4.1 GMPLS Routing ............................................. 13 4.2 Control Plane Network ..................................... 13 - 5 P2P Signaling ............................................ 14 + 5 GMPLS Signaling .......................................... 14 6 Link Management .......................................... 14 7 Path Computation and Selection ............................ 16 8 Multiple Domains .......................................... 16 9 Security Considerations ................................... 16 10 IANA Considerations ....................................... 17 11 References ................................................ 17 11.1 Normative References ...................................... 17 11.2 Informative References .................................... 17 12 Acknowledgments ........................................... 18 13 Author's Addresses ........................................ 19 @@ -99,111 +100,125 @@ Multiple organizations have been active in extending Ethernet technology. This activity has taken place in the IEEE 802.1 Working Group, the ITU and the MEF. These groups have been focusing on Ethernet forwarding, Ethernet management plane extensions and the Ethernet Spanning Tree Control Plane, but not an explicitly routed, constraint based control plane. In the forwarding plane context, extensions have been, or are being, defined to support different Ethernet forwarding models, protection modes and service interfaces. Examples of such extensions include - [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. The provider extensions - allow for greater flexibility in the forwarding plane. In the - 802.1Qay case the extensions allow for a departure from forwarding - based on Ethernet spanning tree. The greater flexibility in + [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These extensions allow + for greater flexibility in the forwarding plane and, in some cases, + the extensions allow for a departure from forwarding based on + Ethernet spanning tree. In the 802.1Qay case, greater flexibility in forwarding is achieved through the addition of a "provider" address space. - This document is a framework for GMPLS Ethernet Label switching + This document provides a framework for GMPLS Ethernet Label switching (GELS). It will be followed by technology specific documents. GELS - will require more than one switching type, and the GMPLS procedures - that will need to be changed is dependent on switching, and thus will - be covered in the technology specific documents. + will likely require more than one switching type, and the GMPLS + procedures that will need to be changed is dependent on switching, + and thus will be covered in the technology specific documents. In the new provider bridge model developed in the IEEE802.1ad-project and amended to the IEEE802.1Q standard [802.1Q], an extra VLAN identifier (VID) is added. This VLAN is referred to as the Service VID, (S-VID and is carried in a Service TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah] a backbone VID (B-VID) and B-MAC header with a Service Instance (I-TAG) encapsulates a customer Ethernet frame or a service Ethernet frame. An example of Ethernet protection extensions can be found in [G.8031]. In the IEEE802.1Q standard the terms Provider Backbone Bridges (PBB) and Provider Backbone Bridged Network (PBBN) is used in the context of these extensions. Ethernet operations, administration, and maintenance (OAM) is another important area that is being extended to enable provider Ethernet services. Related extensions can be found in [802.1ag] and [Y.1731]. + An Ethernet based service model is also being defined within the + context of the Metro Ethernet Forum (MEF) and International + Telecommunication Union (ITU). [MEF.6] and [G.8011] provide parallel + frameworks for defining network-oriented characteristics of Ethernet + services in transport networks. The framework discusses general + Ethernet connection characteristics, Ethernet User-Network Interfaces + (UNIs) and Ethernet Network-Network Interfaces (NNIs). Within this + framework, [G.8011.1] defines the Ethernet Private Line (EPL) service + and [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) + service. [MEF.6] covers both service types. These activities are + consistent with the types of Ethernet switching defined in [802.1ah]. + The Ethernet forwarding and management plane extensions explicitly allow for the disabling of standard Ethernet spanning tree but do not define an explicitly routed, constraint based control plane. The IEEE802.1, in [802.1Qay], works on an new amendment that explicitly allows for traffic engineering of Ethernet forwarding paths. The IETF chartered the GMPLS work to specify a common control plane for physical path and core tunneling technologies for the Internet and telecommunication service providers. The GMPLS architecture is specified in RFC3945 [RFC3945]. The protocols specified for GMPLS have been used to control "Transport Networks", e.g. Optical and TDM networks. This document provides a framework for use of GMPLS to control "transport" Ethernet. The GMPLS architecture already handles a number - of transport technologies but Ethernet adds a few new constraints - that must be documented. Some additional extensions to the GMPLS - control plane are needed and this document provides a framework for - these extensions. All extensions to support Eth-LSPs are also - expected to build on the GMPLS Architecture and related + of transport technologies but "transport" Ethernet adds a few new + constraints that must be documented. Some additional extensions to + the GMPLS control plane are needed and this document provides a + framework for these extensions. All extensions to support Eth-LSPs + are also expected to build on the GMPLS Architecture and related specifications. This document introduces and explains the concept of an Ethernet Label Switched Path (Eth-LSP). The data plane aspects of Eth-LSPs are outside the scope of this document and IETF activities. The intent of this document is to reuse and align with as much of the GMPLS protocols as possible. For example reusing the IP control - plane addressing allows the existing signaling, routing, LMP and path - computation to be used as specified. Additions are made only to - accommodate features of Ethernet that are not already supported by - GMPLS. The GMPLS protocols support a set of tools for hierarchical - LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms - support a variety of networks from peer to peer to UNIs and NNIs. + plane addressing allows existing signaling, routing, LMP and path + computation to be used as specified. The GMPLS protocols support a + set of tools for hierarchical LSPs as well as contiguous LSPs. GMPLS + specific protocol mechanisms support a variety of networks from peer + to peer to UNIs and NNIs. Additions to existing GMPLS capabilities + will only be made to accommodate features unique to "transport" + Ethernet. 2. Background This section provides background to the types of switching and services that are supported within the defined framework. The former is particularly important as it identifies the switching functions that GMPLS will need to represent and control. The intent is for this document to allow for all standard forms of Ethernet switching and services. The material presented in this section is based on the on-going work taking place in the IEEE 802.1 Working Group, the ITU and the MEF. This section references and, to some degree, summarizes that work. This section is not a replacement for, or an authoritative description of that work. 2.1. Ethernet Switching In Ethernet switching terminology, the bridge relay is responsible for forwarding and replicating the frames. Bridge relays forward - frames based on the header fields: Virtual Local Area Network (VLAN) - Identifiers (VID) and Destination Media Access Control (DMAC) - address. PBB [802.1ah] has also introduced a Service Instance tag (I- - TAG). Across all the Ethernet extensions (already referenced in the - Introduction), multiple forwarding functions, or service interfaces, - have been defined using the combination of VIDs, DMACs, and I-TAGs. - PBB [802.1ah] provides a breakdown of the different types of Ethernet - switching services. Figure 1 reproduces this breakdown. + frames based on the Ethernet header fields: Virtual Local Area + Network (VLAN) Identifiers (VID) and Destination Media Access Control + (DMAC) address. PBB [802.1ah] has also introduced a Service Instance + tag (I-TAG). Across all the Ethernet extensions (already referenced + in the Introduction), multiple forwarding functions, or service + interfaces, have been defined using the combination of VIDs, DMACs, + and I-TAGs. PBB [802.1ah] provides a breakdown of the different + types of Ethernet switching services. Figure 1 reproduces this + breakdown. Service Types _,,-' | '--.._ _,.-'' | `'--.._ _,.--' | `'--.. Port based S-tagged I-tagged _,- -. _.' `. _,' `. one-to-one bundled @@ -250,81 +265,78 @@ This is a special case, all frames are mapped from a single incoming port to a single destination Ethernet port. o I-tagged The edge of a PBBN consists of a combined backbone relay (B- component relay) and service instance relay (I-component relay). An I-Tag contains a service identifier (24 bit I-SID) and priority markings as well as some other flags. An I-Tagged service is typically between the edges of the PBBN and terminated at each edge on an I-component that faces a customer port so the service is - often not visible except at the edges. However since the I- - component relay involves a distinct relay it is possible to have a + often not visible except at the edges. However, since the I- + component relay involves a distinct relay, it is possible to have a visible I-Tagged Service by separating the I component relay from the B-component relay. Two examples where it makes sense to do this are: an I-Tagged service between two PBBNs and as an attachment to a customer's Provider Instance Port. - In general, the different types determine which of the Ethernet - header fields are used in the forwarding/switching function, e.g. VID - only or VID and DMACs. The types may also require the use of + In general, the different switching type determines which of the + Ethernet header fields are used in the forwarding/switching function, + e.g. VID only or VID and DMACs. The type may also require the use of additional Ethernet headers or fields. Services defined for UNIs tend to use the headers on a hop-by-hop basis. - In most cases for bridging, the header fields cannot be changed hop- - by-hop, but some translations of VID field values are permitted - typically at the edges. Again, while not specifically described in - 802.1ah, the Ethernet services being defined in the context of + In most bridging cases, the header fields cannot be changed hop-by- + hop, but some translations of VID field values are permitted, + typically at the edges. While not specifically described in + [802.1ah], the Ethernet services being defined in the context of [MEF.6] and [G.8011] also fall into the types defined in Figure 1. Across all service types, the Ethernet data plane is bi-directional congruent. This means that the forward and reverse paths share the exact same set of nodes, ports and bi-directional links. This - property is fundamental. The 802.1 group has defined maintained this - bi-directional congruent property in the definition of Connectivity + property is fundamental. The 802.1 group has maintained this bi- + directional congruent property in the definition of Connectivity Fault Management (CFM) which is part of the overall Operations Administration and Management (OAM) capability. 2.2. Operations, Administration, and Maintenance (OAM) Robustness is enhanced with the addition of data plane OAM to provide both fault and performance management. - For the Eth LSP unicast mode of behavior, the hardware performs - unicast packet forwarding of known MAC addresses exactly as Ethernet - currently operates. The OAM currently defined, [802.1ag] and [Y.1731] - can also be reused without modification of the protocols. + For the Eth-LSP unicast mode of behavior, the hardware performs + unicast packet forwarding of known MAC addresses leveraging existing + Ethernet forwarding. - OAM relies on domain wide path identifiers, for data plane - forwarding, utilizing the 60 bit unique connection ID (VID/DMAC). - Determining a broken path or misdirected packet in this case relies - on the connection ID not being altered on the Eth-LSP. These - identifiers are independent of the control plane so it works equally + Ethernet OAM messages [802.1ag] and [Y.1731], rely on data plane + forwarding for both directions. Determining a broken path or + misdirected packet in this case relies on OAM following the Eth-LSP. + These identifiers are dependent on the data plane so it works equally well for provisioned or GMPLS controlled paths. Ethernet OAM currently consists of: Defined in both [802.1ag & Y.1731]: - CCM/RDI: Connectivity Check, Remote Defect Indication - LBM/LBR: Loopback Message, Loopback Reply - LTM/LTR: Link trace Message, Link trace Reply - VSM/VSR: Vendor-specific extensions Message/Reply Additionally defined in [Y.1731]: - AIS: Alarm Indication Signal - LCK: Locked Signal - TST: Test - LMM/LMR: Loss Measurement Message/Reply - DM/DMM/DMR: Delay Measurement - EXM/EXR: Experimental - APS, MCC: Automatic Protection Switching, Maintenance Communication Channel - - Placeholders for ITU other standards With some Eth-LSP label formats bidirectional transactions (e.g. LBM/LBR) and reverse direction transactions MAY have a different VID for each direction. Currently Y.1731 & 802.1ag makes no representations with respect to this but work us underway to address this in PBB-TE [802.1Qay]. 2.3. Terminology 2.3.1. Concepts @@ -346,40 +358,46 @@ Shared forwarding is a property of a data path where a single forwarding entry (VID + DMAC) may be used for frames from multiple sources (SMAC). Shared forwarding does not change any data plane behavior it saves forwarding information base (FIB) entries only. From all other aspects it behaves as if there were multiple FIB entries. o In-band GMPLS Signaling - In-band GMPLS Signaling is IP based signaling on the native - Ethernet links encapsulated by a single hop Ethernet header. - Logical links that use a dedicated VID on the same physical links - would be considered In-band signaling. + In-band GMPLS Signaling is IP based control messages which are + sent on the native Ethernet links encapsulated by a single hop + Ethernet header. Logical links that use a dedicated VID on the + same physical links would be considered In-band signaling. - o Out-of-band GMPLS Signaling is IP based signaling between - Ethernet switches that uses some other links other than the - Ethernet data plane links. Out of band signaling typically shares - a different fate from the data links. + o Out-of-band GMPLS Signaling - o Contiguous Eth-LSP is an Eth-LSP that maps one to one with and + Out-of-band GMPLS Signaling is IP based control messages which + are sent between Ethernet switches that uses some other links + other than the Ethernet data plane links. Out of band signaling + typically shares a different fate from the data links. + + o Contiguous Eth-LSP + + A contiguous Eth-LSP is an Eth-LSP that maps one to one with an LSP at a domain boundary. Stitched LSP are contiguous LSPs. - o Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and - tunneled either individually or bundled with other LSPs through a - domain. + o Hierarchical Eth-LSP -2.3.2. Acronyms + Hierarchical Eth-LSPs are Eth-LSPs that are encapsulated and + tunneled, either individually or bundled, with other LSPs through + a domain. - The following acronyms are used in this document: +2.3.2. Abbreviations and Acronyms + + The following abbreviations and acronyms are used in this document: CFM Connectivity Fault Management DMAC Destination MAC Address CCM Continuity Check Message Eth-LSP Ethernet Label Switched Path I-SID Service Identifier LMP Link Management Protocol MAC Media Access Control MP2MP Multipoint to multipoint NMS Network Management System @@ -397,28 +415,28 @@ TAG An Ethernet short form for a TAG Header TAG Header An extension to an Ethernet frame carrying priority and other information. TSpec Traffic specification VID VLAN Identifier VLAN Virtual LAN 2.4. Ethernet and MPLS similarities and differences Ethernet is similar to MPLS in that there is a default payload type. - In MPLS the default payload is either another MPLS label or an IP + In MPLS, the default payload is either another MPLS label or an IP packet. The IP packet may carry any type of service IP carries. Ethernet assumes an Ethernet frame as the default payload. The actual service can be anything that Ethernet carries. - In MPLS pseudo wires where other types of payloads are used natively - the payload may be identified implicitly or explicitly by using a - control word removing the need for the IP header. + In MPLS pseudo wires, where other types of payloads are used + natively, the payload may be identified implicitly or explicitly by + using a control word removing the need for the IP header. Similarly, in Ethernet the option to carry other payloads by using either implicit or explicit means is being discussed. Ethernet bridging is different from MPLS in that while the switching decision is taken on whatever is defined as the Ethernet label, that label is usually not swapped at each hop. 3. Framework @@ -442,86 +460,87 @@ - bandwidth profile; - priority level; - preemption characteristics; - protection/resiliency capability; - routing policy, such as an explicit route; - bi-directional service; - end-to-end and segment protection; - hierarchy - The bandwidth profile may be used, to set committed information rate - and peak information rate, and policies based on either under- + The bandwidth profile may be used to set committed information rate, + peak information rate, and policies based on either under- subscription or over-subscription. Services covered by this - framework MUST have a TSpec that follows the Ethernet Traffic + framework MUST use a TSpec that follows the Ethernet Traffic parameters defined in [ETH-TSPEC]. - In applying GMPLS to Ethernet, GMPLS will be extended to work with - the Ethernet data plane and switching functions. The definition of - GMPLS support for Ethernet is multi-faceted due to the different - forwarding/switching functions inherent in the different 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 + In applying GMPLS to "transport" Ethernet, GMPLS may be extended to + work with the Ethernet data plane and switching functions. The + definition of GMPLS support for Ethernet is multi-faceted due to the + different forwarding/switching functions inherent in the different + 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 general characteristics of the IEEE 802.1Q [802.1Q] data plane - are left unchanged. 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 specified - under IEEE802.1Qay allows for turning off learning and hence this - broadcast mechanism. A special case is when a VID is defined for only - two ports on one bridge, in that case all frames with that VID - received over one of these ports are forward over the over port. + 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. + + 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 + specified under IEEE802.1Qay allows for turning off learning and + hence this broadcast mechanism. A special case is when a VID is + defined for only two ports on one bridge, in that case all frames + with that VID received over one of these ports are forward over the + over port. This document does not define any specific format for an Eth-LSP label. Rather, it is expected that service specific documents will - define any signaling and routing extensions needed to support that + define any signaling and routing extensions needed to support a specific Ethernet service. Depending on the requirements of a service, it may be necessary to define multiple GMPLS protocol extensions and procedures. It is expected that all such extensions will be consistent with this document. - It is expected that key a requirement will be to describe label - formats and encodings. It may also be 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 is defined in [RFC3945] and [RFC3471] as - indicating the type of switching that should be performed on a - particular link for 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 may be required for each - new Ethernet switching paradigm that is supported. + It is expected that key a requirement for service specific documents + will be to describe label formats and encodings. It may also be + 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. 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. + 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. 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 @@ -532,55 +551,55 @@ In the case where another address family or type of identifier is required to support an Ethernet service, extensions may be defined to provide mapping to an IP address. Extensions to support non-IP based LSP identification in signaling, i.e., replacement of the IP address in the RSVP SESSION or SENDER_TSPEC objects, are not permitted under this framework. 4.1. GMPLS Routing - GMPLS routing [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 - configuration if LMP is not available. 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 2, it will be - necessary to define one or more new Interface Switching Capabilities - to support Eth-LSPs. 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 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. 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. One way to implement this is with an IGP that views each switch as a terminated IP adjacency. In other words, IP traffic and a simple routing table are available for the control plane but there is no requirement for a high performance IP data plane. This IP connectivity can be provided as a separate independent network (out of band) or integrated with the Ethernet switches (in- band). -5. P2P Signaling +5. GMPLS Signaling GMPLS signaling, see [RFC3471], is well suited to the control of Eth- LSPs and Ethernet switches. Signaling enables the ability to dynamically establish a path from one ingress or egress node. The signaled path may be completely static and not change for the duration of its lifetime. However, signaling also has the capability to dynamically adjust the path in a coordinated fashion after the path has been established. The range of signaling options from static to dynamic are under operator control. Standardized signaling also improves multi-vendor interoperability over simple management. @@ -595,34 +614,34 @@ 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 and is not - necessarily operating before the Link is operational it primarily + 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 creation of - unnumbered interfaces can be automated. If LMP is not used there is - an additional provisioning requirement to add GMPLS link identifiers. + 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 - [Y.1731]. It is recommended that LMP not be used for Fault + fault management capabilities that overlap with [IEEE802.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 link property correlation but that Ethernet mechanisms for OAM such @@ -654,55 +673,56 @@ Switch 1 link Switch 2 Figure 2: Logical Link Management Options 7. Path Computation and Selection GMPLS does not specify a specific method for selecting paths or supporting path computation. GMPLS allows for a wide ranges of possibilities supported from very simple path computation to very elaborate path coordination where a large number of coordinated paths - are required. The path computation could take the form of paths - being computed either on a management station with local computation - for rerouting or more sophisticated path computation servers. + 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 and selection work; see [PATH-COMP] + the emerging path computation element and selection work; see [PATH- + COMP] 8. Multiple Domains - This document will support the signaling of Ethernet parameters - across multiple domains supporting both contiguous Eth-LSP and - Hierarchical Ethernet LSPs. The intention is to support the GMPLS - tools of hierarchy supporting Peer to Peer models, UNIs and NNIs. + 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. 9. Security Considerations - The architecture for GMPLS controlled Ethernet assumes that the - network consists of trusted devices, but does not require that the - ports over which a UNI is defined is trusted, nor does equipment - connected to these ports need to be trusted. Access to the trusted - domain SHALL only occur through the protocols defined in the UNI or - NNI or through protected management interfaces. Where GMPLS is + The architecture for GMPLS controlled "transport" Ethernet assumes + that the network consists of trusted devices, but does not require + that the ports over which a UNI is defined is trusted, nor does + equipment connected to these ports need to be trusted. Access to the + trusted domain SHALL only occur through the protocols defined in the + UNI or NNI or through protected management interfaces. Where GMPLS is applied to the control of VLAN only, the commonly known techniques for mitigation of Ethernet DOS attacks may be required on UNI ports. 10. IANA Considerations - New values are required for signaling and error codes as indicated. - This section will be completed in a later version. + No new values are specified in this document. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3471] Berger, L. (editor), "Generalized MPLS Signaling Functional Description", January 2003, RFC3471. @@ -834,10 +854,12 @@ The IETF invites any interested party to bring to its attention 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