draft-ietf-ccamp-lmp-behavior-negotiation-03.txt   draft-ietf-ccamp-lmp-behavior-negotiation-04.txt 
Network Working Group Dan Li Network Working Group Dan Li
Internet Draft Huawei Internet Draft Huawei
Updates: RFC4204 D. Ceccarelli Updates: 4204, 4207,4209, 5818 D. Ceccarelli
Category: Standards Track Ericsson Category: Standards Track Ericsson
Lou Berger
LabN
Expires: October 2011 April 7, 2011 Expires: December 2011 June 7, 2011
Behavior Negotiation in The Link Management Protocol Link Management Protocol Behavior Negotiation and
Configuration Modifications
draft-ietf-ccamp-lmp-behavior-negotiation-03.txt draft-ietf-ccamp-lmp-behavior-negotiation-04.txt
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. 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 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 46
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 October 7, 2011. This Internet-Draft will expire on December 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
warranty as described in the Simplified BSD License. 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 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 3
2. LMP Behavior Negotiation Procedure........................... 3 2. LMP Message Modifications.................................... 4
3. Backward Compatibility....................................... 5 2.1. Modified Message Formats................................ 4
4. Security Considerations...................................... 6 2.2. Processing ............................................. 5
5. IANA Considerations ......................................... 7 3. LMP Behavior Negotiation..................................... 6
5.1. New LMP Class Type...................................... 7 3.1. BehaviorConfig C-Type Format............................ 6
5.2. New Capabilities Registry............................... 7 3.2. Processing ............................................. 7
6. Contributors ................................................ 8 4. Backward Compatibility....................................... 7
7. Acknowledgments ............................................. 8 5. Security Considerations...................................... 8
8. References .................................................. 8 6. IANA Considerations ......................................... 9
8.1. Normative References.................................... 8 6.1. New LMP Class Type...................................... 9
8.2. Informative References.................................. 9 6.2. New Capabilities Registry............................... 9
9. Authors' Addresses .......................................... 9 7. Contributors ............................................... 10
8. Acknowledgments ............................................ 10
9. References ................................................. 10
9.1. Normative References................................... 10
9.2. Informative References................................. 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 the network, if one GMPLS Label Switch Router (LSR) supports a In a network, if one LMP node supports a new behavior or protocol
new behavior or protocol extension, but its peer LSR does not, it is extension but its adjacent node does not, it is beneficial to have a
necessary to have a protocol mechanism for resolving issues that may protocol mechanism to discover the capabilities of peer nodes so
arise. It is also beneficial to have a protocol mechanism to that the right protocol extensions can be selected and the correct
discover the capabilities of peer LSRs so that the right protocol features can be enabled. There are no such procedures defined in the
extensions can be selected and the correct features enabled. There base LMP specification [RFC4204]. [RFC4209] defined a specific
are no such procedures defined in the base LMP specification mechanism to identify support for the functions defined in that
[RFC4204], so this document defines how to handle LMP extensions document. This document defines an LMP extension to support the
both at legacy LSRs and at upgraded LSRs that would communicate with identification of supported LMP functions in a generic fashion, as
legacy LSRs. well as how a node supporting these extensions would communicate
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 [RCF4204], these behaviors Test, LinkSummary, and ChannelStatus. Per [RCF4204], 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. 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 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. The Trace function has
been extended for the support of OTNs (Optical Transport Networks) been extended for the support of OTNs (Optical Transport Networks)
in [LMP-TEST]. 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.
It is likely that future extensions to LMP for other functions or It is likely that future extensions to LMP for other functions or
technologies will require the definition of further LMP messages. technologies will require the definition of further LMP messages.
This document describes the behavior negotiation procedure to make This document describes an LMP extension, which is referred to as
sure both LSRs at the ends of each link understand the LMP messages behavior negotiation, which enables nodes at the ends of a link to
that they exchange. 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.
2. LMP Behavior Negotiation Procedure 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 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 message includes a CONFIG
object of type BehaviorConfig.
3. LMP Behavior Negotiation
The Config message is used in the control channel negotiation phase The Config message is used in the control channel negotiation phase
of LMP [RFC4204]. The LMP behavior negotiation procedure is defined of LMP [RFC4204]. The LMP behavior negotiation procedure is defined
in this document as an addition to this phase. in this document as an addition to this phase.
The Config message is defined in Section 12.3.1 of [RFC4204] and The Config message is defined in Section 12.3.1 of [RFC4204] and
carries the <CONFIG> object (class name 6) as defined in Section carries the CONFIG object (class name 6) as defined in Section 13.6
13.6 of [RFC4204]. of [RFC4204].
Two class types have been defined: Two class types have been defined:
- C-Type = 1, HelloConfig, defined in [RFC4204] - C-Type = 1, HelloConfig, defined in [RFC4204]
- C-Type = 2, LMP_WDM_CONFIG, defined in [RFC4209] - C-Type = 2, LMP_WDM_CONFIG, defined in [RFC4209]
This document defines a third C-Type with value 3 (TBD by IANA) to This document defines a third C-Type to report and negotiate LMP
report and negotiate currently defined LMP mechanisms and behaviors, mechanisms and behaviors. Its usage indicates support for the
and to allow future LMP extensions to be reported and negotiated. extensions defined in this document.
- C-Type = 3, BEHAVIOR_CONFIG 3.1. BehaviorConfig C-Type Format
The format of the new type of CONFIG Class is defined as follows: Class = 6
- C-Type = (To be assigned by IANA), BehaviorConfig
0 1 2 3 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 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: Flags:
B: 1 bit
This bit indicates support for the basic behaviors defined in
[RFC4204].
S: 1 bit S: 1 bit
This bit indicates support for the Trace behavior of SONET/SDH This bit indicates support for the Trace behavior of SONET/SDH
technology-specific defined in [RFC4207]. technology-specific defined in [RFC4207].
D: 1 bit D: 1 bit
This bit indicates support for the DWDM behavior defined in This bit indicates support for the DWDM behavior defined in
[RFC4209]. [RFC4209].
C: 1 bit C: 1 bit
This bit indicates support for the data channel consistency check This bit indicates support for the data channel consistency check
behavior defined in [RFC5818]. behavior defined in [RFC5818].
Further bits may be defined in future documents. Must Be Zero (MBZ): Variable length
The MUST_BE_ZERO field MUST be sent as zero and MUST NOT be ignored The remaining bits in the flags field MUST be set to zero (0).
on receipt. This allows the detection of unsupported or unknown LMP The number of bits present is based on the Length field of the
behaviors when new bits are allocated to indicate further LMP object header and MUST include enough bits so the Length
capabilities and are sent as one. field MUST be at least 8, and MUST be a multiple of 4.
Upon receiving a bit set related to an unsupported or unknown Other bits may be defined in future documents, in which case the
behavior, a ConfigNack message MUST be sent with a <CONFIG> object, number of MBZ bits field is expected to change.
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 3.2. Processing
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 The inclusion of a BehaviorConfig type object in a message is
discussed above in Section 2.2.
An LSR that receives a Config message containing a <CONFIG> object When sending a BehaviorConfig type object, the N-bit (negotiable) in
with a C-Type that it does not recognize should respond with a the LMP object header must be set (N=1) in the LMP object header.
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 When sending a BehaviorConfig type object in Config and ConfigNack
with different C-Types should be processed. Thus it is possible that messages, the flags field SHOULD be set based on the supported
a legacy node receiving a BEHAVIOR_CONFIG object on a Config message capabilities of the sending node. When sending a ConfigAck message,
that also includes a HelloConfig or LMP_WDM_CONFIG object might the flags field MUST be set to the value received in the
react as follows: corresponding Config message.
- Reject the message because of the unknown BEHAVIOR_CONFIG object When receiving a BehaviorConfig type object, the node compares the
as described above. flags field against its capacities. Any bit set in the MBZ portion
of the flags field MUST be interpreted as unacceptable. Processing
related to unacceptable values in CONFIG objects is defined in
[RFC4204] and is not modified by this document.
- Reject the message because of multiple <CONFIG> objects. This 4. Backward Compatibility
achieves the same effective result.
- Ignore the second <CONFIG> object. This would result in the The required use of the BehaviorConfig type CONFIG object enables
BEHAVIOR_CONFIG object being unprocessed and also not rejected. nodes which support the extensions defined in this document to
explicitly identify when a neighboring node does not. When a non-
supporting node receives a Config message with the BehaviorConfig
type CONFIG object or multiple CONFIG objects its behavior is likely
to be one of the following behaviors:
An LSR that receives a ConfigNack message rejecting a Config message a) Reject the Config message because of the unknown BehaviorConfig
that it sent containing the BEHAVIOR CONFIG C-Type because that object type and send a ConfigNack message which includes the
object variant is not supported by its peer MUST NOT draw any unsupported C-type.
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 b) Reject the message because of multiple CONFIG objects and send a
features, and those documents require support of the BEHAVIOR CONFIG ConfigNack message which includes all but one of the CONFIG
C-Type, an LSR that receives a ConfigNack message rejecting a Config objects.
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 c) Silently ignore the one or more of the CONFIG object, and respond
with a 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 in the Config message. Behavior (c) results in a ConfigAck
message without a BehaviorConfig type CONFIG object. In each of
these cases, the node SHOULD explicitly identify that the LMP
neighbor does not support the extensions defined in this document.
Behavior (d) results in no response at all. When the node reaches
the, [RFC4204] defined, "retry limit", the node SHOULD infer that
the LMP neighbor does not support the extensions defined in this
document.
Once a node identifies a neighbor as not supporting the extensions
defined in this document, the node SHOULD follow previously defined
Config message usage.
5. Security Considerations
[RFC4204] describes how LMP messages between peers can be secured, [RFC4204] describes how LMP messages between peers can be secured,
and these measures are equally applicable to messages carrying the and these measures are equally applicable to messages carrying the
new <CONFIG> object defined in this document. new CONFIG object defined in this document.
The operation of the procedures described in this document does not The procedures described in this document do not of itself
of itself constitute a security risk since they do not cause any constitute a security risk since they do not cause any change in
change in network state. It would be possible, if the messages were network state. It would be possible, if the messages were
intercepted or spoofed to cause bogus alerts in the management plane, intercepted or spoofed to cause bogus alerts in the management plane,
or to cause LMP peers to consider that they could or could not or to cause LMP peers to consider that they could or could not
operate protocol extensions, and so the use of the LMP security operate protocol extensions, and so the use of the LMP security
measures are RECOMMENDED. measures are RECOMMENDED.
Note, however, that [RFC4204] refers to [RFC2401], which has been Note, however, that [RFC4204] refers to [RFC2401], which has been
replaced by [RFC4301]. Also, the reference to IKEv2 in [RFC4301] is replaced by [RFC4301]. Also, the reference to IKEv2 in [RFC4301] is
out of date, and the current reference for IKEv2 is [RFC5996]. out of date, and the current reference for IKEv2 is [RFC5996].
5. IANA Considerations 6. IANA Considerations
5.1. New LMP Class Type 6.1. New LMP Class Type
IANA maintains the "Link Management Protocol (LMP)" registry which IANA maintains the "Link Management Protocol (LMP)" registry which
has a subregistry called "LMP Object Class name space and Class type has a subregistry called "LMP Object Class name space and Class type
(C-Type)". (C-Type)".
IANA is requested to make an assignment from this registry as IANA is requested to make an assignment from this registry as
follows: follows:
6 CONFIG [RFC4204] 6 CONFIG [RFC4204]
CONFIG Object Class type name space: CONFIG Object Class type name space:
C-Type Description Reference C-Type Description Reference
------ ------------------------ --------- ------------ --------------------- ---------
3 BEHAVIOR_CONFIG [This.I-D] 3(suggested) BehaviorConfig [This.I-D]
5.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 Behaviour
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 Behaviour 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 limited by the length field of the CONFIG object which gives rise to
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.
The registry is initially populated as follows: The registry is initially populated as follows:
Bit | Bit | Meaning | Reference Bit | Bit | Meaning | Reference
Number | Name | | Number | Name | |
-------+------+----------------------------------------+---------- -------+------+----------------------------------------+----------
0 | B | Basic LMP behavior support | [This.ID] 0 | S | SONET/SDH Test support | [This.ID]
1 | S | SONET/SDH Test support | [This.ID] 1 | D | DWDM support | [This.ID]
2 | D | DWDM support | [This.ID] 2 | C | Data Channel consistency check support | [This.ID]
3 | C | Data Channel consistency check support | [This.ID]
6. Contributors 7. Contributors
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A 16153 Via A. Negrone 1/A 16153
Genoa Italy Genoa Italy
Phone: +39 010 600 3736 Phone: +39 010 600 3736
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
7. Acknowledgments 8. Acknowledgments
Thanks to Adrian Farrel, Lou Berger and Richard Graveman for their Thanks to Adrian Farrel and Richard Graveman for their useful
useful comments. comments.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005 Internet Protocol", RFC 4301, December 2005
skipping to change at page 9, line 5 skipping to change at page 11, line 5
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.
8.2. Informative References 9.2. Informative References
[LMP TEST] D. Ceccarelli, Ed., "Link Management Protocol (LMP) Test [LMP TEST] D. Ceccarelli, Ed., "Link Management Protocol (LMP) Test
Messages Extensions for Evolutive Optical Transport Messages Extensions for Evolutive Optical Transport
Networks (OTN)" draft-ceccarelli-ccamp-gmpls-g709-lmp- Networks (OTN)" draft-ceccarelli-ccamp-gmpls-g709-lmp-
test-02.txt, May, 2010. test-02.txt, May, 2010.
9. 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: 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
LabN Consulting, L.L.C.
Email: lberger@labn.net
 End of changes. 50 change blocks. 
138 lines changed or deleted 228 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/