draft-ietf-ccamp-lmp-behavior-negotiation-04.txt   draft-ietf-ccamp-lmp-behavior-negotiation-05.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: December 2011 June 7, 2011 Expires: July 2012 January 17, 2012
Link Management Protocol Behavior Negotiation and Link Management Protocol Behavior Negotiation and
Configuration Modifications Configuration Modifications
draft-ietf-ccamp-lmp-behavior-negotiation-04.txt draft-ietf-ccamp-lmp-behavior-negotiation-05.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 1, line 46 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 December 7, 2011. This Internet-Draft will expire on July 16, 2012.
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 7, line 26 skipping to change at page 7, line 26
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 MBZ bits field is expected to change. number of MBZ bits 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
the LMP object header must be set (N=1) in the LMP object header. the LMP object header MUST be set (N=1) in the LMP object header.
When sending a BehaviorConfig type object in Config and ConfigNack When sending a BehaviorConfig type object in Config and ConfigNack
messages, the flags field SHOULD be set based on the supported messages, the flags field SHOULD be set based on the supported
capabilities of the sending node. When sending a ConfigAck message, capabilities of the sending node. When sending a ConfigAck message,
the flags field MUST be set to the value received in the the flags field MUST be set to the value received in the
corresponding Config message. corresponding Config message.
When receiving a BehaviorConfig type object, the node compares the When receiving a BehaviorConfig type object, the node compares the
flags field against its capacities. Any bit set in the MBZ portion flags field against its capacities. Any bit set in the MBZ portion
of the flags field MUST be interpreted as unacceptable. Processing of the flags field MUST be interpreted as unacceptable. Processing
skipping to change at page 8, line 17 skipping to change at page 8, line 17
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
with a ConfigAck message that does not include any CONFIG objects. with a ConfigAck message that does not include any CONFIG objects.
d) Treat the message as malformed, and discard it without any d) Treat the message as malformed, and discard it without any
response. response.
Behaviors (a) and (b) result in ConfigNack messages with a Behaviors (a) and (b) result in ConfigNack messages with a
BehaviorConfig type object whose contents are identical to what was BehaviorConfig type object whose contents are identical to what was
sent in the Config message. Behavior (c) results in a ConfigAck sent in the Config message. Behavior (c) results in a ConfigAck
message without a BehaviorConfig type CONFIG object. In each of message without a BehaviorConfig type CONFIG object. In each of
these cases, the node SHOULD explicitly identify that the LMP these cases, the node SHOULD explicitly identify that the LMP
neighbor does not support the extensions defined in this document. neighbor does not support the extensions defined in this document.
Behavior (d) results in no response at all. When the node reaches Behavior (d) results in no response at all. When the node reaches
the, [RFC4204] defined, "retry limit", the node SHOULD infer that the, [RFC4204] defined, "retry limit", the node SHOULD infer that
the LMP neighbor does not support the extensions defined in this the LMP neighbor does not support the extensions defined in this
document. document.
Once a node identifies a neighbor as not supporting the extensions Once a node identifies a neighbor as not supporting the extensions
skipping to change at page 11, line 10 skipping to change at page 11, line 10
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.
9.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-03.txt, April, 2011.
10. 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 Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
 End of changes. 8 change blocks. 
9 lines changed or deleted 9 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/