draft-ietf-ccamp-lmp-behavior-negotiation-09.txt   draft-ietf-ccamp-lmp-behavior-negotiation-10.txt 
Network Working Group Dan Li Network Working Group Dan Li
Internet Draft Huawei Internet Draft Huawei
Updates: 4204, 4207, 4209, 5818 D. Ceccarelli Updates: 4204, 4207, 4209, 5818 D. Ceccarelli
Category: Standards Track Ericsson Category: Standards Track Ericsson
Lou Berger Lou Berger
LabN LabN
Expires: June 2013 December 20, 2012 Expires: July 2013 January 24, 2013
Link Management Protocol Behavior Negotiation and Link Management Protocol Behavior Negotiation and
Configuration Modifications Configuration Modifications
draft-ietf-ccamp-lmp-behavior-negotiation-09.txt draft-ietf-ccamp-lmp-behavior-negotiation-10.txt
Abstract Abstract
The Link Management Protocol (LMP) is used to coordinate the The Link Management Protocol (LMP) is used to coordinate the
properties, use, and faults of data links in Generalized properties, use, and faults of data links in Generalized
Multiprotocol Label Switching (GMPLS) networks. This document Multiprotocol Label Switching (GMPLS)-controlled networks. This
defines an extension to LMP to negotiate capabilities and indicate document defines an extension to LMP to negotiate capabilities and
support for LMP extensions. The defined extension is compatible indicate support for LMP extensions. The defined extension is
with non-supporting implementations. compatible with non-supporting implementations.
This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818. This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 19, 2013. This Internet-Draft will expire on July 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 3, line 11 skipping to change at page 3, line 11
3.2. Processing ............................................. 7 3.2. Processing ............................................. 7
4. Backward Compatibility....................................... 7 4. Backward Compatibility....................................... 7
5. Security Considerations...................................... 8 5. Security Considerations...................................... 8
6. IANA Considerations ......................................... 9 6. IANA Considerations ......................................... 9
6.1. New LMP Class Type...................................... 9 6.1. New LMP Class Type...................................... 9
6.2. New Capabilities Registry............................... 9 6.2. New Capabilities Registry............................... 9
7. Contributors ............................................... 10 7. Contributors ............................................... 10
8. Acknowledgments ............................................ 10 8. Acknowledgments ............................................ 10
9. References ................................................. 10 9. References ................................................. 10
9.1. Normative References................................... 10 9.1. Normative References................................... 10
9.2. Informative References................................. 11
10. Authors' Addresses ........................................ 11 10. Authors' Addresses ........................................ 11
1. Introduction 1. Introduction
The Link Management Protocol (LMP) [RFC4204] has been successfully The Link Management Protocol (LMP) [RFC4204] has been successfully
deployed in Generalized Multiprotocol Label Switching (GMPLS)- deployed in Generalized Multiprotocol Label Switching (GMPLS)-
controlled networks. controlled networks.
New LMP behaviors and protocol extensions have been introduced in a New LMP behaviors and protocol extensions have been introduced in a
number of IETF documents as set out later in this section. It is number of IETF documents as set out later in this section. It is
likely that future extensions will be made to support additional likely that future extensions will be made to support additional
functions. functions.
In a network, if one LMP node supports a new behavior or protocol In a network, if one LMP-capable node supports a new behavior or
extension but its adjacent node does not, it is beneficial to have a protocol extension but its adjacent node does not, it is beneficial
protocol mechanism to discover the capabilities of peer nodes so to have a protocol mechanism to discover the capabilities of peer
that the right protocol extensions can be selected and the correct nodes so that the right protocol extensions can be selected and the
features can be enabled. There are no such procedures defined in the correct features can be enabled. There are no such procedures
base LMP specification [RFC4204]. [RFC4209] defined a specific defined in the base LMP specification [RFC4204]. [RFC4209] defined a
mechanism to identify support for the functions defined in that specific mechanism to identify support for the functions specified
document. This document defines an LMP extension to support the in that document. This document defines an LMP extension to support
identification of supported LMP functions in a generic fashion, as the identification of supported LMP functions in a generic fashion,
well as how a node supporting these extensions would communicate as well as how a node supporting these extensions would communicate
with legacy nodes. with legacy nodes.
In [RFC4204], the basic behaviors have been defined around the use In [RFC4204], the basic behaviors have been defined around the use
of the standard LMP messages, which include Config, Hello, Verify, of the standard LMP messages, which include Config, Hello, Verify,
Test, LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors Test, LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors
MUST be supported when LMP is implemented, and the message types MUST be supported when LMP is implemented, and the message types
from 1 to 20 have been assigned by IANA for these messages. Support from 1 to 20 have been assigned by IANA for these messages. Support
for all functions required by [RFC4204] is assumed by this document. for all functions required by [RFC4204] is assumed by this document.
In [RFC4207], the SONET/SDH technology-specific behavior and In [RFC4207], the SONET/SDH technology-specific behavior and
information for LMP is defined. The Trace behavior is added to LMP, 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 and the message types from 21 to 31 were assigned by IANA for the
messages that provide the TRACE function. The Trace function has messages that provide the TRACE function.
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 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 between a peer node and an adjacent Optical Line System (OLS). The
LMP object class type and sub-object class name have been extended LMP object class type and sub-object class name have been extended
to support DWDM behavior. to support DWDM behavior.
In [RFC5818], the data channel consistency check behavior is defined, In [RFC5818], the data channel consistency check behavior is defined,
and the message types from 32 to 34 have been assigned by IANA for and the message types from 32 to 34 have been assigned by IANA for
messages that provide this behavior. messages that provide this behavior.
skipping to change at page 4, line 32 skipping to change at page 4, line 29
defined CONFIG object. defined CONFIG object.
This document also modifies the format of messages that carry CONFIG This document also modifies the format of messages that carry CONFIG
object to allow for multiple objects. Multiple CONFIG objects allow object to allow for multiple objects. Multiple CONFIG objects allow
behavior negotiation concurrent with existing usage of the CONFIG behavior negotiation concurrent with existing usage of the CONFIG
object, i.e., HelloConfig C-Type defined in [RFC4204] and object, i.e., HelloConfig C-Type defined in [RFC4204] and
LMP_WDM_CONFIG C-Type defined in [RFC4209]. This document modifies LMP_WDM_CONFIG C-Type defined in [RFC4209]. This document modifies
the ConfigAck message to include CONFIG objects so that acceptable the ConfigAck message to include CONFIG objects so that acceptable
parameters are explicitly identified. It also describes how a node parameters are explicitly identified. It also describes how a node
which supports the extensions defined in this document interacts which supports the extensions defined in this document interacts
with a legacy LMP node. with a legacy LMP-capable node.
2. LMP Message Modifications 2. LMP Message Modifications
LMP Config, ConfigNack and ConfigAck messages are modified by this LMP Config, ConfigNack and ConfigAck messages are modified by this
document to allow for the inclusion of multiple CONFIG objects. The document to allow for the inclusion of multiple CONFIG objects. The
Config and ConfigNack messages were only defined to carry one CONFIG Config and ConfigNack messages were only defined to carry one CONFIG
object in [RFC4204]. The ConfigAck message, which was defined object in [RFC4204]. The ConfigAck message, which was defined
without carrying any CONFIG objects in [RFC4204], is modified to without carrying any CONFIG objects in [RFC4204], is modified to
enable explicit identification of negotiated configuration enable explicit identification of negotiated configuration
parameters. The inclusion of CONFIG objects in ConfigAck messages is parameters. The inclusion of CONFIG objects in ConfigAck messages is
triggered by the use of the BehaviorConfig object (defined below) in triggered by the use of the BehaviorConfig object (defined below) in
a received Config message. 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 2.1. Modified Message Formats
The format of the Config message as updated by this document is as The format of the Config message as updated by this document is as
follows: follows:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ] <LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]
The format of the ConfigAck message as updated by this document is The format of the ConfigAck message as updated by this document is
as follows: as follows:
skipping to change at page 5, line 41 skipping to change at page 5, line 41
objects of the same C-type. Unless specified as part of the CONFIG objects of the same C-type. Unless specified as part of the CONFIG
object definition, ordering of CONFIG objects is not significant. object definition, ordering of CONFIG objects is not significant.
Nodes which support the extensions defined in this document MUST Nodes which support the extensions defined in this document MUST
include a BehaviorConfig type object when sending a Config message include a BehaviorConfig type object when sending a Config message
to a neighbor whose support for the extensions is either known or to a neighbor whose support for the extensions is either known or
unknown. When the neighbor is known to not support the extensions, unknown. When the neighbor is known to not support the extensions,
the object MUST NOT be sent. Inclusion of other CONFIG objects in a 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 Config message is at the discretion of the message sender, and is
based on the rules defined as part of CONFIG object definition. based on the rules defined as part of CONFIG object definition.
Nodes MAY include, HelloConfig, LMP_WDM_CONFIG, BehaviorConfig Nodes MAY include HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object
object types in a single message. types in a single message.
Inclusion of multiple CONFIG objects in a ConfigNack message is Inclusion of multiple CONFIG objects in a ConfigNack message is
based on the processing of a received Config message. Per [RFC4204] based on the processing of a received Config message. Per [RFC4204]
"Parameters where agreement was reached MUST NOT be included in the "Parameters where agreement was reached MUST NOT be included in the
ConfigNack Message." As such, a ConfigNack message MUST NOT include ConfigNack Message." As such, a ConfigNack message MUST NOT include
CONFIG objects which are acceptable and MUST include any CONFIG CONFIG objects which are acceptable and MUST include any CONFIG
objects which are not acceptable. When a CONFIG object is included objects which are not acceptable. When a CONFIG object is included
in a ConfigNack message, per [RFC4204], the object is to include in a ConfigNack message, per [RFC4204], the object is to include
"acceptable alternate values for negotiable parameters". "acceptable alternate values for negotiable parameters".
skipping to change at page 7, line 23 skipping to change at page 7, line 23
behavior defined in [RFC5818]. behavior defined in [RFC5818].
Must Be Zero (MBZ): Variable length Must Be Zero (MBZ): Variable length
The remaining bits in the flags field MUST be set to zero (0). The remaining bits in the flags field MUST be set to zero (0).
The number of bits present is based on the Length field of the The number of bits present is based on the Length field of the
LMP object header and MUST include enough bits so the Length LMP object header and MUST include enough bits so the Length
field MUST be at least 8, and MUST be a multiple of 4. field MUST be at least 8, and MUST be a multiple of 4.
Other bits may be defined in future documents, in which case the Other bits may be defined in future documents, in which case the
number of MBZ bits field is expected to change. number of bits in MBZ field is expected to change.
3.2. Processing 3.2. Processing
The inclusion of a BehaviorConfig type object in a message is The inclusion of a BehaviorConfig type object in a message is
discussed above in Section 2.2. discussed above in Section 2.2.
When sending a BehaviorConfig type object, the N-bit (negotiable) in 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. the LMP object header MUST be set (N=1) in the LMP object header.
When sending a BehaviorConfig type object in Config and ConfigNack When sending a BehaviorConfig type object in Config and ConfigNack
skipping to change at page 8, line 29 skipping to change at page 8, line 29
response. response.
Behaviors (a) and (b) result in ConfigNack messages with a Behaviors (a) and (b) result in ConfigNack messages with a
BehaviorConfig type object whose contents are identical to what was BehaviorConfig type object whose contents are identical to what was
sent in the Config message. Behavior (c) results in a ConfigAck sent in the Config message. Behavior (c) results in a ConfigAck
message without a BehaviorConfig type CONFIG object. In each of message without a BehaviorConfig type CONFIG object. In each of
these cases, the node SHOULD explicitly identify that the LMP these cases, the node SHOULD explicitly identify that the LMP
neighbor does not support the extensions defined in this document. neighbor does not support the extensions defined in this document.
Behavior (d) results in no response at all. When the node reaches Behavior (d) results in no response at all. When the node reaches
the, [RFC4204] defined, "retry limit", the node SHOULD infer that the, [RFC4204]-defined, "retry limit", the node SHOULD infer that
the LMP neighbor does not support the extensions defined in this the LMP neighbor does not support the extensions defined in this
document. document.
Once a node identifies a neighbor as not supporting the extensions Once a node identifies a neighbor as not supporting the extensions
defined in this document, the node SHOULD follow previously defined defined in this document, the node SHOULD follow previously defined
Config message usage. Config message usage.
5. Security Considerations 5. Security Considerations
[RFC4204] describes how LMP messages between peers can be secured, [RFC4204] describes how LMP messages between peers can be secured,
skipping to change at page 9, line 31 skipping to change at page 9, line 31
CONFIG Object Class type name space: CONFIG Object Class type name space:
C-Type Description Reference C-Type Description Reference
------------ --------------------- --------- ------------ --------------------- ---------
3(suggested) BehaviorConfig [This.I-D] 3(suggested) BehaviorConfig [This.I-D]
6.2. New Capabilities Registry 6.2. New Capabilities Registry
IANA is requested to create a new subregistry of the "Link IANA is requested to create a new subregistry of the "Link
Management Protocol (LMP)" registry to track the Behaviour Management Protocol (LMP)" registry to track the Behavior
Configuration bits defined in Section 2 of this document. It is Configuration bits defined in Section 2 of this document. It is
suggested that this registry be called "LMP Behaviour Configuration suggested that this registry be called "LMP Behavior Configuration
Flags". Flags".
Allocations from this registry are by Standards Action. Allocations from this registry are by Standards Action.
Bits in this registry are numbered from zero as the most significant Bits in this registry are numbered from zero as the most significant
bit (transmitted first). The number of bits that can be present is 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 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 (255 x 32)-8 = 8152. IANA is strongly recommended to allocate new
bits with the lowest available unused number. bits with the lowest available unused number.
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Management Protocol (LMP) Test Messages", RFC 4207, Management Protocol (LMP) Test Messages", RFC 4207,
October 2005. October 2005.
[RFC4209] A. Fredette, Ed., "Link Management Protocol (LMP) for [RFC4209] A. Fredette, Ed., "Link Management Protocol (LMP) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Dense Wavelength Division Multiplexing (DWDM) Optical Line
Systems", RFC 4209, October 2005. Systems", RFC 4209, October 2005.
[RFC5818] D. Li, Ed., "Data Channel Status Confirmation Extensions [RFC5818] D. Li, Ed., "Data Channel Status Confirmation Extensions
for the Link Management Protocol", RFC 5818, April 2010. for the Link Management Protocol", RFC 5818, April 2010.
9.2. Informative References [RFC5511] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF): A
Syntax Used to Form Encoding Rules in Various Routing
[LMP TEST] D. Ceccarelli, Ed., "Link Management Protocol (LMP) Test Protocol Specifications", RFC 5511, April 2009.
Messages Extensions for Evolutive Optical Transport
Networks (OTN)" draft-ceccarelli-ccamp-gmpls-g709-lmp-
test-04.txt, July, 2012.
10. Authors' Addresses 10. Authors' Addresses
Dan Li Dan Li
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base, F3-5-B R&D Center, Huawei Industrial Base,
Shenzhen 518129 China Shenzhen 518129 China
Phone: +86 755-289-70230 Phone: +86 755-289-70230
Email: danli@huawei.com Email: huawei.danli@huawei.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova - Sestri Ponente Genova - Sestri Ponente
Italy Italy
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
 End of changes. 18 change blocks. 
37 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/