Skip to main content

Revised Definition of The GMPLS Switching Capability and Type Fields
draft-berger-ccamp-swcaps-update-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Lou Berger , Julien Meuric
Last updated 2012-02-21
Replaced by draft-ietf-ccamp-swcaps-update, RFC 7074
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-berger-ccamp-swcaps-update-00
Internet Draft                                         Lou Berger (LabN)
Updates: 3471, 4202, 4203, 5307           Julien Meuric (France Telecom)
Category: Standards Track
Expiration Date: August 20, 2012

                                                       February 20, 2012

  Revised Definition of The GMPLS Switching Capability and Type Fields

                draft-berger-ccamp-swcaps-update-00.txt

Abstract

   GMPLS provides control for multiple switching technologies, and
   hierarchical switching within a technology.  GMPLS routing and
   signaling use common values to indicate switching technology type.
   These values are carried in routing in the Switching Capability
   field, and in signaling in the Switching Type field. While the
   values using 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 any document that uses the
   GMPLS Switching Capability and Types fields, in particular RFC
   3471, RFC 4202, RFC 4203, and RFC 5307.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of 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 August 20, 2012

Berger, et. al.              Standards Track                    [Page 1]
Internet-Draft   draft-berger-ccamp-swcaps-update-00.txt  February 20, 2012

Copyright and License Notice

   Copyright (c) 2012 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 Multi-Protocol 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 been 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.

   In general, a Switching Type does not indicate a specific data plane
   technology, but rather 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

Berger, et. al.              Standards Track                    [Page 2]
Internet-Draft   draft-berger-ccamp-swcaps-update-00.txt  February 20, 2012

   problematic from two perspectives.  The first issue is that there are
   examples of switching technologies were there are 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 issues is that the
   Switching Capability field value is used in routing 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

   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 proposes
   deprecating the use of the Switching Types as an identifier of
   hierarchy levels within a switching technology, and limit its use to
   identification of a per-switching technology SCSI field format. This
   document also defines, for routing, a generic method for identifying
   a hierarchy levels within a switching technology.

   An alternate approach, which is not advocated by this document, is to
   ensure that Switching Types are assigned for all hierarchy levels
   within a switching technology as part of any new work, e.g., as part
   of [GMPLS-G709].

   This document updates any document that uses the GMPLS Switching
   Capability and Switching Type fields, in particular RFCs 3471, 4202,
   4203, and 5307.

1.1. Current Switching Type Definition

   The Switching Type values are carried in both routing and signaling.
   Values are identified in the IANA GMPLS Signaling Parameters
   Switching Type registry, which is currently located at
      http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-
      parameters.xml

Berger, et. al.              Standards Track                    [Page 3]
Internet-Draft   draft-berger-ccamp-swcaps-update-00.txt  February 20, 2012

   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)                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   and

      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
         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].

Berger, et. al.              Standards Track                    [Page 4]
Internet-Draft   draft-berger-ccamp-swcaps-update-00.txt  February 20, 2012

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, i.e., [RFC4202], [RFC4203] and [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 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 should use two different
      Switching Types.  Additionally, a different Switching Type MUST be
      used to indicate 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, that a new Switching Type SHOULD
   be used.

2.2. Signaling -- Switching Type Field

   For signaling, i.e., [RFC3471] which is used by [RFC3473], the
   following definition should be used for 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.

Berger, et. al.              Standards Track                    [Page 5]
Internet-Draft   draft-berger-ccamp-swcaps-update-00.txt  February 20, 2012

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 NOT be treated as reserved values, i.e.,
      SHOULD NOT be generated and SHOULD be ignored upon receipt.

3. Intra-Layer Hierarchy

   [Authors note: This section is for discussion and may be dropped.
   Particularly, need to revisit MLN/IACD/XRO implications to ensure
   there are no gating issues.]

   Multiple switching technologies support forms of hierarchical
   switching within a particular data plane technology.  As discussed
   above, GMPLS routing originally envisioned support for such cases for
   packet networks using PSC-2, 3, 4.  In other cases, GMPLS defined
   support using technology specific mechanisms, for example Signal Type
   was defined for SONET/SDH, see [RFC4606].  Given that one of the
   objectives of GMPLS is to generalize control plane protocols, it is
   reasonable to define a method for supporting hierarchical switching
   within a particular data plane technology that is not specific to any
   particular technology.  This section defines such a mechanism for
   routing.  No additional mechanism is defined for signaling.

   In order to support hierarchical switching within a particular data
   plane technology in routing, this section defines a Intra-Layer
   Hierarchy, or ILH, field.  This field allows for representation of up
   to 15 layers of hierarchical switching.  The ILH field is carried in
   a portion of the previously defined reserved field of the Interface
   Switching Capability Descriptor and has the following format:

       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       |  ILH  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For compatibility reasons, an ILH value of 0 indicates that the ILH
   field is not being used.  The mapping of ILH values to specific
   levels of hierarchy within a data plane technology is specific to
   each switching technology and is therefore outside the scope of this
   document.

Berger, et. al.              Standards Track                    [Page 6]
Internet-Draft   draft-berger-ccamp-swcaps-update-00.txt  February 20, 2012

4. Compatibility

   This document has two impacts on existing implementations.  Both
   routing and signaling impacts must be considered.

   For existing implementations, the primary impact is deprecating the
   use of PSC-2, 3 and 4.  At the time of publication of this document,
   there are no known deployments (or even implementations) that make
   use of these values so there is no compatibility issues for current
   routing and signaling implementations.

   A secondary impact is the use of the previously reserved field of the
   routing Interface Switching Capability Descriptor.  For existing
   routing implementations, this field should be set to all zeros when
   generating a Descriptor, and should be ignored on receipt.
   Furthermore, existing nodes are expected to propagate reserved fields
   without any modification.  Therefore the use of this reserved field
   is not considered to result in any compatibility issues in routing.
   As this field is not used in signaling, there are no signaling
   compatibility issues.

5. Security Considerations

   This document impacts the values carried in a single field in
   signaling and routing.  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].

