draft-ietf-ccamp-lmp-behavior-negotiation-07.txt   draft-ietf-ccamp-lmp-behavior-negotiation-08.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 5, 2012 Expires: June 2013 December 19, 2012
Link Management Protocol Behavior Negotiation and Link Management Protocol Behavior Negotiation and
Configuration Modifications Configuration Modifications
draft-ietf-ccamp-lmp-behavior-negotiation-07.txt draft-ietf-ccamp-lmp-behavior-negotiation-08.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) networks. This document
defines an extension to LMP to negotiate capabilities and indicate defines an extension to LMP to negotiate capabilities and indicate
support for LMP extensions. The defined extension is compatible support for LMP extensions. The defined extension is compatible
with non-supporting implementations. with non-supporting implementations.
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 5, 2013. This Internet-Draft will expire on June 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2012 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 ................................................ 3 1. Introduction ................................................ 3
2. LMP Message Modifications.................................... 4 2. LMP Message Modifications.................................... 4
skipping to change at page 3, line 30 skipping to change at page 3, line 39
features can be enabled. There are no such procedures defined in the features can be enabled. There are no such procedures defined in the
base LMP specification [RFC4204]. [RFC4209] defined a specific base LMP specification [RFC4204]. [RFC4209] defined a specific
mechanism to identify support for the functions defined in that mechanism to identify support for the functions defined in that
document. This document defines an LMP extension to support the document. This document defines an LMP extension to support the
identification of supported LMP functions in a generic fashion, as identification of supported LMP functions in a generic fashion, as
well as how a node supporting these extensions would communicate 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 [RCF4204], 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. 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.
skipping to change at page 5, line 27 skipping to change at page 5, line 37
ConfigNack message. A maximum of a single object of any particular ConfigNack message. A maximum of a single object of any particular
C-type SHALL be included. A node which receives a message with C-type SHALL be included. A node which receives a message with
multiple CONFIG objects of the same C-type SHALL process the first multiple CONFIG objects of the same C-type SHALL process the first
object of a particular C-type and ignore any subsequent CONFIG object of a particular C-type and ignore any subsequent CONFIG
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 types in a single message. object 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
skipping to change at page 8, line 45 skipping to change at page 9, line 5
new CONFIG object defined in this document. new CONFIG object defined in this document.
The procedures described in this document do not of itself The procedures described in this document do not of itself
constitute a security risk since they do not cause any change in constitute a security risk since they do not cause any 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] references for security have been
replaced by [RFC4301]. Also, the reference to IKEv2 in [RFC4301] is updated with [RFC4301] and the current reference for IKEv2 is
out of date, and the current reference for IKEv2 is [RFC5996]. [RFC5996].
6. IANA Considerations 6. IANA Considerations
6.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
 End of changes. 9 change blocks. 
11 lines changed or deleted 23 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/