doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6898.txt b/doc/rfc/rfc6898.txt
new file mode 100644
index 0000000..5ff854b
--- /dev/null
+++ b/doc/rfc/rfc6898.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                             D. Li
+Request for Comments: 6898                                        Huawei
+Updates: 4204, 4207, 4209, 5818                            D. Ceccarelli
+Category: Standards Track                                       Ericsson
+ISSN: 2070-1721                                                L. Berger
+                                                                    LabN
+                                                              March 2013
+
+
+           Link Management Protocol Behavior Negotiation and
+                      Configuration Modifications
+
+Abstract
+
+   The Link Management Protocol (LMP) is used to coordinate the
+   properties, use, and faults of data links in networks controlled by
+   Generalized Multiprotocol Label Switching (GMPLS).  This document
+   defines an extension to LMP to negotiate capabilities and indicate
+   support for LMP extensions.  The defined extension is compatible with
+   non-supporting implementations.
+
+   This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.
+
+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/rfc6898.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 1]
+
+RFC 6898                LMP Behavior Negotiation              March 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................4
+   2. LMP Message Modifications .......................................4
+      2.1. Modified Message Formats ...................................4
+      2.2. Processing .................................................5
+   3. LMP Behavior Negotiation ........................................6
+      3.1. BehaviorConfig C-Type Format ...............................6
+      3.2. Processing .................................................7
+   4. Backward Compatibility ..........................................7
+   5. Security Considerations .........................................8
+   6. IANA Considerations .............................................9
+      6.1. New LMP Class Type .........................................9
+      6.2. New Capabilities Registry ..................................9
+   7. Normative References ...........................................10
+   8. Acknowledgments ................................................10
+   9. Contributors ...................................................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 2]
+
+RFC 6898                LMP Behavior Negotiation              March 2013
+
+
+1.  Introduction
+
+   The Link Management Protocol (LMP) [RFC4204] has been successfully
+   deployed in networks controlled by Generalized Multiprotocol Label
+   Switching (GMPLS).
+
+   New LMP behaviors and protocol extensions have been introduced in a
+   number of IETF documents, as set out later in this section.  It is
+   likely that future extensions will be made to support additional
+   functions.
+
+   In a network, if one LMP-capable node supports a new behavior or
+   protocol extension but its adjacent node does not, it is beneficial
+   to have a protocol mechanism to discover the capabilities of peer
+   nodes so that the right protocol extensions can be selected and the
+   correct features can be enabled.  There are no such procedures
+   defined in the base LMP specification [RFC4204]. [RFC4209] defined a
+   specific mechanism to identify support for the functions specified in
+   that document.  This document defines an LMP extension to support the
+   identification of supported LMP functions in a generic fashion, as
+   well as how a node supporting these extensions would communicate with
+   legacy nodes.
+
+   In [RFC4204], the basic behaviors have been defined around the use of
+   the standard LMP messages, which include Config, Hello, Verify, Test,
+   LinkSummary, and ChannelStatus.  Per [RFC4204], these behaviors MUST
+   be supported when LMP is implemented, and the message types from 1 to
+   20 have been assigned by IANA for these messages.  Support for all
+   functions required by [RFC4204] is assumed by this document.
+
+   In [RFC4207], the SONET/SDH technology-specific behavior and
+   information for LMP is defined.  The Trace behavior is added to LMP,
+   and the message types from 21 to 31 have been assigned by IANA for
+   the messages that provide the Trace function.
+
+   In [RFC4209], extensions to LMP are defined to allow it to be used
+   between a peer node and an adjacent Optical Line System (OLS).  The
+   LMP object class type and subobject class name have been extended to
+   support Dense Wavelength Division Multiplexing (DWDM) behavior.
+
+   In [RFC5818], the data channel consistency check behavior is defined,
+   and the message types from 32 to 34 have been assigned by IANA for
+   messages that provide this behavior.
+
+   It is likely that future extensions to LMP for other functions or
+   technologies will require the definition of further LMP messages.
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 3]
+
+RFC 6898                LMP Behavior Negotiation              March 2013
+
+
+   This document describes an LMP extension, referred to as behavior
+   negotiation, that enables the nodes at the ends of a link to identify
+   the LMP messages and functions supported by the adjacent node.  The
+   extension makes use of a new CONFIG object.  The use of this new
+   object does not preclude the use of existing or yet to be defined
+   CONFIG objects.
+
+   This document also modifies the format of messages that carry the
+   CONFIG object to allow for multiple objects.  Multiple CONFIG objects
+   allow behavior negotiation concurrent with existing usage of the
+   CONFIG object, i.e., HelloConfig C-Type defined in [RFC4204] and
+   LMP-WDM_CONFIG C-Type defined in [RFC4209].  This document modifies
+   the ConfigAck message to include CONFIG objects so that acceptable
+   parameters are explicitly identified.  It also describes how a node
+   that supports the extensions defined in this document interacts with
+   a legacy LMP-capable node.
+
+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.  LMP Message Modifications
+
+   LMP Config, ConfigNack, and ConfigAck messages are modified by this
+   document to allow for the inclusion of multiple CONFIG objects.  The
+   Config and ConfigNack messages were only defined to carry one CONFIG
+   object in [RFC4204].  The ConfigAck message, which was defined
+   without carrying any CONFIG objects in [RFC4204], is modified to
+   enable explicit identification of negotiated configuration
+   parameters.  The inclusion of CONFIG objects in ConfigAck messages is
+   triggered by the use of the BehaviorConfig object (defined below) in
+   a received Config message.
+
+   The message formats in the sections that follow use Backus-Naur Form
+   (BNF) encoding as defined in [RFC5511].
+
+2.1.  Modified Message Formats
+
+   The format of the Config message as updated by this document is as
+   follows:
+    <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
+                         <LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 4]
+
+RFC 6898                LMP Behavior Negotiation              March 2013
+
+
+   The format of the ConfigAck message as updated by this document is as
+   follows:
+
+    <ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
+                            <REMOTE_CCID> <MESSAGE_ID_ACK>
+                            <REMOTE_NODE_ID>[ <CONFIG> ... ]
+
+   The format of the ConfigNack message as updated by this document is
+   as follows:
+
+    <ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
+                             <LOCAL_NODE_ID>  <REMOTE_CCID>
+                             <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
+                             <CONFIG> [ <CONFIG> ... ]
+
+2.2.  Processing
+
+   Nodes that support the extensions defined in this document MAY
+   include multiple CONFIG objects when sending a Config, ConfigAck, and
+   ConfigNack message.  A maximum of a single object of any particular
+   C-type SHALL be included.  A node that receives a message with
+   multiple CONFIG objects of the same C-type SHALL process the first
+   object of a particular C-type and ignore any subsequent CONFIG
+   objects of the same C-type.  Unless specified as part of the CONFIG
+   object definition, ordering of CONFIG objects with different C-type
+   values is not significant.
+
+   Nodes that support the extensions defined in this document MUST
+   include a BehaviorConfig type object when sending a Config message to
+   a neighbor whose support for the extensions is either known or
+   unknown.  When the neighbor is known to not support the extensions,
+   the object MUST NOT be sent.  Inclusion of other CONFIG objects in a
+   Config message is at the discretion of the message sender and is
+   based on the rules defined as part of CONFIG object definition.
+   Nodes MAY include HelloConfig, LMP-WDM_CONFIG, BehaviorConfig object
+   types in a single message.
+
+   Inclusion of multiple CONFIG objects in a ConfigNack message is based
+   on the processing of a received Config message.  Per [RFC4204],
+   "Parameters where agreement was reached MUST NOT be included in the
+   ConfigNack Message."  As such, a ConfigNack message MUST NOT include
+   CONFIG objects that are acceptable and MUST include any CONFIG
+   objects which are not acceptable.  When a CONFIG object is included
+   in a ConfigNack message, per [RFC4204], the object is to include
+   "acceptable alternate values for negotiable parameters".
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 5]
+
+RFC 6898                LMP Behavior Negotiation              March 2013
+
+
+   When sending a ConfigAck message, nodes supporting the extensions
+   defined in this document MUST include all CONFIG objects received in
+   the corresponding Config message when that message includes a CONFIG
+   object of type BehaviorConfig.
+
+3.  LMP Behavior Negotiation
+
+   The Config message is used in the control channel negotiation phase
+   of LMP [RFC4204].  The LMP behavior negotiation procedure is defined
+   in this document as an addition to this phase.
+
+   The Config message is defined in Section 12.3.1 of [RFC4204] and
+   carries the CONFIG object (class name 6) as defined in Section 13.6
+   of [RFC4204].
+
+   Two class types have been defined:
+
+   - C-Type = 1, HelloConfig, defined in [RFC4204]
+
+   - C-Type = 2, LMP-WDM_CONFIG, defined in [RFC4209]
+
+   This document defines a third C-Type to report and negotiate LMP
+   mechanisms and behaviors.  Its usage indicates support for the
+   extensions defined in this document.
+
+3.1.  BehaviorConfig C-Type Format
+
+   Class = 6
+
+   - C-Type = 3, BehaviorConfig
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |S|D|C|                   Must Be Zero (MBZ)                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Flags:
+
+     S: 1 bit
+
+      This bit indicates support for the Trace behavior of SONET/SDH
+      technology-specific defined in [RFC4207].
+
+     D: 1 bit
+
+      This bit indicates support for the DWDM behavior defined in
+      [RFC4209].
+
+
+
+Li, et al.                   Standards Track                    [Page 6]
+
+RFC 6898                LMP Behavior Negotiation              March 2013
+
+
+     C: 1 bit
+
+      This bit indicates support for the data channel consistency check
+      behavior defined in [RFC5818].
+
+     Must Be Zero (MBZ): Variable length
+
+      The remaining bits in the flags field MUST be set to zero (0).
+      This field MUST be sized to ensure 32-bit alignment of the object.
+
+      Other bits may be defined in future documents, in which case the
+      number of bits in the MBZ field is expected to change.
+
+3.2.  Processing
+
+   The inclusion of a BehaviorConfig type object in a message is
+   discussed above in Section 2.2.
+
+   When sending a BehaviorConfig type object, the N-bit (negotiable) in
+   the LMP object header MUST be set (N=1) in the LMP object header.
+
+   When sending a BehaviorConfig type object in Config and ConfigNack
+   messages, the flags field SHOULD be set based on the supported
+   capabilities of the sending node.  When sending a ConfigAck message,
+   the flags field MUST be set to the value received in the
+   corresponding Config message.
+
+   When receiving a BehaviorConfig type object, the node compares the
+   flags field against its capacities.  Any bit set in the MBZ portion
+   of the flags field MUST be interpreted as unacceptable.  Processing
+   related to unacceptable values in CONFIG objects is defined in
+   [RFC4204] and is not modified by this document.
+
+4.  Backward Compatibility
+
+   The required use of the BehaviorConfig type CONFIG object enables
+   nodes that support the extensions defined in this document to
+   explicitly identify when a neighboring node does not.  When a non-
+   supporting node receives a Config message with the BehaviorConfig
+   type CONFIG object or multiple CONFIG objects, its behavior is to be
+   one of the following behaviors:
+
+   a) Reject the Config message because of the unknown BehaviorConfig
+      object type and send a ConfigNack message which includes the
+      unsupported C-type.
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 7]
+
+RFC 6898                LMP Behavior Negotiation              March 2013
+
+
+   b) Reject the message because of multiple CONFIG objects and send a
+      ConfigNack message which includes all but one of the CONFIG
+      objects.
+
+   c) Silently ignore the one or more of the CONFIG object, and respond
+      with a ConfigAck message that does not include any CONFIG objects.
+
+   d) Treat the message as malformed, and discard it without any
+      response.
+
+   Behaviors (a) and (b) result in ConfigNack messages with a
+   BehaviorConfig type object whose contents are identical to what was
+   sent in the Config message.  Behavior (c) results in a ConfigAck
+   message without a BehaviorConfig type CONFIG object.  In each of
+   these cases, the node SHOULD explicitly identify that the LMP
+   neighbor does not support the extensions defined in this document.
+
+   Behavior (d) results in no response at all.  When the node reaches
+   the "retry limit", defined in [RFC4204], the node SHOULD infer that
+   the LMP neighbor does not support the extensions defined in this
+   document.
+
+   Once a node identifies a neighbor as not supporting the extensions
+   defined in this document, the node SHOULD follow previously defined
+   Config message usage.
+
+5.  Security Considerations
+
+   [RFC4204] describes how LMP messages between peers can be secured,
+   and these measures are equally applicable to messages carrying the
+   new CONFIG object defined in this document.
+
+   Alone, the procedures described in this document do not constitute a
+   security risk, since they do not cause any change in network state.
+   It would be possible, if the messages were intercepted or spoofed to
+   cause bogus alerts in the management plane, or to cause LMP peers to
+   consider that they could or could not operate protocol extensions,
+   and so the use of the LMP security measures are RECOMMENDED.
+
+   Note, however, that [RFC4204] references for security have been
+   updated with [RFC4301], and the current reference for IKEv2 is
+   [RFC5996].
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 8]
+
+RFC 6898                LMP Behavior Negotiation              March 2013
+
+
+6.  IANA Considerations
+
+6.1.  New LMP Class Type
+
+   IANA maintains the "Link Management Protocol (LMP) Parameters"
+   registry, which has a subregistry called "LMP Object Class name space
+   and Class type (C-Type)".
+
+   IANA has made an assignment from this registry as follows:
+
+      6   CONFIG                              [RFC4204]
+
+   CONFIG Object Class type name space:
+
+      C-Type        Description            Reference
+      ------------  ---------------------  ---------
+      3             BehaviorConfig         RFC 6898
+
+6.2.  New Capabilities Registry
+
+   IANA has created a new subregistry of the "Link Management Protocol
+   (LMP) Parameters" registry to track the Behavior Configuration bits
+   defined in Section 2 of this document.  This registry is called "LMP
+   Behavior Configuration Flags".
+
+   Allocations from this registry are by Standards Action.
+
+   Bits in this registry are numbered from zero as the most significant
+   bit (transmitted first).  The number of bits that can be present is
+   limited by the length field of the CONFIG object, which gives rise to
+   (255 x 32)-8 = 8152.  IANA is strongly recommended to allocate new
+   bits with the lowest available unused number.
+
+   The registry is initially populated as follows:
+
+      Bit    | Bit  | Meaning                                | Reference
+      Number | Name |                                        |
+      -------+------+----------------------------------------+----------
+        0    |   S  | SONET/SDH Test support                 | RFC 6898
+        1    |   D  | DWDM support                           | RFC 6898
+        2    |   C  | Data Channel consistency check support | RFC 6898
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 9]
+
+RFC 6898                LMP Behavior Negotiation              March 2013
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
+              5996, September 2010.
+
+   [RFC4204]  Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
+              October 2005.
+
+   [RFC4207]  Lang, J. and D. Papadimitriou, "Synchronous Optical
+              Network (SONET)/Synchronous Digital Hierarchy (SDH)
+              Encoding for Link Management Protocol (LMP) Test
+              Messages", RFC 4207, October 2005.
+
+   [RFC4209]  Fredette, A., Ed., and J. Lang, Ed., "Link Management
+              Protocol (LMP) for Dense Wavelength Division Multiplexing
+              (DWDM) Optical Line Systems", RFC 4209, October 2005.
+
+   [RFC5818]  Li, D., Xu, H., Bardalai, S., Meuric, J., and D. Caviglia,
+              "Data Channel Status Confirmation Extensions for the Link
+              Management Protocol", RFC 5818, April 2010.
+
+   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+              Used to Form Encoding Rules in Various Routing Protocol
+              Specifications", RFC 5511, April 2009.
+
+8.  Acknowledgments
+
+   Thanks to Adrian Farrel and Richard Graveman for their useful
+   comments.
+
+9.  Contributors
+
+   Diego Caviglia
+   Ericsson
+   Via E. Melen, 77
+   Genova - Erzelli
+   Italy
+   Phone: +39 010 600 3736
+   EMail: diego.caviglia@ericsson.com
+
+
+
+
+
+Li, et al.                   Standards Track                   [Page 10]
+
+RFC 6898                LMP Behavior Negotiation              March 2013
+
+
+Authors' Addresses
+
+   Dan Li
+   Huawei Technologies
+   F3-5-B R&D Center, Huawei Industrial Base,
+   Shenzhen 518129
+   China
+   Phone: +86 755-289-70230
+   EMail: huawei.danli@huawei.com
+
+   Daniele Ceccarelli
+   Ericsson
+   Via E. Melen, 77
+   Genova - Erzelli
+   Italy
+   EMail: daniele.ceccarelli@ericsson.com
+
+   Lou Berger
+   LabN Consulting, L.L.C.
+   EMail: lberger@labn.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                   [Page 11]
+