diff options
Diffstat (limited to 'doc/rfc/rfc7074.txt')
| -rw-r--r-- | doc/rfc/rfc7074.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc7074.txt b/doc/rfc/rfc7074.txt new file mode 100644 index 0000000..af2725a --- /dev/null +++ b/doc/rfc/rfc7074.txt @@ -0,0 +1,507 @@ + + + + + + +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/rfc7074. + + + + + + + + + + + + +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 + [RFC3945], included support for five types of switching capabilities. + An additional type was also defined in [RFC6002]. 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 [RFC4202], + [RFC4203], and [RFC5307], 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 [RFC3471], 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 [RFC4606] and G.709 [RFC4328]. 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 [RFC6004] and [RFC6060], 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 + [RFC4202]. Per [RFC4202], 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 [RFC4203] and in IS-IS as defined by + [RFC5307]: + + 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 [RFC3471] and is used + by [RFC3473]: + + 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 [RFC2119]. + +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 [RFC4202] [RFC4203] [RFC5307], 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 [RFC3471], which is used by [RFC3473], 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 [RFC4203] and + [RFC5307]. + + 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 + [RFC3473]. + +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 [RFC5920]. + + + + + + + +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 + [RFC3471][RFC4328][This Document] + + Value Name Reference + 0 Unassigned + 1 Packet-Switch Capable-1 (PSC-1) [RFC3471] + 2 Deprecated [This Document] + 3 Deprecated [This Document] + 4 Deprecated [This Document] + 5-29 Unassigned + 30 Ethernet Virtual Private Line (EVPL) [RFC6004] + 31-39 Unassigned + 40 802_1 PBB-TE [RFC6060] + 41-50 Unassigned + 51 Layer-2 Switch Capable (L2SC) [RFC3471] + 52-99 Unassigned + 100 Time-Division-Multiplex Capable (TDM) [RFC3471] + 101-124 Unassigned + 125 Data Channel Switching Capable (DCSC) [RFC6002] + 126-149 Unassigned + 150 Lambda-Switch Capable (LSC) [RFC3471] + 151-199 Unassigned + 200 Fiber-Switch Capable (FSC) [RFC3471] + 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 + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Functional Description", RFC + 3471, January 2003. + + [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing + Extensions in Support of Generalized Multi-Protocol + Label Switching (GMPLS)", RFC 4202, October 2005. + + [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4203, October 2005. + + [RFC5307] 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. + + [RFC3473] 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 + + + [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture", RFC 3945, October 2004. + + [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol + Label Switching (GMPLS) Signaling Extensions for G.709 + Optical Transport Networks Control", RFC 4328, January + 2006. + + [RFC4606] 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. + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + + [RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data + Channel Switching Capable (DCSC) and Channel Set Label + Extensions", RFC 6002, October 2010. + + [RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) + Support for Metro Ethernet Forum and G.8011 Ethernet + Service Switching", RFC 6004, October 2010. + + [RFC6060] 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] + |