Link Management Protocol Behavior Negotiation and Configuration Modifications
updates
- rfc-4204 — Link Management Protocol (LMP)
- rfc-4207 — Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages
- rfc-4209 — Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
- rfc-5818 — Data Channel Status Confirmation Extensions for the Link Management Protocol
Extracted elements (21)
CONFIG objects in Config and ConfigNack were limited to one object each in RFC 4204, and ConfigAck carried none. This document extends all three messages to support multiple CONFIG objects so that behavior negotiation (BehaviorConfig) can proceed concurrently with existing HelloConfig and LMP-WDM_CONFIG usage without requiring separate message exchanges.
The BehaviorConfig mechanism was introduced because the base LMP specification (RFC 4204) defined no general capability discovery procedure for adjacent nodes. RFC 4209 had defined an ad-hoc mechanism specific to that document; this document generalizes it so future LMP extensions can reuse the same negotiation framework.
The BehaviorConfig object uses the N-bit (negotiable) to allow the object's flags to be subject to negotiation, consistent with the LMP object header convention. This ensures that nodes can signal willingness to accept different capability sets rather than treating the values as fixed requirements.
When a non-supporting legacy node receives a Config message with BehaviorConfig or multiple CONFIG objects, it may: (a) send ConfigNack with unsupported C-type, (b) send ConfigNack for multiple CONFIG objects, (c) silently ignore unknown objects and respond with ConfigAck without CONFIG objects, or (d) discard the message silently. A supporting node SHOULD infer lack of extension support in cases (a)-(c) and revert to prior Config usage.
A ConfigNack message MUST NOT include CONFIG objects that are acceptable, and MUST include any CONFIG objects that are not acceptable, with acceptable alternate values for negotiable parameters as required by RFC 4204.
A maximum of a single CONFIG object of any particular C-type SHALL be included in a message. A receiver that receives multiple CONFIG objects of the same C-type SHALL process only the first and ignore any subsequent ones.
A node supporting these extensions MUST include a BehaviorConfig object when sending a Config message to a neighbor whose support is either known or unknown. When the neighbor is known NOT to support the extensions, the BehaviorConfig object MUST NOT be sent.
Any bit set in the MBZ portion of the BehaviorConfig flags field MUST be interpreted as unacceptable; processing of unacceptable values follows RFC 4204.
MBZ bits in the BehaviorConfig object MUST be set to zero and MUST be sized to ensure 32-bit alignment of the object.
When a node identifies a neighbor as not supporting these extensions (including via retry-limit expiry for behavior (d)), it SHOULD follow previously defined Config message usage without BehaviorConfig objects.
When sending a BehaviorConfig object in Config or ConfigNack messages, the flags field SHOULD be set based on the supported capabilities of the sending node. When sending a ConfigAck, the flags field MUST be set to the value received in the corresponding Config message.
When sending a BehaviorConfig object, the N-bit (negotiable) in the LMP object header MUST be set (N=1).
When sending a ConfigAck message in response to a Config that includes a BehaviorConfig object, the node MUST include all CONFIG objects that were received in the corresponding Config message.
RFC 6898 defines BehaviorConfig as a new C-Type (C-Type = 3) under the existing CONFIG object class (Class = 6) in LMP. This object is used to negotiate supported LMP behaviors and extensions between adjacent nodes.
The Config message is modified to allow multiple CONFIG objects: '<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> <LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]'. This extends the single-object constraint from RFC 4204.
The ConfigAck message is modified to carry CONFIG objects: '<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> <REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID> [ <CONFIG> ... ]'. RFC 4204 defined ConfigAck without any CONFIG objects; this extension enables explicit identification of negotiated parameters.
The ConfigNack message is modified to allow multiple CONFIG objects: '<ConfigNack Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> <REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG> [ <CONFIG> ... ]'.
IANA assigned C-Type = 3 (BehaviorConfig) under the existing 'LMP Object Class name space and Class type (C-Type)' subregistry for CONFIG (Class 6) in the 'Link Management Protocol (LMP) Parameters' registry.
IANA created a new subregistry 'LMP Behavior Configuration Flags' under the LMP Parameters registry. Allocations require Standards Action. Bits are numbered from zero as the most significant bit. Initial entries: bit 0 (S) = SONET/SDH Test support, bit 1 (D) = DWDM support, bit 2 (C) = Data Channel consistency check support. Maximum 8152 bits are possible given the CONFIG object length field.
The security measures defined in RFC 4204 for LMP peer communication (referencing IPsec via RFC 4301 and IKEv2 via RFC 5996) are equally applicable to messages carrying the new BehaviorConfig object. Use of LMP security measures is RECOMMENDED because intercepted or spoofed BehaviorConfig messages could cause peers to incorrectly enable or disable protocol extensions, resulting in bogus management-plane alerts.
The BehaviorConfig object is a 32-bit field containing three 1-bit flags (S, D, C) in the most significant positions followed by a Must Be Zero (MBZ) field padded to ensure 32-bit alignment. The S bit signals SONET/SDH Trace support (RFC 4207), D bit signals DWDM support (RFC 4209), and C bit signals data channel consistency check support (RFC 5818).