Network Working Group                                          Dan Li
Internet Draft                                                 Huawei
Updates: RFC4204 4204, 4207,4209, 5818                          D. Ceccarelli
Category: Standards Track                                    Ericsson
                                                           Lou Berger
                                                                 LabN

Expires: October December 2011                                   April                                   June 7, 2011

             Link Management Protocol Behavior Negotiation in and
                       Configuration Modifications

             draft-ietf-ccamp-lmp-behavior-negotiation-04.txt

Abstract

   The Link Management Protocol

             draft-ietf-ccamp-lmp-behavior-negotiation-03.txt (LMP) is used to coordinate the
   properties, use, and faults of data links in Generalized
   Multiprotocol Label Switching (GMPLS) networks. 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.

Status of this Memo

   This Internet-Draft is submitted to IETF 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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on October December 7, 2011.

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.

Abstract

   The Link Management Protocol (LMP) is used to coordinate the
   properties, use, and faults of data links in Generalized
   Multiprotocol Label Switching (GMPLS) networks. Various proposals
   have been advanced to provide extensions to the base LMP
   specification. This document defines an extension to negotiate
   capabilities and support for those extensions, and provides a
   generic procedure for LMP implementations that do not recognize or
   do not support any one of these extensions.

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

Table of Contents

   1. Introduction ................................................ 2 3
   2. LMP Behavior Negotiation Procedure........................... 3 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....................................... 5
   4. 7
   5. Security Considerations...................................... 6
   5. 8
   6. IANA Considerations ......................................... 7
      5.1. 9
      6.1. New LMP Class Type...................................... 7
      5.2. 9
      6.2. New Capabilities Registry............................... 7
   6. Contributors ................................................ 8 9
   7. Acknowledgments ............................................. 8 Contributors ............................................... 10
   8. Acknowledgments ............................................ 10
   9. References .................................................. 8
      8.1. ................................................. 10
      9.1. Normative References.................................... 8
      8.2. References................................... 10
      9.2. Informative References.................................. 9
   9. References................................. 11
   10. Authors' Addresses .......................................... 9 ........................................ 11

1. Introduction

   The Link Management Protocol (LMP) [RFC4204] has been successfully
   deployed in Generalized Multiprotocol Label Switching (GMPLS)-
   controlled networks.

   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 the a network, if one GMPLS Label Switch Router (LSR) LMP node supports a new behavior or protocol extension,
   extension but its peer LSR adjacent node does not, it is
   necessary to have a protocol mechanism for resolving issues that may
   arise. It is also beneficial to have a
   protocol mechanism to discover the capabilities of peer LSRs 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], so this [RFC4204]. [RFC4209] defined a specific
   mechanism to identify support for the functions defined in that
   document. This document defines how an LMP extension to handle support the
   identification of supported LMP functions in a generic fashion, as
   well as how a node supporting these extensions
   both at legacy LSRs and at upgraded LSRs that would communicate
   with legacy LSRs. 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 [RCF4204], 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 were assigned by IANA for the
   messages that provide the TRACE function. The Trace function has
   been extended for the support of OTNs (Optical Transport Networks)
   in [LMP-TEST].

   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 sub-object class name have been extended
   to support 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.

   This document describes the behavior negotiation procedure an LMP extension, which is referred to make
   sure both LSRs as
   behavior negotiation, which enables nodes at the ends of each a link understand 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 object.

   This document also modifies the format of messages that carry 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
   which supports the extensions defined in this document interacts
   with a legacy LMP node.

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

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

   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 which 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 which 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 is not significant.

   Nodes which 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 LMP messages extensions is either known or
   unknown. (But not when the neighbor is known to not support the
   extensions.) Inclusion of other CONFIG objects in a Config message
   is at the discretion of the message sender, and is based on the
   rules defined by 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 which 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".

   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 they exchange.

2. message includes a CONFIG
   object of type BehaviorConfig.

3. LMP Behavior Negotiation Procedure

   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> 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 with value 3 (TBD by IANA) to report and negotiate currently defined LMP
   mechanisms and behaviors,
   and to allow future LMP behaviors. Its usage indicates support for the
   extensions to be reported and negotiated. defined in this document.

