RFC 6898
Link Management Protocol Behavior Negotiation and Configuration Modifications
RFC 6898 🎀 Link Management Protocol Behavior Negotiation and Configuration Modifications
Here's the title block tea ☕✨
- Organization: Internet Engineering Task Force (IETF) 🌸
- Authors: D. Li (Huawei), D. Ceccarelli (Ericsson), and L. Berger (LabN) 👑
- Category: Standards Track 🔥
- ISSN: 2070-1721
- Date: March 2013 📅
- Updates: RFC 4204, RFC 4207, RFC 4209, and RFC 5818 🦋
- Obsoletes: nothing is listed in the title block
Table of Contents 📖
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. LMP Message Modifications .......................................4
2.1. Modified Message Formats ...................................4
2.2. Processing .................................................5
3. LMP Behavior Negotiation ........................................6
3.1. BehaviorConfig C-Type Format ...............................6
3.2. Processing .................................................7
4. Backward Compatibility ..........................................7
5. Security Considerations .........................................8
6. IANA Considerations .............................................9
6.1. New LMP Class Type .........................................9
6.2. New Capabilities Registry ..................................9
7. Normative References ...........................................10
8. Acknowledgments ................................................10
9. Contributors ...................................................10Abstract 💖
Okay so, the Link Management Protocol (LMP) is what coordinates the properties, use, and faults of data links in networks run by Generalized Multiprotocol Label Switching (GMPLS) 🌈. This document adds an LMP extension that lets nodes negotiate capabilities and show that they support LMP extensions ✨. The extension is compatible with implementations that don't support it 🫶.
This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818 💅.
Status of This Memo 📝
This is an Internet Standards Track document 🔥.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, has received public review, and has been approved for publication by the Internet Engineering Steering Group (IESG) 🙌. For more on Internet Standards, check Section 2 of RFC 5741 🤓.
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6898 🍓.
Copyright Notice ©️
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication 📜. Please read these carefully, because they describe your rights and restrictions for 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 they come without warranty, as described in the Simplified BSD License 💀.
1. Introduction ✨
The Link Management Protocol (LMP) [RFC4204] has been successfully deployed in networks controlled by Generalized Multiprotocol Label Switching (GMPLS) 🚀.
New LMP behaviors and protocol extensions have shown up in a bunch of IETF documents, which are listed later in this section 📚. It's likely that future extensions will be added to support more functions 🔮.
Here's the thing 🧚: if one LMP-capable node supports a new behavior or protocol extension but its adjacent node doesn't, it's really useful to have a protocol mechanism that discovers the capabilities of peer nodes. That way the right protocol extensions get selected and the correct features get enabled 💅. There are no such procedures defined in the base LMP specification [RFC4204]. [RFC4209] defined a specific mechanism to identify support for the functions in that document. This document defines an LMP extension that identifies supported LMP functions in a generic way, and it also explains how a node that supports these extensions talks to legacy nodes 🫶.
In [RFC4204], the basic behaviors are defined around the standard LMP messages: Config, Hello, Verify, Test, LinkSummary, and ChannelStatus 🎀. Per [RFC4204], these behaviors MUST be supported when LMP is implemented, and IANA assigned the message types 1 to 20 to these messages 🔥. This document assumes support for all functions required by [RFC4204] 💖.
In [RFC4207], the SONET/SDH technology-specific behavior and information for LMP is defined. The Trace behavior is added to LMP, and IANA assigned the message types 21 to 31 to the messages that provide the Trace function 🦋.
In [RFC4209], extensions to LMP are defined so it can be used between a peer node and an adjacent Optical Line System (OLS) 🌸. The LMP object class type and subobject class name were extended to support Dense Wavelength Division Multiplexing (DWDM) behavior 🌈.
In [RFC5818], the data channel consistency check behavior is defined, and IANA assigned the message types 32 to 34 to the messages that provide this behavior 🧁.
It's likely that future LMP extensions for other functions or technologies will need further LMP messages too 🔭.
This document describes an LMP extension, called behavior negotiation, that lets the nodes at the two ends of a link identify the LMP messages and functions supported by the adjacent node 👑. The extension uses a new CONFIG object. Using this new object doesn't rule out existing CONFIG objects or ones yet to be defined ✨.
This document also changes the format of messages that carry the CONFIG object so they can hold multiple objects 💅. Multiple CONFIG objects let behavior negotiation happen alongside the existing use of the CONFIG object, namely the HelloConfig C-Type defined in [RFC4204] and the LMP-WDM_CONFIG C-Type defined in [RFC4209] 🫧. This document also changes the ConfigAck message to include CONFIG objects, so the acceptable parameters are explicitly identified 🙌. Finally, it describes how a node that supports the extensions 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, and ConfigAck messages are modified by this document so they can include multiple CONFIG objects 🎀. The Config and ConfigNack messages were only defined to carry one CONFIG object in [RFC4204] 😭. The ConfigAck message was defined without carrying any CONFIG objects in [RFC4204], but this document modifies it so negotiated configuration parameters can be explicitly identified ✨. Including 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 Config message, as updated by this document, looks like this:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]The ConfigAck message, as updated by this document, looks like this:
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>[ <CONFIG> ... ]The ConfigNack message, as updated by this document, looks like this:
<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 in this document MAY include multiple CONFIG objects when they send a Config, ConfigAck, or ConfigNack message 🌟. A maximum of a single object of any particular C-type SHALL be included 🙅♀️. A node that receives a message with multiple CONFIG objects of the same C-type SHALL process the first object of that particular C-type and ignore any later CONFIG objects of the same C-type 👀. Unless the CONFIG object definition says otherwise, the ordering of CONFIG objects with different C-type values doesn't matter 🤷♀️.
Nodes that support the extensions in this document MUST include a BehaviorConfig type object when they send a Config message to a neighbor whose support for the extensions is either known or unknown 🫶. When the neighbor is known not to support the extensions, the object MUST NOT be sent 🚫. Including other CONFIG objects in a Config message is up to the message sender, and it's based on the rules in the CONFIG object definition 🎀. Nodes MAY include HelloConfig and LMP-WDM_CONFIG and BehaviorConfig object types in a single message 🌈.
Including multiple CONFIG objects in a ConfigNack message depends on how a received Config message was processed 🔍. Per [RFC4204], "Parameters where agreement was reached MUST NOT be included in the ConfigNack Message." So a ConfigNack message MUST NOT include CONFIG objects that are acceptable, and it MUST include any CONFIG objects that are not acceptable 🙅♀️. When a CONFIG object is included in a ConfigNack message, the object is, per [RFC4204], to include "acceptable alternate values for negotiable parameters" 💫.
When sending a ConfigAck message, nodes that support the extensions 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]. This document defines the LMP behavior negotiation procedure 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 so far:
This document defines a third C-Type to report and negotiate LMP mechanisms and behaviors 🎉. Using it indicates support for the extensions in this document 💜.
3.1. BehaviorConfig C-Type Format ✨
okay so the BehaviorConfig object lives under Class = 6, and its C-Type = 3 is named BehaviorConfig 🎀 here's the layout:
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 🚩 there are three of them, and they're the whole personality of this object:
S: 1 bit 🧪 this one says you support the Trace behavior of SONET/SDH technology, as defined in [RFC4207].
D: 1 bit 🌈 this one says you support the DWDM behavior defined in [RFC4209].
C: 1 bit ✅ this one says you support the data channel consistency check behavior defined in [RFC5818].
Must Be Zero (MBZ): variable length 🙈 the leftover bits in the flags field MUST be set to zero (0). This field MUST be sized so the object stays 32-bit aligned. ngl that alignment rule is very correct of it 💅
Other bits might get defined in future documents, and if that happens, the number of bits in the MBZ field is expected to change. Plot twist, but a predictable one ✨
3.2. Processing 💌
The inclusion of a BehaviorConfig type object in a message was already covered above, in Section 2.2 💖
When you're sending a BehaviorConfig type object, the N-bit (negotiable) in the LMP object header MUST be set (N=1) in the LMP object header. yes, it's said twice, and yes, it's on purpose 😭
When you send 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 you send a ConfigAck message, though, the flags field MUST be set to the value you received in the corresponding Config message. no improvising, bestie 🫶
When you receive 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. How unacceptable values in CONFIG objects get handled is defined in [RFC4204], and this document doesn't change that at all 🙅♀️
4. Backward Compatibility 🔁✨
The required use of the BehaviorConfig type CONFIG object lets nodes that support the extensions in this document explicitly spot a neighbor that doesn't. When a non-supporting node gets a Config message carrying the BehaviorConfig type CONFIG object (or multiple CONFIG objects), it does one of the following:
- a) Rejects the Config message because of the unknown BehaviorConfig object type, and sends a ConfigNack message that includes the unsupported C-type.
- b) Rejects the message because of multiple CONFIG objects, and sends a ConfigNack message that includes all but one of the CONFIG objects.
- c) Silently ignores one or more of the CONFIG objects, and responds with a ConfigAck message that does not include any CONFIG objects.
- d) Treats the message as malformed, and discards 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 hits the "retry limit", which is 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. (main character behavior: go back to what everyone already knows 💅)
5. Security Considerations 🔐💀
okay, this part is serious, so listen up 👀
[RFC4204] describes how LMP messages between peers can be secured, and those same measures apply equally to messages carrying the new CONFIG object defined in this document.
Alone, the procedures in this document don't create a security risk, because they don't cause any change in network state. Still, if the messages were intercepted or spoofed, it would be possible to cause bogus alerts in the management plane, or to make LMP peers think they could or could not operate protocol extensions. So the use of the LMP security measures is RECOMMENDED. Please don't skip this 🙏
Note, however, that the [RFC4204] references for security have been updated with [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) Parameters" registry, which has a subregistry called "LMP Object Class name space and Class type (C-Type)".
IANA has made an assignment from this registry as follows:
6 CONFIG [RFC4204]
CONFIG Object Class type name space:
C-Type Description Reference
------------ --------------------- ---------
3 BehaviorConfig RFC 68986.2. New Capabilities Registry 🎀
IANA has created a new subregistry of the "Link Management Protocol (LMP) Parameters" registry to track the Behavior Configuration bits defined in Section 2 of this document. It's called "LMP Behavior Configuration Flags" 🧚
Allocations from this registry are by Standards Action.
Bits in this registry are numbered from zero, with the most significant bit as the one transmitted first. The number of bits that can be present is limited by the length field of the CONFIG object, which works out to (255 x 32)-8 = 8152. IANA is strongly recommended to allocate new bits using the lowest available unused number. (lowest available, we love an efficient queue 💅)
The registry starts out populated like this:
Bit | Bit | Meaning | Reference
Number | Name | |
-------+------+----------------------------------------+----------
0 | S | SONET/SDH Test support | RFC 6898
1 | D | DWDM support | RFC 6898
2 | C | Data Channel consistency check support | RFC 68987. 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. 🛡️
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 🔐
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. 🔗
[RFC4207] Lang, J. and D. Papadimitriou, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", RFC 4207, October 2005. 🧪
[RFC4209] 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] Li, 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., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. 🧩
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.comAuthors' Addresses 💌
Dan Li
Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base,
Shenzhen 518129
China
Phone: +86 755-289-70230
EMail: huawei.danli@huawei.com
Daniele Ceccarelli
Ericsson
Via E. Melen, 77
Genova - Erzelli
Italy
EMail: daniele.ceccarelli@ericsson.com
Lou Berger
LabN Consulting, L.L.C.
EMail: lberger@labn.net📦 where this page comes from
- ietf: rfc6898 2013-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms