draft-ietf-ccamp-lmp-behavior-negotiation-01.txt   draft-ietf-ccamp-lmp-behavior-negotiation-02.txt 
Network Working Group Dan Li Network Working Group Dan Li
Internet Draft Huawei Internet Draft Huawei
Updates: RFC4204 D. Ceccarelli Updates: RFC4204 D. Ceccarelli
Category: Standards Track Ericsson Category: Standards Track Ericsson
Expires: April 2011 October 11, 2010 Expires: September 2011 March 14, 2011
Behavior Negotiation in The Link Management Protocol Behavior Negotiation in The Link Management Protocol
draft-ietf-ccamp-lmp-behavior-negotiation-01.txt draft-ietf-ccamp-lmp-behavior-negotiation-02.txt
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 34
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 April 11, 2011. This Internet-Draft will expire on September 13, 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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 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. Various proposals Multiprotocol Label Switching (GMPLS) networks. Various proposals
have been advanced to provide extensions to the base LMP have been advanced to provide extensions to the base LMP
specification. This document defines an extension to negotiated specification. This document defines an extension to negotiate
capabilities and provides a generic procedure for LMP capabilities and support for those extensions, and provides a
implementations that do not recognize or do not support any one of generic procedure for LMP implementations that do not recognize or
these extensions. 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 ................................................ 2
2. LMP Behavior Negotiation Procedure ........................... 3 2. LMP Behavior Negotiation Procedure........................... 3
3. Backwards Compatibility ...................................... 5 3. Backward Compatibility....................................... 5
4. Security Considerations ...................................... 5 4. Security Considerations...................................... 6
5. IANA Considerations .......................................... 6 5. IANA Considerations ......................................... 6
5.1. New LMP Class Type ...................................... 6 5.1. New LMP Class Type...................................... 6
5.2. New Capabilities Registry ............................... 6 5.2. New Capabilities Registry............................... 7
6. Contributors ................................................. 7 6. Contributors ................................................ 7
7. Acknowledgments .............................................. 7 7. Acknowledgments ............................................. 8
8. References ................................................... 7 8. References .................................................. 8
8.1. Normative References .................................... 7 8.1. Normative References.................................... 8
8.2. Informative References .................................. 8 8.2. Informative References.................................. 8
9. Authors' Addresses ........................................... 8 9. Authors' Addresses .......................................... 9
1. Introduction 1. Introduction
The Link Management Protocol (LMP) [RFC4204] is being 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. New LMP behaviors and protocol extensions are controlled networks.
being introduced in a number of IETF documents.
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.
In the network, if one GMPLS Label Switch Router (LSR) supports a 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 new behavior or protocol extension, but its peer LSR does not, it is
necessary to have a protocol mechanism for resolving issues that may necessary to have a protocol mechanism for resolving issues that may
arise. It is also beneficial to have a protocol mechanism to arise. It is also beneficial to have a protocol mechanism to
discover the capabilities of peer LSRs. There is no such procedure discover the capabilities of peer LSRs so that the right protocol
defined in the base LMP specification [RFC4204], so this document extensions can be selected and the correct features enabled. There
defines how to handle LMP extensions both at legacy LSRs and at are no such procedures defined in the base LMP specification
upgraded LSRs that would communicate with legacy LSRs. [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 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.
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 the behavior negotiation procedure to make
sure both LSRs at the ends of each link understand the LMP messages sure both LSRs at the ends of each link understand the LMP messages
that they exchange. that they exchange.
2. LMP Behavior Negotiation Procedure 2. LMP Behavior Negotiation Procedure
The Config message is used in the control channel negotiation phase The Config message is used in the control channel negotiation phase
of LMP [RC4204]. 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 of [RFC4204]. 13.6 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]
skipping to change at page 4, line 22 skipping to change at page 4, line 26
report and negotiate currently defined LMP mechanisms and behaviors, report and negotiate currently defined LMP mechanisms and behaviors,
and to allow future LMP extensions to be reported and negotiated. and to allow future LMP extensions to be reported and negotiated.
- C-Type = 3, BEHAVIOR_CONFIG - C-Type = 3, BEHAVIOR_CONFIG
The format of the new type of CONFIG Class is defined as follows: The format of the new type of CONFIG Class is defined as follows:
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|O| Reserved | | Length |B|S|D|C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 8 bits Length: 8 bits
This field indicates the total length of the objects expressed in This field indicates the total length of the objects expressed in
multiples of 4 bytes. multiples of 4 bytes.
Flags: Flags:
B: 1 bit B: 1 bit
skipping to change at page 5, line 5 skipping to change at page 5, line 10
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].
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. Further bits may be defined in future documents.
The Reserved field MUST be sent as zero and MUST NOT be ignored on The Reserved field MUST be sent as zero and MUST NOT be ignored on
receipt. This allows the detection of unsupported or unknown LMP receipt. This allows the detection of unsupported or unknown LMP
behaviors when new bits are allocated to indicate further behaviors when new bits are allocated to indicate further
capabilities and are sent as one. capabilities and are sent as one.
Upon receiving a bit set related to an unsupported or unknown Upon receiving a bit set related to an unsupported or unknown
behavior, a ConfigNack message MUST be sent with a <CONFIG> object, behavior, a ConfigNack message MUST be sent with a <CONFIG> object,
the BEHAVIOR_CONFIG C-Type representing the supported LMP behaviors. the BEHAVIOR_CONFIG C-Type representing the supported LMP behaviors.
An LSR receiving such a ConfigNack SHOULD select a supported set of An LSR receiving such a ConfigNack SHOULD select a supported set of
capabilities and send a further Config message, or MAY raise an capabilities and send a further Config message, or MAY raise an
alert to the management system (or log an error) and stop trying to alert to the management system (or log an error) and stop trying to
perform LMP communications with its neighbor. perform LMP communications with its neighbor.
3. Backwards Compatibility 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 An LSR that receives a Config message containing a <CONFIG> object
with a C-Type that it does not recognize MUST respond with a with a C-Type that it does not recognize should respond with a
ConfigNack message as described in [RFC4204]. Thus, legacy LMP nodes ConfigNack message as described in [RFC4204]. Thus, legacy LMP nodes
that do not support the BEHAVIOR_CONFIG C-Type defined in this that do not support the BEHAVIOR_CONFIG C-Type defined in this
document will respond with a ConfigNack message. document will respond with a ConfigNack message.
It's not explicitly stated in [RFC4204] that a Config Message could Note that [RFC4204] does not describe how multiple <CONFIG> objects
include multiple <CONFIG> objects. But with new CONFIG C-Types are with different C-Types should be processed. Thus it is possible that
defined, multiple <CONFIG> objects (each with a different Class Type) a legacy node receiving a BEHAVIOR_CONFIG object on a Config message
MAY be present on a Config message in which case all of the objects that also includes a HelloConfig or LMP_WDM_CONFIG object might
MUST be processed. react as follows:
- Reject the message because of the unknown BEHAVIOR_CONFIG object
as described above.
- 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 4. 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 operation of the procedures described in this document does not
of itself constitute a security risk since they do not cause any of itself constitute a security risk since they do not cause any
change in network state. It would be possible, if the messages were change in network state. It would be possible, if the messages were
skipping to change at page 6, line 26 skipping to change at page 7, line 14
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 BEHAVIOR_CONFIG [This.I-D]
5.2. New Capabilities Registry 5.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.
skipping to change at page 7, line 12 skipping to change at page 7, line 41
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 | B | Basic LMP behavior support | [This.ID]
1 | S | SONET/SDH Test support | [This.ID] 1 | S | SONET/SDH Test support | [This.ID]
2 | D | DWDM support | [This.ID] 2 | D | DWDM support | [This.ID]
3 | C | Data Channel consistency check support | [This.ID] 3 | C | Data Channel consistency check support | [This.ID]
4 | O | OTN TEST behavior | [This.ID]
6. Contributors 6. 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
 End of changes. 19 change blocks. 
46 lines changed or deleted 78 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/