--- 1/draft-ietf-ccamp-gmpls-ethernet-arch-05.txt 2009-10-14 22:12:08.000000000 +0200 +++ 2/draft-ietf-ccamp-gmpls-ethernet-arch-06.txt 2009-10-14 22:12:08.000000000 +0200 @@ -1,43 +1,48 @@ Internet Draft Don Fedyk, Alcatel-Lucent Category: Informational Lou Berger, LabN -Expiration Date: March 1, 2010 Loa Andersson, Ericsson AB +Expiration Date: April 14, 2010 Loa Andersson, Ericsson AB - September 1, 2009 + October 14, 2009 Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework - draft-ietf-ccamp-gmpls-ethernet-arch-05.txt + draft-ietf-ccamp-gmpls-ethernet-arch-06.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. + 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 BCP 78 and BCP 79. + Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 March 1, 2010. + This Internet-Draft will expire on April 14, 2010. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -56,62 +61,56 @@ 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. Table of Contents 1 Introduction ........................................... 4 1.1 Terminology ............................................ 6 1.1.1 Concepts ............................................... 6 - 1.1.2 Abbreviations and Acronyms ............................. 8 + 1.1.2 Abbreviations and Acronyms ............................. 7 2 Background ............................................. 8 - 2.1 Ethernet Switching ..................................... 9 + 2.1 Ethernet Switching ..................................... 8 2.2 Operations, Administration, and Maintenance (OAM) ...... 11 - 2.3 Ethernet Switching Characteristics ..................... 12 + 2.3 Ethernet Switching Characteristics ..................... 11 3 Framework .............................................. 12 4 GMPLS Routing and Addressing Model ..................... 14 - 4.1 GMPLS Routing .......................................... 15 + 4.1 GMPLS Routing .......................................... 14 4.2 Control Plane Network .................................. 15 - 5 GMPLS Signaling ........................................ 16 + 5 GMPLS Signaling ........................................ 15 6 Link Management ........................................ 16 - 7 Path Computation and Selection ......................... 18 + 7 Path Computation and Selection ......................... 17 8 Multiple VLANs ......................................... 18 9 Security Considerations ................................ 18 - 10 IANA Considerations .................................... 19 - 11 References ............................................. 19 - 11.1 Normative References ................................... 19 + 10 IANA Considerations .................................... 18 + 11 References ............................................. 18 + 11.1 Normative References ................................... 18 11.2 Informative References ................................. 19 - 12 Acknowledgments ........................................ 21 - 13 Author's Addresses ..................................... 21 - -Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" - in this document are to be interpreted as described in [RFC2119]. + 12 Acknowledgments ........................................ 20 + 13 Author's Addresses ..................................... 20 1. Introduction 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. The evolution and development of Ethernet capabilities in these areas is a very active and ongoing process. Multiple organizations have been active in extending Ethernet - technology to support transport networks. This activity has taken - place in the Institute of Electrical and Electronics Engineers (IEEE) - 802.1 Working Group, the International Telecommunication Union (ITU) - and the Metro Ethernet Forum (MEF). These groups have been focusing - on Ethernet forwarding, Ethernet management plane extensions and the + Technology support transport networks. This activity has taken place + in the Institute of Electrical and Electronics Engineers (IEEE) 802.1 + Working Group, the International Telecommunication Union (ITU) and + the Metro Ethernet Forum (MEF). These groups have been focusing on + Ethernet forwarding, Ethernet management plane extensions and the Ethernet Spanning Tree Control Plane, but not on an explicitly routed, constraint based control plane. In the forwarding plane context, extensions have been, or are being, defined to support different transport Ethernet forwarding models, protection modes, and service interfaces. Examples of such extensions include [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These extensions allow for greater flexibility in the Ethernet forwarding plane and, in some cases, the extensions allow for a departure from forwarding based on Ethernet spanning tree. For example, in the @@ -141,21 +140,21 @@ An example of Ethernet protection extensions can be found in [G.8031]. 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 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. These framework documents discuss general + transport networks. These framework documents discusses general Ethernet connection characteristics, Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network Interfaces (NNIs). [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 allow for the disabling of standard Ethernet spanning tree but do not define an explicitly routed, constraint based control plane. For example @@ -181,41 +180,41 @@ This document introduces and explains GMPLS control plane use for transport Ethernet and the concept of the 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 existing signaling, routing, LMP and path computation to be used as specified. The GMPLS protocols support hierarchical LSPs as well as contiguous LSPs. Also, GMPLS 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. + mechanisms support a variety of network reference points from UNIs to + NNIs. Additions to existing GMPLS capabilities will only be made to + accommodate features unique to transport Ethernet. 1.1. Terminology 1.1.1. Concepts The following are basic Ethernet and GMPLS terms: o Asymmetric Bandwidth This term refers to a property of a Bidirectional service instance may have differing bandwidth allocation in each direction. o Bidirectional Congruent LSP - This term refers to the property of a bi-directional LSP that - uses only the same nodes, ports, and links in both directions. - Ethernet data planes are normally bi-directional or reverse path + This term refers to the property of a bidirectional LSP that uses + only the same nodes, ports, and links in both directions. + Ethernet data planes are normally bidirectional or reverse path congruent. o Contiguous Eth-LSP A contiguous Eth-LSP is an Eth-LSP that maps one to one with an another LSP at a VLAN boundary. Stitched LSPs are contiguous LSPs. o Eth-LSP @@ -229,34 +228,34 @@ o In-band GMPLS 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 - 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. + Out-of-band GMPLS Signaling is composed of IP based control + messages that are sent between Ethernet switches over links other + than the links used by the Ethernet data plane. Out of band + signaling typically shares a different fate from the data links. o Point-to-point (P2P) Traffic Engineering (TE) Service Instance - An TE service instance made up from two P2P unidirectional Eth- - LSPs. + A TE service instance made up of a single bidirectional P2P or + two P2P unidirectional Eth-LSPs. o Point-to-multipoint (P2MP) Traffic Engineering (TE) Service Instance - An TE service Instance supported by a set of LSPs which comprises + A TE service Instance supported by a set of LSPs which comprises one P2MP LSP from a root to n leaves plus a Bidirectional Congruent point-to-point (P2P) LSP from each of the leaves to the root. o Shared forwarding 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. Shared forwarding saves forwarding database @@ -355,21 +354,21 @@ [802.1ah] defines a new I-tagged service type but does not specifically define the Ethernet services being defined in the context of [MEF.6] and [G.8011] which are also illustrated in Figure 1. To summarize the definitions: o Port based This is a frame based service that supports specific frame types, - no Service VLAN tagging, with MAC address based switching. + no Service VLAN tagging or MAC address based switching. o S-tagged There are multiple Service VLAN tag (S-tag) aware services, including: + one-to-one In this service, each VLAN identifier (VID) is mapped into a different service. + Bundled @@ -407,25 +406,25 @@ e.g. VID only or VID and DMACs. The switching type may also require the use of additional Ethernet headers or fields. Services defined for UNIs tend to use the headers for requesting service (service delimiter) and are relevant between the customer site and network edge. In most bridging cases, the header fields cannot be changed, but some translations of VID field values are permitted, typically at the network edges. - Across all service types, the Ethernet data plane is bi-directional + Across all service types, the Ethernet data plane is bidirectional 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 maintained this bi- - directional congruent property in the definition of Connectivity + exact same set of nodes, ports and bidirectional links. This + property is fundamental. The 802.1 group has maintained this + bidirectional 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. Ethernet OAM messages [802.1ag] and [Y.1731], rely on data plane forwarding for both directions. Determining a broken path or @@ -448,79 +447,80 @@ - DM/DMM/DMR: Delay Measurement - EXM/EXR: Experimental - APS, MCC: Automatic Protection Switching, Maintenance Communication Channel These functions are supported across all the Standardized Eth-LSP formats. 2.3. Ethernet Switching Characteristics - Ethernet is similar to MPLS it encapsulates different packet and + Ethernet is similar to MPLS as it encapsulates different packet and frame types for data transmission. In Ethernet, the encapsulated data is referred to as MAC client data. The encapsulation is an Ethernet MAC frame with a header, a source address, destination address, optional VLAN identifier, Type and length on the front of the MAC client data with optional padding and a Frame Check Sequence at the end of the frame. The type of MAC client data is typically identified by an "Ethertype" value. This is an explicit type indication but Ethernet also supports an implicit type indication. - Ethernet bridging switches Ethernet based on the Frame destination - MAC address and VLAN. The VLAN identifies a virtual set of Bridges - and LANs. The address is assumed to be unique and invariant within - the VLAN. MAC addresses are often globally unique but this is not + Ethernet bridging switches based on a frame's destination MAC address + and VLAN. The VLAN identifies a virtual active set of Bridges and + LANs. The address is assumed to be unique and invariant within the + VLAN. MAC addresses are often globally unique but this is not necessary for bridging. 3. Framework As defined in the GMPLS Architecture [RFC3945], the GMPLS control plane can be applied to a technology by controlling the data plane - and switching characteristics of that technology. The architecture - includes a clear separation between a control plane and a data plane. - Control plane and data plane separation allows the GMPLS control - plane to remain architecturally and functionally unchanged while - controlling different technologies. The architecture also requires - IP connectivity for the control plane to exchange information, but - does not otherwise require an IP data plane. + and switching characteristics of that technology. The GMPLS + architecture, per [RFC3945], allowed for control of Ethernet bridges + and other layer 2 technologies using the Layer-2 Switch Capable + (L2SC) switching type. But, the control of Ethernet switching was + not explicitly defined in [RFC3471], [RFC4202] or any other + subsequent GMPLS reference document. + + The GMPLS architecture includes a clear separation between a control + plane and a data plane. Control plane and data plane separation + allows the GMPLS control plane to remain architecturally and + functionally unchanged while controlling different technologies. The + architecture also requires IP connectivity for the control plane to + exchange information, but does not otherwise require an IP data + plane. All aspects of GMPLS, i.e., addressing, signaling, routing and link management, may be applied to Ethernet switching. GMPLS can provide control for traffic engineered and protected Ethernet service paths. This document defines the term "Eth-LSP" to refer to Ethernet service paths that are controlled via GMPLS. As is the case with all GMPLS controlled services, Eth-LSPs can leverage common traffic engineering attributes such as: - bandwidth profile; - forwarding priority level; - connection preemption characteristics; - protection/resiliency capability; - routing policy, such as an explicit route; - - bi-directional service; + - bidirectional service; - end-to-end and segment protection; - hierarchy 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 use a TSpec that follows the Ethernet Traffic + framework will use a TSpec that follows the Ethernet Traffic parameters defined in [ETH-TSPEC]. - The GMPLS architecture, per [RFC3945], allowed for control of - Ethernet bridges and other layer 2 technologies using the Layer-2 - Switch Capable (L2SC) switching type. The control of Ethernet - switching was not explicitly defined in [RFC3471], [RFC4202] or any - other subsequent GMPLS reference document. - In applying GMPLS to "transport" Ethernet, GMPLS will need to 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 @@ -531,21 +531,21 @@ 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. A special case is when a VID is defined for only two ports on one bridge, effectively resulting in a p2p - forwarding constraint, in this case all frames tagged with that VID + forwarding constraint. In this case all frames tagged with that VID received over one of these ports are forward over the other port without address learning. [802.1Qay]allows for turning off learning and hence the broadcast mechanism providing means to create explicitly routed Ethernet connections. 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 a @@ -559,110 +559,111 @@ 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. Since 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 + an LSP. The L2SC switching type may already be used by + implementations performing layer 2 switching including Ethernet. As + such, and to allow the continued use of that switching type and those implementations, and to distinguish the different Ethernet switching - paradigms, a new Ethernet switching type MUST be defined for each new + paradigms, a new switching type needs to 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 document. GMPLS control for Eth-LSPs uses the Routing and Addressing Model described in [RFC3945]. Most notably this includes the use of IP addresses to identify interfaces and LSP end-points. It also includes support for both numbered and unnumbered interfaces. 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. Support of Ethernet MUST strictly - comply to the GMPLS protocol suite addressing as specific in RFC3471, - RFC3473 and related. + provide mapping to an IP address. Support of Eth-LSPs is expected to + strictly comply to the GMPLS protocol suite addressing as specific in + RFC3471, RFC3473 and related documents. 4.1. GMPLS Routing GMPLS routing as defined in [RFC4202] uses IP routing protocols 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 Descriptor. 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 + 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 based on resource information obtained + from 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 Descriptor. As mentioned in Section + 3, the definition of one or more new Interface Switching Capabilities + to support Eth-LSPs is expected. Again, the L2SC Interface Switching + Capabilities will not be used to represent interfaces capable of supporting Eth-LSPs defined by this document and subsequent documents in support of the transport Ethernet switching paradigms. In addition, 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 functionality 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 connectivity 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 needing a high performance IP data plane. + One way to implement this is with an IP routed network supported by + 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 needing a high + performance IP data plane, or for forwarding user traffic over this + IP network. This IP connectivity can be provided as a separate independent network (out of band) or integrated with the Ethernet switches (in- band). 5. GMPLS Signaling GMPLS signaling, see [RFC3471][RFC3473], is well suited to the - control of Eth-LSPs and Ethernet switches. Signaling enables the + control of Eth-LSPs and Ethernet switches. Signaling provides the ability to dynamically establish a path from an ingress node to an 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. + Standardized signaling also improves multi-vendor interoperability. - GMPLS signaling supports the establishment and control of bi- - directional and unidirectional data paths. Ethernet is bi-directional - by nature and the CFM has been built to leverage this. Prior to CFM - the emulation of a physical wire and the learning requirements also - mandated bi-directional connections. Given this, Eth-LSPs MUST be bi- - directional congruent. Eth-LSPs may be either P2P or P2MP (see - [RFC4875]). GMPLS signaling also allows for full and partial LSP - protection; see [RFC4872] and [RFC4873]. + GMPLS signaling supports the establishment and control of + bidirectional and unidirectional data paths. Ethernet is + bidirectional by nature and CFM has been built to leverage this. + Prior to CFM, the emulation of a physical wire and the learning + requirements also mandated bidirectional connections. Given this, + Eth-LSPs need to be bidirectional congruent. Eth-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 bi-directional LSP. [GMPLS-ASYM], an Experimental - document, provides procedures if asymmetric bandwidth bi-directional + direction of a bidirectional LSP. [GMPLS-ASYM], an Experimental + document, provides procedures if asymmetric bandwidth bidirectional LSPs are required. 6. Link Management Link discovery has been specified for Ethernet in [802.1AB]. 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. However the 802.1AB capability is an optional feature, it is not necessarily operating before a link is @@ -671,34 +672,33 @@ In the GMPLS context, LMP [RFC4204] has been defined to support GMPLS control plane link management and discovery features. LMP also supports for the control plane the automated creation of unnumbered interfaces. If LMP is not used there is an additional configuration requirement for GMPLS link identifiers. For large-scale implementations LMP is beneficial. LMP also has optional fault management capabilities, primarily for opaque and transparent network technology. With IEEE's newer CFM [802.1ag] and ITU's [Y.1731] capabilities, this optional capability may not be needed. It is the goal of the GMPLS Ethernet architecture to allow the selection of the - best tool set for the user - needs. The full functionality of Ethernet CFM should be supported - when using a GMPLS control plane. + best tool set for the user needs. The full functionality of Ethernet + CFM should be supported when using a GMPLS control plane. 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 expected that LMP would be used for control plane functions of link property correlation but that Ethernet - mechanisms for OAM such as CFM, link trace etc would be used for data - plane fault management and fault trace. + mechanisms for OAM such as CFM, link trace, etc. would be used for + data plane fault management and fault trace. +-------------+ +-------------+ | +---------+ | | +---------+ | | | | | | | | |GMPLS | | LMP |-|<------>|-| LMP | |Link Property | | | | | | | |Correlation | | (opt) | |GMPLS | | (opt) | | | | | | | | | | Bundling | +---------+ | | +---------+ | | +---------+ | | +---------+ | @@ -745,21 +745,21 @@ and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS hierarchy for the support of Peer to Peer models, UNIs and NNIs. 9. Security Considerations 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 are defined are trusted, nor does equipment connected to these ports trusted. In general, these requirements are no different from the security requirements for - operating any GMPLS network. Access to the trusted network SHALL only + operating any GMPLS network. Access to the trusted network will only occur through the protocols defined for the UNI or NNI or through protected management interfaces. When in-band GMPLS signaling is used for the control plane the security of the control plane and the data plane may affect each other. When out-of-band GMPLS signaling is used the control plane the data plane security is decoupled from the control plane and therefore the security of the data plane has less impact on overall security. @@ -773,23 +773,20 @@ issues that any protocol extensions introduce. 10. IANA Considerations 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. [RFC3473] Berger, L. (editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", January 2003, RFC3473. [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support of Generalized MPLS", RFC 4202, October 2005 @@ -830,21 +827,21 @@ [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 Multipoint TE LSPs", IETF RFC 4875, May 2007 [RFC4655] Farrel, A. et.al., "Path Computation Element (PCE) - Architecture", RCF 4655, August 2006. + Architecture", RFC 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 ", @@ -882,11 +878,11 @@ Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net Loa Andersson Ericsson AB Phone: +46 10 717 52 13 Email: loa.andersson@ericsson.com -Generated on: Tue Sep 1 11:27:49 EDT 2009 +Generated on: Wed Oct 14 14:54:18 EDT 2009