| Internet Engineering Task Force | S. Aldrin |
| Internet-Draft | |
| Intended status: Informational | C. Pignataro, Ed. |
| Expires: September 6, 2018 | N. Kumar, Ed. |
| Cisco | |
| N. Akiya | |
| Big Switch Networks | |
| R. Krishnan | |
| A. Ghanwani | |
| Dell | |
| March 5, 2018 |
Service Function Chaining (SFC) Operation, Administration and Maintenance (OAM) Framework
draft-ietf-sfc-oam-framework-04
This document provides a reference framework for Operations, Administration and Maintenance (OAM) for Service Function Chaining (SFC).
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 RFC 2119.
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 https://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 September 6, 2018.
Copyright (c) 2018 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 (https://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.
Service Function Chaining (SFC) enables the creation of composite services that consist of an ordered set of Service Functions (SF) that are to be applied to packets and/or frames selected as a result of classification [RFC7665]. Service Function Chaining is a concept that provides for more than just the application of an ordered set of SFs to selected traffic; rather, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities. The foundations of SFC are described in the following documents:
The reader is assumed to be familiar with the material in these documents.
This document provides a reference framework for Operations, Administration and Maintenance (OAM, [RFC6291]) of SFC. Specifically, this document provides:
The focus of this document is to provide an architectural framework for SFC OAM, particularly focused on the aspect of the Operations component within OAM. Actual solutions and mechanisms are outside the scope of this document.
Multiple layers come into play for implementing the SFC. These include the service layer and the underlying layers (Network, Link etc)
o----------------------Service Layer----------------------o
+------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7|
|fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+
+------+
o------VM1------o o--VM2--o o--VM3--o
o-----------------o-------------------o---------------o Overlay network
o-----------------o-----------------------------------o Underlay network
o--------o--------o--------o--------o--------o--------o Link
Figure 1: SFC Layering Example
While Figure 1 depicts a sample example where SFs are enabled as virtual entities, the SFC architecture does not make any assumptions on how SFC data plane elements are deployed. The SFC architecture is flexible to accomodate physical or virtual entity deployment. SFC OAM adheres to this flexibility and accordingly it is applicable whether SFC data plane elements are deployed directly on physical hardware, as one or more Virtual Machines, or any combination thereof.
The SFC operates at the service layer. For the purpose of defining the OAM framework, the service layer is broken up into three distinct components.
Below figure illustrates an example where OAM for the three defined components are used within the SFC environment.
+-Classifier +-Service Function Chain OAM
| OAM |
| | ______________________________________________
| \ /\ Service Function Chain \
| \ / \ +---+ +---+ +-----+ +---+ \
| \ / \ |SF1| |SF2| |Proxy|--|SF3| \
| +------+ \/ \ +---+ +---+ +-----+ +---+ \
+----> | |...(+-> ) | | | )
|Classi| \ / +-----+ +-----+ +-----+ /
|fier | \ / | SFF1|----| SFF2|----| SFF3| /
| | \ / +--^--+ +--^--+ +-----+ /
+----|-+ \/____________|________________________________/
| |
+----------SF_OAM------+
+---+ +---+
+SF_OAM>|SF3| |SF5|
| +-^-+ +-^-+
+------|---+ | |
|Controller| +-SF_OAM+
+----------+
Service Function OAM (SF_OAM)
Figure 2: SFC OAM for Three Components
One SFC OAM requirement for the service function component is to allow an SFC-aware network device to check the availability to a specific service function, located on the same or different network devices. Service function availability is an aspect which raises an interesting question. How to determine that a service function is available?. On one end of the spectrum, one might argue that a service function is sufficiently available if the service node (physical or virtual) hosting the service function is available and is functional. On the other end of the spectrum, one might argue that the service function availability can only be concluded if the packet, after passing through the service function, was examined and verified that the packet got expected service applied.
The former approach will likely not provide sufficient confidence to the actual service function availability, i.e. a service node and a service function are two different entities. The latter approach is capable of providing an extensive verification, but comes with a cost. Some service functions make direct modifications to packets, while other service functions do not make any modifications to packets. Additionally, purpose of some service functions is to, conditionally, drop packets intentionally. In such case, packets will not be coming out from the service function. The fact is that there are many flavors of service functions available, and many more flavors of service functions will likely be introduced in future. Even a given service function may introduce a new functionality within a service function (e.g., a new signature in a firewall). The cost of this approach is that verifier functions will need to be continuously modified to "keep up" with new services coming out: lack of extendibility.
This framework document provides a RECOMMENDED architectural model where generalized approach is taken to verify that a service function is sufficiently available. More specifics on the mechanism to characterize SF-specific OAM to validate the service offering is outside the scope of this document. Those mechanism are implementation and deployment specific.
Second SFC OAM requirement for the service function component is to allow an SFC aware network device to check the loss and delay induced by a specific service function. TBD - details will be provided in a later revision.
Verifying an SFC is a complicated process as the SFC could be comprised of varying SF's. Thus, SFC requires the OAM layer to perform validation and verification of SF's within an SFP, as well as connectivity and fault isolation.
In order to perform service connectivity verification of an SFC, the OAM could be initiated from any SFC aware network devices for end-to-end paths or partial path terminating on a specific SF within the SFC. The goal of this OAM function is to ensure the SF's chained together has connectivity as it is intended to when SFC was established. Necessary return code should be defined to be sent back in the response to OAM packet, in order to qualify the verification.
When ECMP is in use at the service layer for any given SFC, there must be the ability to discover and traverse all available paths.
TBD - further details will be provided in a later revision.
Any SFC-aware network device must have the ability to perform loss and delay measurements over the service function chain as a unit (i.e. end-to-end) or to a specific segment of service function through the SFC.
A classifier maintains the classification rules that maps a flow to a specific SFC. It is vital that the classifier is correctly configured with updated classification rules and functioning accordingly. The SFC OAM must be able to validate the classification rules by assessing whether a flow is appropriately mapped to the relevant SFC. Sample OAM packets can be presented to the classifiers to assess the behavior with regards to a given classification entry.
Section 3 describes SFC OAM operations that is required on each SFC component. This section explores the same from the OAM functionality point of view, which many will be applicable to multiple SFC components.
Various SFC OAM requirements listed in Section 3, provides the need for various OAM functions at different layers. Many of the OAM functions at different layers are already defined and in existence. In order to apply such OAM functions at service layer, they have to be enhanced to operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in multiple SFCs.
Connectivity is mainly an on-demand function to verify that the connectivity exists between network elements and the availability exists to service functions. Ping is a common tool used to perform this function. OAM messages SHOULD be encapsulated with necessary SFC header and with OAM markings when testing the service function chain component. OAM messages MAY be encapsulated with necessary SFC header and with OAM markings when testing the service function component. Some of the OAM functions performed by connectivity functions are as follows:
Continuity is a model where OAM messages are sent periodically to validate or verify the reachability to a given SF or through a given SFC. This allows monitor network device to quickly detect failures like link failures, network failures, service function outages or service function chain outages. BFD is one such function which helps in detecting failures quickly. OAM functions supported by continuity check are as follows:
Tracing is an important OAM function that allows the operation to trigger an action (e.g., response generation) from every transit device (e.g., SFF, SF, SFC Proxy etc) on the tested layer. This function is typically useful to gather information from every transit devices or to isolate the failure point towards an SF or through an SFC. Some of the OAM functions supported by trace functions are:
Performance management functions involve measuring of packet loss, delay, delay variance, etc. These measurements could be measured pro-actively and on-demand.
SFC OAM framework should provide the ability to perform packet loss for an SFC. Measuring packet loss is very important function. Using on-demand function, the packet loss could be measured using statistical means. Using OAM packets, the approximation of packet loss for a given SFC could be measured.
Delay within an SFC could be measured from the time it takes for a packet to traverse the SFC from ingress SFC node to egress SFF. As the SFCs are generally unidirectional in nature, measurement of one-way delay [RFC7679] is important. In order to measure one-way delay, time synchronization must be supported by means of NTP, PTP, GPS, etc.
One-way delay variation [RFC3393] could also be measured by sending OAM packets and measuring the jitter between the packets passing through an SFC.
Some of the OAM functions supported by the performance measurement functions are:
This section identifies various OAM functions available at different levels. It also identifies various gaps, if not all, existing within the existing toolset, to perform OAM function required for SFC.
There are various OAM tool sets available to perform OAM functions within various layers. These OAM functions could validate some of the underlay and overlay networks. Tools like ping and trace are in existence to perform connectivity check and tracing intermediate hops in a network. These tools support different network types like IP, MPLS, TRILL etc. There is also an effort to extend the tool set to provide connectivity and continuity checks within overlay networks. BFD is another tool which helps in detecting data forwarding failures. The following table is not exhaustive.
+----------------+--------------+-------------+--------+------------+
| Layer | Connectivity | Continuity | Trace | Performance|
+----------------+--------------+-------------+--------+------------+
| Underlay N/w | Ping | E-OAM, BFD | Trace | IPPM, MPLS |
+----------------+--------------+-------------+--------+------------+
| Overlay N/w | Ping | BFD, NVo3 | Trace | IPPM |
+----------------+--------------+-------------+--------+------------+
| SF | None + None + None + None |
+----------------+--------------+-------------+--------+------------+
| SFC | None + None + None + None |
+----------------+--------------+-------------+--------+------------+
Table 3: OAM Tool GAP Analysis
+----------------+--------------+-------------+--------+------------+
| Layer |Configuration |Orchestration|Topology|Notification|
+----------------+--------------+-------------+--------+------------+
| Underlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog|
+----------------+--------------+-------------+--------+------------+
| Overlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog|
+----------------+--------------+-------------+--------+------------+
| SF |CLI, Netconf + CLI + None + None |
+----------------+--------------+-------------+--------+------------+
| SFC |CLI, Netconf + CLI + None + None |
+----------------+--------------+-------------+--------+------------+
Table 4: OAM Tool GAP Analysis (contd.)
As shown in Table 3, OAM functions for SFC are not standardized yet. Hence, there are no standard based tools available to verify SF and SFC.
Primary OAM functions exist for underlying layers. Tools like ping, trace, BFD, etc., exist in order to perform these OAM functions. Configuration, orchestration and manageability of SF and SFC could be performed using CLI, NETCONF, etc.
As depicted in Table 3 and 4, for configuration, manageability and orchestration, providing data and information models for SFC is very much needed. With virtualized SF and SFC, manageability of these functions has to be done programmatically.
This section describes the operational aspects of SFC OAM at the Service layer to perform the SFC OAM function defined in Section 4 and analyze the applicability of various existing OAM toolsets in the service layer.
SFC OAM function described in Section 4 performed at the service layer or overlay network layer must mark the packet as OAM packet so that relevant nodes can differentiate an OAM packet from data packets. The base header defined in Section 2.2 of [RFC8300] assigns a bit to indicate OAM packets. When NSH encapsulation is used at the service layer, the O bit must be set to differentiate the OAM packet. Any other overlay encapsulations used in future must have a way to mark the packet as OAM packet.
Upon receiving OAM packet, an SFC-aware SFs may choose to discard the packet if it does not support OAM functionality or if the local policy prevent it from processing OAM packet. When SF supports OAM functionality, it is desired to process the packet and respond back accordingly that helps with end-to-end verification. To avoid hitting any performance impact, SFC-aware SFs can rate limit the number of OAM packets processed.
Service Function Forwarder (SFF) may choose not to forward the OAM packet to an SF if the SF does not support OAM function or if the policy does not allow to forward OAM packet to an SF. SFF may choose to skip the SF, modify the header and forward to next SFC node in the chain. Although, skipping an SF might have implication on some OAM function (e.g., delay measurement may not be accurate). How SFF detects if the connected SF supports or allowed to process OAM packet is outside the scope of this document. It could be a configuration parameter instructed by the controller or can be a dynamic negotiation between SF and SFF.
If the SFF receiving the OAM packet bound to a given SFC is the last SFF in the chain, it must send a relevant response to the initiator of the OAM packet. Depending on the type of OAM solution and tool set used, the response could be a simple response (ICMP reply or BFD reply packet) or could include additional data from the received OAM packet (like stats data consolidated along the path). The proposed solution should detail it further.
Any SFC-aware node that initiates OAM packet must set the OAM marker in the overlay encapsulation.
As described in Section 4, there are different OAM functions that may require different OAM solutions. While the presence of OAM marker in the overlay header (e.g., O bit in the NSH header) indicates it as OAM packet, it is not sufficient to indicate what OAM function the packet is intended for. The Next Protocol field in NSH header may be used to indicate what OAM function is it intended to or what toolset is used.
As described in Section 5.1, there are different tool sets available to perform OAM functions at different layers. This section describes the applicability of some of the available toolsets in the service layer.
[RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6 network respectively. It explains how ICMP messages can be used to test the network reachability between different end points and perform basic network diagnostics.
ICMP could be leveraged for basic OAM functions like SF availability or SFC availability. The Initiator can generate ICMP echo request message and control the service layer encapsulation header to get the response from relevant node. For example, a classifier initiating OAM can generate ICMP echo request message, can set the TTL field in NSH header to 255 to get the response from last SFF and thereby test the SFC availability. Alternately, the initiator can set the TTL to other value to get the response from specific SFs and there by test partial SFC availability. Alternately, the initiator could send OAM packets with sequentially incrementing the TTL in NSH header to trace the SFP.
It could be observed that ICMP at its current stage may not be able to perform all required SFC OAM functions, but as explained above, it can be used for basic OAM functions.
[RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism for fast failure detection. [RFC5881] and [RFC5884] defines the applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network.
S-BFD could be leveraged to perform SF or SFC availability. An initiator could generate BFD control packet and set the "Your Discriminator" value as last SFF in the control packet. Upon receiving the control packet, last SFF will reply back with relevant DIAG code. We could also use the TTL field in the NSH header to perform partial SFC availability. For example, the initiator can set the "Your Discriminator" value to the SF that is intended to be tested and set the TTL field in NSH header in a way that it will be expired on the relevant SF. How the initiator gets the Discriminator value of the SF is outside the scope of this document.
[I-D.brockners-proof-of-transit] defines a mechanism to perform proof of transit to securely verify if a packet traversed the relevant path or chain. While the mechanism is defined inband (i.e, it will be included in data packets), it can be used to perform various SFC OAM functions as well.
In-Situ OAM could be used with O bit set and perform SF availability, SFC availability of performance measurement.
[I-D.penno-sfc-trace] defines a protocol that checks for path liveliness and trace the service hops in any SFP. Section 3 of [I-D.penno-sfc-trace] defines the SFC trace packet format while section 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF and SFF respectively.
An initiator can control the SIL in SFC trace packet to perform SF and SFC availability test.
SFC and SF OAM must provide mechanisms for:
No action is required by IANA for this document.
We would like to thank Mohamed Boucadair for his review and comments.
| [RFC0792] | Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4443] | Conta, A., Deering, S. and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006. |
| [RFC7498] | Quinn, P. and T. Nadeau, "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015. |
| [RFC7665] | Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015. |
| [RFC8300] | Quinn, P., Elzur, U. and C. Pignataro, "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018. |