MPLS Transport Profile Lock Instruct and Loopback Functions
updates
- rfc-6371 — Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
Extracted elements (22)
A transport path is kept locked while there is an in-force management Lock command regardless of whether LI messages are being received, because in loopback scenarios LI messages may not continue to be delivered on the locked path.
This document updates RFC 6371 Sections 7.1.1 and 7.1.2 because the RFC 6371 framework assumed the Lock Instruct message independently enables locking and requires a response. The mechanism defined here requires Lock commands to be sent by management to both ends of the path, so the LI message does not require a response.
While the lock function can be realized entirely using the management plane, dispatching messages to two MEPs simultaneously presents coordination challenges. The optional LI OAM message provides additional in-band coordination to achieve a tightly-windowed lock when the management plane is busy.
This document updates RFC 6371 Sections 7.1.1 and 7.1.2. The LI mechanism defined here diverges from the RFC 6371 framework by not requiring a response to the Lock Instruct message and by relying on management-plane coordination to both ends rather than independent LI-triggered locking.
After being unlocked and not having received an LI message for a multiple of 3.5 times the Refresh Timer (or having never received an LI message), the MEP unlocks the transport path and puts it back into service.
The Refresh Timer value in the LI message MUST NOT be changed for the duration of a lock. A node receiving an LI message with a changed Refresh Timer MAY ignore the new value and continue to apply the old value.
The Reserved field in the LI message MUST be set to zero on transmission and SHOULD be ignored on receipt.
When a MEP receives a Lock command from an NMS or management process, it MUST take the transport path out of service; that is, it MUST stop injecting or forwarding traffic onto the locked LSP, PW, or bidirectional Section.
When a MEP receives an errored LI message (unrecognized label binding, no return path, or unexpected Source MEP-ID), the receiving MEP MUST NOT apply a lock. A MEP receiving errored LI messages SHOULD perform local diagnostic actions such as counting the messages and MAY log them.
When a MEP receives an Unlock command from a management process, it MUST cease sending LI messages. However, if the MEP is still receiving LI messages from the remote peer, the transport path MUST remain out of service until LI messages also stop.
When rapid coordination of lock state is desired, after locking the transport path the source MEP MUST send an LI message targeting the remote MEP and MUST retransmit LI messages at the frequency indicated by the Refresh Timer value set in the message.
For loopback to operate, the transport path must be bidirectional, the loopback node must lie on both forward and return paths (possible for MEPs and MIPs on co-routed bidirectional LSPs, PWs, and MPLS Sections, but only for MEPs on associated bidirectional LSPs), and test packet TTL must be large enough for the round trip.
Loopback at an intermediate node requires management configuration to set the loopback at either the ingress or egress interface. The management plane must ensure both MEPs are locked before requesting loopback state, and the MEP must not send test data until loopback is properly configured.
The lock function enables an operator to take a transport path (LSP, PW, or bidirectional MPLS Section) out of service for administrative reasons, stopping injection or forwarding of client traffic while allowing OAM messages and test traffic to continue.
The Lock Instruct (LI) message is carried in the Generic ACH and identified by PW ACH Type 0x0026. It provides in-band coordination to complement management-plane Lock commands, allowing both ends of a transport path to be locked within a tight time window.
The loopback function sets a specific node (MEP or MIP) on a transport path into loopback mode so it returns all received data (including user data and OAM) toward the originator unmodified except for normal per-hop processing such as TTL decrement. It is an out-of-service function that requires the transport path to be locked first.
IANA assigned PW ACH Type 0x0026 for the Lock Instruct (LI) OAM message in the 'Pseudowire Associated Channel Types' registry. The TLV Follows field is No.
MPLS-TP security builds on MPLS security assumptions (traffic injection is hard); the LI protocol additionally depends on G-ACh security as defined in RFC 5586 and RFC 4385, and on the data-plane security of the associated channel discussed in RFC 5085.
The G-ACh can be used as a covert channel providing end-to-end connectivity that SHOULD NOT be policed by transit nodes, making it impossible to simply prevent traffic from being carried between consenting nodes. This is a wider problem than the scope of this document.
The G-ACh is essentially connection-oriented, so injection or modification of LI control messages requires subversion of a transit node, which is considered hard in MPLS networks and not addressable at the protocol level; management-level techniques are more appropriate countermeasures.
A transport path transitions to the Locked state when either (a) a management Lock command is received (causing the MEP to begin sending LI messages) or (b) LI messages are received from the remote MEP. It transitions back to Unlocked when management sends an Unlock command AND LI messages have not been received for 3.5× the Refresh Timer interval.
The LI message format contains a 4-bit Version field (currently 1), a 20-bit Reserved field (MUST be zero on transmission), an 8-bit Refresh Timer field (maximum seconds between successive LI messages, default 1, value 0 not permitted), followed by a variable-length MEP Source ID TLV identifying the originating MEP.