draft-ietf-ccamp-lmp-behavior-negotiation-06.txt   draft-ietf-ccamp-lmp-behavior-negotiation-07.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: January 2013 July 30, 2012 Expires: June 2013 December 5, 2012
Link Management Protocol Behavior Negotiation and Link Management Protocol Behavior Negotiation and
Configuration Modifications Configuration Modifications
draft-ietf-ccamp-lmp-behavior-negotiation-06.txt draft-ietf-ccamp-lmp-behavior-negotiation-07.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.
This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818.
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.
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 January 29, 2013.
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 4, line 29 skipping to change at page 4, line 29
LMP_WDM_CONFIG C-Type defined in [RFC4209]. This document modifies LMP_WDM_CONFIG C-Type defined in [RFC4209]. This document modifies
the ConfigAck message to include CONFIG objects so that acceptable the ConfigAck message to include CONFIG objects so that acceptable
parameters are explicitly identified. It also describes how a node parameters are explicitly identified. It also describes how a node
which supports the extensions defined in this document interacts which supports the extensions defined in this document interacts
with a legacy LMP node. with a legacy LMP node.
2. LMP Message Modifications 2. LMP Message Modifications
LMP Config, ConfigNack and ConfigAck messages are modified by this LMP Config, ConfigNack and ConfigAck messages are modified by this
document to allow for the inclusion of multiple CONFIG objects. The document to allow for the inclusion of multiple CONFIG objects. The
Config and ConfigNack messages were only defined to carry on CONFIG Config and ConfigNack messages were only defined to carry one CONFIG
object in [RFC4204]. The ConfigAck message, which was defined object in [RFC4204]. The ConfigAck message, which was defined
without carrying any CONFIG objects in [RFC4204], is modified to without carrying any CONFIG objects in [RFC4204], is modified to
enable explicit identification of negotiated configuration enable explicit identification of negotiated configuration
parameters. The inclusion of CONFIG objects in ConfigAck messages is parameters. The inclusion of CONFIG objects in ConfigAck messages is
triggered by the use of the BehaviorConfig object (defined below) in triggered by the use of the BehaviorConfig object (defined below) in
a received Config message. a received Config message.
2.1. Modified Message Formats 2.1. Modified Message Formats
The format of the Config message as updated by this document is as The format of the Config message as updated by this document is as
skipping to change at page 5, line 27 skipping to change at page 5, line 27
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. (But not when the neighbor is known to not support the unknown. (When the neighbor is known to not support the extensions,
extensions.) Inclusion of other CONFIG objects in a Config message the object MUST NOT be sent.) Inclusion of other CONFIG objects in a
is at the discretion of the message sender, and is based on the Config message is at the discretion of the message sender, and is
rules defined by as part of CONFIG object definition. Nodes MAY based on the rules defined as part of CONFIG object definition.
include, HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object types in Nodes MAY include, HelloConfig, LMP_WDM_CONFIG, BehaviorConfig
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
objects which are not acceptable. When a CONFIG object is included objects which are not acceptable. When a CONFIG object is included
in a ConfigNack message, per [RFC4204], the object is to include in a ConfigNack message, per [RFC4204], the object is to include
"acceptable alternate values for negotiable parameters". "acceptable alternate values for negotiable parameters".
 End of changes. 6 change blocks. 
11 lines changed or deleted 12 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/