OAM Mechanism for SFF-SF Connectivity Verification

As described in Service Function Chaining (SFC) Architecture , Service Function Forwarders (SFFs) are responsible for forwarding traffic to connected Service Functions (SFs). We believe there is a need for the SFFs to monitor connectivity to the SFs at the NSH layer. Rather than have the SFFs simply ping each SF's IP stack, we believe it is important to test NSH connectivity because the two protocols (IP and NSH) are often handled by different hardware or code modules. As an example, an SFF may wish to health-check multiple connected SFs prior to load-balancing NSH traffic to the SFs, having the means to automatically remove unreachable SFs from service. This document proposes an NSH OAM format allowing an SFF to request a neighboring SF to respond to an echo request via NSH encapsulation. This format can also be used for an SFF to request an neighboring SFF to respond to an echo request. Note that this connectivity checking is NOT to be confused with path verification. It is in fact a feature of this mechanism that no path forwarding needs to be configured to perform the connectivity verification. This document proposes use of the format of continuity check proposed in to be used within NSH frames for SFF-to-SF connectivity verification.

An SFF may determine connectivity to an SF by means of echo request/response. However, any two NSH nodes could verify connectivity by the following mechanism. By embedding the overlay ping packet format in NSH, the packet format is that of . The MD-type 2 is shown, since no metadata is required.

The fields are: Length: Header length in words MD-type: metadata type of 2 is used because no metadata is required. OAM Protocol: a value of TBA1 indicates the NSH header is followed by an OAM Ping message. Service Path ID: Should be set by sender to 0xffffff. Receiver should ignore it. Service Index: Should be set by sender to 255. Receiver should ignore it. Version Number: refer to Global Flags: refer to Message Type: Initiator (SFF) is to use the code for "Overlay Echo Request" and responder (SF) is to use the code for "Overlay Echo Reply" Reply Mode: code for "Reply to Sender" (requires extension) Return Code: Unused at this time. MUST be ignored by initiator and responder. Return Subcode: Unused at this time. MUST be ignored by initiator and responder. Sender's Handle: an arbitrary handle chosen by the initiator, to be echoed by the responder. This value is generally constant across requests and may be useful for identifying the initiator in a debugging situation. Sequence Number: a number chosen by the initiator, to be echoed by the responder. This value is generally incremeted by 1 between requests and may be useful for debugging packet loss counts. TLVs: The initiator may place any TLVs. The responder MUST echo back the TLVs verbatim unless TLVs are specifically defined otherwise. No OAM TLVs are required for this connectivity verification. However, (a) timestamp TLVs are expected to be useful for the sender to measure round-trip time; (b) large padding TLVs are expected to be useful for verifying MTU of a connection.

An NSH node receiving an echo request MUST do the following: Clone the NSH packet and contents verbatim Change the Message Type from "Overlay Echo Request" to "Overlay Echo Reply" Send the NSH packet back to the initiator using the transport the echo request was received on. Note that for this type of OAM packet, the NSH packet is NOT forwarded according to path ID and service index, rather MUST be returned to the immediate peer. The echo is expected to work even when SFF forwarding tables are empty or incomplete. For example, an NSH packet transported directly over Ethernet MUST be returned to the MAC address from which it was received. As another example, an NSH packet received over UDP MUST be returned to the IP address and UDP port the were the source address and ports of the request. It might not be possible to use this OAM packet if there is not an obvious way to return the packet to the sender.

Thanks to the Overlay OAM Design team and authors of for pointing us an approach in common with other overlays.

TODO: Need to request any codes, subcodes or TLVs?

To reduce any attack surface, the initiator should verify that the received echo response is a response to the echo request it sent by comparing the handle and sequence number fields.