LSP-Ping and BFD encapsulation over ACH

LSP-Ping and are OAM mechanisms for MPLS LSPs. This document describes ACH encapsulation for LSP-Ping, to enable use of LSP-Ping when IP addressing is not in use. When IP addressing is in use, procedures specified in apply as is. This document also clarifies the use of BFD for MPLS LSPs using ACH encapsulation, when IP addressing may not be available and/or it may not be desirable to encapsulate BFD packets in IP.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

In certain MPLS-TP deployment scenarios IP addressing might not be available or it may be preferred to use non-IP encapsulation for LSP-Ping and BFD packets. To enable re-use of OAM techniques provided by LSP-Ping and BFD in such networks, rest of this document defines extensions to LSP-Ping and procedures for using BFD. Sections and describe a new ACH code-point for performing LSP-Ping over ACH. Section describes procedures for using BFD over ACH.

defines an ACH mechanism for MPLS LSPs. This document defines a new ACH channel type for LSP-Ping, when IP addressing is not in use, for LSP-Ping over associated bi-directional LSPs and co-routed bi-directional LSPs.

When ACH header is used, an LSP-Ping packet will look as follows:

When using LSP-Ping over the ACH header, the LSP-Ping Reply mode in the LSP-Ping echo request MUST be set to 4 (Reply via application level control channel).

defines an PW-ACH mechanism for pseudowires. The ACH channel type for LSP-Ping defined in will be re-used for pseudowires so that IP addressing is not needed when using LSP-Ping OAM over pseudowires.

When sending LSP-Ping packets using ACH, without IP encapsulation, there MAY be a need to identify the source address of the packet. This source address will be specified via the Source Address TLV, being defined in . Only 1 source address TLV MUST be present in a LSP-Ping packet. The source address MUST specify the address of the originator of the packet. If more than 1 such TLV is present in a LSP-Ping request packet, then an error of "Malformed echo request received" SHOULD be returned. If more than 1 source address TLV is present, then the packet SHOULD be dropped without further processing.

When sending LSP-Ping packets using ACH, there MAY be a need to identify the maintenance end point (MEP) and/or the maintenance intermediate point (MIP) being monitored. The MEP/MIP identifiers defined in can be carried in the ACH TLVs for identification.

describes how BFD can be used for Continuity Check for MPLS LSPs. When IP addressing is in use, the procedures described in apply as is. This section clarifies the usage of BFD in the context of MPLS-TP LSPs when it is not desirable to use IP encapsulation. When using BFD over MPLS-TP LSPs, the BFD descriminator MAY either be signaled via LSP-Ping or be statically configured. The BFD packets MUST be sent over ACH when IP encapsulation is not used. The ACH Channel type MUST be set to the value specified in . BFD packets, for both directions, MUST be sent over the MPLS-TP LSP and IP forwarding SHOULD NOT be used for the reverse path. The format of a BFD packet when using it as an OAM tool for MPLS-TP LSPs SHOULD be as follows:

specifies how BFD can be used over MPLS PWs. BFD supports continuous fault monitoring and thus meets the pro-active Continuity Check and verification requirement specified in . BFD SHOULD be run pro-actively. This function SHOULD be performed between End Points (MEPs) of PWs, LSPs and Sections. For point to multipoint Continuity Check, there is work in progress on using BFD for P2MP MPLS LSPs ( ) and this can be leveraged for MPLS-TP LSPs as well. Failure of a BFD session over a LSP can be used to trigger protection switching or other fault remedial procedures. When sending BFD packets using ACH, there MAY be a need to identify the maintenance end point (MEP) and/or the maintenance intermediate point (MIP) being monitored. The MEP/MIP identifiers defined in can be carried in the ACH TLVs for identification.

The draft does not introduce any new security considerations. Those discussed in are also applicable to this document.

A new Channel type is defined in . IANA is requested to assign a new value from the "PW Associated Channel Type" registry, as per IETF consensus policy.