Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

PROPOSED STANDARD
Internet Engineering Task Force (IETF)                         L. BergerRequest for Comments: 7074                                          LabNUpdates:3471,4202,4203,5307                                J. MeuricCategory: Standards Track                                         OrangeISSN: 2070-1721                                            November 2013Revised Definition of the GMPLS Switching Capability and Type FieldsAbstract   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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7074.Berger & Meuric              Standards Track                    [Page 1]

RFC 7074        GMPLS Switching and Type Fields Revision   November 2013Copyright Notice   Copyright (c) 2013 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 20131.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 shouldBerger & 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 20132.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 toSection 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 20135.  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 20136.  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.  References7.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",RFC3471, 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",RFC3473, 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.comBerger & Meuric              Standards Track                    [Page 9]

[8]ページ先頭

©2009-2025 Movatter.jp