draft-ietf-ccamp-lmp-behavior-negotiation-10.txt   draft-ietf-ccamp-lmp-behavior-negotiation-11.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: July 2013 January 24, 2013 Expires: August 2013 February 8, 2013
Link Management Protocol Behavior Negotiation and Link Management Protocol Behavior Negotiation and
Configuration Modifications Configuration Modifications
draft-ietf-ccamp-lmp-behavior-negotiation-10.txt draft-ietf-ccamp-lmp-behavior-negotiation-11.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)-controlled networks. This Multiprotocol Label Switching (GMPLS)-controlled networks. This
document defines an extension to LMP to negotiate capabilities and document defines an extension to LMP to negotiate capabilities and
indicate support for LMP extensions. The defined extension is indicate support for LMP extensions. The defined extension is
compatible with non-supporting implementations. compatible 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 July 21, 2013. This Internet-Draft will expire on August 5, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 5, line 25 skipping to change at page 5, line 27
The format of the ConfigNack message as updated by this document is The format of the ConfigNack message as updated by this document is
as follows: as follows:
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID> <ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID> <LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<CONFIG> [ <CONFIG> ... ] <CONFIG> [ <CONFIG> ... ]
2.2. Processing 2.2. Processing
Nodes which support the extensions defined in this document MAY Nodes that support the extensions defined in this document MAY
include multiple CONFIG objects when sending a Config, ConfigAck and include multiple CONFIG objects when sending a Config, ConfigAck and
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 with different C-type
values is not significant.
Nodes which support the extensions defined in this document MUST Nodes that 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 object Nodes MAY include HelloConfig, LMP_WDM_CONFIG, BehaviorConfig 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
skipping to change at page 7, line 18 skipping to change at page 7, line 23
[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].
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 This field MUST be sized to ensure 32 bit alignment of the object.
LMP object header and MUST include enough bits so the Length
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 bits in MBZ 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
skipping to change at page 8, line 4 skipping to change at page 8, line 6
of the flags field MUST be interpreted as unacceptable. Processing of the flags field MUST be interpreted as unacceptable. Processing
related to unacceptable values in CONFIG objects is defined in related to unacceptable values in CONFIG objects is defined in
[RFC4204] and is not modified by this document. [RFC4204] and is not modified by this document.
4. Backward Compatibility 4. Backward Compatibility
The required use of the BehaviorConfig type CONFIG object enables The required use of the BehaviorConfig type CONFIG object enables
nodes which support the extensions defined in this document to nodes which support the extensions defined in this document to
explicitly identify when a neighboring node does not. When a non- explicitly identify when a neighboring node does not. When a non-
supporting node receives a Config message with the BehaviorConfig supporting node receives a Config message with the BehaviorConfig
type CONFIG object or multiple CONFIG objects its behavior is likely type CONFIG object or multiple CONFIG objects its behavior is to be
to be one of the following behaviors: one of the following behaviors:
a) Reject the Config message because of the unknown BehaviorConfig a) Reject the Config message because of the unknown BehaviorConfig
object type and send a ConfigNack message which includes the object type and send a ConfigNack message which includes the
unsupported C-type. unsupported C-type.
b) Reject the message because of multiple CONFIG objects and send a b) Reject the message because of multiple CONFIG objects and send a
ConfigNack message which includes all but one of the CONFIG ConfigNack message which includes all but one of the CONFIG
objects. objects.
c) Silently ignore the one or more of the CONFIG object, and respond c) Silently ignore the one or more of the CONFIG object, and respond
 End of changes. 8 change blocks. 
11 lines changed or deleted 10 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/