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:
OAM functions applicable at this component include testing the SFs from any SFC-aware network device (e.g., classifiers, controllers, and other service nodes). Testing an SF may be more expansive than just checking connectivity to the SF, such as checking if the SF is providing its intended service. Refer to Section 3.1.1 for a more detailed discussion.
OAM functions applicable at this component include (but are not limited to) testing the SFCs and the SFPs, validation of the correlation between an SFC and the actual forwarding path followed by a packet matching that SFC, i.e., the Rendered Service Path (RSP). Some of the hops of an SFC may not be visible when Hierarchical Service Function Chaining (hSFC) [RFC 8459] is in use. In such schemes, it is the responsibility of the Internal Boundary Node (IBN) to glue the connectivity between different levels for end-to-end OAM functionality.
OAM functions applicable at this component include testing the validity of the classification rules and detecting any incoherence among the rules installed when more than one classifier is used, as explained in Section 2.2 of RFC 7665.
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| /
| | \ / +--^--+ +-----+ +-----+ /
| +-^-+ +-^-+
+------|---+ | |
Service Function OAM (SF_OAM)
It is expected that multiple SFC OAM solutions will be defined, each targeting one specific component of the service layer. However, it is critical that SFC OAM solutions together provide the coverage of all three SFC OAM components: the SF component, the SFC component, and the classifier component.
One SFC OAM requirement for the SF component is to allow an SFC-aware network device to check the availability of a specific SF (instance), located on the same or different network device(s). For cases where multiple instances of an SF are used to realize a given SF for the purpose of load sharing, SF availability can be performed by checking the availability of any one of those instances, or the availability check may be targeted at a specific instance. SF availability is an aspect that raises an interesting question: How does one determine that an SF is available? At one end of the spectrum, one might argue that an SF is sufficiently available if the service node (physical or virtual) hosting the SF is available and is functional. At the other end of the spectrum, one might argue that the SF's availability can only be deduced if the packet, after passing through the SF, was examined and it was verified that the packet did indeed get the expected service.
The former approach will likely not provide sufficient confidence about the actual SF availability, i.e., a service node and an SF are two different entities. The latter approach is capable of providing an extensive verification but comes at a cost. Some SFs make direct modifications to packets, while others do not. Additionally, the purpose of some SFs may be to drop certain packets intentionally. In such cases, it is normal behavior that certain packets will not be egressing out from the SF. The OAM mechanism needs to take into account such SF specifics when assessing SF availability. Note that there are many flavors of SFs available and many more that are likely be introduced in the future. Even a given SF may introduce a new functionality (e.g., a new signature in a firewall). The cost of this approach is that the OAM mechanism for some SF will need to be continuously modified in order to "keep up" with new functionality being introduced.
The SF availability check can be performed using a generalized approach, i.e., at an adequate granularity to provide a basic SF service. The task of evaluating the true availability of an SF is a complex activity, currently having no simple, unified solution. There is currently no standard means of doing so. Any such mechanism would be far from a typical OAM function, so it is not explored as part of the analysis in Sections [4
] and [5
The second SFC OAM requirement for the SF component is to allow an SFC-aware network device to check the performance metrics, such as loss and delay induced by a specific SF for processing legitimate traffic. Performance measurement can be passive by using live traffic, an active measurement by using synthetic probe packets, or a hybrid method that uses a combination of active and passive measurement. More details about this OAM function is explained in Section 4.4
On the one hand, the performance of any specific SF can be quantified by measuring the loss and delay metrics of the traffic from the SFF to the respective SF, while on the other hand, the performance can be measured by leveraging the loss and delay metrics from the respective SFs. The latter requires SF involvement to perform the measurement, while the former does not. For cases where multiple instances of an SF are used to realize a given SF for the purpose of load sharing, SF performance can be quantified by measuring the metrics for any one instance of SF or by measuring the metrics for a specific instance.
The metrics measured to quantify the performance of the SF component are not just limited to loss and delay. Other metrics, such as throughput, also exist and the choice of metrics for performance measurement is outside the scope of this document.
An SFC could comprise varying SFs, and so the OAM layer is required to perform validation and verification of SFs within an SFP, in addition to connectivity verification and fault isolation.
In order to perform service connectivity verification of an SFC/SFP, the OAM functions could be initiated from any SFC-aware network device of an SFC-enabled domain for end-to-end paths, or partial paths terminating on a specific SF, within the SFC/SFP. The goal of this OAM function is to ensure the SFs chained together have connectivity, as was intended at the time when the SFC was established. The necessary return codes should be defined for sending back in the response to the OAM packet, in order to complete 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.
A detailed explanation of the mechanism is outside the scope of this document and is expected to be included in the actual solution document.
Any SFC-aware network device should have the ability to make performance measurements over the entire SFC (i.e., end-to-end) or on a specific segment of SFs within the SFC.
A classifier maintains the classification rules that map a flow to a specific SFC. It is vital that the classifier is correctly configured with updated classification rules and is functioning as expected. The SFC OAM must be able to validate the classification rules by assessing whether a flow is appropriately mapped to the relevant SFC and detect any misclassification. Sample OAM packets can be presented to the classifiers to assess the behavior with regard to a given classification entry.
The classifier availability check may be performed to check the availability of the classifier to apply the rules and classify the traffic flows. Any SFC-aware network device should have the ability to perform availability checking of the classifier component for each SFC.
Any SFC-aware network device should have the ability to perform performance measurement of the classifier component for each SFC. The performance can be quantified by measuring the performance metrics of the traffic from the classifier for each SFC/SFP.
The underlay network provides connectivity between the SFC components, so the availability or the performance of the underlay network directly impacts the SFC OAM.
Any SFC-aware network device may have the ability to perform an availability check or performance measurement of the underlay network using any existing OAM functions listed in Section 5.1.
The overlay network provides connectivity for the service plane between the SFC components and is mostly transparent to the SFC data-plane elements.
Any SFC-aware network device may have the ability to perform an availability check or performance measurement of the overlay network using any existing OAM functions listed in Section 5.1