Network Working Group                                          Dan Li 
Internet Draft                                                 Huawei 
Updates: RFC4204                                        D. Ceccarelli 
Category: Standards Track                                    Ericsson 
 
Expires: September 2011                                March 14, 2011 
                                      


           Behavior Negotiation in The Link Management Protocol 


             draft-ietf-ccamp-lmp-behavior-negotiation-02.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 September 13, 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 September 2011               [Page 1] 

draft-ietf-ccamp-lmp-behavior-negotiation-02.txt            March 2011 
    

   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 
   2. LMP Behavior Negotiation Procedure........................... 3 
   3. Backward Compatibility....................................... 5 
   4. Security Considerations...................................... 6 
   5. IANA Considerations ......................................... 6 
      5.1. New LMP Class Type...................................... 6 
      5.2. New Capabilities Registry............................... 7 
   6. Contributors ................................................ 7 
   7. Acknowledgments ............................................. 8 
   8. References .................................................. 8 
      8.1. Normative References.................................... 8 
      8.2. Informative References.................................. 8 
   9. Authors' Addresses .......................................... 9 
    
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. 
 
 
Li. et al.               Expires September 2011               [Page 2] 

draft-ietf-ccamp-lmp-behavior-negotiation-02.txt            March 2011 
    

   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 
   arise. It is also beneficial to have a protocol mechanism to 
   discover the capabilities of peer LSRs so that the right protocol 
   extensions can be selected and the correct features enabled. There 
   are no such procedures 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. 

    

2. 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. 
 
 
Li. et al.               Expires September 2011               [Page 3] 

draft-ietf-ccamp-lmp-behavior-negotiation-02.txt            March 2011 
    

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

 
 
Li. et al.               Expires September 2011               [Page 4] 

draft-ietf-ccamp-lmp-behavior-negotiation-02.txt            March 2011 
    

     C: 1 bit 

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

   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. 

   Note that multiple <CONFIG> objects (each with a different Class 
   Type) MAY be present on a Config message in which case all of the 
   objects SHOULD be processed, but see the note on backward 
   compatibility in the next section. However, if more than one 
   <CONFIG> object with the same Class Type is present on a Config 
   message, the message SHOULD be rejected. 

    

3. Backward Compatibility 

   An LSR that receives a Config message containing a <CONFIG> object 
   with a C-Type that it does not recognize should 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. 

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

   - Reject the message because of the unknown BEHAVIOR_CONFIG object 
      as described above. 


 
 
Li. et al.               Expires September 2011               [Page 5] 

draft-ietf-ccamp-lmp-behavior-negotiation-02.txt            March 2011 
    

   - 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 and also not rejected. 

   An LSR that receives a ConfigNack message rejecting a Config message 
   that it sent containing the BEHAVIOR CONFIG C-Type because that 
   object variant is not supported by its peer MUST NOT draw any 
   conclusions about the level of support at the peer for LMP options 
   described by bits B, S, D, and C. Instead, the LSR MUST revert to 
   current practices of configuration or discovery through attempts to 
   exercise the options. 

   However, as future documents are published describing new LMP 
   features, and those documents require support of the BEHAVIOR CONFIG 
   C-Type, an LSR that receives a ConfigNack message rejecting a Config 
   message that it sent containing the BEHAVIOR CONFIG C-Type because 
   that object variant is not supported by its peer SHOULD conclude 
   that the additional options it wants to use are not supported by the 
   peer. 

    

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

    

5. 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)". 
 
 
Li. et al.               Expires September 2011               [Page 6] 

draft-ietf-ccamp-lmp-behavior-negotiation-02.txt            March 2011 
    

   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: 

   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] 
    

6. Contributors 

   Diego Caviglia   
   Ericsson  
   Via A. Negrone 1/A 16153  
   Genoa Italy  
   Phone: +39 010 600 3736  
   Email: diego.caviglia@ericsson.com 
    
 
 
Li. et al.               Expires September 2011               [Page 7] 

draft-ietf-ccamp-lmp-behavior-negotiation-02.txt            March 2011 
    

7. Acknowledgments 

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

    

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

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. 

    










 
 
Li. et al.               Expires September 2011               [Page 8] 

draft-ietf-ccamp-lmp-behavior-negotiation-02.txt            March 2011 
    

9. 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 September 2011               [Page 9]