wdiff rfc6898.original rfc6898.txt

Network Working Group Dan Li
Internet Draft Engineering Task Force (IETF) D. Li
Request for Comments: 6898 Huawei
Updates: 4204, 4207, 4209, 5818 D. Ceccarelli
Category: Standards Track Ericsson
Lou
ISSN: 2070-1721 L. Berger
LabN

Expires: August 2013 February 8,
March 2013

Link Management Protocol Behavior Negotiation and
Configuration Modifications

draft-ietf-ccamp-lmp-behavior-negotiation-11.txt

Abstract

The Link Management Protocol (LMP) is used to coordinate the
properties, use, and faults of data links in networks controlled by
Generalized Multiprotocol Label Switching (GMPLS)-controlled networks. (GMPLS). 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.

This document updates RFC 4204, RFC 4207, RFC 4209 4209, and RFC 5818.

Status of this 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 an Internet Standards Track document.

This document is a product 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
(IETF). It represents the consensus of six
months the IETF community. It has
received public review and may be updated, replaced, or obsoleted has been approved for publication by other documents
at any time. It the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work available in progress."

The list Section 2 of RFC 5741.

Information about the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list status of Internet-Draft Shadow Directories can this document, any errata,
and how to provide feedback on it may be accessed obtained at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 5, 2013.
http://www.rfc-editor.org/info/rfc6898.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without 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

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 ................................................ 3 ....................................................3
1.1. Conventions Used in This Document ..........................4
2. LMP Message Modifications.................................... 4 Modifications .......................................4
2.1. Modified Message Formats................................ 4 Formats ...................................4
2.2. Processing ............................................. 5 .................................................5
3. LMP Behavior Negotiation..................................... 6 Negotiation ........................................6
3.1. BehaviorConfig C-Type Format............................ 6 Format ...............................6
3.2. Processing ............................................. 7 .................................................7
4. Backward Compatibility....................................... 7 Compatibility ..........................................7
5. Security Considerations...................................... 8 Considerations .........................................8
6. IANA Considerations ......................................... 9 .............................................9
6.1. New LMP Class Type...................................... 9 Type .........................................9
6.2. New Capabilities Registry............................... 9 Registry ..................................9
7. Contributors ............................................... 10 Normative References ...........................................10
8. Acknowledgments ............................................ 10 ................................................10
9. References ................................................. 10
9.1. Normative References................................... 10
10. Authors' Addresses ........................................ 11 Contributors ...................................................10

1. Introduction

The Link Management Protocol (LMP) [RFC4204] has been successfully
deployed in networks controlled by Generalized Multiprotocol Label
Switching (GMPLS)-
controlled networks. (GMPLS).

New LMP behaviors and protocol extensions have been introduced in a
number of IETF documents documents, as set out later in this section. It is
likely that future extensions will be made to support additional
functions.

In a network, if one LMP-capable node supports a new behavior or
protocol extension but its adjacent node does not, it is beneficial
to have a protocol mechanism to discover the capabilities of peer
nodes so that the right protocol extensions can be selected and the
correct features can be enabled. There are no such procedures
defined in the base LMP specification [RFC4204]. [RFC4209] defined a
specific mechanism to identify support for the functions specified in
that document. This document defines an LMP extension to support the
identification of supported LMP functions in a generic fashion, as
well as how a node supporting these extensions would communicate with
legacy nodes.

In [RFC4204], the basic behaviors have been defined around the use of
the standard LMP messages, which include Config, Hello, Verify, Test,
LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors MUST
be supported when LMP is implemented, and the message types 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
information for LMP is defined. The Trace behavior is added to LMP,
and the message types from 21 to 31 were have been assigned by IANA for
the messages that provide the TRACE 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 subobject class name have been extended to
support DWDM Dense Wavelength Division Multiplexing (DWDM) behavior.

In [RFC5818], the data channel consistency check behavior is defined,
and the message types from 32 to 34 have been assigned by IANA for
messages that provide this behavior.

It is likely that future extensions to LMP for other functions or
technologies will require the definition of further LMP messages.

This document describes an LMP extension, which is referred to as behavior
negotiation, which that enables the nodes at the ends of a link to 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. objects.

This document also modifies the format of messages that carry the
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
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
that supports the extensions defined in this document interacts with
a legacy LMP-capable node.

1.1. 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].

2. LMP Message Modifications

LMP Config, ConfigNack 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 one 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.

The message formats in the sections that follow use Backus-Naur Form
(BNF) encoding as defined in [RFC5511].

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 that support the extensions defined in this document MAY
include multiple CONFIG objects when sending a Config, ConfigAck ConfigAck, and
ConfigNack message. A maximum of a single object of any particular
C-type SHALL be included. A node which that 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 with different C-type
values is not significant.

Nodes that 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. When the neighbor is known to not support the extensions,
the object MUST NOT be sent. Inclusion of other CONFIG objects in a
Config message is at the discretion of the message sender, sender and is
based on the rules defined as part of CONFIG object definition.
Nodes MAY include HelloConfig, LMP_WDM_CONFIG, 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] [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 that 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
of LMP [RFC4204]. The LMP behavior negotiation procedure is defined
in this document as an addition to 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].

Two class types have been defined:

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

- C-Type = 2, LMP_WDM_CONFIG, LMP-WDM_CONFIG, defined in [RFC4209]

