    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]