Data Channel Status Confirmation Extensions for the Link Management Protocol
updated by
- rfc-6898 — Link Management Protocol Behavior Negotiation and Configuration Modifications
Extracted elements (25)
LMP was chosen as the protocol to carry data channel status confirmation because it is already used to verify data plane connectivity between adjacent LSRs, making it a natural fit for this additional function without requiring a new protocol.
The ConfirmDataChannelStatusAck message is used both when statuses match and when they do not match, simplifying the protocol by avoiding a separate 'no mismatch' acknowledgment message type.
The extensions target mismatches caused by human error, manual misconfiguration, and failure to clean up the data plane after control plane disconnection rather than broken implementations. The document explicitly states it is not intended to deal with broken implementations.
Nodes running only pre-RFC-5818 LMP cannot recognize the three new message types. Because legacy node behavior upon receipt of unknown messages is unspecified in RFC 4204, this document assumes deployments supporting this feature will consist entirely of nodes implementing these extensions. Mixed-environment deployment may become possible if LMP is extended with capability discovery.
ConfirmDataChannelStatus SHOULD be sent using LMP reliable transmission mechanisms. If the retry limit is reached without receiving an Ack or Nack, the SENDER SHOULD terminate the confirmation procedure and SHOULD raise an alert to the management plane.
If a ConfirmDataChannelStatus message has a MESSAGE_ID value less than the largest MESSAGE_ID previously received from the sender for the specified TE link, the message SHOULD be treated as out-of-order.
If the data channel status confirmation procedure is supported but the node is unable to begin the procedure, a ConfirmDataChannelStatusNack containing ERROR_CODE 'Unwilling to Confirm' MUST be sent. The originator MAY schedule retransmission after a configured time; a default of 10 minutes is suggested.
If the Length field indicates padding is required in the Data Channel Status subobject, the Length MUST indicate the length up to but not including the first byte of padding.
In the case of SONET/SDH, the Data Channel ID in the new subobject SHOULD be used to identify each timeslot of the data link, encoded as per RFC 4606.
The contents of the MESSAGE_ID_ACK objects in ConfirmDataChannelStatusAck and ConfirmDataChannelStatusNack MUST be obtained from the ConfirmDataChannelStatus message being acknowledged or rejected.
The Data Channel Status subobject MUST be part of the Data_Link Class and MUST carry the status of the TE link end in ConfirmDataChannelStatus and ConfirmDataChannelStatusAck messages.
The procedures defined in this document are designed for periodic or on-demand use; it is NOT RECOMMENDED that the procedures be used to provide a continuous and on-line monitoring process.
The SENDER's ConfirmDataChannelStatus message MUST contain one or more DATA_LINK objects, each of which MUST contain one or more Data Channel Status subobjects. The Data Channel ID MUST indicate which channel needs confirmation and MUST report the sender's channel status.
Upon receipt of a ConfirmDataChannelStatus message, the RECEIVER MUST extract the data channel statuses and SHOULD compare them with its own. If a mismatch is found, the result SHOULD be reported to the management plane. The RECEIVER SHOULD also send ConfirmDataChannelStatusAck carrying all local end statuses.
Upon receipt of a ConfirmDataChannelStatusAck message, the SENDER MUST compare the received remote data channel statuses with local statuses. If a mismatch is found, the result SHOULD be reported to the management plane.
When a node receives a ConfirmDataChannelStatus message and the data channel status confirmation procedure is not supported but the message is recognized, a ConfirmDataChannelStatusNack containing ERROR_CODE 'Channel Status Confirmation Procedure not supported' MUST be sent.
A data channel status mismatch exists when one LSR endpoint of a TE link believes the channel is assigned to carry data while the other does not. Such stranded resources cannot be detected by routing protocol TE advertisements alone, and cannot be assigned to new LSPs because they appear to be in use.
The ConfirmDataChannelStatus message is used to report the local end's data channel status to the remote end and request the remote end to return its channel statuses. It contains a Common Header, LOCAL_LINK_ID, MESSAGE_ID, and one or more DATA_LINK objects.
The ConfirmDataChannelStatusAck message is sent back to the originator of ConfirmDataChannelStatus to return the requested data channel statuses. It contains a Common Header, MESSAGE_ID_ACK, and one or more DATA_LINK objects, and is sent regardless of whether statuses match or not.
The ConfirmDataChannelStatusNack message is sent when a node receives ConfirmDataChannelStatus but cannot support or begin the procedure. It contains a Common Header, optional LOCAL_LINK_ID, MESSAGE_ID_ACK, and an ERROR_CODE. Two error codes are defined: 0x01 (procedure not supported) and 0x02 (unwilling to confirm).
A new DATA_LINK sub-object type value 9 ('Data Channel Status') is allocated in the IANA 'DATA_LINK Sub-object Class name space' embedded registry within the LMP Object Class registry.
A new ERROR_CODE class type C-Type value 4 ('ConfirmDataChannelStatusNack') is allocated in the IANA LMP Object Class registry for the ERROR_CODE object.
Three new LMP Message Type values are allocated in the IANA 'LMP Message Type' subregistry: 32 (ConfirmDataChannelStatus), 33 (ConfirmDataChannelStatusAck), and 34 (ConfirmDataChannelStatusNack).
RFC 4204 describes how LMP messages between peers can be secured; those measures apply equally to the new messages. Although the procedures do not cause network state changes, intercepted or spoofed messages could trigger bogus management plane alerts, so use of LMP security measures from RFC 4204 is RECOMMENDED. The procedures may also serve as an additional security check to verify data channels have not been illicitly modified.
The Data Channel Status subobject consists of a 1-byte Type, 1-byte Length, 2-byte Data Channel Status flags (0x0000=available/free, 0x0001=unavailable/in-use), and a variable-length Data Channel ID encoded as a label value. All subobjects must be padded to a four-byte boundary with trailing zeros; the Length field excludes padding bytes.