RFC 4204
Link Management Protocol (LMP)
Link Management Protocol (LMP) 🎀
Okay bestie, first the ID card 🪪. This is RFC 4204, Link Management Protocol (LMP), written by J. Lang, Ed. from Sonos, Inc. It's dated October 2005 and it's a Standards Track document, so it's officially a real protocol spec 💅.
Status of This Memo
This is an Internet standards track protocol for the Internet community, and the authors are openly asking for discussion and suggestions for improvements 🌸. To check the standardization state and status of this protocol, look at the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
For scalability reasons, multiple data links can be combined into one traffic engineering (TE) link ✨. Managing TE links isn't limited to in-band messaging either, since out-of-band techniques can be used too 🧚.
This document defines a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. LMP is the one that keeps control channel connectivity going, verifies the physical connectivity of the data links, correlates link property information, suppresses downstream alarms, and localizes link failures for protection and restoration purposes. It does all of this across multiple kinds of networks 👑.
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................5
2. LMP Overview ....................................................6
3. Control Channel Management ......................................8
3.1. Parameter Negotiation ......................................9
3.2. Hello Protocol ............................................10
4. Link Property Correlation ......................................13
5. Verifying Link Connectivity ....................................15
5.1. Example of Link Connectivity Verification .................18
6. Fault Management ...............................................19
6.1. Fault Detection ...........................................20
6.2. Fault Localization Procedure ..............................20
6.3. Examples of Fault Localization ............................21
6.4. Channel Activation Indication .............................22
6.5. Channel Deactivation Indication ...........................23
7. Message_Id Usage ...............................................23
8. Graceful Restart ...............................................24
9. Addressing .....................................................25
10. Exponential Back-off Procedures ...............................26
10.1. Operation ...............................................26
10.2. Retransmission Algorithm ................................27
11. LMP Finite State Machines .....................................28
11.1. Control Channel FSM .....................................28
11.2. TE Link FSM .............................................32
11.3. Data Link FSM ...........................................34
12. LMP Message Formats ...........................................38
12.1. Common Header ...........................................39
12.2. LMP Object Format .......................................41
12.3. Parameter Negotiation Messages ..........................42
12.4. Hello Message (Msg Type = 4) ............................43
12.5. Link Verification Messages ..............................43
12.6. Link Summary Messages ...................................47
12.7. Fault Management Messages ...............................49
13. LMP Object Definitions ........................................50
13.1. CCID (Control Channel ID) Class .........................50
13.2. NODE_ID Class ...........................................51
13.3. LINK_ID Class ...........................................52
13.4. INTERFACE_ID Class ......................................53
13.5. MESSAGE_ID Class ........................................54
13.6. CONFIG Class ............................................55
13.7. HELLO Class .............................................56
13.8. BEGIN_VERIFY Class ......................................56
13.9. BEGIN_VERIFY_ACK Class ..................................58
13.10. VERIFY_ID Class ........................................59
13.11. TE_LINK Class ..........................................59
13.12. DATA_LINK Class ........................................61
13.13. CHANNEL_STATUS Class ...................................65
13.14. CHANNEL_STATUS_REQUEST Class ...........................68
13.15. ERROR_CODE Class .......................................70
14. References ....................................................71
14.1. Normative References ....................................71
14.2. Informative References ..................................72
15. Security Considerations .......................................73
15.1. Security Requirements ...................................73
15.2. Security Mechanisms .....................................74
16. IANA Considerations ...........................................76
17. Acknowledgements ..............................................83
18. Contributors ..................................................831. Introduction ✨
Okay, big picture first 🔥. Networks are being built with routers, switches, crossconnects, dense wavelength division multiplexed (DWDM) systems, and add-drop multiplexors (ADMs). They share a common control plane, like Generalized MPLS (GMPLS), so they can allocate resources dynamically and stay survivable using protection and restoration techniques 💖.
A pair of nodes can have thousands of interconnects. Each interconnect might hold multiple data links when multiplexing is in play, like Frame Relay DLCIs at Layer 2, or TDM slots and WDM wavelengths at Layer 1 🌈. For scalability, multiple data links may be combined into a single traffic-engineering (TE) link.
To talk to each other for routing, signaling, and link management, nodes need a pair of IP interfaces that are mutually reachable. We call that pair a control channel 🦋. Here's the catch: "mutually reachable" doesn't mean the two interfaces are directly connected by an IP link. There could be an IP network sitting between them 🙈. Also, the interface that carries the control messages might not be the same one the data flows over.
This document defines LMP, which runs between a pair of nodes and is used to manage TE links and verify reachability of the control channel. For this document, those nodes are called "LMP neighbors" or simply "neighboring nodes" 🫶.
In GMPLS, the control channels between two adjacent nodes no longer have to use the same physical medium as the data links between them 🧚. A control channel could ride a separate virtual circuit, a wavelength, a fiber, an Ethernet link, an IP tunnel routed over a separate management network, or a multi-hop IP network. Here's why that matters: if a control channel is logically or physically diverse from its data links, the health of the control channel doesn't necessarily tell you the health of the data links, and vice versa 😭. So a clean separation between the fate of the control channel and the data links must be made. New mechanisms must be developed to manage the data links, both for link provisioning and for fault management.
One of the jobs LMP handles is checking that the grouping of links into TE links, plus the properties of those links, match at both endpoints. This is called "link property correlation" 💅. LMP can also pass those link properties to the IGP module, which can then announce them to other nodes in the network. And LMP can tell the signaling module which TE links map to which control channels. Basically, LMP is the valuable "glue" in the control plane 🎀.
The control network (single or multi-hop) is necessary for communication to happen, but it's by no means sufficient 💀. If two interfaces are separated by an IP network, faults in that IP network can leave no IP path from one interface to the other, which interrupts communication between them. On the flip side, not every failure in the control network affects a given control channel, which is exactly why control channels need to be established and managed 🌸.
For this document, each node that a data link terminates on can see it as either a 'port' or a 'component link', depending on the multiplexing capability of that endpoint. Component links are multiplex capable, while ports are not 🍓. This distinction matters a lot, because managing these links (resource allocation, label assignment, and physical verification, for example) is different depending on multiplexing capability.
Here are some examples. A Frame Relay switch can demultiplex an interface into virtual circuits based on DLCIs 🦋. Similarly, a SONET crossconnect with OC-192 interfaces may be able to demultiplex the OC-192 stream into four OC-48 streams 👑. When multiple interfaces get grouped into a single TE link using link bundling [RFC4201], the link resources have to be identified at three levels: Link_Id, the component interface Id, and the label that identifies a virtual circuit, timeslot, and so on. Resource allocation happens at the lowest level (the labels), but physical connectivity happens at the component link level 🌈.
Now a different example. Say an optical switch (for example, a PXC) transparently switches OC-192 lightpaths ✨. If multiple interfaces are grouped into a single TE link again, link bundling [RFC4201] is not required, and only two levels of identification are needed: Link_Id and Port_Id. In this case both resource allocation and physical connectivity happen at the lowest level, which is the port level 💜.
To make sure data links with different multiplexing capabilities can interwork, LMP-capable devices SHOULD allow sub-channels of a component link to be locally configured as (logical) data links 🧚. For example, imagine a router with 4 OC-48 interfaces connected through a 4:1 MUX to a cross-connect with OC-192 interfaces. The cross-connect should be able to configure each sub-channel (for example, an STS-48c SPE, if the 4:1 MUX is a SONET MUX) as a data link 🔥.
LMP is designed to support aggregating one or more data links into a TE link. That can mean ports into TE links, or component links into TE links 🫶. The whole point of forming a TE link is to group and map information about certain physical resources, and their properties, into the information that Constrained SPF uses for path computation and that GMPLS signaling uses too 💖.
More parts are coming, so stay tuned, bestie 🦋✨
1.1. Terminology 🧚
Okay bestie, first up are the key words. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119]. Those are the official vibes, so don't freestyle them. 💅
You're also expected to already know the terminology in [RFC3471], [RFC4202], and [RFC4201]. No pressure! 🌸
Bundled Link: Per [RFC4201], a bundled link is a TE link where, for GMPLS signaling purposes, a combination of <link identifier, label> is NOT enough to unambiguously identify the resources an LSP is using. A bundled link is made up of two or more component links. 🎀
Control Channel: A control channel is a pair of mutually reachable interfaces that nodes use to talk to each other for routing, signaling, and link management. It's the group chat that keeps everyone in sync! 💬
Component Link: Per [RFC4201], a component link is a subset of the resources of a TE Link where (a) the partition is minimal, and (b) inside each subset, a label is enough to unambiguously identify the resources an LSP is using. Tiny, precise, iconic. ✨
Data Link: A data link is a pair of interfaces used to transfer user data. Lowkey the big plot twist here is that in GMPLS, the control channel(s) between two adjacent nodes are no longer required to use the same physical medium as the data links between those nodes. Freedom! 🦋
Link Property Correlation: This is a procedure for correlating the local and remote properties of a TE link. Matching notes so everyone's on the same page. 🫶
Multiplex Capability: The ability to multiplex/demultiplex a data stream into sub-rate streams for switching purposes. Splitting and merging the streams, very chef's kiss. 🍓
Node_Id: For a node running OSPF, the LMP Node_Id is the same as the address contained in the OSPF Router Address TLV. For a node running IS-IS and advertising the TE Router ID TLV, the Node_Id is the same as the advertised Router ID. It's giving consistency. 👑
Port: An interface that terminates a data link. 💜
TE Link: Per [RFC4202], a TE link is a logical construct that represents a way to group and map the information about certain physical resources (and their properties) that interconnect LSRs. That info then gets used by Constrained SPF for path computation, and by GMPLS signaling. Main character energy for a construct! 🌈
Transparent: A device is called X-transparent if it forwards incoming signals from input to output without examining or modifying the X aspect of the signal. For example, a Frame Relay switch is network-layer transparent, and an all-optical switch is electrically transparent. The "transparent" is doing a lot here, ngl. 🙈
2. LMP Overview ✨
Okay so LMP has two core procedures: control channel management and link property correlation. Control channel management is how you establish and maintain control channels between adjacent nodes. It's done with a Config message exchange plus a fast keep-alive mechanism between the nodes. The fast keep-alive is required if lower-level mechanisms aren't available to detect control channel failures. 🔥
Link property correlation is how you synchronize the TE link properties and verify the TE link configuration. Iconic duo. 👯♀️
LMP requires that a pair of nodes have at least one active bi-directional control channel between them. Each direction of the control channel is identified by a Control Channel Id (CC_Id), and the two directions get coupled together using the LMP Config message exchange. Except for Test messages, which may be limited by the transport mechanism for in-band messaging, ALL LMP packets run over UDP with an LMP port number. The link level encoding of the control channel is outside the scope of this document. Not our problem, bestie! 🦋
An "LMP adjacency" forms between two nodes when at least one bi-directional control channel is established between them. You can have multiple control channels active at once for each adjacency. Control channel parameters, however, MUST be individually negotiated for each control channel. If the LMP fast keep-alive is used over a control channel, LMP Hello messages MUST be exchanged over that control channel. Other LMP messages MAY be transmitted over any of the active control channels between a pair of adjacent nodes. One or more active control channels can be grouped into a logical control channel for signaling, routing, and link property correlation purposes. Teamwork makes the dream work! 🫶
The link property correlation function of LMP is designed to aggregate multiple data links (ports or component links) into a TE link and to synchronize the properties of that TE link. As part of it, a LinkSummary message exchange is defined. The LinkSummary message includes the local and remote Link_Ids, a list of all data links that comprise the TE link, and various link properties. A LinkSummaryAck or LinkSummaryNack message MUST be sent in response to receiving a LinkSummary message, indicating agreement or disagreement on the link properties. Yes or no, no ghosting. 💅
LMP messages are transmitted reliably using Message_Ids and retransmissions. Message_Ids are carried in MESSAGE_ID objects. No more than one MESSAGE_ID object may be included in an LMP message. For control-channel-specific messages, the Message_Id is within the scope of the control channel the message is sent over. For TE-link-specific messages, the Message_Id is within the scope of the LMP adjacency. The value of the Message_Id is monotonically increasing and wraps around when the maximum value is reached. Round and round it goes! 🎡
In this document, two additional LMP procedures are defined: link connectivity verification and fault management. These are especially useful when the control channels are physically diverse from the data links. Link connectivity verification handles data plane discovery, Interface_Id exchange (Interface_Ids are used in GMPLS signaling, either as port labels or component link identifiers, depending on the configuration), and physical connectivity verification. It works by sending Test messages over the data links and TestStatus messages back over the control channel. Note that the Test message is the ONLY LMP message that must be transmitted over the data link. The ChannelStatus message exchange is used between adjacent nodes for both suppressing downstream alarms and localizing faults for protection and restoration. Detective energy, honestly. 🔍
For LMP link connectivity verification, the Test message is transmitted over the data links. For X-transparent devices, this requires examining and modifying the X aspect of the signal. The procedure is coordinated using a BeginVerify message exchange over a control channel. To support the different aspects of transparency, a Verify Transport Mechanism is included in the BeginVerify and BeginVerifyAck messages. There's no requirement that all data links lose their transparency at the same time, but at a minimum, it must be possible to terminate them one at a time. There's also no requirement that the control channel and TE link use the same physical medium. However, the control channel MUST be terminated by the same two control elements that control the TE link. Since the BeginVerify message exchange coordinates the Test procedure, it also naturally coordinates the transition of the data links in and out of transparent mode. Choreography! 💃
The LMP fault management procedure is based on a ChannelStatus message exchange that uses the following messages: ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. The ChannelStatus message is sent unsolicited and is used to notify an LMP neighbor about the status of one or more data channels of a TE link. The ChannelStatusAck message acknowledges receipt of the ChannelStatus message. The ChannelStatusRequest message queries an LMP neighbor for the status of one or more data channels of a TE Link. The ChannelStatusResponse message acknowledges receipt of the ChannelStatusRequest message and indicates the states of the queried data links. Asking and answering, the full conversation. 🌸
3. Control Channel Management 🎀
To start an LMP adjacency between two nodes, one or more bi-directional control channels MUST be activated. The control channels can be used to exchange control-plane information such as link provisioning and fault management information (implemented using a messaging protocol such as LMP, proposed in this document), path management and label distribution information (implemented using a signaling protocol such as RSVP-TE [RFC3209]), and network topology and state distribution information (implemented using traffic engineering extensions of protocols such as OSPF [RFC3630] and IS-IS [RFC3784]). So many jobs for one channel! 🧚
For LMP's purposes, the exact implementation of the control channel is not specified. It could be, for example, a separate wavelength or fiber, an Ethernet link, an IP tunnel through a separate management network, or the overhead bytes of a data link. Each node assigns a node-wide, unique, 32-bit, non-zero integer control channel identifier (CC_Id). This identifier comes from the same space as the unnumbered interface Id. LMP packets run over UDP with an LMP port number, so the link level encoding of the control channel is not part of the LMP specification. Bestie, that's a whole vibe. 🦋
To establish a control channel, the destination IP address on the far end of the control channel must be known. That knowledge may be manually configured or automatically discovered. Note that for in-band signaling, a control channel could be explicitly configured on a particular data link. In that case, the Config message exchange can be used to dynamically learn the IP address on the far end of the control channel. This is done by sending the Config message with a unicast IP source address and a multicast IP destination address (224.0.0.1 or ff02::1). The ConfigAck and ConfigNack messages MUST be sent to the source IP address found in the IP header of the received Config message. Reply to the sender, always! 💌
Control channels exist independently of TE links, and multiple control channels may be active simultaneously between a pair of nodes. Individual control channels can be realized in different ways. One might be implemented in-fiber while another is implemented out-of-fiber. As such, control channel parameters MUST be negotiated over each individual control channel, and LMP Hello packets MUST be exchanged over each control channel to maintain LMP connectivity if other mechanisms are not available. Since control channels are electrically terminated at each node, it may be possible to detect control channel failures using lower layers (e.g., SONET/SDH). Every channel gets its own check-in! ✅
There are four LMP messages used to manage individual control channels: the Config, ConfigAck, ConfigNack, and Hello messages. These messages MUST be transmitted on the channel they refer to. All other LMP messages may be transmitted over any of the active control channels between a pair of LMP adjacent nodes. 🌈
To maintain an LMP adjacency, it's necessary to have at least one active control channel between a pair of adjacent nodes. Remember that multiple control channels can be active simultaneously between a pair of nodes. If a control channel fails, alternate active control channels can be used, and it may be possible to activate additional control channels as described below. Backup plans are literally the move. 🫶
3.1. Parameter Negotiation 💅
okay so control channel activation starts with a parameter negotiation exchange 🎀 using Config, ConfigAck, and ConfigNack messages. The contents of these messages are built out of LMP objects, and each object is either negotiable or non-negotiable (you can tell which by the N bit in the object header 👀). Negotiable objects let LMP peers agree on certain values together. Non-negotiable objects are for announcing a specific value that doesn't need negotiating, or isn't allowed to be negotiated. 🫶
To activate a control channel, a Config message MUST be transmitted to the remote node, and in response, a ConfigAck message MUST be received at the local node. ✨ The Config message carries the Local Control Channel Id (CC_Id), the sender's Node_Id, a Message_Id for reliable messaging, and a CONFIG object. Both the local and remote nodes can start the configuration procedure at the same time 😭, so there's a tiebreak to avoid confusion. The node with the higher Node_Id wins the contention. The node with the lower Node_Id MUST stop transmitting the Config message and respond to the Config message it received instead. 🏆 If the Node_Ids are equal, then one (or both) nodes have been misconfigured 💀. The nodes MAY continue to retransmit Config messages in hopes that the misconfiguration gets corrected. Note that the problem may be solved by an operator changing the Node_Ids on one or both nodes.
The ConfigAck message acknowledges receipt of the Config message and expresses agreement on ALL of the configured parameters, both negotiable and non-negotiable. 💖
The ConfigNack message acknowledges receipt of the Config message too 🌸, but it also indicates which (if any) non-negotiable CONFIG objects are unacceptable, and proposes alternate values for the negotiable parameters.
If a node receives a ConfigNack message with acceptable alternate values for negotiable parameters, the node SHOULD transmit a Config message using these values for those parameters. 🦋
If a node receives a ConfigNack message with unacceptable alternate values, the node MAY continue to retransmit Config messages in hopes that the misconfiguration gets corrected. Note that the problem may be solved by an operator changing parameters on one or both nodes. 🙈
When multiple control channels use the same physical interface, the parameter negotiation exchange is performed for each control channel. The various LMP parameter negotiation messages are matched up with their control channels by their node-wide unique identifiers (CC_Ids). 🧚
3.2. Hello Protocol 🌈
Once a control channel is activated between two adjacent nodes, the LMP Hello protocol can be used to keep control channel connectivity going between the nodes and to detect control channel failures. 💜 The LMP Hello protocol is meant to be a lightweight keep-alive mechanism. It reacts to control channel failures quickly, so that IGP Hellos don't get lost and the associated link-state adjacencies don't get removed unnecessarily. Quick and efficient, no notes 🔥.
3.2.1. Hello Parameter Negotiation 🎀
Before sending Hello messages, the HelloInterval and HelloDeadInterval parameters MUST be agreed upon by the local and remote nodes. These parameters are exchanged in the Config message. The HelloInterval says how often LMP Hello messages get sent, measured in milliseconds (ms). For example, if the value were 150, then the transmitting node would send the Hello message at least every 150 ms ⏱️. The HelloDeadInterval says how long a device should wait to receive a Hello message before declaring a control channel dead, also measured in milliseconds (ms).
The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval parameters MUST be set to zero. 🙅♀️
The values for the HelloInterval and HelloDeadInterval should be selected carefully. The goal is rapid response time to control channel failures without causing congestion, which is a real balancing act 🤹♀️. As such, different values will likely be configured for different control channel implementations. When the control channel is implemented over a directly connected link, the suggested default values are 150 ms for the HelloInterval and 500 ms for the HelloDeadInterval. ✨
When a node has either sent or received a ConfigAck message, it may begin sending Hello messages. Once it has sent a Hello message and received a valid Hello message (i.e., one with expected sequence numbers; see Section 3.2.2), the control channel moves to the up state. 🎉 (It is also possible to move to the up state without sending Hellos, if other methods are used to indicate bi-directional control-channel connectivity. For example, indication of bi-directional connectivity may be learned from the transport layer.) If, however, a node receives a ConfigNack message instead of a ConfigAck message, the node MUST not send Hello messages, and the control channel SHOULD NOT move to the up state. 🚫 See Section 11.1 for the complete control channel FSM.
3.2.2. Fast Keep-alive ⚡
Each Hello message carries two sequence numbers. The first one (TxSeqNum) is the sequence number for the Hello message being sent. The second one (RcvSeqNum) is the sequence number of the last Hello message received from the adjacent node over this control channel. 📬
There are two special sequence numbers. TxSeqNum MUST NOT ever be 0. TxSeqNum = 1 is used to indicate that the sender has just started or has restarted and has no recollection of the last TxSeqNum that was sent. So the first Hello sent has a TxSeqNum of 1 and an RxSeqNum of 0. When TxSeqNum reaches (2^32)-1, the next sequence number used is 2, not 0 or 1, because those two have special meanings 🙃.
Under normal operation, the difference between the RcvSeqNum in a received Hello message and the local TxSeqNum that gets generated will be at most 1. The difference can be more than one only when a control channel restarts or when the values wrap around 🔄.
Since the 32-bit sequence numbers may wrap, the following expression may be used to test whether a newly received TxSeqNum value is less than a previously received value:
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}Having sequence numbers in the Hello messages lets each node verify that its peer is receiving its Hello messages. 🫶 By including the RcvSeqNum in Hello packets, the local node knows which Hello packets the remote node has received.
The following example shows how the sequence numbers work. Only the operation at one node is shown, and alternative scenarios are possible 👩💻:
- After completing the configuration stage, Node A sends Hello messages to Node B with
{TxSeqNum=1;RcvSeqNum=0}. - Node A receives a Hello from Node B with
{TxSeqNum=1;RcvSeqNum=1}. When theHelloIntervalexpires on Node A, it sends Hellos to Node B with{TxSeqNum=2;RcvSeqNum=1}. - Node A receives a Hello from Node B with
{TxSeqNum=2;RcvSeqNum=2}. When theHelloIntervalexpires on Node A, it sends Hellos to Node B with{TxSeqNum=3;RcvSeqNum=2}. 💖
3.2.3. Control Channel Down 📴
To bring a control channel down gracefully for administration purposes, there's a ControlChannelDown flag in the Common Header of LMP packets 🧁. When data links are still in use between a pair of nodes, a control channel SHOULD only be taken down administratively when there are other active control channels that can manage the data links. Don't leave the data links without a manager, bestie 🥺.
When bringing a control channel down administratively, a node MUST set the ControlChannelDown flag in all LMP messages sent over the control channel. The node that started the control channel down procedure may stop sending Hello messages after HelloDeadInterval seconds have passed, or if it receives an LMP message over the same control channel with the ControlChannelDown flag set. 👋
When a node receives an LMP packet with the ControlChannelDown flag set, it SHOULD send a Hello message with the ControlChannelDown flag set and move the control channel to the down state. 🌙
3.2.4. Degraded State 🥀
Control channels can be physically diverse from the data links they're associated with. That's a big deal, because it means there may not be any active control channels available while the data links are still in use. For many applications, it's unacceptable to tear down a link that's carrying user traffic just because the control channel is no longer available 😤. However, the traffic using the data links may no longer be guaranteed the same level of service. So the TE link is in a Degraded state. ⚠️
When a TE link is in the Degraded state, routing and signaling SHOULD be notified, so that new connections are not accepted and the TE link is advertised with no unreserved resources. 🚧
4. Link Property Correlation ✨
okay bestie, this section is all about making sure both ends of a link are literally on the same page 🫶 As part of LMP, there's a whole link property correlation exchange for TE links, and it runs on the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages 💌 Everything in these messages is built from LMP objects, and each object is either negotiable or non-negotiable (you can tell which one by the N flag in the object header) 🎀 Negotiable objects let both sides agree on certain link parameters, kind of like a group project where everyone picks the value together 🤝 Non-negotiable objects are for announcing specific values that don't need, or don't allow, any negotiating 💅
Each TE link gets a Link_Id assigned at each end. These identifiers MUST be the same type (i.e, IPv4, IPv6, unnumbered) at both ends 🙅 If a LinkSummary message comes in with different local and remote TE link types, then a LinkSummaryNack message MUST be sent with Error Code "Bad TE Link Object" 💀 Same energy for data links: each one gets an Interface_Id at each end, and those identifiers MUST also be the same type at both ends. If a LinkSummary message arrives with different local and remote Interface_Id types, then a LinkSummaryNack message MUST be sent with Error Code "Bad Data Link Object" 😭
Link property correlation SHOULD be done before the link is brought up, and it MAY be done any time a link is up and not in the Verification process ⏰
The LinkSummary message is used to verify, for consistency, the TE and data link information on both sides 🔍 Link Summary messages also do three jobs: (1) aggregate multiple data links (either ports or component links) into a TE link; (2) exchange, correlate (to determine inconsistencies), or change TE link parameters; and (3) exchange, correlate (to determine inconsistencies), or change Interface_Ids (either Port_Ids or component link identifiers) 🦋
The LinkSummary message includes a TE_LINK object followed by one or more DATA_LINK objects 🧚 The TE_LINK object identifies the TE link's local and remote Link_Id and indicates support for fault management and link verification procedures for that TE link. The DATA_LINK objects characterize the data links that make up the TE link. These objects include the local and remote Interface_Ids, and may include one or more sub-objects that further describe the properties of the data links 🌸
If the LinkSummary message is received from a remote node, and the Interface_Id mappings match the ones stored locally, then the two nodes have agreement on the Verification procedure (see Section 5) and data link identification configuration 🥰 If the verification procedure is not used, the LinkSummary message can be used to verify agreement on manual configuration 📝
The LinkSummaryAck message is used to signal agreement on the Interface_Id mappings and link property definitions ✅ Otherwise, a LinkSummaryNack message MUST be transmitted, indicating which Interface mappings are not correct and/or which link properties are not accepted 🙈
If aLinkSummaryNackmessage says theInterface_Idmappings are not correct and the link verification procedure is enabled, then the link verification process SHOULD be repeated for all mismatched, free data links. If an allocated data link has a mapping mismatch, it SHOULD be flagged and verified when it becomes free 🚩
If a LinkSummaryNack message includes negotiable parameters, then acceptable values for those parameters MUST be included 💜 And if a LinkSummaryNack message is received and includes negotiable parameters, then the initiator of the LinkSummary message SHOULD send a new LinkSummary message. That new message SHOULD include new values for the negotiable parameters, and these values SHOULD take into account the acceptable values received in the LinkSummaryNack message 🔁
It is possible that the LinkSummary message could grow quite large because of the number of DATA LINK objects 📦 An LMP implementation SHOULD be able to fragment when transmitting LMP messages, and it MUST be able to re-assemble IP fragments when receiving LMP messages 🧩
5. Verifying Link Connectivity ✨
okay bestie, this section is about an optional procedure 🎀 that can check the physical connectivity of the data links, and also dynamically learn (aka discover 🔍) which TE link and Interface_Id associations belong together. The procedure SHOULD be done when a TE link is being established, and then again on a periodic basis for all the unallocated (free) data links of the TE link 💖
Support for it gets advertised by setting the "Link Verification Supported" flag in the TE_LINK object of the LinkSummary message 💅
If a BeginVerify message comes in and link verification isn't supported for that TE link, then a BeginVerifyNack message MUST be transmitted, with an Error Code saying "Link Verification Procedure not supported for this TE Link." 🙅♀️ kinda harsh but it's the rule, no cap 😭
Okay so here's the vibe with transparent devices 🦋 a unique thing about them is that the data isn't modified or examined during normal operation. That makes it really tricky to validate the connectivity of the data links and set up the label mappings. So for proper verification, it is required that until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency) 🫶 To support different degrees of opaqueness (like examining overhead bytes, terminating the IP payload, etc.), and therefore different mechanisms for transporting the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages ✨
There's no requirement that all data links get terminated at the same time 🙌 but at a minimum, the data links MUST be able to be terminated one at a time. For the link verification procedure, it's also assumed that the nodal architecture is designed so messages can be sent and received over any data link. Note that this is trivial for opaque devices, since each data link is electrically terminated and processed before being forwarded to the next opaque device. In transparent devices, though, this is an additional requirement 🌸
To interconnect two nodes, a TE link is defined between them, and at a minimum, there MUST be at least one active control channel between the nodes. For link verification, a TE link MUST include at least one data link 💜
Once a control channel is set up between the two nodes, data link connectivity can be verified by exchanging Test messages over each of the data links specified in the TE link. It should be noted that all LMP messages except the Test message are exchanged over the control channels, and Hello messages keep getting exchanged over each control channel during the data link verification process. The Test message is sent over the data link being verified. Data links are tested in the transmit direction because they're unidirectional, so it may be possible for both nodes to (independently) exchange the Test messages at the same time 🔥
To kick things off, the local node MUST send a BeginVerify message over a control channel. To limit the scope of Link Verification to a particular TE Link, the local Link_Id MUST be non-zero. If this field is zero, the data links can span multiple TE links and/or they may make up a TE link that's yet to be configured 👀 For the case where the local Link_Id field is zero, the "Verify all Links" flag of the BEGIN_VERIFY object is what tells apart data links that span multiple TE links from those that haven't been assigned to a TE link yet. Specifically, verification of data links spanning multiple TE links is indicated by setting the local Link_Id field to zero and setting the "Verify all Links" flag. Verification of data links not yet assigned to a TE link is indicated by setting the local Link_Id field to zero and clearing the "Verify all Links" flag 🧚
The BeginVerify message also carries the number of data links to be verified 📋 the interval (called VerifyInterval) at which the Test messages will be sent, the encoding scheme and transport mechanisms that are supported, the data rate for Test messages, and, when the data links correspond to fibers, the wavelength identifier over which the Test messages will be transmitted 🌈
If the remote node receives a BeginVerify message and it's ready to process Test messages, it MUST send a BeginVerifyAck message back to the local node, specifying the desired transport mechanism for the TEST messages. The remote node includes a 32-bit, node-unique Verify_Id in the BeginVerifyAck message. The Verify_Id MAY be randomly selected, but it MUST NOT overlap any other Verify_Id currently being used by the node selecting it. The Verify_Id is then used in all the corresponding verification messages to tell apart different LMP peers and/or parallel Test procedures 🎯 When the local node gets a BeginVerifyAck message from the remote node, it may begin testing the data links by transmitting periodic Test messages over each data link. The Test message includes the Verify_Id and the local Interface_Id for the associated data link. The remote node MUST send either a TestStatusSuccess or a TestStatusFailure message in response for each data link. A TestStatusAck message MUST be sent to confirm receipt of the TestStatusSuccess and TestStatusFailure messages. Unacknowledged TestStatusSuccess and TestStatusFailure messages SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached (see also Section 10) 🔁
It's also permissible for the sender to terminate the Test procedure any time after sending the BeginVerify message. An EndVerify message SHOULD be sent for this purpose 🛑
Message correlation is done using message identifiers and the Verify_Id, which is what lets data links belonging to different link bundles or LMP sessions get verified in parallel. Iconic multitasking 💅✨
When a Test message is received, the received Interface_Id (used in GMPLS as either a Port label or a component link identifier, depending on the configuration) is recorded and mapped to the local Interface_Id for that data link, and a TestStatusSuccess message MUST be sent. The TestStatusSuccess message includes the local Interface_Id along with the Interface_Id and Verify_Id received in the Test message. Getting a TestStatusSuccess message means the Test message was detected at the remote node, so the physical connectivity of the data link has been verified 🥳 When the TestStatusSuccess message is received, the local node SHOULD mark the data link as up and send a TestStatusAck message to the remote node. But if the Test message isn't detected at the remote node within an observation period (specified by the VerifyDeadInterval), the remote node MUST send a TestStatusFailure message over the control channel. That tells everyone the verification of the data link's physical connectivity has failed 💀 When the local node receives a TestStatusFailure message, it SHOULD mark the data link as FAILED and send a TestStatusAck message to the remote node. Once all the data links on the list have been tested, the local node SHOULD send an EndVerify message to show that testing is complete on this link 🏁
If the local/remote data link mappings are already known, the link verification procedure can be optimized by testing the data links in a defined order that both nodes know about. The suggested criterion for this ordering is increasing the value of the remote Interface_Id 📈
Last but not least, both the local and remote nodes SHOULD maintain the complete list of Interface_Id mappings for correlation purposes 🫶💖
5.1. Example of Link Connectivity Verification 🎀
Okay so, Figure 1 shows a full example of the link verification scenario that kicks off when a link between Node A and Node B gets added 💅. Here the TE link is made of three free ports, each sent along its own separate fiber, and it's paired with a bi-directional control channel (the one marked with a "c") 🧚. Here's how the verification goes:
- A sends a
BeginVerifymessage over the control channel to B, saying it's about to verify the ports that form the TE link. TheLOCAL_LINK_IDobject in thatBeginVerifymessage carries the identifier (IP address or interface index) that A assigns to the link. - When B gets the
BeginVerifymessage, it creates aVerify_Idand binds it to the TE Link from A 🦋. This binding gets used later, when B receives the Test messages from A, because those messages carry theVerify_Id. B figures out the identifier (IP address or interface index) that A gives the TE link by checking theLOCAL_LINK_IDobject in theBeginVerifymessage it got. (If the data ports aren't assigned to the TE Link yet, the binding is limited to theNode_Idof A.) B answers with aBeginVerifyAckmessage to A. TheLOCAL_LINK_IDobject in theBeginVerifyAckmessage carries the identifier (IP address or interface index) that B assigns to the TE link. TheREMOTE_LINK_IDobject in theBeginVerifyAckmessage is what binds the Link_Ids that A and B each assigned. TheVerify_Idgoes back to A inside theBeginVerifyAckmessage, over the control channel. 🫶 - When A gets the
BeginVerifyAckmessage, it starts sending periodic Test messages over the first port (Interface Id=1) 🔥. Each Test message includes theInterface_Idfor that port, plus theVerify_Idthat B assigned. - When B gets the Test messages, it maps the received
Interface_Idto its own localInterface_Id = 10and sends aTestStatusSuccessmessage over the control channel back to Node A ✨. TheTestStatusSuccessmessage includes both the local and the receivedInterface_Ids for the port, along with theVerify_Id. TheVerify_Idis what lets everyone work out the local and remote TE link identifiers (IP addresses or interface indices) that the data links belong to. - A will send a
TestStatusAckmessage over the control channel back to B, to say it got theTestStatusSuccessmessage. - This whole thing repeats until every port is verified 🌈.
- At this point, A will send an
EndVerifymessage over the control channel to B, saying testing is complete. - B will respond by sending an
EndVerifyAckmessage over the control channel back to A 💜.
Note that this procedure can be used to "discover" the connectivity of the data ports. Literally the whole point, bestie 🙈.
+---------------------+ +---------------------+
+ + + +
+ Node A +<-------- c --------->+ Node B +
+ + + +
+ + + +
+ 1 +--------------------->+ 10 +
+ + + +
+ + + +
+ 2 + /---->+ 11 +
+ + /----/ + +
+ + /---/ + +
+ 3 +----/ + 12 +
+ + + +
+ + + +
+ 4 +--------------------->+ 14 +
+ + + +
+---------------------+ +---------------------+Figure 1: Example of link connectivity between Node A and Node B.
6. Fault Management 🚨
Okay, this section is about an optional LMP procedure 🍓. It handles failures by quickly telling everyone the status of one or more data channels of a TE Link. The scope of this procedure stays inside a TE link, so using it gets negotiated as part of the LinkSummary exchange. It can rapidly isolate data link and TE link failures, and it's built to work for both unidirectional and bi-directional LSPs. Main character energy 👑.
Here's the twist: when you use transparent devices, the usual ways of monitoring the health of allocated data links may no longer be appropriate 🙈. Fault detection doesn't live in layer 2 or layer 3 anymore. It gets handed off to the physical layer (i.e., loss of light or optical monitoring of the data) ⭐.
Quick reminder: a TE link connecting two nodes can be made of a bunch of data links. If one or more data links fail between two nodes, a mechanism must be used for rapid failure notification, so the right protection/restoration mechanisms can kick in 💀. And if the failure gets cleared, a mechanism must be used to notify that the failure is clear and the channel status is OK 🫶.
6.1. Fault Detection 🔍
Fault detection should be handled at the layer closest to the failure. For optical networks, that's the physical (optical) layer. One way to detect faults at the physical layer is to detect loss of light (LOL) 💡. Other techniques for monitoring optical signals are still being developed and won't be covered further in this document. Still, it should be clear that the mechanism LMP uses for fault notification is independent of the mechanism used to detect the failure. It just relies on the fact that a failure has been detected 🦋.
6.2. Fault Localization Procedure 🕵️♀️
Sometimes a data link failure between two nodes gets propagated downstream, so every downstream node detects the failure without knowing where it actually happened. To avoid a pile of alarms coming from the same failure, LMP gives failure notification through the ChannelStatus message 🌸. This message may be used to indicate that a single data channel has failed, that multiple data channels have failed, or that an entire TE link has failed. Failure correlation happens locally at each node once it gets the failure notification 💅.
To pin a fault down to a particular link between adjacent nodes, a downstream node (downstream in terms of data flow) that detects data link failures sends a ChannelStatus message to its upstream neighbor, saying a failure has been detected. It bundles together the notification for all the failed data links. An upstream node that receives the ChannelStatus message MUST send a ChannelStatusAck message to the downstream node to say it got the ChannelStatus message. The upstream node should correlate the failure to see if it's also detected locally for the corresponding LSP(s). If, for example, the failure is clear on the input of the upstream node or internally, then the upstream node has localized the failure 🎯. Once the failure is correlated, the upstream node SHOULD send a ChannelStatus message to the downstream node saying the channel is failed or is OK. If the downstream node doesn't receive a ChannelStatus message, it SHOULD send a ChannelStatusRequest message for the channel in question 🥺. Once the failure is localized, the signaling protocols may be used to start span or path protection and restoration procedures 🔥.
If all of the data links of a TE link have failed, the upstream node MAY be notified of the TE link failure without listing each data link of the failed TE link. This happens by sending the failure notification in a ChannelStatus message that identifies the TE Link, without including the Interface_Ids in the CHANNEL_STATUS object 🌈.
6.3. Examples of Fault Localization 🧚
In Figure 2, there's a sample network with four nodes connected in a linear array configuration. The control channels are bi-directional and are labeled with a "c". All LSPs are bi-directional too 💜.
In the first example [see Fig. 2(a)], there's a failure on one direction of the bi-directional LSP. Node 4 detects the failure and sends a ChannelStatus message to Node 3 that indicates the failure (e.g., LOL) to the corresponding upstream node. When Node 3 gets the ChannelStatus message from Node 4, it sends a ChannelStatusAck message back to Node 4 and correlates the failure locally. When Node 3 correlates the failure and verifies that it's clear, it has localized the failure to the data link between Node 3 and Node 4 🎀. At that point, Node 3 should send a ChannelStatus message to Node 4 saying the failure has been localized.
In the second example [see Fig. 2(b)], a single failure (e.g., fiber cut) hits both directions of the bi-directional LSP 😭. Node 2 (Node 3) detects the failure of the upstream (downstream) direction and sends a ChannelStatus message to the upstream (in terms of data flow) node that indicates the failure (e.g., LOL). Simultaneously (ignoring propagation delays), Node 1 (Node 4) detects the failure on the upstream (downstream) direction and sends a ChannelStatus message to the corresponding upstream (in terms of data flow) node that indicates the failure. Node 2 and Node 3 have localized both directions of the failure ✨.
+-------+ +-------+ +-------+ +-------+
+ Node1 + + Node2 + + Node3 + + Node4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + +
<---+---\\--+--------+-------+---\ + + + /--+--->
+ \--+--------+-------+---\\---+-------+---##---+---//--+----
+ + + + \---+-------+--------+---/ +
+ + + + + + (a) + +
----+-------+--------+---\ + + + + +
<---+-------+--------+---\\--+---##---+--\ + + +
+ + + \--+---##---+--\\ + + +
+ + + + (b) + \\--+--------+-------+--->
+ + + + + \--+--------+-------+----
+ + + + + + + +
+-------+ +-------+ +-------+ +-------+Figure 2: Two types of data link failures are shown (indicated by ## in the figure): (A) a data link corresponding to the downstream direction of a bi-directional LSP fails, (B) two data links corresponding to both directions of a bi-directional LSP fail. The control channel connecting two nodes is indicated with a "c".
6.4. Channel Activation Indication ✨
Okay so the ChannelStatus message can also be used to tell an LMP neighbor that the data link should be actively monitored 👀 This is called Channel Activation Indication, and it's giving very useful in networks with transparent nodes, where the status of data links may need to be triggered using control channel messages 🦋 Like, say a data link is pre-provisioned, and then the physical link fails after verification but before user traffic gets inserted. Without a mechanism that says "hey, this data link should be active," the failure might just... not be detectable 😭
The ChannelStatus message is used to indicate that a channel or group of channels are now active. The ChannelStatusAck message MUST be transmitted upon receipt of a ChannelStatus message 🫶 When a ChannelStatus message is received, the corresponding data link(s) MUST be put into the Active state. And if a failure is detected once they're in the Active state, the ChannelStatus message SHOULD be transmitted as described in Section 6.2. Iconic behavior, honestly 💅
6.5. Channel Deactivation Indication 🌸
The ChannelStatus message can also be used to tell an LMP neighbor that the data link no longer needs to be actively monitored. This is the counterpart to the Channel Active Indication, so think of it as the other half of the friendship bracelet 🧚
When a ChannelStatus message is received with Channel Deactive Indication, the corresponding data link(s) MUST be taken out of the Active state. Bye bye, active state 👋
7. Message_Id Usage 💜
The MESSAGE_ID and MESSAGE_ID_ACK objects get included in LMP messages to support reliable message delivery. This section walks through how they're used, and both objects contain a Message_Id field 🎀
Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message. One per message, bestie, no sharing 🙅♀️
For control-channel-specific messages, the Message_Id field is within the scope of the CC_Id. For TE link specific messages, the Message_Id field is within the scope of the LMP adjacency. So the same number can mean different things depending on which lane you're in 🛣️
The Message_Id field of the MESSAGE_ID object contains a generator-selected value. This value MUST be monotonically increasing, no drama, always going up 📈 A value is considered to be previously used when it has been sent in an LMP message with the same CC_Id (for control channel specific messages) or LMP adjacency (for TE Link specific messages). The Message_Id field of the MESSAGE_ID_ACK object contains the Message_Id field of the message being acknowledged, so it's basically the receipt that says "got it" 🧾
Unacknowledged messages sent with the MESSAGE_ID object SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached (see also Section 10). Keep knocking until someone answers 🚪✨
Note that the 32-bit Message_Id value may wrap 🌀 The following expression may be used to test if a newly received Message_Id value is less than a previously received value:
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}Nodes processing incoming messages SHOULD check to see if a newly received message is out of order and can be ignored. Out-of-order messages can be identified by examining the value in the Message_Id field. If a message is determined to be out-of-order, that message should be silently dropped. Ghosted, quietly 👻
If the message is a Config message, and the Message_Id value is less than the largest Message_Id value previously received from the sender for the CC_Id, then the message SHOULD be treated as being out-of-order.
If the message is a LinkSummary message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the TE Link, then the message SHOULD be treated as being out-of-order.
If the message is a ChannelStatus message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the specified TE link, then the receiver SHOULD check the Message_Id value previously received for the state of each data channel included in the ChannelStatus message. If the Message_Id value is greater than the most recently received Message_Id value associated with at least one of the data channels included in the message, the message MUST NOT be treated as out of order; otherwise, the message SHOULD be treated as being out of order. However, the state of any data channel MUST NOT be updated if the Message_Id value is less than the most recently received Message_Id value associated with the data channel. This one is a whole plot twist, so read it twice 🫣
All other messages MUST NOT be treated as out-of-order. Everyone else gets a free pass 🥂
8. Graceful Restart 🔄
This section describes the mechanism to resynchronize the LMP state after a control plane restart. A control plane restart may occur when bringing up the first control channel after a control communications failure. A control communications failure may be the result of an LMP adjacency failure, or a nodal failure wherein the LMP control state is lost but the data plane is unaffected. The latter is detected by setting the "LMP Restart" bit in the Common Header of the LMP messages. When the control plane fails due to the loss of the control channel, the LMP link information should be retained. It is possible that a node may be capable of retaining the LMP link information across a nodal failure. However, in both cases the status of the data channels MUST be synchronized. Comeback arc, but make it make sense 🎬
It is assumed the Node_Id and Local Interface_Ids remain stable across a control plane restart. Stable IDs, stable vibes 🧘
After the control plane of a node restarts, the control channel(s) must be re-established using the procedures of Section 3.1. When re-establishing control channels, the Config message SHOULD be sent using the unicast IP source and destination addresses.
If the control plane failure was the result of a nodal failure where the LMP control state is lost, then the "LMP Restart" flag MUST be set in LMP messages until a Hello message is received with the RcvSeqNum equal to the local TxSeqNum. This indicates that the control channel is up and the LMP neighbor has detected the restart. Ping-pong confirmation, very reassuring 🏓
The following assumes that the LMP component restart only occurred on one end of the TE Link. If the LMP component restart occurred on both ends of the TE Link, the normal procedures for LinkSummary should be used, as described in Section 4. Two-sided restarts get the regular LinkSummary treatment, babe, no special rules 🙃
Once a control channel is up, the LMP neighbor MUST send a LinkSummary message for each TE Link across the adjacency. All the objects of the LinkSummary message MUST have the N-bit set to 0, indicating that the parameters are non-negotiable. This provides the local/remote Link_Id and Interface_Id mappings, the associated data link parameters, and an indication of which data links are currently allocated to user traffic 📋 When a node receives the LinkSummary message, it checks its local configuration. If the node is capable of retaining the LMP link information across a restart, it must process the LinkSummary message as described in Section 4 with the exception that the allocated/de-allocated flag of the DATA_LINK object received in the LinkSummary message MUST take precedence over any local value. If, however, the node was not capable of retaining the LMP link information across a restart, the node MUST accept the data link parameters of the received LinkSummary message and respond with a LinkSummaryAck message. Plot armor for the incoming LinkSummary, obviously 🛡️
Upon completion of the LinkSummary exchange, the node that has restarted the control plane SHOULD send a ChannelStatusRequest message for that TE link. The node SHOULD also verify the connectivity of all unallocated data channels. Check the vibes, then check the channels ✅
9. Addressing 📮
All LMP messages are run over UDP with an LMP port number (except, in some cases, the Test messages, which may be limited by the transport mechanism for in-band messaging). The destination address of the IP packet MAY be either the address learned in the Configuration procedure (i.e., the Source IP address found in the IP header of the received Config message), an IP address configured on the remote node, or the Node_Id. The Config message is an exception, as described below. Address book energy 📇
The manner in which a Config message is addressed may depend on the signaling transport mechanism. When the transport mechanism is a point-to-point link, Config messages SHOULD be sent to the Multicast address (224.0.0.1 or ff02::1). Otherwise, Config messages MUST be sent to an IP address on the neighboring node. This may be configured at both ends of the control channel or may be automatically discovered. Config is the one message with its own dress code 👗
10. Exponential Back-off Procedures 🌷
This section is based on [RFC2961] and provides exponential back-off procedures for message retransmission. Implementations MUST use the described procedures or their equivalent. No freestyling on this one, friends 🫡
10.1. Operation 🎢
The following operation is one possible mechanism for exponential back-off retransmission of unacknowledged LMP messages. The sending node retransmits the message until an acknowledgement message is received or until a retry limit is reached. When the sending node receives the acknowledgement, retransmission of the message is stopped. The interval between message retransmission is governed by a rapid retransmission timer. The rapid retransmission timer starts at a small interval and increases exponentially until it reaches a threshold. Think of it like a snooze button that gets more and more patient 😴➡️😤
The following time parameters are useful to characterize the procedures:
Rapid retransmission interval Ri:
Ri is the initial retransmission interval for unacknowledged messages. After sending the message for the first time, the sending node will schedule a retransmission after Ri milliseconds. ⏰
Rapid retry limit Rl:
Rl is the maximum number of times a message will be transmitted without being acknowledged. Three strikes, roughly 🎳
Increment value Delta:
Delta governs the speed with which the sender increases the retransmission interval. The ratio of two successive retransmission intervals is (1 + Delta). Delta is the gas pedal 🏎️💨
Suggested default values for an initial retransmission interval (Ri) of 500 ms are a power of 2 exponential back-off (Delta = 1) and a retry limit of 3. So the cute defaults are 500 ms, Delta = 1, and a retry limit of 3 🍓
10.2. Retransmission Algorithm 🧮
After a node transmits a message requiring acknowledgement, it should immediately schedule a retransmission after Ri seconds. If a corresponding acknowledgement message is received before Ri seconds, then message retransmission SHOULD be canceled. Otherwise, it will retransmit the message after (1+Delta)*Ri seconds. The retransmission will continue until either an appropriate acknowledgement message is received or the rapid retry limit, Rl, has been reached. Ping, wait, ping louder 🔔
A sending node can use the following algorithm when transmitting a message that requires acknowledgement:
Prior to initial transmission, initialize Rk = Ri and Rn = 0.
while (Rn++ < Rl) {
transmit the message;
wake up after Rk milliseconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged message or no reply from receiver and Rl
reached*/
do any needed clean up;
exit;Asynchronously, when a sending node receives a corresponding acknowledgment message, it will change the retry count, Rn, to Rl. Got the reply, so the retry counter just gives up and goes home 🏠💖
Note that the transmitting node does not advertise or negotiate the use of the described exponential back-off procedures in the Config or LinkSummary messages. No announcements needed, it's a silent little ritual 🤫
11. LMP Finite State Machines 🧠
11.1. Control Channel FSM 🚦
The control channel FSM defines the states and logics of operation of an LMP control channel. Every control channel gets its own little traffic light, and this is the rulebook for it 🌈
11.1.1. Control Channel States
okay so a control channel can be in one of these states 💖 each one matches a certain condition of the channel and usually comes with a specific LMP message that gets sent to the far end on a regular schedule ✨
Down: this is the starter state 🌸 nothing is trying to bring the control channel up and no LMP messages get sent. the control channel parameters get reset to their initial values.ConfSnd: this is the parameter negotiation state 🫶 the node keeps sending aConfigmessage and waits for the other side to reply with eitherConfigAckorConfigNack. the FSM doesn't move intoActiveuntil the remote side has positively acknowledged the parameters 💅ConfRcv: this is also parameter negotiation, but the node is the one waiting 🦋 it's waiting for acceptable configuration parameters from the remote side. once those arrive and get acknowledged, the FSM can move on toActive✨Active: the node periodically sends aHellomessage and waits to receive a validHello🧚 once a valid one lands, it can transition to the up state.Up: the CC is operational 👑 validHellomessages come in and the node keeps sending its own.GoingDown: a CC can end up here because of administrative action 😭 while it's in this state, the node sets theControlChannelDownbit in every message it sends 🙈
11.1.2. Control Channel Events
the control channel is described in terms of FSM states and events, and the events are where the drama happens 🎀 they come from the underlying protocols and software modules, the packet processing routines, and the FSMs of associated TE links. every event has its own number and symbolic name 💜 here's the lineup:
1 : evBringUp:this is an externally triggered event that says control channel negotiation should begin 🌈 it could come from an operator command, from a control channel bootstrap procedure finishing successfully, or from configuration. depending on the configuration, it triggers either:- 1a) sending a
Configmessage, - 1b) a period of waiting to receive a
Configmessage from the remote node.
- 1a) sending a
2 : evCCDn:generated when there's an indication that the control channel isn't available anymore 💀3 : evConfDone:aConfigAckcame in, acknowledging the Config parameters ✅4 : evConfErr:aConfigNackcame in, rejecting the Config parameters 🙅♀️5 : evNewConfOK:a new Config message came in from the neighbor and got positively acknowledged 🫶6 : evNewConfErr:a new Config message came in from the neighbor and got rejected with aConfigNack😤7 : evContenWin:a new Config message came in from the neighbor at the same time the local node sent its own Config message to that neighbor 🥊 the local node wins the contention, so the received Config message gets ignored 👑8 : evContenLost:same simultaneous situation, but this time the local node loses the contention 🥀- 8a) the Config message is positively acknowledged.
- 8b) the Config message is negatively acknowledged.
9 : evAdminDown:the administrator asked for the control channel to be brought down administratively 🛑10: evNbrGoesDn:a packet with the ControlChannelDown flag came in from the neighbor 😭11: evHelloRcvd:a Hello packet with the expected SeqNum has been received 💖12: evHoldTimer:the HelloDeadInterval timer expired, which means no Hello packet showed up 💔 this moves the control channel back into the Negotiation state, and depending on local configuration, it triggers either:- 12a) the sending of periodic Config messages,
- 12b) a period of waiting to receive Config messages from the remote node.
13: evSeqNumErr:a Hello with an unexpected SeqNum came in and got discarded 🙈14: evReconfig:the control channel parameters have been reconfigured and need renegotiation 🔁15: evConfRet:a retransmission timer expired and a Config message gets resent 🔄16: evHelloRet:the HelloInterval timer expired and a Hello packet gets sent 💌17: evDownTimer:a timer expired and no messages with the ControlChannelDown flag set have been received ⏰
11.1.3. Control Channel FSM Description
Figure 3 shows the control channel FSM as a state transition diagram, and yes, it's giving spaghetti but it's our spaghetti 🍝✨
+--------+
+----------------->| |<--------------+
| +--------->| Down |<----------+ |
| |+---------| |<-------+ | |
| || +--------+ | | |
| || | ^ 2,9| 2| 2|
| ||1b 1a| | | | |
| || v |2,9 | | |
| || +--------+ | | |
| || +->| |<------+| | |
| || 4,7,| |ConfSnd | || | |
| || 14,15+--| |<----+ || | |
| || +--------+ | || | |
| || 3,8a| | | || | |
| || +---------+ |8b 14,12a| || | |
| || | v | || | |
| |+-|------>+--------+ | || | |
| | | +->| |-----|-|+ | |
| | |6,14| |ConfRcv | | | | |
| | | +--| |<--+ | | | |
| | | +--------+ | | | | |
| | | 5| ^ | | | | |
| | +---------+ | | | | | | |
| | | | | | | | | |
| | v v |6,12b | | | | |
| |10 +--------+ | | | | |
| +----------| | | | | | |
| | +--| Active |---|-+ | | |
10,17| | 5,16| | |-------|---+ |
+-------+ 9 | 13 +->| | | | |
| Going |<--|----------+--------+ | | |
| Down | | 11| ^ | | |
+-------+ | | |5 | | |
^ | v | 6,12b| | |
|9 |10 +--------+ | |12a,14 |
| +----------| |---+ | |
| | Up |-------+ |
+------------------| |---------------+
+--------+
| ^
| |
+---+
11,13,16
Figure 3: Control Channel FSMEvent evCCDn always forces the FSM to the down state 🪦 and events evHoldTimer and evReconfig always force the FSM to the Negotiation state (either ConfSnd or ConfRcv) 💅
11.2. TE Link FSM
the TE Link FSM defines the states and logic of how the LMP TE Link operates 🦋
11.2.1. TE Link States
an LMP TE link can be in one of these states 🌸 each one matches a certain condition of the TE link and usually comes with a specific LMP message that gets sent to the far end on a regular schedule, either over the associated control channel or in-band over the data links ✨
Down: there are no data links allocated to the TE link 🫥Init: data links have been allocated to the TE link, but the configuration isn't synced with the LMP neighbor yet 🤞 theLinkSummarymessage gets sent to the LMP neighbor on a regular schedule.Up: this is the normal operational state of the TE link 👑 at least one LMP control channel is required to be operational between the nodes sharing the TE link. as part of normal operation, theLinkSummarymessage may get sent periodically to the LMP neighbor, or it may be generated by an external request 💫Degraded: all LMP control channels are down 😭 but the TE link still has some data links that are allocated to user traffic 🩹
11.2.2. TE Link Events
TE Link events come from the packet processing routines and from the FSMs of the associated control channel(s) and the data links 💜 every event has its own number and symbolic name, and here they are:
1 : evDCUp:one or more data channels have been enabled and assigned to the TE Link 🌈2 : evSumAck:aLinkSummarymessage came in and got positively acknowledged ✅3 : evSumNack:aLinkSummarymessage came in and got negatively acknowledged 🙅♀️4 : evRcvAck:aLinkSummaryAckmessage came in, acknowledging the TE Link Configuration 🫶5 : evRcvNack:aLinkSummaryNackmessage came in 😬6 : evSumRet:a retransmission timer expired and theLinkSummarymessage gets resent 🔄7 : evCCUp:the first active control channel goes up 🚀8 : evCCDown:the last active control channel goes down 📉9 : evDCDown:the last data channel of the TE Link has been removed 🥀
11.2.3. TE Link FSM Description ✨
Okay bestie, Figure 4 is the whole TE Link FSM as a state transition diagram. Let's look at it 👀
3,7,8
+--+
| |
| v
+--------+
| |
+------------>| Down |<---------+
| | | |
| +--------+ |
| | ^ |
| 1| |9 |
| v | |
| +--------+ |
| | |<-+ |
| | Init | |3,5,6 |9
| | |--+ 7,8 |
9| +--------+ |
| | |
| 2,4| |
| v |
+--------+ 7 +--------+ |
| |------>| |----------+
| Deg | | Up |
| |<------| |
+--------+ 8 +--------+
| ^
| |
+--+
2,3,4,5,6
Figure 4: LMP TE Link FSMQuick heads up: the sub-states that can show up when the link verification procedure is used are left out of this FSM 🙈
11.3. Data Link FSM 🎀
Okay, so the data link FSM is the thing that defines the states and logic of a data link inside an LMP TE link. Its behaviour gets described with FSM states and events. A data link can be in active (transmitting) mode, where it sends Test messages, or in passive (receiving) mode, where it receives Test messages. To keep things clear, there are separate FSMs for active and passive data links. But they share one single set of data link states and events, which is so smart 🧠
11.3.1. Data Link States 💜
Any data link can be in one of these states. Each state tells you what condition the data link is in.
Down:The data link has not been put in the resource pool, meaning the link is not 'in service' 😴Test:The data link is being tested, and an LMP Test message gets sent through it on a regular basis 📨PasvTest:The data link is being checked for incoming test messages 👀Up/Free:The link passed testing and is now in the resource pool (in-service). It hasn't been given to any data traffic yet 🦋Up/Alloc:The link is up and has been handed out for data traffic 🔥
11.3.2. Data Link Events 🌸
Data link events come from the packet processing routines, plus the FSMs of the associated control channel and TE link. Every event has a number and a symbolic name. Here's the lineup:
- 1
:evCCUp:The first active control channel comes up ⬆️ - 2
:evCCDown:LMP neighbour connectivity is gone. This means the last LMP control channel between the neighbouring nodes has failed 💀 - 3
:evStartTst:An external event that kicks off sending Test messages over the data link 🚀 - 4
:evStartPsv:An external event that kicks off listening for Test messages over the data link 👂 - 5
:evTestOK:Link verification worked and the link can now be used for path establishment ✅- (a) This event means the Link Verification procedure (see Section 5) worked for this data link, and a TestStatusSuccess message came in over the control channel.
- (b) This event means the link is ready for path establishment, but the Link Verification procedure wasn't used. For in-band signalling of the control channel, just getting the control channel established may be enough to verify the link.
- 6
:evTestRcv:A Test message came in over the data port, and a TestStatusSuccess message is sent back over the control channel 📬 - 7
:evTestFail:Link verification came back negative. This could be because (a) a TestStatusFailure message was received, or (b) the Verification procedure ended without a TestStatusSuccess or TestStatusFailure message arriving for the data link 😬 - 8
:evPsvTestFail:Link verification came back negative. This means no Test message was detected, and either (a) the VerifyDeadInterval has expired, or (b) the Verification procedure has ended and the VerifyDeadInterval hasn't expired yet ⏳ - 9
:evLnkAlloc:The data link has been allocated 🎁 - 10
:evLnkDealloc:The data link has been de-allocated 🫗 - 11
:evTestRet:A retransmission timer has expired, so the Test message gets resent 🔁 - 12
:evSummaryFail:The LinkSummary didn't match for this data port 🙅 - 13
:evLocalizeFail:A Failure has been localised to this data link 📍 - 14
:evdcDown:The data channel isn't available anymore 🌧️
11.3.3. Active Data Link FSM Description 🦋
Figure 5 shows how the LMP active data link FSM works, as a state transition diagram. Serving main character energy 💅
+------+
| |<-------+
+--------->| Down | |
| +----| |<-----+ |
| | +------+ | |
| |5b 3| ^ | |
| | | |7 | |
| | v | | |
| | +------+ | |
| | | |<-+ | |
| | | Test | |11 | |
| | | |--+ | |
| | +------+ | |
| | 5a| 3^ | |
| | | | | |
| | v | | |
|12 | +---------+ | |
| +-->| |14 | |
| | Up/Free |----+ |
+---------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |------+
| |
+---------+Figure 5: Active LMP Data Link FSM
11.3.4. Passive Data Link FSM Description 🧚
Figure 6 shows how the LMP passive data link FSM works, as a state transition diagram. Same shape, different vibe 💜
+------+
| |<------+
+---------->| Down | |
| +-----| |<----+ |
| | +------+ | |
| |5b 4| ^ | |
| | | |8 | |
| | v | | |
| | +----------+ | |
| | | PasvTest | | |
| | +----------+ | |
| | 6| 4^ | |
| | | | | |
| | v | | |
|12 | +---------+ | |
| +--->| Up/Free |14 | |
| | |---+ |
+----------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |-----+
| |
+---------+Figure 6: Passive LMP Data Link FSM
12. LMP Message Formats 💌
Okay so every LMP message, except for the Test messages in some cases (since the transport mechanism for in-band messaging can limit them), runs over UDP on LMP port number (701) 🎀
12.1. Common Header 💖
On top of the UDP header and the standard IP header, all LMP messages (except the Test messages in some cases, which may be limited by the transport mechanism for in-band messaging) start with this common header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | (Reserved) | Flags | Msg Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMP Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Reserved field should be sent as zero and ignored on receipt 🧹
Everything is defined in network byte order, which is big-endian byte order 🌈
- Vers: 4 bits 🔢
- Protocol version number. This is version 1.
- Flags: 8 bits 🚩
- The following bit values are defined. All other bits are reserved, should be sent as zero, and should be ignored on receipt.
0x01: ControlChannelDown0x02: LMP Restart- This bit is set when a nodal failure has happened and the LMP control state has been lost. This flag may be reset to 0 when a Hello message is received with RcvSeqNum equal to the local TxSeqNum. 😱
- Msg Type: 8 bits 📬
- The following values are defined. All other values are reserved.
1 = Config
2 = ConfigAck
3 = ConfigNack
4 = Hello
5 = BeginVerify
6 = BeginVerifyAck
7 = BeginVerifyNack
8 = EndVerify
9 = EndVerifyAck
10 = Test
11 = TestStatusSuccess
12 = TestStatusFailure
13 = TestStatusAck
14 = LinkSummary
15 = LinkSummaryAck
16 = LinkSummaryNack
17 = ChannelStatus
18 = ChannelStatusAck
19 = ChannelStatusRequest
20 = ChannelStatusResponseAll of the messages go over the control channel, EXCEPT the Test message, which goes over the data link being tested 🛤️
- LMP Length: 16 bits 📏
- The total length of this LMP message in bytes, including the common header and any variable-length objects that follow. 🫶
12.2. LMP Object Format 🎀
okay so LMP messages are built out of objects 🧩 every object is identified by its Object Class and Class-type, and every object has a name that we always capitalize in this doc ✨ objects can be negotiable or non-negotiable, and the N bit in the object header tells you which one it is 💅 negotiable objects let the devices bargain over values, while non-negotiable objects are for announcing values that aren't up for debate 🙅♀️
all values are in network byte order (aka big-endian) 🌸 here's what the object looks like:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object contents) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's the breakdown 🔍
N is 1 bit. N=1 means the object is negotiable, and N=0 means it's non-negotiable 🫶
C-Type is 7 bits. It's the Class-type, and it's unique within an Object Class. The values live in Section 13 🧚
Class is 8 bits. It tells you what kind of object you're looking at. Each object has a name, and it's always capitalized here 💖
Length is 16 bits. It's the length of the whole object in bytes, and it counts the N, C-Type, Class, and Length fields too 📏
12.3. Parameter Negotiation Messages 🤝
12.3.1. Config Message (Msg Type = 1) 💌
the Config message is used during the control channel negotiation phase of LMP ✨ its contents are built from LMP objects, and it's laid out like this:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG>the above transmission order SHOULD be followed 📋
the MESSAGE_ID object is within the scope of the LOCAL_CCID object 🧠
the Config message MUST be periodically transmitted until one of three things happens: (1) it gets a ConfigAck or ConfigNack message back, (2) a retry limit gets hit and no ConfigAck or ConfigNack has shown up, or (3) it receives a Config message from the remote node and loses the contention (for example, the remote node's Node_Id is higher than the local node's Node_Id) 😭 both the retransmission interval and the retry limit are local configuration parameters, so you set those yourself ⚙️
12.3.2. ConfigAck Message (Msg Type = 2) ✅
the ConfigAck message acknowledges that the Config message was received, and it says "yes, we agree on everything" 🥰
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>the above transmission order SHOULD be followed 📋
the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be copied from the Config message being acknowledged 🪞
12.3.3. ConfigNack Message (Msg Type = 3) 🙅♀️
the ConfigNack message also acknowledges the Config message, but it says "nope" 💀 it's used to show disagreement on non-negotiable parameters, or to suggest other values for negotiable ones 🔄 parameters where agreement was reached MUST NOT be included in the ConfigNack message 🚫
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>the above transmission order SHOULD be followed 📋
the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being negatively acknowledged 🔍
it's possible that more than one parameter is invalid in the Config message 🙈
if a negotiable CONFIG object is in the ConfigNack message, it MUST include acceptable values for its parameters 🌈
if the ConfigNack message has CONFIG objects for non-negotiable parameters, those MUST be copied from the CONFIG objects that were received in the Config message 🫶
if the ConfigNack message is received and it only has negotiable CONFIG objects, then a new Config message SHOULD be sent 🔁 the values in that new Config message's CONFIG object SHOULD take into account the acceptable values in the ConfigNack message 🧠
if a node receives a Config message and recognizes the CONFIG object but doesn't recognize the C-Type, then a ConfigNack message MUST be sent that includes the unknown CONFIG object 🚨
12.4. Hello Message (Msg Type = 4) 👋
the Hello message looks like this:
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>the above transmission order SHOULD be followed 📋
the Hello message MUST be periodically transmitted at least once every HelloInterval msec 💓 if no Hello message gets received within the HelloDeadInterval, the control channel is assumed to have failed 💀
12.5. Link Verification Messages 🔎
12.5.1. BeginVerify Message (Msg Type = 5) 🚀
the BeginVerify message goes over the control channel and starts the link verification process ✨
<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY>the above transmission order SHOULD be followed 📋
to limit the scope of Link Verification to one particular TE Link, the Link_Id field of the LOCAL_LINK_ID object MUST be non-zero 🎯 if that field is zero, the data links can span multiple TE links and/or they may make up a TE link that hasn't been configured yet 🤷♀️ in that special case where the local Link_Id field is zero, the "Verify all Links" flag of the BEGIN_VERIFY object is what tells the difference between data links that span multiple TE links and data links that haven't been assigned to a TE link yet (see Section 5) 🧩
the REMOTE_LINK_ID object may be included if the local/remote Link_Id mapping is known 🗺️
if it's included, the Link_Id field of the REMOTE_LINK_ID object MUST be non-zero 🔢
the BeginVerify message MUST be periodically transmitted until either (1) the node gets a BeginVerifyAck or BeginVerifyNack message to accept or reject the verify process, or (2) a retry limit has been reached and no BeginVerifyAck or BeginVerifyNack message has come back 🥺 both the retransmission interval and the retry limit are local configuration parameters ⚙️
12.5.2. BeginVerifyAck Message (Msg Type = 6) 🥳
when a BeginVerify message is received and Test messages are ready to be processed, a BeginVerifyAck message MUST be transmitted 💅
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID>the above transmission order SHOULD be followed 📋
the LOCAL_LINK_ID object may be included if the local/remote Link_Id mapping is known or was learned through the BeginVerify message 🧠
if the LOCAL_LINK_ID is included, its Link_Id field MUST be non-zero 🔢
the contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being acknowledged 🔍
the VERIFY_ID object holds a node-unique value that's assigned by whoever generated the BeginVerifyAck message 🪪 this value is how you tell one Verification process apart from others coming from multiple LMP neighbors and/or parallel Test procedures between the same LMP neighbors 🫶
12.5.3. BeginVerifyNack Message (Msg Type = 7) 🙅♀️
if a BeginVerify message is received and the node is unwilling or unable to begin the Verification procedure, a BeginVerifyNack message MUST be transmitted 🚫
<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <ERROR_CODE>the above transmission order SHOULD be followed 📋
the contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being negatively acknowledged 🔍
if the Verification process isn't supported, the ERROR_CODE MUST indicate "Link Verification Procedure not supported" 😬
if Verification is supported but the node can't begin the procedure, the ERROR_CODE MUST indicate "Unwilling to verify" 🙅♀️ if a BeginVerifyNack message comes in with that ERROR_CODE, the node that originated the BeginVerify SHOULD schedule a BeginVerify retransmission after Rf seconds, where Rf is a locally defined parameter ⏰
if the Verification Transport mechanism isn't supported, the ERROR_CODE MUST indicate "Unsupported verification transport mechanism" 🚧
if remote configuration of the Link_Id isn't supported and the content of the REMOTE_LINK_ID object (included in the BeginVerify message) doesn't match any configured values, the ERROR_CODE MUST indicate "Link_Id configuration error" 🧐
if a node receives a BeginVerify message and recognizes the BEGIN_VERIFY object but not its C-Type, the ERROR_CODE MUST indicate "Unknown object C-Type" 🤨
12.5.4. EndVerify Message (Msg Type = 8) 🛑
the EndVerify message goes over the control channel and ends the link verification process 🏁 the initiating node can send it any time it wants to end the Verify procedure 💁♀️
<EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>the above transmission order SHOULD be followed 📋
the EndVerify message will be periodically transmitted until either (1) an EndVerifyAck message has been received, or (2) a retry limit has been reached and no EndVerifyAck message has been received 🔁 both the retransmission interval and the retry limit are local configuration parameters ⚙️
12.5.5. EndVerifyAck Message (Msg Type =9) 🫶
the EndVerifyAck message goes over the control channel and acknowledges that the link verification process has ended 🎉
<EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>the above transmission order SHOULD be followed 📋
the contents of the MESSAGE_ID_ACK object MUST be obtained from the EndVerify message being acknowledged 🪞
12.5.6. Test Message (Msg Type = 10) 🦋
Okay bestie, the Test message is the one that actually travels over the data link to check that the physical connection is working. Unless it says otherwise, these messages MUST be sent over UDP, just like every other LMP message 💅 The format goes like this:
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>The above transmission order SHOULD be followed ✨
Heads up 🙈 this one goes over a data link, not the control channel. The transport gets negotiated with the Verify Transport Mechanism field of the BEGIN_VERIFY object and the Verify Transport Response field of the BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).
The transmitting node keeps sending a Test message periodically (at least once every VerifyInterval ms) on that data link. It stops when either (1) it gets a correlating TestStatusSuccess or TestStatusFailure message over the control channel from the receiving node, or (2) all the active control channels between the two nodes have failed. Meanwhile, the remote node keeps sending a TestStatus message periodically over the control channel until it gets either a correlating TestStatusAck message or an EndVerify message 🫶
12.5.7. TestStatusSuccess Message (Msg Type = 11) 🎀
The TestStatusSuccess message goes over the control channel and is used to send the mapping between the local Interface_Id and the Interface_Id that came in the Test message. Iconic 👑
<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID>The above transmission order SHOULD be followed 💖
The contents of the REMOTE_INTERFACE_ID object MUST be copied from the corresponding Test message being positively acknowledged 🌸
12.5.8. TestStatusFailure Message (Msg Type = 12) 🙈
The TestStatusFailure message also goes over the control channel, and it's used to say that the Test message was not received. Not me having to explain that one 💀
<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
<VERIFY_ID>The above transmission order SHOULD be followed 🧚
12.5.9. TestStatusAck Message (Msg Type = 13) 🌈
The TestStatusAck message is used to acknowledge that the TestStatusSuccess or TestStatusFailure message arrived. Literally the receipt of the receipt 😭
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>The above transmission order SHOULD be followed ✨
The contents of the MESSAGE_ID_ACK object MUST be obtained from the TestStatusSuccess or TestStatusFailure message being acknowledged 💜
12.6. Link Summary Messages 🍓
12.6.1. LinkSummary Message (Msg Type = 14) 🦋
The LinkSummary message is used to synchronize the Interface_Ids and to line up the properties of the TE link. It's giving teamwork 🫶
<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...]The above transmission order SHOULD be followed ✨
A LinkSummary message can be exchanged any time a link is not in the Verification process. It MUST be sent periodically until either (1) the node receives a LinkSummaryAck or LinkSummaryNack message, or (2) a retry limit has been reached and no LinkSummaryAck or LinkSummaryNack message has come back. Both the retransmission interval and the retry limit are local configuration parameters, so they're on you, bestie 🔥
12.6.2. LinkSummaryAck Message (Msg Type = 15) 💅
The LinkSummaryAck message says "yep, we agree" on the Interface_Id synchronization and on accepting all the link parameters. The second this message lands, the local node makes the Link_Id associations. Main character moment 👑
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>The above transmission order SHOULD be followed 🌸
12.6.3. LinkSummaryNack Message (Msg Type = 16) 🙈
The LinkSummaryNack message is used to say "nope, not agreed" on non-negotiated parameters, or to suggest other values for negotiable parameters. Parameters where agreement was reached MUST NOT be included in the LinkSummaryNack message. Don't overthink it, just leave them out 🫶
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]The above transmission order SHOULD be followed ✨
The DATA_LINK objects MUST include acceptable values for all negotiable parameters. If the LinkSummaryNack includes DATA_LINK objects for non-negotiable parameters, they MUST be copied from the DATA_LINK objects received in the LinkSummary message 💖
If a LinkSummaryNack message is received and only includes negotiable parameters, then a new LinkSummary message SHOULD be sent. The values in that new LinkSummary message SHOULD take into account the acceptable parameters included in the LinkSummaryNack message. Compromise era 🌈
Now the error codes, which are very specific so pay attention 🧐
- If the LinkSummary message is received with unacceptable, non-negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable non-negotiable LINK_SUMMARY parameters."
- If the LinkSummary message is received with unacceptable negotiable parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY parameters."
- If the LinkSummary message is received with an invalid TE_LINK object, the ERROR_CODE MUST indicate "Invalid TE_LINK object."
- If the LinkSummary message is received with an invalid DATA_LINK object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object."
- If the LinkSummary message is received with a TE_LINK object but the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown TE_LINK object C-Type."
- If the LinkSummary message is received with a DATA_LINK object but the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown DATA_LINK object C-Type."
12.7. Fault Management Messages 🚨
12.7.1. ChannelStatus Message (Msg Type = 17) 💖
The ChannelStatus message goes over the control channel and tells an LMP neighbor how a data link is doing. A node that receives a ChannelStatus message MUST respond with a ChannelStatusAck message. Here's the format 🎀
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS>The above transmission order SHOULD be followed ✨
If the CHANNEL_STATUS object doesn't include any Interface_Ids, that means the entire TE Link has failed. Oof 😭
12.7.2. ChannelStatusAck Message (Msg Type = 18) 🧚
The ChannelStatusAck message acknowledges that the ChannelStatus message was received. The format is:
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>The above transmission order SHOULD be followed 🌸
The contents of the MESSAGE_ID_ACK object MUST be obtained from the ChannelStatus message being acknowledged 💜
12.7.3. ChannelStatusRequest Message (Msg Type = 19) 🦋
The ChannelStatusRequest message goes over the control channel and is used to ask for the status of one or more data links. A node that receives a ChannelStatusRequest message MUST respond with a ChannelStatusResponse message. The format:
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>]The above transmission order SHOULD be followed 🫶
If the CHANNEL_STATUS_REQUEST object is not included, the ChannelStatusRequest is asking for the status of ALL of the data links of the TE Link. Full send 🔥
12.7.4. ChannelStatusResponse Message (Msg Type = 20) 👑
The ChannelStatusResponse message acknowledges the ChannelStatusRequest message and tells the LMP neighbor the status of the data channel(s). The format:
<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
<CHANNEL_STATUS>The above transmission order SHOULD be followed ✨
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ChannelStatusRequest message being acknowledged 🌈
13. LMP Object Definitions 🧚
13.1. CCID (Control Channel ID) Class 🎀
Class = 1
- C-Type = 1, LOCAL_CCID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+CC_Id: 32 bits
This MUST be node-wide unique and non-zero. The CC_Id identifies the control channel of the sender associated with the message 💅
This object is non-negotiable.
- C-Type = 2, REMOTE_CCID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+CC_Id: 32 bits
This identifies the remote node's CC_Id and MUST be non-zero 🫶
This object is non-negotiable.
13.2. NODE_ID Class 💜
Class = 2
- C-Type = 1, LOCAL_NODE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Node_Id:
This identifies the node that originated the LMP packet ✨
This object is non-negotiable.
- C-Type = 2, REMOTE_NODE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Node_Id:
This identifies the remote node 🌸
This object is non-negotiable.
13.3. LINK_ID Class 🔗
Okay bestie, the LINK_ID class is where we name our Links 💅 It's Class = 3, and it comes in a bunch of flavours depending on the address family and whether it's the local or remote end.
C-Type = 1, IPv4 LOCAL_LINK_IDC-Type = 2, IPv4 REMOTE_LINK_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C-Type = 3, IPv6 LOCAL_LINK_IDC-Type = 4, IPv6 REMOTE_LINK_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C-Type = 5, Unnumbered LOCAL_LINK_IDC-Type = 6, Unnumbered REMOTE_LINK_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Link_Id:
For LOCAL_LINK_ID, this is the sender's Link for the message, and it's giving main character energy ✨ This value MUST be non-zero.
For REMOTE_LINK_ID, this is the remote node's Link_Id, and it MUST be non-zero 🌸
This object is non-negotiable 🔒
13.4. INTERFACE_ID Class 🦋
Next up is INTERFACE_ID, Class = 4. Same deal as LINK_ID, just for data links instead of Links 💜
C-Type = 1, IPv4 LOCAL_INTERFACE_IDC-Type = 2, IPv4 REMOTE_INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C-Type = 3, IPv6 LOCAL_INTERFACE_IDC-Type = 4, IPv6 REMOTE_INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C-Type = 5, Unnumbered LOCAL_INTERFACE_IDC-Type = 6, Unnumbered REMOTE_INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Interface_Id:
For the LOCAL_INTERFACE_ID, this identifies the data link. This value MUST be node-wide unique and non-zero. Very important, no duplicates allowed 🙅♀️
For the REMOTE_INTERFACE_ID, this identifies the remote node's data link. The Interface_Id MUST be non-zero 💖
This object is non-negotiable 🔒
13.5. MESSAGE_ID Class 📨
Class = 5 is MESSAGE_ID, and it's how messages get tracked and acknowledged. It's giving receipts 🧾
C-Type=1, MessageId
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message_Id:
The Message_Id field identifies a message. The value goes up over time and only ever goes down when it wraps around 🔄 It's how acknowledgments get matched up.
This object is non-negotiable 🔒
C-Type = 2, MessageIdAck
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Message_Id:
The Message_Id field identifies the message being acknowledged. This value is copied from the MESSAGE_ID object of the message being acknowledged. Copy-paste energy, but make it a protocol 📋
This object is non-negotiable 🔒
13.6. CONFIG Class ⚙️
Class = 6. is CONFIG, and this is where the timers live ⏰
C-Type = 1, HelloConfig
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+HelloInterval: 16 bits.
This tells you how often Hello packets get sent, measured in milliseconds (ms) ⏱️
HelloDeadInterval: 16 bits.
If no Hello packets come in within the HelloDeadInterval, the control channel is assumed to have failed. Rip 💀 It's measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and it SHOULD be at least 3 times the value of HelloInterval 🥰
If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero. No keep-alive, no timers, zero vibes 0️⃣
13.7. HELLO Class 👋
Class = 7 is HELLO, the little "still alive?" messages of the control channel 💬
C-Type = 1, Hello
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RcvSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TxSeqNum: 32 bits
This is the current sequence number for this Hello message. It gets incremented once it's reflected in the RcvSeqNum of a Hello packet received over the control channel. It's a whole back-and-forth, bestie 🏓
TxSeqNum=0 is not allowed 🚫 TxSeqNum=1 is used to indicate that this is the first Hello message sent over the control channel. Fresh start, new vibes 🌱
RcvSeqNum: 32 bits
This is the sequence number of the last Hello message received over the control channel. RcvSeqNum=0 is used to indicate that a Hello message has not yet been received. Nothing received yet, so zero is the honest answer 🫶
This object is non-negotiable 🔒
13.8. BEGIN_VERIFY Class 🔍
Class = 8 is BEGIN_VERIFY, and this is the message that kicks off the whole verification situation 🎬
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | VerifyInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | (Reserved) | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TransmissionRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Reserved field should be sent as zero and ignored on receipt. Lowkey a vibe check for everyone 🌿
Flags: 16 bits
The following flags are defined:
0x0001Verify all Links: If this bit is set, the verification process checks all unallocated links. Otherwise it only verifies new ports or component links that are about to be added to this TE link 🔗0x0002Data Link Type: If set, the data links to be verified are ports. Otherwise, they are component links 🔌
VerifyInterval: 16 bits
This is the gap between successive Test messages, measured in milliseconds (ms) ⏳
Number of Data Links: 32 bits
This is how many data links are going to get verified 🔢
EncType: 8 bits
This is the encoding type of the data link. The defined EncType values line up with the LSP Encoding Type values of [RFC3471] 🧩
Verify Transport Mechanism: 16 bits
This defines the transport mechanism for the Test Messages. The scope of this bit mask is limited to each encoding type. The local node sets the bits for every mechanism it can support for sending LMP test messages, and the receiver picks the one it wants in the BeginVerifyAck message 🎯
The following flag is defined across all Encoding Types. Every other flag depends on the Encoding Type:
0x8000 Payload:Test Message transmitted in the payload: Capable of sending Test messages in the payload. The Test message goes out as an IP packet, as defined above 📦
TransmissionRate: 32 bits
This is the transmission rate of the data link the Test messages get sent over. It's expressed in bytes per second and represented in IEEE floating-point format 📈
Wavelength: 32 bits
When a data link is assigned to a port or component link that can transmit multiple wavelengths (like a fiber or waveband-capable port), it's essential to know which wavelength the test messages go over 🌈 This value corresponds to the wavelength the Test messages get sent at, and it only has local significance. If there's no ambiguity about which wavelength the message gets sent over, then this value SHOULD be set to 0 ✨
13.9. BEGIN_VERIFY_ACK Class ✅
Class = 9 is BEGIN_VERIFY_ACK, the reply that says "yep, let's go" 💜
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+VerifyDeadInterval: 16 bits
If a Test message doesn't get detected within the VerifyDeadInterval, then a node sends the TestStatusFailure message for that data link. Not it 😤
Verify_Transport_Response: 16 bits
The recipient of the BeginVerify message (and the future recipient of the TEST messages) picks the transport mechanism from the options offered by the transmitter of the Test messages. One and only one bit MUST be set in the verification transport response. Pick ONE, no more, no less 🎀
This object is non-negotiable 🔒
That's the whole LINK_ID through BEGIN_VERIFY_ACK crew, bestie 🌈💅
13.10. VERIFY_ID Class ✨
okay so this one is giving tiny but mighty 🦋 Class = 10 and there's just one C-Type, C-Type = 1 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verify_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Verify_Id is 32 bits 💜 and its whole job is to tell apart Test messages coming from different TE links and/or LMP peers. It's a node-unique value, which means it's assigned by the recipient of the BeginVerify message 🫶
This object is non-negotiable 💅
13.11. TE_LINK Class 🌈
Class = 11, and this one comes in three flavours depending on the C-Type 🧚
C-Type = 1, IPv4 TE_LINKC-Type = 2, IPv6 TE_LINKC-Type = 3, Unnumbered TE_LINK
For IPv4 TE_LINK (C-Type = 1):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For IPv6 TE_LINK (C-Type = 2):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For Unnumbered TE_LINK (C-Type = 3):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Reserved field should be sent as zero and ignored on receipt 🌸
Flags: 8 bits 🚩 Only these flags are defined, and every other bit-value is reserved, so it should be sent as zero and ignored on receipt:
0x01Fault Management Supported.0x02Link Verification Supported.
Local_Link_Id: this identifies the node's local Link_Id, and it MUST be non-zero 💖
Remote_Link_Id: this identifies the remote node's Link_Id, and it MUST be non-zero 💖
13.12. DATA_LINK Class 🍓
Class = 12, and there are three C-Types here too 👑
C-Type = 1, IPv4 DATA_LINKC-Type = 2, IPv6 DATA_LINKC-Type = 3, Unnumbered DATA_LINK
For IPv4 DATA_LINK (C-Type = 1):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For IPv6 DATA_LINK (C-Type = 2):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For Unnumbered DATA_LINK (C-Type = 3):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Reserved field should be sent as zero and ignored on receipt 🌷
Flags: 8 bits 🎀 Only these flags are defined, and every other bit-value is reserved, so it should be sent as zero and ignored on receipt:
0x01Interface Type: If set, the data link is a port, otherwise it is a component link.0x02Allocated Link: If set, the data link is currently allocated for user traffic. If a single Interface_Id is used for both the transmit and receive data links, then this bit only applies to the transmit interface.0x04Failed Link: If set, the data link is failed and not suitable for user traffic.
Local_Interface_Id: this is the local identifier of the data link, and it MUST be node-wide unique and non-zero 🔥
Remote_Interface_Id: this is the remote identifier of the data link, and it MUST be non-zero ✨
Subobjects: the contents of the DATA_LINK object are a series of variable-length data items called subobjects 🧚 They're defined in Section 13.12.1 below.
A DATA_LINK object may contain more than one subobject 💜 More than one subobject of the same Type may show up if multiple capabilities are supported over the data link. Multiples are literally allowed, bestie 💅
13.12.1. Data Link Subobjects 🦋
The contents of the DATA_LINK object include a series of variable-length data items called subobjects, and each one has this form:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+Type: 8 bits 🌈 This tells you what kind of contents the subobject holds. The currently defined values are:
Type = 1, Interface Switching TypeType = 2, Wavelength
Length: 8 bits 📏 This is the total length of the subobject in bytes, counting the Type and Length fields too. The Length MUST be at least 4, and MUST be a multiple of 4 💖
13.12.1.1. Subobject Type 1: Interface Switching Type 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Switching Type| EncType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Switching Type: 8 bits 🔁 This identifies the local Interface Switching Type of the TE link, as defined in [RFC3471].
EncType: 8 bits 🧵 This is the encoding type of the data link. The defined EncType values are consistent with the LSP Encoding Type values of [RFC3471].
Minimum Reservable Bandwidth: 32 bits 🫧 This is measured in bytes per second and represented in IEEE floating point format.
Maximum Reservable Bandwidth: 32 bits 🫧 This is measured in bytes per second and represented in IEEE floating point format.
If the interface only supports a fixed rate, the minimum and maximum bandwidth fields are set to the same value 🎯
13.12.1.2. Subobject Type 2: Wavelength 🌈
Okay so this one's the wavelength subobject, and it's giving tidy little box 📦✨ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Reserved field should be sent as zero and ignored on receipt. 🫶 Basically, put zeros in there and don't fuss over what you read back.
Wavelength: 32 bits 🔥 This tells you which wavelength is carried over the port. The values only mean something between the two neighbors on either end, so they aren't some universal code. Lowkey iconic that it's scoped like that 💅
13.13. CHANNEL_STATUS Class 🚦
Class = 13C-Type = 1, IPv4 INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C-Type = 2, IPv6 INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C-Type = 3, Unnumbered INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel_Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Active bit: 1 bit ⚡ This indicates that the Channel is allocated to user traffic and the data link should be actively monitored.
Direction bit: 1 bit ➡️⬅️ This tells you the direction (transmit/receive) of the data channel that the CHANNEL_STATUS object is talking about. If it's set, the data channel is in the transmit direction.
Channel_Status: 30 bits 🚨 This is the status condition of a data channel. These are the defined values, and everything else is reserved:
1 Signal Okay (OK): Channel is operational
2 Signal Degrade (SD): A soft failure caused by a BER exceeding
a preselected threshold. The specific
BER used to define the threshold is
configured.
3 Signal Fail (SF): A hard signal failure including (but not
limited to) loss of signal (LOS), loss of
frame (LOF), or Line AIS.This object contains one or more Interface_Ids followed by a Channel_Status field. 💖
To show the status of the whole TE Link, there MUST be only one Interface_Id, and it MUST be zero. 👑 Those are the rules, no exceptions.
This object is non-negotiable. 💅
13.14. CHANNEL_STATUS_REQUEST Class 🧚
Class = 14C-Type = 1, IPv4 INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This object contains one or more Interface_Ids. 🌸
The Length of this object is 4 + 4N in bytes, where N is the number of Interface_Ids. 🧮
C-Type = 2, IPv6 INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This object contains one or more Interface_Ids. 🦋
The Length of this object is 4 + 16N in bytes, where N is the number of Interface_Ids. 🔢
C-Type = 3, Unnumbered INTERFACE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This object contains one or more Interface_Ids. ✨
The Length of this object is 4 + 4N in bytes, where N is the number of Interface_Ids. 💜
This object is non-negotiable. 💅🎀
13.15. ERROR_CODE Class 💌
Okay so this is the ERROR_CODE object, aka the way a node tells its bestie exactly what went wrong 🙈 It's giving "we need to talk." Here's the Class number:
Class = 20
There are two C-Types, and they're both lowkey iconic.
- C-Type = 1, BEGIN_VERIFY_ERROR
- C-Type = 2, LINK_SUMMARY_ERROR
C-Type = 1, BEGIN_VERIFY_ERROR 🦋
The layout for this one is a single 32-bit ERROR CODE field:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The bit-values are defined in network byte order (big-endian), and they mean:
0x01= Link Verification Procedure not supported.0x02= Unwilling to verify.0x04= Unsupported verification transport mechanism.0x08= Link_Id configuration error.0x10= Unknown object C-Type.
All the other bit-values are reserved. They should be sent as zero and ignored on receipt 💅 Also, you can set multiple bits at once to flag multiple errors, which is very much a "list all the drama" moment ✨
This object is non-negotiable 🔒
If a BeginVerifyNack message comes in with Error Code 2, the node that originated the BeginVerify SHOULD schedule a BeginVerify retransmission after Rf seconds, where Rf is a locally defined parameter. So the retry timing is a local choice, bestie 🧚
C-Type = 2, LINK_SUMMARY_ERROR 🌈
Same vibe, different drama. The layout is the same single 32-bit ERROR CODE field:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Again, network byte order (big-endian), and the bit-values are:
0x01= Unacceptable non-negotiable LINK_SUMMARY parameters.0x02= Renegotiate LINK_SUMMARY parameters.0x04= Invalid TE_LINK Object.0x08= Invalid DATA_LINK Object.0x10= Unknown TE_LINK object C-Type.0x20= Unknown DATA_LINK object C-Type.
Every other bit-value is reserved, so send it as zero and ignore it on receipt. Multiple bits can be set for multiple errors, and this object is non-negotiable too 🫶
14. References 📚
14.1. Normative References 🔥
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
- [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
- [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
- [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
- [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
- [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [RFC3471] Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.
14.2. Informative References 🧠
- [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
- [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
15. Security Considerations 🚨
This part is serious, bestie. Read it all 🫠
There are number of attacks that an LMP protocol session can potentially experience. Some examples include:
- an adversary may spoof control packets;
- an adversary may modify the control packets in transit;
- an adversary may replay control packets;
- an adversary may study a number of control packets and try to break the key using cryptographic tools. If the hash/encryption algorithm used has known weaknesses, then it becomes easy for the adversary to discover the key using simple tools.
This section specifies an IPsec-based security mechanism for LMP 🔐
15.1. Security Requirements 🛡️
The following requirements are applied to the mechanism described in this section.
- LMP security MUST be able to provide authentication, integrity, and replay protection.
- For LMP traffic, confidentiality is not needed. Only authentication is needed to ensure that the control packets (packets sent along the LMP Control Channel) are originating from the right place and have not been modified in transit. LMP Test packets exchanged through the data links do not need to be protected.
- For LMP traffic, protecting the identity of LMP end-points is not commonly required.
- The security mechanism should provide for well defined key management schemes. The key management schemes should be well analyzed to be cryptographically secure. The key management schemes should be scalable. In addition, the key management system should be automatic.
- The algorithms used for authentication MUST be cryptographically sound. Also, the security protocol MUST allow for negotiating and using different authentication algorithms.
15.2. Security Mechanisms ✨
okay so IPsec is a whole protocol suite 🔐 that secures communication at the network layer between two peers. The bundle is made up of the IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management protocol for IP networks, and AH and ESP are the ones actually protecting the IP traffic 💖. IKE is defined specific to the IP domain of interpretation, so it's very much tailored 🎀.
Considering the requirements in Section 15.1, it is recommended that, where security is needed for LMP, implementations use IPsec as described below 🫶:
- Implementations of LMP over IPsec protocol SHOULD support manual keying mode.
Manual keying mode gives you an easy way to set up and diagnose IPsec functionality 🧚.
However, note that manual keying mode cannot effectively support features such as replay protection and automatic re-keying. An implementer using manual keys must be aware of these limits 💀.
It is recommended that an implementer use manual keying only for diagnostic purposes, and use dynamic keying protocol to make use of features such as replay protection and automatic re-keying 🌸.
- IPsec ESP with trailer authentication in tunnel mode MUST be supported 💅.
- Implementations MUST support authenticated key exchange protocols. IKE [RFC2409] MUST be used as the key exchange protocol if keys are dynamically negotiated between peers 🔥.
- Implementation MUST use the IPsec DOI [RFC2407] 👑.
- For IKE protocol, the identities of the SAs negotiated in Quick Mode represent the traffic that the peers agree to protect, and are comprised of address space, protocol, and port information. It's giving main character energy 🦋.
For LMP over IPsec, it is recommended that the identity payload for Quick mode contain the following information:
The identities MUST be of type IP addresses, and the value of the identities SHOULD be the IP addresses of the communicating peers 🍓.
The protocol field MUST be UDP. The port field SHOULD be set to zero to indicate port fields should be ignored. This implies all UDP traffic between the peers must be sent through the IPsec tunnel. If an implementation supports port-based selectors, it can opt for a more finely grained selector by specifying the port field to the LMP port. If, however, the peer does not use port-based selectors, the implementation MUST fall back to using a port selector value of 0 😭.
- Aggressive mode of IKE negotiation MUST be supported ✨.
When IPsec is configured to be used with a peer, all LMP messages are expected to be sent over the IPsec tunnel (crypto channel). Similarly, an LMP receiver configured to use Ipsec with a peer should reject any LMP traffic that does not come through the crypto channel 🙈.
The crypto channel can be pre-setup with the LMP neighbor, or the first LMP message sent to the peer can trigger the creation of the IPsec tunnel 🌈.
A set of control channels can share the same crypto channel. When LMP Hellos are used to monitor the status of the control channel, it is important to keep in mind that the keep-alive failure in a control channel may also be due to a failure in the crypto channel. The following method is recommended to ensure that an LMP communication path between two peers is working properly 🧠.
- If LMP Hellos detect a failure on a control channel, switch to an alternate control channel and/or try to establish a new control channel.
- Ensure the health of the control channels using LMP Hellos. If all control channels indicate a failure and it is not possible to bring up a new control channel, tear down all existing control channels. Also, tear down the crypto channel (both the IKE SA and IPsec SAs).
- Reestablish the crypto channel. Failure to establish a crypto channel indicates a fatal failure for LMP communication.
- Bring up the control channel. Failure to bring up the control channel indicates a fatal failure for LMP communication.
When LMP peers are dynamically discovered (particularly the initiator), the following points should be noted 👀:
When using pre-shared key authentication in identity protection mode (main mode), the pre-shared key is required to compute the value of SKEYID (used for deriving keys to encrypt messages during key exchange). In main mode of IKE, the pre-shared key to be used has to be identified before receiving the peer's identity payload. The pre-shared key is required for calculating SKEYID. The only information available about the peer at this point is its IP address from which the negotiation came from. Keying off the IP address of a peer to get the pre-shared key is not possible, since the addresses are dynamic and not known beforehand 🥺.
Aggressive mode key exchange can be used, since identification payloads are sent in the first message 🎯.
Note, however, that aggressive mode is prone to passive denial of service attacks. Using a shared secret (group shared secret) among a number of peers is strongly discouraged, because this opens up the solution to man-in-the-middle attacks 🚨.
Digital-signature-based authentication is not prone to such problems. It is RECOMMENDED that a digital-signature-based authentication mechanism be used where possible 💜.
If pre-shared-key-based authentication is required, then aggressive mode SHOULD be used. IKE pre-shared authentication key values SHOULD be protected in a manner similar to the user's account password 🔐✨.
16. IANA Considerations ✨
okay so the IANA has assigned port number 701 to LMP 🎀
so here's the deal 💅 this part gives guidelines for how IANA assigns codes in each LMP name space. Ranges are set aside for Private Use, for Expert Review, and for Standards Action (as defined in [RFC2434].
Private Use is the proprietary-extension zone 🙈 Assignments from there don't need to be documented. But ngl, independent LMP implementations that use the same Private Use code points generally won't interoperate, so be careful with those in a multi-vendor network 🧚
Expert Review ranges get checked by an Expert that the IESG designates 👑 The intent is that these code points are used for Experimental extensions, so assignments MUST be accompanied by Experimental RFCs. If deployment shows these extensions are useful, they should be described in Standards Track RFCs, and new code points from the Standards Action ranges MUST be assigned. 🔥
Standards Action ranges are the main-character zone ✨ Assignments from them MUST be documented by a Standards Track RFC, typically submitted to an IETF Working Group, but in any case following the usual IETF procedures for Proposed Standards.
The Reserved bits of the LMP Common Header should be allocated by Standards Action, pursuant to the policies outlined in [RFC2434]. 🦋
LMP defines the following name spaces that require management:
- LMP Message Type.
- LMP Object Class.
- LMP Object Class type (C-Type). These are unique within the Object Class.
- LMP Sub-object Class type (Type). These are unique within the Object Class.
Okay, the LMP Message Type name space should be allocated like this: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-127 are allocated by Standards Action, 128-240 are allocated through an Expert Review, and 241-255 are reserved for Private Use. 💖
The LMP Object Class name space should be allocated like this: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for Private Use. 🌸
The policy for allocating values out of the LMP Object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which the Object Class names are allocated. 🧚
The policy for allocating values out of the LMP Sub-object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which sub-objects are allocated. 🧚
The following name spaces have been assigned by IANA: 🌈
------------------------------------------------------------------
LMP Message Type name space
o Config message (Message type = 1)
o ConfigAck message (Message type = 2)
o ConfigNack message (Message type = 3)
o Hello message (Message type = 4)
o BeginVerify message (Message type = 5)
o BeginVerifyAck message (Message type = 6)
o BeginVerifyNack message (Message type = 7)
o EndVerify message (Message type = 8)
o EndVerifyAck message (Message type = 9)
o Test message (Message type = 10)
o TestStatusSuccess message (Message type = 11)
o TestStatusFailure message (Message type = 12)
o TestStatusAck message (Message type = 13)
o LinkSummary message (Message type = 14)
o LinkSummaryAck message (Message type = 15)
o LinkSummaryNack message (Message type = 16)
o ChannelStatus message (Message type = 17)
o ChannelStatusAck message (Message type = 18)
o ChannelStatusRequest message (Message type = 19)
o ChannelStatusResponse message (Message type = 20)------------------------------------------------------------------
LMP Object Class name space and Class type (C-Type)
o CCID Class name (1)
The CCID Object Class type name space should be allocated as follows:
pursuant to the policies outlined in [RFC2434], the numbers in the
range 0-111 are allocated by Standards Action, 112-119 are allocated
through an Expert Review, and 120-127 are reserved for Private Use.
- LOCAL_CCID (C-Type = 1)
- REMOTE_CCID (C-Type = 2)
o NODE_ID Class name (2)
The NODE ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- LOCAL_NODE_ID (C-Type = 1)
- REMOTE_NODE_ID (C-Type = 2)
o LINK_ID Class name (3)
The LINK_ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- IPv4 LOCAL_LINK_ID (C-Type = 1)
- IPv4 REMOTE_LINK_ID (C-Type = 2)
- IPv6 LOCAL_LINK_ID (C-Type = 3)
- IPv6 REMOTE_LINK_ID (C-Type = 4)
- Unnumbered LOCAL_LINK_ID (C-Type = 5)
- Unnumbered REMOTE_LINK_ID (C-Type = 6)
o INTERFACE_ID Class name (4)
The INTERFACE_ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- IPv4 LOCAL_INTERFACE_ID (C-Type = 1)
- IPv4 REMOTE_INTERFACE_ID (C-Type = 2)
- IPv6 LOCAL_INTERFACE_ID (C-Type = 3)
- IPv6 REMOTE_INTERFACE_ID (C-Type = 4)
- Unnumbered LOCAL_INTERFACE_ID (C-Type = 5)
- Unnumbered REMOTE_INTERFACE_ID (C-Type = 6)
o MESSAGE_ID Class name (5)
The MESSAGE_ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- MESSAGE_ID (C-Type = 1)
- MESSAGE_ID_ACK (C-Type = 2)
o CONFIG Class name (6)
The CONFIG Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- HELLO_CONFIG (C-Type = 1)
o HELLO Class name (7)
The HELLO Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- HELLO (C-Type = 1)
o BEGIN_VERIFY Class name (8)
The BEGIN_VERIFY Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- Type 1 (C-Type = 1)
o BEGIN_VERIFY_ACK Class name (9)
The BEGIN_VERIFY_ACK Object Class type name space should be allocated
as follows: pursuant to the policies outlined in [RFC2434], the
numbers in the range 0-111 are allocated by Standards Action, 112-119
are allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- Type 1 (C-Type = 1)
o VERIFY_ID Class name (10)
The VERIFY_ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- Type 1 (C-Type = 1)
o TE_LINK Class name (11)
The TE_LINK Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- IPv4 TE_LINK (C-Type = 1)
- IPv6 TE_LINK (C-Type = 2)
- Unnumbered TE_LINK (C-Type = 3)
o DATA_LINK Class name (12)
The DATA_LINK Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
private Use.
- IPv4 DATA_LINK (C-Type = 1)
- IPv6 DATA_LINK (C-Type = 2)
- Unnumbered DATA_LINK (C-Type = 3)
The DATA_LINK Sub-object Class name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range of 0-127 are allocated by Standards Action, 128-247 are
allocated through an Expert Review, and 248-255 are reserved for
private Use.
- Interface Switching Type (sub-object Type = 1)
- Wavelength (sub-object Type = 2)
o CHANNEL_STATUS Class name (13)
The CHANNEL_STATUS Object Class type name space should be allocated
as follows: pursuant to the policies outlined in [RFC2434], the
numbers in the range 0-111 are allocated by Standards Action, 112-119
are allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- IPv4 INTERFACE_ID (C-Type = 1)
- IPv6 INTERFACE_ID (C-Type = 2)
- Unnumbered INTERFACE_ID (C-Type = 3)
o CHANNEL_STATUS_REQUESTClass name (14)
The CHANNEL_STATUS_REQUEST Object Class type name space should be
allocated as follows: pursuant to the policies outlined in [RFC2434],
the numbers in the range 0-111 are allocated by Standards Action,
112-119 are allocated through an Expert Review, and 120-127 are
reserved for Private Use.
- IPv4 INTERFACE_ID (C-Type = 1)
- IPv6 INTERFACE_ID (C-Type = 2)
- Unnumbered INTERFACE_ID (C-Type = 3)
o ERROR_CODE Class name (20)
The ERROR_CODE Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
private Use.
- BEGIN_VERIFY_ERROR (C-Type = 1)
- LINK_SUMMARY_ERROR (C-Type = 2)17. Acknowledgements ✨
The authors gave a huge shoutout to Andre Fredette 🫶, who made so many contributions to this document. They also thanked Ayan Banerjee, George Swallow, Adrian Farrel, Dimitri Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful comments and suggestions 💅. Finally, they thanked John Yu, Suresh Katukam, and Greg Bernstein for their helpful suggestions for the in-band control channel applicability 🦋.
18. Contributors 🌸
These are the lovely people who helped build this spec, bestie. Here's how to reach them 💌
Jonathan P. Lang
Sonos, Inc.
223 E. De La Guerra St.
Santa Barbara, CA 93101
EMail: jplang@ieee.org
Krishna Mitra
Independent Consultant
EMail: kmitra@earthlink.net
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
EMail: jdrake@calient.net
Kireeti Kompella
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Yakov Rekhter
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089
EMail: yakov@juniper.net
Lou Berger
Movaz Networks
EMail: lberger@movaz.com
Debanjan Saha
IBM Watson Research Center
EMail: dsaha@us.ibm.com
Debashis Basak
Accelight Networks
70 Abele Road, Suite 1201
Bridgeville, PA 15017-3470
EMail: dbasak@accelight.com
Hal Sandick
Shepard M.S.
2401 Dakota Street
Durham, NC 27705
EMail: sandick@nc.rr.com
Alex Zinin
Alcatel
EMail: alex.zinin@alcatel.com
Bala Rajagopalan
Intel Corp.
2111 NE 25th Ave
Hillsboro, OR 97123
EMail: bala.rajagopalan@intel.com
Sankar Ramamoorthi
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089
EMail: sankarr@juniper.netContact Address 💜
If you want to get in touch with the main author, Jonathan P. Lang, here's where to find him 📬
Jonathan P. Lang
Sonos, Inc.
829 De La Vina, Suite 220
Santa Barbara, CA 93101
EMail: jplang@ieee.orgFull Copyright Statement 🧚
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔥
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4204 2005-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms