| Internet Engineering Task Force | D. Dolson |
| Internet-Draft | K. Larose |
| Intended status: Informational | Sandvine |
| Expires: January 9, 2017 | July 8, 2016 |
OAM Mechanism for SFF-SF Connectivity Verification
draft-dolson-sfc-oam-sff-sf-cv-00
This document describes a mechanism and packet format for allowing a Service Function Forwarder (SFF) to verify connectivity of an connected SFF or Service Function (SF).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
As described in Service Function Chaining (SFC) Architecture [RFC7665], 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 [I-D.ooamdt-rtgwg-demand-cc-cv] 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 [I-D.ooamdt-rtgwg-demand-cc-cv] in NSH, the packet format is that of Figure 1. The MD-type 2 is shown, since no metadata is required.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
|Ver|O|C|R|R|R|R|R|R| Length=2 | MD-type=0x2 | OAM Proto=TBA1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSH
| Service Path ID=0xffffff | SI=0xff | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
| Version Number | Global Flags | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Message Type | Reply mode | Return Code | Return S.code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM
| Sender's Handle | | Ping
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
| TLVs | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
Figure 1: OAM Ping Encapsulated within NSH
The fields are:
An NSH node receiving an echo request MUST do the following:
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 [I-D.ooamdt-rtgwg-demand-cc-cv] 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.
| [I-D.ooamdt-rtgwg-demand-cc-cv] | Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar, D., Chen, M., Yizhou, L., Mozes, D. and i. ibagdona@gmail.com, "On-demand Continuity Check (CC) and Connectivity Verification(CV) for Overlay Networks", Internet-Draft draft-ooamdt-rtgwg-demand-cc-cv-00, July 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7665] | Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015. |