[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-ccamp-lmp-behavior-negotiation

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


Expires: March 2010                                 September 16, 2009


             Behavior Negotiation in Link Management Protocol



              draft-li-ccamp-lmp-behavior-negotiation-00.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.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Li                       Expires March 2010                   [Page 1]

draft-li-ccamp-lmp-behavior-negotiation-00.txt           September 2009


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 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. Security Considerations......................................4
   4. IANA Considerations..........................................5
   5. Acknowledgments..............................................5
   6. References...................................................5
      6.1. Normative References....................................5
      6.2. Informative References..................................5
   7. Author's Address.............................................6

1. Introduction

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

   In the network, if one GMPLS Label Switching 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. 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 communicate with legacy LSRs.

   In [RFC4204], the basic behaviors have been defined around the use of
   the standard LMP message, which includes Config, Hello, Verify, Test,


Li                       Expires March 2010                   [Page 2]

draft-li-ccamp-lmp-behavior-negotiation-00.txt           September 2009


   LinkSummary, ChannelStatus. Per [RCF4204], these behaviors MUST be
   supported when the LMP is implemented, and the message types from 1
   to 20 are used for these behaviors.

   In [RFC4207], the SONET/SDH technology-specific information for LMP
   is defined. The TRACE behavior is added to LMP, and the message types
   from 21 to 31 were defined for 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 sub-object class name have been extended to
   support DWDM behavior.

   In [DCSC], the data channel consistency check behavior is defined,
   the message types from 32 to 34 are used for this behavior.

   This document describes the behavior negotiation procedure to make
   sure both LSRs understand the LMP messages being exchanged between
   peers.

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

   Two class types have been defined.

   o    C-Type = 1, HelloConfig, defined in [RFC4204]

   o    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 new and future LMP extensions and behaviors. The
   format of the new CONFIG Class is defined as follows:

   o    C-Type = 3, ENHANCED_BEHAVIOR_CONFIG






Li                       Expires March 2010                   [Page 3]

draft-li-ccamp-lmp-behavior-negotiation-00.txt           September 2009


    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|                      (Reserved)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   S: 1 bit

   This bit indicates support for the SONET/SDH TRACE messages defined
   in [RFC4207].

   D: 1 bit

   This bit indicates support for the Data Channel Status Confirmation
   messages defined in [DCSC].

   Further bits may be defied in future documents.

   The Reserved field MUST be sent as zero and MUST NOT be ignored on
   receipt. This allows the detection of supported/unsupported LMP
   behaviors. For example, if a bit is set that is not recognized, then
   a ConfigNack message MUST be sent with a CONFIG object that
   represents the supported LMP behaviors.

   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 ENHANCED_BEHAVIOR_CONFIG C-Type defined in
   this document will respond with a ConfigNack message.

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





Li                       Expires March 2010                   [Page 4]

draft-li-ccamp-lmp-behavior-negotiation-00.txt           September 2009


4. IANA Considerations

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

5. Acknowledgments

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

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.

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

6.2. Informative References

   [DCSC]    D. Li, Ed., "Data Channel Status Confirmation Extensions
               for the Link Management Protocol", draft-ietf-ccamp-
               confirm-data-channel-status-07.txt, September 2009







Li                       Expires March 2010                   [Page 5]

draft-li-ccamp-lmp-behavior-negotiation-00.txt           September 2009


7. Author's Address

   Dan Li
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base,
   Shenzhen 518129 China

   Phone: +86 755-289-70230
   Email: danli@huawei.com






































Li                       Expires March 2010                   [Page 6]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/