6. IANA Considerations

   IANA needs to deprecate and redefine the registry.

7. Acknowledgments

   We thank John Drake for highlighting the current inconsistent
   definitions associated with the Switching Capability and Type Fields.

8. References

8.1. Normative References

   [RFC2119] Bradner, S., "RFC Key Words Key words for use in RFCs to
             Indicate Requirement Levels", RFC 2119, March 1997.

Berger, et. al.              Standards Track                    [Page 7]
Internet-Draft   draft-berger-ccamp-swcaps-update-00.txt  February 20, 2012

   [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Functional Description", RFC 3471,
             January 2003.

   [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4202, October 2005.

   [RFC4203] Kompella, K., Rekhter, Y., "OSPF Extensions in Support
             of Generalized Multi-Protocol Label Switching (GMPLS)",
             RFC 4203, October 2005.

   [RFC5307] Kompella, K., Rekhter, Y., "IS-IS Extensions in Support
             of Generalized Multi-Protocol Label Switching (GMPLS)",
             RFC 5307, October 2008.

8.2. Informative References

   [GMPLS-G709] Zhang, F., Li, D., Li, H., Belotti, S., Ceccarelli,
                D., "Framework for GMPLS and PCE Control of G.709
                Optical Transport Networks", work in progress,
                draft-ietf-ccamp-gmpls-g709-framework.

   [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RFC 3473, January
             2003.

   [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
             (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Extensions for G.709 Optical
             Transport Networks Control", RFC 4328, January 2006.

   [RFC4606] Mannie, E., Papadimitriou, D., "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., "Security Framework for MPLS and GMPLS
             Networks", RFC 5920, July 2010.

   [RFC6002] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) Data
             Channel Switching Capable (DCSC) and Channel Set Label
             Extensions", RFC 6002, October 2010.

Berger, et. al.              Standards Track                    [Page 8]
Internet-Draft   draft-berger-ccamp-swcaps-update-00.txt  February 20, 2012

   [RFC6004] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) Support
             for Metro Ethernet Forum and G.8011 Ethernet Service
             Switching", RFC 6004, front 2010.

   [RFC6060] Fedyk, D., Shah, H., Bitar, N., Takacs, A., "Generalized
             Multiprotocol Label Switching (GMPLS) Control of
             Ethernet Provider Backbone Traffic Engineering
             (PBB-TE)", RFC 6060, March 2011.

9. Authors' Addresses

   Lou Berger
   LabN Consulting, L.L.C.
   Phone: +1-301-468-9228
   Email: lberger@labn.net

   Julien Meuric
   France Telecom
   Research & Development
   2, avenue Pierre Marzin
   22307 Lannion Cedex - France
   Phone: +33 2 96 05 28 28
   Email: julien.meuric@orange-ftgroup.com

Berger, et. al.              Standards Track                    [Page 9]
Generated on: Mon, Feb 20, 2012 12:31:51 PM