Network Working Group                                          Dan Li
Internet Draft                                                 Huawei
Updates: RFC4204                                        D. Ceccarelli
Category: Standards Track                                    Ericsson

Expires: April 2011                                   October 11, 2010



           Behavior Negotiation in The Link Management Protocol


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


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 April 11, 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



Li. et al.               Expires April 2011               [Page 1]

 
draft-ietf-ccamp-lmp-behavior-negotiation-01.txt            October 2010


   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 negotiated
   capabilities 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
   2. LMP Behavior Negotiation Procedure ........................... 3
   3. Backwards Compatibility ...................................... 5
   4. Security Considerations ...................................... 5
   5. IANA Considerations .......................................... 6
      5.1. New LMP Class Type ...................................... 6
      5.2. New Capabilities Registry ............................... 6
   6. Contributors ................................................. 7
   7. Acknowledgments .............................................. 7
   8. References ................................................... 7
      8.1. Normative References .................................... 7
      8.2. Informative References .................................. 8
   9. Authors' Addresses ........................................... 8

. Introduction

   The Link Management Protocol (LMP) [RFC4204] is being successfully
   deployed in Generalized Multiprotocol Label Switching (GMPLS)-
   controlled networks. New LMP behaviors and protocol extensions are
   being introduced in a number of IETF documents.

   In the network, if one GMPLS Label Switch Router (LSR) supports a
   new behavior or protocol extension, but its peer LSR does not, it is
   necessary to have a protocol mechanism for resolving issues that may


Li. et al.               Expires April 2011               [Page 2]

 
draft-ietf-ccamp-lmp-behavior-negotiation-01.txt            October 2010


   arise. It is also beneficial to have a protocol mechanism to
   discover the capabilities of peer LSRs. There is no such procedure
   defined in the base LMP specification [RFC4204], so this document
   defines how to handle LMP extensions both at legacy LSRs and at
   upgraded LSRs that would communicate with legacy LSRs.

   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.

   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 to make
   sure both LSRs at the ends of each link understand the LMP messages
   that they exchange.



. LMP Behavior Negotiation Procedure

   The Config message is used in the control channel negotiation phase
   of LMP [RC4204]. 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].



Li. et al.               Expires April 2011               [Page 3]

 
draft-ietf-ccamp-lmp-behavior-negotiation-01.txt            October 2010


   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 extensions to be reported and negotiated.

   - C-Type = 3, BEHAVIOR_CONFIG

   The format of the new type of CONFIG Class is defined as follows:

    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|O|           Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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


Li. et al.               Expires April 2011               [Page 4]

 
draft-ietf-ccamp-lmp-behavior-negotiation-01.txt            October 2010


     O: 1 bit

      This bit indicates support for the TEST behavior of OTN
      technology-specific defined in [LMP TEST].

   Further bits may be defined in future documents.

   The Reserved field MUST be sent as zero and MUST NOT be ignored on
   receipt. This allows the detection of unsupported or unknown LMP
   behaviors when new bits are allocated to indicate further
   capabilities and are sent as one.

   Upon receiving a bit set related to an unsupported or unknown
   behavior, a ConfigNack message MUST be sent with a <CONFIG> object,
   the BEHAVIOR_CONFIG C-Type representing the supported LMP behaviors.
   An LSR receiving such a ConfigNack SHOULD select a supported set of
   capabilities and send a further Config message, or MAY raise an
   alert to the management system (or log an error) and stop trying to
   perform LMP communications with its neighbor.



. Backwards Compatibility

   An LSR that receives a Config message containing a <CONFIG> object
   with a C-Type that it does not recognize MUST respond with a
   ConfigNack message as described in [RFC4204]. Thus, legacy LMP nodes
   that do not support the BEHAVIOR_CONFIG C-Type defined in this
   document will respond with a ConfigNack message.

   It's not explicitly stated in [RFC4204] that a Config Message could
   include multiple <CONFIG> objects. But with new CONFIG C-Types are
   defined, multiple <CONFIG> objects (each with a different Class Type)
   MAY be present on a Config message in which case all of the objects
   MUST be processed.



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

   The operation of the procedures described in this document does 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


Li. et al.               Expires April 2011               [Page 5]

 
draft-ietf-ccamp-lmp-behavior-negotiation-01.txt            October 2010


   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.



. IANA Considerations

5.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       [This.I-D]

5.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> 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:






Li. et al.               Expires April 2011               [Page 6]

 
draft-ietf-ccamp-lmp-behavior-negotiation-01.txt            October 2010


   Bit    | Bit  | Meaning                                | Reference
   Number | Name |                                        |
   -------+------+----------------------------------------+----------
     0    |   B  | Basic LMP behavior support             | [This.ID]
     1    |   S  | SONET/SDH Test support                 | [This.ID]
     2    |   D  | DWDM support                           | [This.ID]
     3    |   C  | Data Channel consistency check support | [This.ID]
     4    |   O  | OTN TEST behavior                      | [This.ID]


. Contributors

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


. Acknowledgments

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



. References

8.1. Normative References

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

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


Li. et al.               Expires April 2011               [Page 7]

 
draft-ietf-ccamp-lmp-behavior-negotiation-01.txt            October 2010


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



. 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
























Li. et al.               Expires April 2011               [Page 8]