3.1. BehaviorConfig C-Type Format

   Class = 6

   - C-Type = 3, BEHAVIOR_CONFIG

   The format of the new type of CONFIG Class is defined as follows: (To be assigned by IANA), 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     |B|S|D|C|            MUST_BE_ZERO
   |S|D|C|                   Must Be Zero (MBZ)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 8 bits

      This field indicates the total length of the objects expressed in
      multiples of 4 bytes.

   Flags:

     B: 1 bit

      This bit indicates support for the basic behaviors defined in
     [RFC4204].

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

     C: 1 bit

      This bit indicates support for the data channel consistency check
      behavior defined in [RFC5818].

   Further

     Must Be Zero (MBZ): Variable length

      The remaining bits may be defined in future documents.

   The MUST_BE_ZERO the flags field MUST be sent as set to zero (0).
      The number of bits present is based on the Length field of the
      LMP object header and MUST NOT include enough bits so the Length
      field MUST be ignored
   on receipt. This allows at least 8, and MUST be a multiple of 4.

      Other bits may be defined in future documents, in which case the detection
      number of unsupported or unknown LMP
   behaviors when new MBZ bits are allocated field is expected to indicate further
   capabilities and are sent as one.

   Upon receiving change.

3.2. Processing

   The inclusion of a bit set related to an unsupported or unknown
   behavior, BehaviorConfig type object in a ConfigNack message MUST be sent with is
   discussed above in Section 2.2.

   When sending a <CONFIG> BehaviorConfig type object, the BEHAVIOR_CONFIG C-Type representing N-bit (negotiable) in
   the supported LMP behaviors.
   An LSR receiving such a ConfigNack SHOULD select a supported object header must be set of
   capabilities and send a further Config message, or MAY raise an
   alert to (N=1) in the management system (or log an error) and stop trying to
   perform LMP communications with its neighbor.

   Note that multiple <CONFIG> objects (each with a different Class
   Type) MAY be present on object header.

   When sending a Config message BehaviorConfig type object in which case all of Config and ConfigNack
   messages, the
   objects flags field SHOULD be processed, but see the note set based on backward
   compatibility in the next section. However, if more than one
   <CONFIG> object with supported
   capabilities of the same Class Type is present on sending node. When sending a Config ConfigAck message,
   the message SHOULD flags field MUST be rejected.

3. Backward Compatibility

   An LSR that receives a set to the value received in the
   corresponding Config message containing a <CONFIG> object
   with a C-Type that it does not recognize should respond with message.

   When receiving a
   ConfigNack message 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 described unacceptable. Processing
   related to unacceptable values in [RFC4204]. Thus, legacy LMP nodes
   that do 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 which support the BEHAVIOR_CONFIG C-Type extensions defined in this document will respond with to
   explicitly identify when a ConfigNack message.

   Note that [RFC4204] neighboring node does not describe how multiple <CONFIG> objects
   with different C-Types should be processed. Thus it is possible that not. When a legacy non-
   supporting node receiving a BEHAVIOR_CONFIG object on receives a Config message
   that also includes a HelloConfig or LMP_WDM_CONFIG object might
   react as follows:

   - with the BehaviorConfig
   type CONFIG object or multiple CONFIG objects its behavior is likely
   to be one of the following behaviors:

   a) Reject the Config message because of the unknown BEHAVIOR_CONFIG BehaviorConfig
      object
      as described above.

   - type and send a ConfigNack message which includes the
      unsupported C-type.

   b) Reject the message because of multiple <CONFIG> objects. This
      achieves the same effective result.

   - Ignore the second <CONFIG> object. This would result in the
      BEHAVIOR_CONFIG object being unprocessed CONFIG objects and also not rejected.

   An LSR that receives send a
      ConfigNack message rejecting which includes all but one of the CONFIG
      objects.

   c) Silently ignore the one or more of the CONFIG object, and respond
      with a Config 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 containing in the BEHAVIOR Config message.  Behavior (c) results in a ConfigAck
   message without a BehaviorConfig type CONFIG C-Type because object. In each of
   these cases, the node SHOULD explicitly identify that
   object variant is not supported by its peer MUST NOT draw any
   conclusions about the level of LMP
   neighbor does not support the extensions defined in this document.

   Behavior (d) results in no response at all. When the peer for LMP options
   described by bits B, S, D, and C. Instead, node reaches
   the, [RFC4204] defined, "retry limit", the LSR MUST revert to
   current practices of configuration or discovery through attempts to
   exercise node SHOULD infer that
   the options.

   However, as future documents are published describing new LMP
   features, and those documents require neighbor does not support of the BEHAVIOR CONFIG
   C-Type, an LSR that receives extensions defined in this
   document.

   Once a ConfigNack message rejecting node identifies a Config
   message that it sent containing the BEHAVIOR CONFIG C-Type because
   that object variant is neighbor as not supported by its peer SHOULD conclude
   that supporting the additional options it wants to use are not supported by extensions
   defined in this document, the
   peer.

