Link Management Protocol (LMP)
updated by
- rfc-6898 — Link Management Protocol Behavior Negotiation and Configuration Modifications
Extracted elements (31)
Config messages for in-band control channels are sent to the multicast address (224.0.0.1 or ff02::1) rather than a unicast destination, enabling dynamic discovery of the far-end IP address without prior manual configuration. ConfigAck and ConfigNack are then sent back to the source IP address found in the received Config's IP header.
LMP was designed to explicitly separate the fate of control channels from data links. In GMPLS, control channels may be physically diverse from data links (separate fiber, Ethernet, IP tunnel), so the health of one does not correlate to the other, necessitating dedicated mechanisms for data link management and fault localization.
The Verify_Id scoping mechanism was designed to allow parallel link verification across different link bundles or LMP sessions. The Verify_Id is node-unique and MUST NOT overlap any currently active Verify_Id, enabling the remote node to unambiguously correlate Test messages from concurrent verification procedures.
LMP-capable devices SHOULD allow sub-channels of a component link to be locally configured as logical data links to ensure interworking between data links with different multiplexing capabilities. For example, a cross-connect with OC-192 interfaces connected through a 4:1 SONET MUX should configure each OC-48 sub-channel as a separate data link.
A LinkSummaryAck or LinkSummaryNack MUST be sent in response to every LinkSummary message. If a LinkSummaryNack includes negotiable parameters, acceptable values for those parameters MUST be included.
After a control plane restart, once a control channel is up, the LMP neighbor MUST send a LinkSummary message for each TE link across the adjacency with all N-bits set to 0 (non-negotiable). The allocated/de-allocated flag from the received LinkSummary MUST take precedence over any local value.
An upstream node receiving a ChannelStatus message MUST send a ChannelStatusAck. Upon Channel Activation Indication, the corresponding data links MUST be put into the Active state; upon Channel Deactivation Indication, they MUST be taken out of the Active state.
Control channel parameters MUST be individually negotiated for each control channel, and LMP Hello packets MUST be exchanged over each control channel to maintain LMP connectivity if lower-level failure detection mechanisms are not available.
If a BeginVerify message is received and link verification is not supported for the TE link, a BeginVerifyNack MUST be transmitted with Error Code indicating 'Link Verification Procedure not supported for this TE Link.'
Implementations MUST use exponential back-off procedures or their equivalent for retransmission of unacknowledged messages. Suggested defaults are Ri=500ms, Delta=1 (power-of-2 back-off), and retry limit Rl=3.
TE link Link_Id identifiers MUST be the same type (IPv4, IPv6, or unnumbered) at both ends. If a LinkSummary is received with mismatched types, a LinkSummaryNack MUST be sent with Error Code 'Bad TE Link Object'. Similarly, Interface_Id types MUST match at both ends.
The HelloDeadInterval MUST be greater than the HelloInterval and SHOULD be at least 3 times the HelloInterval value. If the fast keep-alive mechanism is not used, both parameters MUST be set to zero.
The Message_Id field in the MESSAGE_ID object MUST be monotonically increasing and scoped to the CC_Id for control-channel-specific messages, or to the LMP adjacency for TE-link-specific messages. No more than one MESSAGE_ID object may be included in any LMP message.
The remote node MUST send either a TestStatusSuccess or TestStatusFailure message for each data link tested. A TestStatusAck MUST be sent to confirm receipt of those messages. Unacknowledged TestStatus messages SHOULD be retransmitted until acknowledged or retry limit is reached.
To activate a control channel, a Config message MUST be transmitted to the remote node and a ConfigAck MUST be received. When both nodes initiate simultaneously, the node with the higher Node_Id wins contention; the lower-Node_Id node MUST stop transmitting Config and respond to the received Config.
TxSeqNum MUST NOT ever be 0. TxSeqNum=1 indicates the sender has just started or restarted. When TxSeqNum reaches (2^32)-1, the next sequence number used is 2, skipping 0 and 1 which have special meanings.
When bringing a control channel down administratively, a node MUST set the ControlChannelDown flag in all LMP messages sent over that control channel.
A TE link enters the Degraded state when all LMP control channels are down but the TE link still includes data links allocated to user traffic. In this state, routing and signaling SHOULD be notified so new connections are not accepted and the TE link is advertised with no unreserved resources.
An LMP control channel is a pair of mutually reachable IP interfaces identified by a 32-bit node-wide unique CC_Id. All LMP packets run over UDP with an LMP port number, except Test messages which may use in-band transport over data links.
The BeginVerify message initiates link connectivity verification, carrying the count of data links to verify, VerifyInterval, supported encoding and transport mechanisms, data rate, and optionally a wavelength identifier. The BeginVerifyAck response includes a node-unique 32-bit Verify_Id used to correlate all subsequent verification messages.
The ChannelStatus message is sent unsolicited to notify an LMP neighbor about the status of one or more data channels of a TE link. It serves fault notification (failure localization), Channel Activation Indication, and Channel Deactivation Indication.
The LinkSummary message includes a TE_LINK object followed by one or more DATA_LINK objects. It is used to aggregate data links into a TE link, exchange and correlate TE link parameters, and exchange Interface_Ids. It carries negotiable and non-negotiable objects identified by the N flag.
The LMP Hello message contains TxSeqNum (sequence number of the sent Hello) and RcvSeqNum (last Hello sequence number received from the adjacent node). This fast keep-alive mechanism allows each node to verify its peer is receiving its transmissions and detects control channel failures.
The Test message is the only LMP message transmitted over a data link (rather than a control channel). It carries the Verify_Id and the local Interface_Id, enabling data plane discovery, Interface_Id exchange, and physical connectivity verification for each data link.
Section 16 defines IANA registries for LMP including message type values, LMP object class and C-type values, sub-object types for DATA_LINK objects, error code values, and the assigned LMP UDP port number. New values require IETF Consensus or Standards Action depending on the registry.
Section 15 identifies LMP security requirements including authentication of LMP messages to prevent spoofing that could disrupt control channels or corrupt TE link state. The document describes security mechanisms such as IPsec to protect LMP messages, noting that unauthenticated LMP is vulnerable to man-in-the-middle attacks.
The Control Channel FSM defines six states: Down (initial), ConfSnd (sending Config messages), ConfRcv (waiting for Config from remote), Active (exchanging Hellos), Up (operational), and GoingDown (administrative shutdown). Transition from Active to Up requires receiving a valid Hello with expected sequence numbers; evCCDn always forces the FSM to Down.
The Data Link FSM defines five states: Down (not in service), Test (sending Test messages over the link), PasvTest (listening for Test messages), Up/Free (verified and in service, not allocated), and Up/Alloc (allocated for data traffic). Separate active-mode and passive-mode FSM descriptions cover the transmit and receive directions respectively.
The TE Link FSM defines four states: Down (no data links allocated), Init (data links allocated but not synchronized with neighbor; LinkSummary messages sent periodically), Up (operational; at least one control channel active), and Degraded (all control channels down but data links still allocated). Transitions are triggered by data channel, control channel, and LinkSummary ACK/NACK events.
Each LMP object carries an N bit in its header identifying whether it is negotiable (N=1, peers may propose alternate values) or non-negotiable (N=0, announces a specific value that must be accepted or rejected outright). Object class and C-type fields further categorize the object.
The LMP Common Header contains a ControlChannelDown flag (set in all messages when administratively shutting down a control channel) and an LMP Restart bit (set after a nodal failure where LMP control state is lost, cleared once a Hello with matching RcvSeqNum is received).