doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc6002.txt b/doc/rfc/rfc6002.txt
new file mode 100644
index 0000000..e84157e
--- /dev/null
+++ b/doc/rfc/rfc6002.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         L. Berger
+Request for Comments: 6002                                          LabN
+Updates: 3471, 3473, 3945, 4202, 4203, 5307                     D. Fedyk
+Category: Standards Track                                 Alcatel-Lucent
+ISSN: 2070-1721                                             October 2010
+
+
+     Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC)
+                    and Channel Set Label Extensions
+
+Abstract
+
+   This document describes two technology-independent extensions to
+   Generalized Multi-Protocol Label Switching (GMPLS).  The first
+   extension defines the new switching type Data Channel Switching
+   Capable.  Data Channel Switching Capable interfaces are able to
+   support switching of the whole digital channel presented on single
+   channel interfaces.  The second extension defines a new type of
+   generalized label and updates related objects.  The new label is
+   called the Generalized Channel_Set Label and allows more than one
+   data plane label to be controlled as part of a Label Switched Path
+   (LSP).
+
+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/rfc6002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 1]
+
+RFC 6002              GMPLS DCSC Channel Extensions         October 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................3
+   2. Data Channel Switching ..........................................3
+      2.1. Compatibility ..............................................4
+   3. Generalized Channel_Set Label Related Formats ...................4
+      3.1. Generalized Channel_Set LABEL_REQUEST Object ...............4
+      3.2. Generalized Channel_Set LABEL Object .......................4
+      3.3. Other Label-Related Objects ................................7
+      3.4. Compatibility ..............................................7
+   4. IANA Considerations .............................................8
+      4.1. Data Channel Switching Type ................................8
+      4.2. Generalized Channel_Set LABEL_REQUEST Object ...............8
+      4.3. Generalized Channel_Set LABEL Object .......................8
+   5. Security Considerations .........................................9
+   6. References ......................................................9
+      6.1. Normative References .......................................9
+      6.2. Informative References ....................................10
+   Acknowledgments ...................................................10
+
+1.  Introduction
+
+   This document describes two technology-independent extensions to
+   Generalized Multi-Protocol Label Switching (GMPLS).  Both of these
+   extensions were initially defined in the context of Ethernet
+   services, see [RFC6004] and [RFC6005], but are generic in nature and
+   may be useful to any switching technology controlled via GMPLS.
+
+   The first extension defines a new switching type, which is called
+   Data Channel Switching Capable (DCSC).  DCSC interfaces are able to
+   support switching of the whole digital channel presented on single
+   channel interfaces.  The second extension defines a new type of
+
+
+
+Berger & Fedyk               Standards Track                    [Page 2]
+
+RFC 6002              GMPLS DCSC Channel Extensions         October 2010
+
+
+   generalized label and updates related objects.  The new label is
+   called the Generalized Channel_Set Label and allows more than one
+   data plane label to be controlled as part of a GMPLS Label Switched
+   Path (LSP).
+
+1.1.  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.  Data Channel Switching
+
+   Current GMPLS switching types are defined in [RFC3945] and [RFC3471]
+   and support switching at the packet (PSC), frame (L2SC), time-slot
+   (TDM), frequency (LSC), and fiber (FSC) granularities.  Parallel
+   definitions for these switching types are also made in [RFC4202],
+   [RFC4203], and [RFC5307].
+
+   One type of switching that is not well represented in this current
+   set is switching that occurs when all data received on an ingress
+   port is switched through a network to an egress port.  While there
+   are similarities between this level of switching and the "opaque
+   single wavelength" case, described in Section 3.5 of [RFC4202], such
+   port-to-port switching is not limited to the optical switching
+   technology implied by the LSC type.  FSC is also similar, but it is
+   restricted to fiber ports and also supports multiple data channels
+   within a fiber port.
+
+   This document defines a new switching type called Data Channel
+   Switching Capable (DCSC).  Port switching seems a more intuitive
+   name, but this naming collides with PSC so is not used.  DCSC
+   interfaces are able to support switching of the whole digital channel
+   presented on single channel interfaces.  Interfaces that inherently
+   support multiple channels, e.g., Wavelength Division Multiplexing
+   (WDM) and channelized TDM interfaces, are specifically excluded from
+   this type.  Any interface that can be represented as a single digital
+   channel are included.  Examples include concatenated TDM and line-
+   encoded interfaces.  Framed interfaces may also be included when they
+   support switching on an interface granularity, for example Ethernet
+   terminated at the physical (port) level and all traffic received on a
+   port is switched to a physical port at the LSP egress.
+
+   DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the
+   value 125.  The DCSC value is carried in routing protocols in the
+   Interface Switching Capability Descriptor defined in [RFC4202], and
+   used in OSPF [RFC4203] and IS-IS [RFC5307].  These documents are not
+   otherwise modified by this document.
+
+
+
+Berger & Fedyk               Standards Track                    [Page 3]
+
+RFC 6002              GMPLS DCSC Channel Extensions         October 2010
+
+
+   The DCSC Switching Type may be used with the Generalized Label
+   Request object, [RFC3473], or the Generalized Channel_Set
+   LABEL_REQUEST object defined below.  Port labels, as defined in
+   [RFC3471], SHOULD be used for LSPs signaled using the DCSC Switching
+   Type.
+
+2.1.  Compatibility
+
+   Transit and egress nodes that do not support the DCSC Switching Type
+   when receiving a Path message with a Label Request containing the
+   DCSC Switching Type will behave in the same way nodes generally
+   handle the case of an unsupported Switching Type.  Specifically, per
+   [RFC3473], such nodes are required to generate a PathErr message,
+   with a "Routing problem/Unsupported Encoding" indication.
+
+   Ingress nodes initiating a Path message containing a Label Request
+   containing the DCSC Switching Type, receiving such a PathErr
+   messages, then notify the requesting application user as appropriate.
+
+3.  Generalized Channel_Set Label Related Formats
+
+   This section defines a new type of generalized label and updates
+   related objects.  This section updates the label-related definitions
+   of [RFC3473].  The ability to communicate more than one label as part
+   of the same LSP was motivated by the support for the communication of
+   one or more VLAN IDs.  Simple concatenation of labels as is done in
+   [RFC4606] was deemed impractical given the large number of VLAN IDs
+   (up to 4096) that may need to be communicated.  The formats defined
+   in this section are not technology specific and may be useful for
+   other switching technologies.  The LABEL_SET object defined in
+   [RFC3473] serves as the foundation for the defined formats.
+
+3.1.  Generalized Channel_Set LABEL_REQUEST Object
+
+   The Generalized Channel_Set LABEL_REQUEST object is used to indicate
+   that the Generalized Channel_Set LABEL object is to be used with the
+   associated LSP.  The format of the Generalized Channel_Set
+   LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST
+   object and uses a C-Type of 5.
+
+3.2.  Generalized Channel_Set LABEL Object
+
+   The Generalized Channel_Set LABEL Object communicates one or more
+   labels, all of which can be used equivalently in the data path
+   associated with a single LSP.  The format of the Generalized
+   Channel_Set LABEL Object is based on the LABEL_SET object defined in
+   [RFC3473].  It differs from the LABEL_SET object in that the full set
+   may be represented in a single object rather than the multiple
+
+
+
+Berger & Fedyk               Standards Track                    [Page 4]
+
+RFC 6002              GMPLS DCSC Channel Extensions         October 2010
+
+
+   objects required by the [RFC3473] LABEL_SET object.  The object MUST
+   be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST
+   object.  The object MUST be processed per [RFC3473].  Make-before-
+   break procedures, see [RFC3209], SHOULD be used when modifying the
+   Channel_Set LABEL object.
+
+   The format of the Generalized Channel_Set LABEL object is:
+
+   o  Generalized Channel_Set LABEL object: Class = 16, C-Type = 4
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   Channel_Set Subobject 1                     |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      :                               :                               :
+      :                               :                               :
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   Channel_Set Subobject N                     |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Channel_Set Subobject size is measured in bytes and MUST always
+   be a multiple of 4, and at least 4, 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Action     |  Num Subchannels  |        Label Type         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Subchannel 1                         |
+      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       ...                     |                               :
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               :
+      :                               :                               :
+      :                               :                               :
+      :                               :                               :
+      :                               :                               :
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Subchannel N                         |
+      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           ...                 |         Padding               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 5]
+
+RFC 6002              GMPLS DCSC Channel Extensions         October 2010
+
+
+   Action: 8 bits
+
+      See [RFC3471] for definition of actions.  Range actions SHOULD be
+      used when possible to minimize the size of the Channel_Set LABEL
+      Object.
+
+   Number of Subchannels: 10 bits
+
+      Indicates the number of subchannels carried in the subobject.
+      When the number of subchannels required exceeds the limit of the
+      field, i.e., 1024, multiple Channel_Set Subobjects MUST be used.
+      Note that the size of the subobject may result in a Path message
+      being larger than a single unfragmented IP packet.  See Section
+      4.4 of [RFC6004] for an example of how this case may be handled.
+
+      A value of zero (0) has special meaning and MAY be used in either
+      the LABEL or UPSTREAM_LABEL object.  A value of zero (0) is used
+      in a LABEL or UPSTREAM_LABEL object to indicate that the
+      subchannel(s) used in the corresponding (downstream or upstream)
+      direction MUST match the subchannel(s) carried in the reverse
+      directions label object.  When value of zero (0) is used, no
+      subchannels are included in the Channel_Set Subobject and only one
+      Channel_Set Subobject may be present.  The zero (0) value MUST NOT
+      be used in both the LABEL and UPSTREAM_LABEL objects of the same
+      LSP.  Note that unacceptable label values continue to be handled
+      according to [RFC3209] and [RFC3473], i.e., they result in PathErr
+      or ResvErr messages with a "Routing problem/Unacceptable label
+      value" indication.  For example, in the case where a Resv message
+      containing a zero (0) in both the LABEL and UPSTREAM_LABEL objects
+      is received, the node would generate a ResvErr message.
+
+   Label Type: 14 bits
+
+      See [RFC3473] for a description of this field.
+
+   Subchannel: Variable
+
+      See [RFC3471] for a description of this field.  Note that this
+      field might not be 32-bit aligned.
+
+   Padding: Variable
+
+      Padding is used to ensure that the length of a Channel_Set
+      Subobject meets the multiple of 4 byte size requirement stated
+      above.  The field is only required when the Subchannel field is
+      not 32-bit aligned and the number of included Subchannel fields
+      result in the Subobject not being 32-bit aligned.
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 6]
+
+RFC 6002              GMPLS DCSC Channel Extensions         October 2010
+
+
+      The Padding field MUST be included when the number of bits
+      represented in all the Subchannel fields included in a Generalized
+      Channel_Set Subobject result in the Subobject not being 32-bit
+      aligned.  When present, the Padding field MUST have a length that
+      results in the Subobject being 32-bit aligned.  When present, the
+      Padding field MUST be set to a zero (0) value on transmission and
+      MUST be ignored on receipt.  These bits SHOULD be passed through
+      unmodified by transit nodes.
+
+      Note that the overall length of a Channel_Set Subobject is
+      determined based on the value of the Num Subchannels field
+      together with the size of each Subchannel field as well as any
+      required padding.  The size of the Subchannel field is uniquely
+      identified by the Label Type field.
+
+3.3.  Other Label-Related Objects
+
+   The previous section introduced a new LABEL object.  As such the
+   formats of the other label-related objects and subobjects are also
+   impacted.  Processing of these objects and subobjects is not modified
+   and remains per their respective specifications.  The other label
+   related objects and subobjects are defined in [RFC3473] and include:
+
+      - SUGGESTED_LABEL object
+      - LABEL_SET object
+      - ACCEPTABLE_LABEL_SET object
+      - UPSTREAM_LABEL object
+      - RECOVERY_LABEL object
+      - Label ERO subobject
+      - Label RRO subobject
+
+   The label-related objects and subobjects each contain a Label field,
+   all of which may carry any label type.  As any label type may be
+   carried, the introduction of a new label type means that the new
+   label type may be carried in the Label field of each of the label-
+   related objects and subobjects.  No new definition needs to specified
+   as their original specification is label-type agnostic.
+
+3.4.  Compatibility
+
+   Transit and egress nodes that do not support the Generalized
+   Channel_Set Label related formats will first receive a Path message
+   containing Generalized Channel_Set LABEL_REQUEST object.  When such a
+   node receives the Path message, per [RFC3209], it will send a PathErr
+   with the error code "Unknown object C_Type".
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 7]
+
+RFC 6002              GMPLS DCSC Channel Extensions         October 2010
+
+
+   Ingress nodes initiating a Path message containing a Generalized
+   Channel_Set LABEL_REQUEST object on receiving such a PathErr
+   messages, then notify the requesting application user as appropriate.
+
+4.  IANA Considerations
+
+   IANA has assigned new values for namespaces defined in this document
+   and summarized in this section.  The registries are available from
+   http://www.iana.org.
+
+4.1.  Data Channel Switching Type
+
+   IANA has made the following assignment in the "Switching Types"
+   section of the "GMPLS Signaling Parameters" registry.
+
+      Value   Type                                   Reference
+      -----   ------------------------------------   ---------
+        125   Data Channel Switching Capable (DCSC)  [RFC6002]
+
+   The assigned value is reflected in IANAGmplsSwitchingTypeTC of the
+   IANA-GMPLS-TC-MIB available from http://www.iana.org.
+
+4.2.  Generalized Channel_Set LABEL_REQUEST Object
+
+   IANA has made the following assignment in the "Class Names, Class
+   Numbers, and Class Types" section of the "RSVP PARAMETERS" registry.
+
+   A new class type for the existing LABEL_REQUEST Object class number
+   (19) with the following definition:
+
+      Class Types or C-Types:
+
+        5 Generalized Channel_Set                  [RFC6002]
+
+4.3.  Generalized Channel_Set LABEL Object
+
+   IANA has made the following assignment in the "Class Names, Class
+   Numbers, and Class Types" section of the "RSVP PARAMETERS" registry.
+
+   A new class type for the existing RSVP_LABEL Object class number (16)
+   with the following definition:
+
+      Class Types or C-Types:
+
+        4 Generalized Channel_Set                  [RFC6002]
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 8]
+
+RFC 6002              GMPLS DCSC Channel Extensions         October 2010
+
+
+5.  Security Considerations
+
+   This document introduces new message object formats for use in GMPLS
+   signaling [RFC3473].  It does not introduce any new signaling
+   messages, nor change the relationship between LSRs that are adjacent
+   in the control plane.  As such, this document introduces no
+   additional security considerations.  See [RFC3473] for relevant
+   security considerations.  Additionally, the existing framework for
+   MPLS and GMPLS security is documented in [RFC5920].
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, December 2001.
+
+   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Functional Description", RFC
+              3471, January 2003.
+
+   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation Protocol-
+              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+              January 2003.
+
+   [RFC3945]  Mannie, E., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Architecture", RFC 3945, October 2004.
+
+   [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.
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 9]
+
+RFC 6002              GMPLS DCSC Channel Extensions         October 2010
+
+
+6.2.  Informative References
+
+   [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.
+
+   [RFC6004]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support
+              for Metro Ethernet Forum and G.8011 Ethernet Service
+              Switching", RFC 6004, October 2010.
+
+   [RFC6005]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support
+              for Metro Ethernet Forum and G.8011 User Network Interface
+              (UNI)", RFC 6005, October 2010.
+
+Acknowledgments
+
+   Dimitri Papadimitriou provided substantial textual contributions to
+   this document and coauthored earlier versions of this document.
+
+   The authors would like to thank Evelyne Roch, Stephen Shew, and
+   Adrian Farrel for their valuable comments.
+
+Authors' Addresses
+
+   Lou Berger
+   LabN Consulting, L.L.C.
+   Phone: +1-301-468-9228
+   EMail: lberger@labn.net
+
+   Don Fedyk
+   Alcatel-Lucent
+   Groton, MA, 01450
+   Phone: +1-978-467-5645
+   EMail: donald.fedyk@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                   [Page 10]
+