English

Whois.SmartWeb.CZ

RFC 7074 - úplné znění

Plné znění RFC 7074:






Internet Engineering Task Force (IETF)                         L. Berger
Request for Comments: 7074                                          LabN
Updates: 3471, 4202, 4203, 5307                                J. Meuric
Category: Standards Track                                         Orange
ISSN: 2070-1721                                            November 2013


  Revised Definition of the GMPLS Switching Capability and Type Fields

Abstract

   GMPLS provides control for multiple switching technologies and for
   hierarchical switching within a technology.  GMPLS routing and
   signaling use common values to indicate the type of switching
   technology.  These values are carried in routing protocols via the
   Switching Capability field, and in signaling protocols via the
   Switching Type field.  While the values used in these fields are the
   primary indicators of the technology and hierarchy level being
   controlled, the values are not consistently defined and used across
   the different technologies supported by GMPLS.  This document is
   intended to resolve the inconsistent definition and use of the
   Switching Capability and Type fields by narrowly scoping the meaning
   and use of the fields.  This document updates all documents that use
   the GMPLS Switching Capability and Types fields, in particular RFCs
   3471, 4202, 4203, and 5307.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/RFC 7074.












Berger & Meuric              Standards Track                    [Page 1]

RFC 7074 GMPLS Switching and Type Fields Revision November 2013 Copyright Notice Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Generalized Multiprotocol Label Switching (GMPLS) provides control for multiple switching technologies. It also supports hierarchical switching within a technology. The original GMPLS Architecture, per [RFC 3945], included support for five types of switching capabilities. An additional type was also defined in [RFC 6002]. The switching types defined in these documents include: 1. Packet Switch Capable (PSC) 2. Layer-2 Switch Capable (L2SC) 3. Time-Division Multiplex Capable (TDM) 4. Lambda Switch Capable (LSC) 5. Fiber-Switch Capable (FSC) 6. Data Channel Switching Capable (DCSC) Support for the original types was defined for routing in [RFC 4202], [RFC 4203], and [RFC 5307], where the types were represented in the Switching Capability (Switching Cap) field. In general, hierarchy within a type is addressed in a type-specific fashion, and a single Switching Capability field value is defined per type. The exception to this is PSC, which was assigned four values to indicate four levels of hierarchy: PSC-1, PSC-2, PSC-3, and PSC-4. The same values used in routing are defined for signaling in [RFC 3471], and are carried in the Switching Type field. Following the IANA registry, we refer to the values used in the routing Switching Capability field and signaling Switching Type field as Switching Types. Berger & Meuric Standards Track [Page 2]
RFC 7074 GMPLS Switching and Type Fields Revision November 2013 In general, a Switching Type does not indicate a specific data-plane technology; this needs to be inferred from context. For example, L2SC was defined to cover Ethernet and ATM, and TDM was defined to cover both SONET/SDH [RFC 4606] and G.709 [RFC 4328]. The basic assumption was that different technologies of the same type would never operate within the same control, i.e., signaling and routing domains. The past approach in assignment of Switching Types has proven to be problematic from two perspectives. The first issue is that some examples of switching technologies have different levels of switching that can be performed within the same technology. For example, there are multiple types of Ethernet switching that may occur within a provider network. The second issue is that the Switching Capability field value is used in Interior Gateway Protocols (IGPs) to indicate the format of the Switching Capability-specific information (SCSI) field, and that an implicit mapping of type to SCSI format is impractical for implementations that support multiple switching technologies. These issues led to the introduction of two new types for Ethernet in [RFC 6004] and [RFC 6060], namely: 7. Ethernet Virtual Private Line (EVPL) 8. 802_1 PBB-TE (Provider Backbone Bridge Traffic Engineering) An additional value is also envisioned to be assigned in support of G.709v3 by [GMPLS-G709] in order to disambiguate the format of the SCSI field. While a common representation of hierarchy levels within a switching technology certainly fits the design objectives of GMPLS, the definition of multiple PSC Switching Types has also proven to be of little value. Notably, there are no known uses of PSC-2, PSC-3, and PSC-4. This document proposes to resolve such inconsistent definitions and uses of the Switching Types by reducing the scope of the related fields and narrowing their use. In particular, this document deprecates the use of the Switching Types as an identifier of hierarchy levels within a switching technology and limits its use to the identification of a per-switching technology SCSI field format. This document updates all documents that use the GMPLS Switching Capability and Switching Type fields, in particular RFCs 3471, 4202, 4203, and 5307. Berger & Meuric Standards Track [Page 3]
RFC 7074 GMPLS Switching and Type Fields Revision November 2013 1.1. Current Switching Type Definition The Switching Type values are carried in both routing and signaling protocols. Values are identified in IANA's "Generalized Multi- Protocol Label Switching (GMPLS) Signaling Parameters" registry, which is currently located at <http://www.iana.org/assignments/ gmpls-sig-parameters/>. For routing, a common information element is defined to carry Switching Type values for both OSPF and IS-IS routing protocols in [RFC 4202]. Per [RFC 4202], Switching Type values are carried in a Switching Capability (Switching Cap) field in an Interface Switching Capability Descriptor. This information shares a common formatting in both OSPF as defined by [RFC 4203] and in IS-IS as defined by [RFC 5307]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... The content of the Switching Capability-specific information field depends on the value of the Switching Capability field. Similarly, the Switching Type field is defined as part of a common format for use by GMPLS signaling protocols in [RFC 3471] and is used by [RFC 3473]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Switching Type: 8 bits Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. This field should Berger & Meuric Standards Track [Page 4]
RFC 7074 GMPLS Switching and Type Fields Revision November 2013 map to one of the values advertised for the corresponding link in the routing Switching Capability Descriptor ... 1.2. 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 [RFC 2119]. 2. Revised Switching Type Definition This document modifies the definition of Switching Type. The definitions are slightly different for routing and signaling and are described in the following sections. 2.1. Routing -- Switching Cap Field For routing [RFC 4202] [RFC 4203] [RFC 5307], the following definition should be used for Switching Cap field: The Switching Cap field indicates the type of switching being advertised via GMPLS Switching Type values. A different Switching Type value SHOULD be used for each data-plane technology, even when those technologies share the same type of multiplexing or switching. For example, Time Division Multiplexing (TDM) technologies that have different multiplexing structures, such as Synchronous Digital Hierarchy (SDH) [G.707] and Optical Transport Network (OTN) [G.709], should use two different Switching Types. As the format of the Switching Capability-specific information field is dependent on the value of this field, a different Switching Type value MUST be used to differentiate between different Switching Capability-specific information field formats. This definition does not modify the format of the Interface Switching Capability Descriptor. Note that from a practical standpoint, this means that any time a new switching technology might use a different Switching Capability- specific information field format, a new Switching Type SHOULD be used. Berger & Meuric Standards Track [Page 5]
RFC 7074 GMPLS Switching and Type Fields Revision November 2013 2.2. Signaling -- Switching Type Field For signaling [RFC 3471], which is used by [RFC 3473], the following definition should be used for the Switching Type field: Indicates the type of switching that should be performed on a particular link via GMPLS Switching Type values. This field maps to one of the values advertised for the corresponding link in the routing Switching Capability Descriptor, see [RFC 4203] and [RFC 5307]. Note that from a practical standpoint, there is no change in the definition of this field. 2.3. Assigned Switching Types This document deprecates the following Switching Types: Value Name 2 Packet-Switch Capable-2 (PSC-2) 3 Packet-Switch Capable-3 (PSC-3) 4 Packet-Switch Capable-4 (PSC-4) These values SHOULD be treated as unsupported types and, in the case of signaling, processed according to Section 2.1.1 of [RFC 3473]. 3. Compatibility For existing implementations, the primary impact of this document is deprecating the use of PSC-2, 3, and 4. At the time of publication, there are no known deployments (or even implementations) that make use of these values, so there are no compatibility issues for current routing and signaling implementations. 4. Security Considerations This document impacts the values carried in a single field in signaling and routing protocols. As no new protocol formats or mechanisms are defined, there are no particular security implications raised by this document. For a general discussion on MPLS- and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC 5920]. Berger & Meuric Standards Track [Page 6]
RFC 7074 GMPLS Switching and Type Fields Revision November 2013 5. IANA Considerations IANA has deprecated some values and redefined the related values in the "IANA-GMPLS-TC-MIB" definitions. In particular, the Switching Types portion of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry been revised to read: Switching Types Registration Procedures Standards Action Reference [RFC 3471][RFC 4328][This Document] Value Name Reference 0 Unassigned 1 Packet-Switch Capable-1 (PSC-1) [RFC 3471] 2 Deprecated [This Document] 3 Deprecated [This Document] 4 Deprecated [This Document] 5-29 Unassigned 30 Ethernet Virtual Private Line (EVPL) [RFC 6004] 31-39 Unassigned 40 802_1 PBB-TE [RFC 6060] 41-50 Unassigned 51 Layer-2 Switch Capable (L2SC) [RFC 3471] 52-99 Unassigned 100 Time-Division-Multiplex Capable (TDM) [RFC 3471] 101-124 Unassigned 125 Data Channel Switching Capable (DCSC) [RFC 6002] 126-149 Unassigned 150 Lambda-Switch Capable (LSC) [RFC 3471] 151-199 Unassigned 200 Fiber-Switch Capable (FSC) [RFC 3471] 201-255 Unassigned A parallel change to IANA-GMPLS-TC-MIB was also made. In particular, under IANAGmplsSwitchingTypeTC a reference to this document has been added as item 3. The following changes have also been made to the related values: psc2(2), -- Deprecated [This Document] psc3(3), -- Deprecated [This Document] psc4(4), -- Deprecated [This Document] Berger & Meuric Standards Track [Page 7]
RFC 7074 GMPLS Switching and Type Fields Revision November 2013 6. Acknowledgments We thank John Drake for highlighting the current inconsistent definitions associated with the Switching Capability and Type fields. Daniele Ceccarelli and Adrian Farrel provided valuable feedback on this document. 7. References 7.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC 4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC 4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC 5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. 7.2. Informative References [G.707] ITU-T Recommendation G.707/Y.1322 (2007), "Network node interface for the synchronous digital hierarchy (SDH)". [G.709] ITU-T Recommendation G.709/Y.1331 (2009), "Interfaces for the Optical Transport Network (OTN)". [GMPLS-G709] Zhang, F., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", Work in Progress, September 2013. [RFC 3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Berger & Meuric Standards Track [Page 8]
RFC 7074 GMPLS Switching and Type Fields Revision November 2013 [RFC 3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC 4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [RFC 4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006. [RFC 5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC 6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions", RFC 6002, October 2010. [RFC 6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching", RFC 6004, October 2010. [RFC 6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, "Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)", RFC 6060, March 2011. 8. Authors' Addresses Lou Berger LabN Consulting, L.L.C. Phone: +1 301 468 9228 EMail: lberger@labn.net Julien Meuric Orange Research & Development 2, Avenue Pierre Marzin 22307 Lannion Cedex -- France Phone: +33 2 96 05 28 28 EMail: julien.meuric@orange.com Berger & Meuric Standards Track [Page 9]


English version: RFC 7074