4. 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> CONFIG object defined in this document.

   The operation of the procedures described in this document does do not of itself
   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] refers to [RFC2401], which has been
   replaced by [RFC4301]. Also, the reference to IKEv2 in [RFC4301] is
   out of date, and the current reference for IKEv2 is [RFC5996].

5.

6. IANA Considerations

5.1.

6.1. New LMP Class Type

   IANA maintains the "Link Management Protocol (LMP)" registry which
   has a subregistry called "LMP Object Class name space and Class type
   (C-Type)".

   IANA is requested to make an assignment from this registry as
   follows:

      6   CONFIG                              [RFC4204]

   CONFIG Object Class type name space:

   C-Type        Description            Reference
   ------   ------------------------
   ------------  ---------------------  ---------
        3   BEHAVIOR_CONFIG
   3(suggested)  BehaviorConfig        [This.I-D]

5.2.

6.2. New Capabilities Registry

   IANA is requested to create a new subregistry of the "Link
   Management Protocol (LMP)" registry to track the Behaviour
   Configuration bits defined in Section 2 of this document. It is
   suggested that this registry be called "LMP Behaviour 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> 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    |   B  | Basic LMP behavior support             | [This.ID]
     1    |   S  | SONET/SDH Test support                 | [This.ID]
     2
     1    |   D  | DWDM support                           | [This.ID]
     3
     2    |   C  | Data Channel consistency check support | [This.ID]

6.

7. Contributors

   Diego Caviglia
   Ericsson
   Via A. Negrone 1/A 16153
   Genoa Italy
   Phone: +39 010 600 3736
   Email: diego.caviglia@ericsson.com

7.

8. Acknowledgments

   Thanks to Adrian Farrel, Lou Berger Farrel and Richard Graveman for their useful
   comments.

8.

9. References

8.1.

9.1. Normative References

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

   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
             Internet Protocol", RFC 4301, December 2005

   [RFC5996] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, "Internet Key
             Exchange Protocol: IKEv2", RFC 5996, September 2010.

   [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204,
             October 2005.

   [RFC4207] J. Lang, Ed., "Synchronous Optical Network (SONET)/
             Synchronous Digital Hierarchy (SDH) Encoding for Link
             Management Protocol (LMP) Test Messages", RFC 4207,
             October 2005.

   [RFC4209] A. Fredette, Ed., "Link Management Protocol (LMP) for
             Dense Wavelength Division Multiplexing (DWDM) Optical Line
             Systems", RFC 4209, October 2005.

   [RFC5818] D. Li, Ed., "Data Channel Status Confirmation Extensions
             for the Link Management Protocol", RFC 5818, April 2010.

8.2.

9.2. Informative References

   [LMP TEST] D. Ceccarelli, Ed., "Link Management Protocol (LMP) Test
             Messages Extensions for Evolutive Optical Transport
             Networks (OTN)" draft-ceccarelli-ccamp-gmpls-g709-lmp-
             test-02.txt, May, 2010.

9.

10. Authors' Addresses

      Dan Li
      Huawei Technologies
      F3-5-B R&D Center, Huawei Industrial Base,
      Shenzhen 518129 China
      Phone: +86 755-289-70230
      Email: danli@huawei.com

      Daniele Ceccarelli
      Ericsson
      Via A. Negrone 1/A
      Genova - Sestri Ponente
      Italy
      Email: daniele.ceccarelli@ericsson.com

     Lou Berger
     LabN Consulting, L.L.C.
      Email: lberger@labn.net