This document defines a third C-Type to report and negotiate LMP
mechanisms and behaviors. Its usage indicates support for the
extensions defined in this document.

3.1. BehaviorConfig C-Type Format

Class = 6

- C-Type = (To be assigned by IANA), 3, BehaviorConfig

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|C| Must Be Zero (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flags:

S: 1 bit

This bit indicates support for the Trace behavior of SONET/SDH
technology-specific defined in [RFC4207].

D: 1 bit

This bit indicates support for the DWDM behavior defined in
[RFC4209].

C: 1 bit

This bit indicates support for the data channel consistency check
behavior defined in [RFC5818].

Must Be Zero (MBZ): Variable length

The remaining bits in the flags field MUST be set to zero (0).
This field MUST be sized to ensure 32 bit 32-bit alignment of the object.

Other bits may be defined in future documents, in which case the
number of bits in the MBZ field is expected to change.

3.2. Processing

The inclusion of a BehaviorConfig type object in a message is
discussed above in Section 2.2.

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.

When sending a BehaviorConfig type object in Config and ConfigNack
messages, the flags field SHOULD be set based on the supported
capabilities of the sending node. When sending a ConfigAck message,
the flags field MUST be set to the value received in the
corresponding Config message.

When receiving a BehaviorConfig type object, the node compares the
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.

4. Backward Compatibility

The required use of the BehaviorConfig type CONFIG object enables
nodes which that 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 objects, its behavior is to be
one of the following behaviors:

a) Reject the Config message because of the unknown BehaviorConfig
object type and send a ConfigNack message which includes the
unsupported C-type.

b) Reject the message because of multiple CONFIG objects and send a
ConfigNack message which includes all but one of the CONFIG
objects.

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,
the "retry limit", defined in [RFC4204], 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,
and these measures are equally applicable to messages carrying the
new CONFIG object defined in this document.

The

Alone, the procedures described in this document do not of itself constitute a
security risk 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.

Note, however however, that [RFC4204] references for security have been
updated with [RFC4301] [RFC4301], and the current reference for IKEv2 is
[RFC5996].

6. IANA Considerations

6.1. New LMP Class Type

IANA maintains the "Link Management Protocol (LMP)" registry (LMP) Parameters"
registry, which has a subregistry called "LMP Object Class name space
and Class type (C-Type)".

IANA is requested to make has made an assignment from this registry as follows:

6 CONFIG [RFC4204]

CONFIG Object Class type name space:

C-Type Description Reference
------------ --------------------- ---------
3(suggested)
3 BehaviorConfig [This.I-D] RFC 6898

6.2. New Capabilities Registry

IANA is requested to create has created a new subregistry of the "Link Management Protocol (LMP)"
(LMP) Parameters" registry to track the Behavior Configuration bits
defined in Section 2 of this document. It is
suggested that this This registry be is called "LMP
Behavior Configuration Flags".

Allocations from this registry are by Standards Action.

Bits in this registry are numbered from zero as the most significant
bit (transmitted first). The number of bits that can be present is
limited by the length field of the CONFIG object object, which gives rise to
(255 x 32)-8 = 8152. IANA is strongly recommended to allocate new
bits with the lowest available unused number.

The registry is initially populated as follows:

7. Contributors

Diego Caviglia
Ericsson
Via A. Negrone 1/A 16153
Genoa Italy
Phone: +39 010 600 3736
Email: diego.caviglia@ericsson.com

8. Acknowledgments

Thanks to Adrian Farrel and Richard Graveman for their useful
comments.

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005 2005.

[RFC5996] C. Kaufman, P. C., Hoffman, Y. P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol: IKEv2", Protocol Version 2 (IKEv2)", RFC
5996, September 2010.

[RFC4204] J. Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
October 2005.

[RFC4207] J. Lang, Ed., J. and D. Papadimitriou, "Synchronous Optical
Network (SONET)/
Synchronous (SONET)/Synchronous Digital Hierarchy (SDH)
Encoding for Link Management Protocol (LMP) Test
Messages", RFC 4207, October 2005.

[RFC4209] A. Fredette, A., Ed., and J. Lang, Ed., "Link Management
Protocol (LMP) for Dense Wavelength Division Multiplexing
(DWDM) Optical Line Systems", RFC 4209, October 2005.

[RFC5818] D. Li, Ed., D., Xu, H., Bardalai, S., Meuric, J., and D. Caviglia,
"Data Channel Status Confirmation Extensions for the Link
Management Protocol", RFC 5818, April 2010.

[RFC5511] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.

10.

8. Acknowledgments

Thanks to Adrian Farrel and Richard Graveman for their useful
comments.

9. Contributors

Diego Caviglia
Ericsson
Via E. Melen, 77
Genova - Erzelli
Italy
Phone: +39 010 600 3736
EMail: diego.caviglia@ericsson.com

Authors' Addresses

Dan Li
Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base,
Shenzhen 518129
China
Phone: +86 755-289-70230
Email:
EMail: huawei.danli@huawei.com

Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A E. Melen, 77
Genova - Sestri Ponente Erzelli
Italy
Email:
EMail: daniele.ceccarelli@ericsson.com

Lou Berger
LabN Consulting, L.L.C.
Email:
EMail: lberger@labn.net