rfc8924.original   rfc8924.txt 
Internet Engineering Task Force S. Aldrin Internet Engineering Task Force (IETF) S. Aldrin
Internet-Draft Google Request for Comments: 8924 Google
Intended status: Informational C. Pignataro, Ed. Category: Informational C. Pignataro, Ed.
Expires: November 26, 2020 N. Kumar, Ed. ISSN: 2070-1721 N. Kumar, Ed.
Cisco Cisco
R. Krishnan R. Krishnan
VMware VMware
A. Ghanwani A. Ghanwani
Dell Dell
May 25, 2020 September 2020
Service Function Chaining (SFC) Service Function Chaining (SFC) Operations, Administration, and
Operations, Administration and Maintenance (OAM) Framework Maintenance (OAM) Framework
draft-ietf-sfc-oam-framework-15
Abstract Abstract
This document provides a reference framework for Operations, This document provides a reference framework for Operations,
Administration and Maintenance (OAM) for Service Function Chaining Administration, and Maintenance (OAM) for Service Function Chaining
(SFC). (SFC).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on November 26, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8924.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 4 1.1. Document Scope
1.2. Acronyms and Terminology . . . . . . . . . . . . . . . . 4 1.2. Acronyms and Terminology
1.2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Acronyms
1.2.2. Terminology . . . . . . . . . . . . . . . . . . . . . 5 1.2.2. Terminology
2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . 5 2. SFC Layering Model
3. SFC OAM Components . . . . . . . . . . . . . . . . . . . . . 6 3. SFC OAM Components
3.1. The SF Component . . . . . . . . . . . . . . . . . . . . 8 3.1. The SF Component
3.1.1. SF Availability . . . . . . . . . . . . . . . . . . . 8 3.1.1. SF Availability
3.1.2. SF Performance Measurement . . . . . . . . . . . . . 9 3.1.2. SF Performance Measurement
3.2. The SFC Component . . . . . . . . . . . . . . . . . . . . 9 3.2. The SFC Component
3.2.1. SFC Availability . . . . . . . . . . . . . . . . . . 9 3.2.1. SFC Availability
3.2.2. SFC Performance Measurement . . . . . . . . . . . . . 10 3.2.2. SFC Performance Measurement
3.3. Classifier Component . . . . . . . . . . . . . . . . . . 10 3.3. Classifier Component
3.4. Underlay Network . . . . . . . . . . . . . . . . . . . . 10 3.4. Underlay Network
3.5. Overlay Network . . . . . . . . . . . . . . . . . . . . . 10 3.5. Overlay Network
4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 11 4. SFC OAM Functions
4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 11 4.1. Connectivity Functions
4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 11 4.2. Continuity Functions
4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 12 4.3. Trace Functions
4.4. Performance Measurement Functions . . . . . . . . . . . . 12 4.4. Performance Measurement Functions
5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Gap Analysis
5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 13 5.1. Existing OAM Functions
5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 14 5.2. Missing OAM Functions
5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 14 5.3. Required OAM Functions
6. Operational Aspects of SFC OAM at the Service Layer . . . . . 14 6. Operational Aspects of SFC OAM at the Service Layer
6.1. SFC OAM Packet Marker . . . . . . . . . . . . . . . . . . 14 6.1. SFC OAM Packet Marker
6.2. OAM Packet Processing and Forwarding Semantic . . . . . . 15 6.2. OAM Packet Processing and Forwarding Semantic
6.3. OAM Function Types . . . . . . . . . . . . . . . . . . . 16 6.3. OAM Function Types
7. Candidate SFC OAM Tools . . . . . . . . . . . . . . . . . . . 16 7. Candidate SFC OAM Tools
7.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. ICMP
7.2. BFD/Seamless-BFD . . . . . . . . . . . . . . . . . . . . 16 7.2. BFD / Seamless BFD
7.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. In Situ OAM
7.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . . . 17 7.4. SFC Traceroute
8. Manageability Considerations . . . . . . . . . . . . . . . . 18 8. Manageability Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Informative References
12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20 Acknowledgements
13. Informative References . . . . . . . . . . . . . . . . . . . 20 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses
1. Introduction 1. Introduction
Service Function Chaining (SFC) enables the creation of composite Service Function Chaining (SFC) enables the creation of composite
services that consist of an ordered set of Service Functions (SF) services that consist of an ordered set of Service Functions (SFs)
that are to be applied to any traffic selected as a result of that are to be applied to any traffic selected as a result of
classification [RFC7665]. SFC is a concept that provides for more classification [RFC7665]. SFC is a concept that provides for more
than just the application of an ordered set of SFs to selected than just the application of an ordered set of SFs to selected
traffic; rather, it describes a method for deploying SFs in a way traffic; rather, it describes a method for deploying SFs in a way
that enables dynamic ordering and topological independence of those that enables dynamic ordering and topological independence of those
SFs as well as the exchange of metadata between participating SFs as well as the exchange of metadata between participating
entities. The foundations of SFC are described in the following entities. The foundations of SFC are described in the following
documents: documents:
o SFC Problem Statement [RFC7498] * SFC Problem Statement [RFC7498]
o SFC Architecture [RFC7665] * SFC Architecture [RFC7665]
The reader is assumed to be familiar with the material in [RFC7665]. The reader is assumed to be familiar with the material in [RFC7665].
This document provides a reference framework for Operations, This document provides a reference framework for Operations,
Administration and Maintenance (OAM, [RFC6291]) of SFC. Administration, and Maintenance (OAM) [RFC6291] of SFC.
Specifically, this document provides: Specifically, this document provides:
o In Section 2, an SFC layering model; * an SFC layering model (Section 2),
o In Section 3, aspects monitored by SFC OAM; * aspects monitored by SFC OAM (Section 3),
o In Section 4, functional requirements for SFC OAM; * functional requirements for SFC OAM (Section 4),
o In Section 5, a gap analysis for SFC OAM. * a gap analysis for SFC OAM (Section 5),
o In Section 6, operational aspects of SFC OAM at the service layer. * operational aspects of SFC OAM at the service layer (Section 6),
o In Section 7, applicability of various OAM tools. * applicability of various OAM tools (Section 7), and
o In Section 8, manageability considerations for SF and SFC. * manageability considerations for SF and SFC (Section 8).
SFC OAM solution documents should refer to this document to indicate SFC OAM solution documents should refer to this document to indicate
the SFC OAM component and the functionality they target. the SFC OAM component and the functionality they target.
OAM controllers are SFC-aware network devices that are capable of OAM controllers are SFC-aware network devices that are capable of
generating OAM packets. They should be within the same generating OAM packets. They should be within the same
administrative domain as the target SFC enabled domain. administrative domain as the target SFC-enabled domain.
1.1. Document Scope 1.1. Document Scope
The focus of this document is to provide an architectural framework The focus of this document is to provide an architectural framework
for SFC OAM, particularly focused on the aspect of the Operations for SFC OAM, particularly focused on the aspect of the Operations
component within OAM. Actual solutions and mechanisms are outside component within OAM. Actual solutions and mechanisms are outside
the scope of this document. the scope of this document.
1.2. Acronyms and Terminology 1.2. Acronyms and Terminology
1.2.1. Acronyms 1.2.1. Acronyms
SFC: Service Function Chain SFC: Service Function Chain
SFF: Service Function Forwarder SFF: Service Function Forwarder
SF: Service Function SF: Service Function
SFP: Service Function Path SFP: Service Function Path
RSP: Rendered Service Path RSP: Rendered Service Path
NSH: Network Service Header NSH: Network Service Header
VM: Virtual Machines VM: Virtual Machine
OAM: Operations, Administration and Maintenance OAM: Operations, Administration and Maintenance
IPPM: IP Performance Measurement IPPM: IP Performance Metrics
BFD: Bidirectional Forwarding Detection BFD: Bidirectional Forwarding Detection
NVO3: Network Virtualization over Layer3 NVO3: Network Virtualization over Layer 3
SNMP: Simple Network Management Protocol SNMP: Simple Network Management Protocol
NETCONF: Network Configuration Protocol NETCONF: Network Configuration Protocol
E-OAM: Ethernet OAM E-OAM: Ethernet OAM
MPLS_PM: MPLS Performance Measurement MPLS_PM: MPLS Performance Measurement
POS: Packet over SONET POS: Packet over SONET
DWDM: Dense Wavelength Division Multiplexing DWDM: Dense Wavelength Division Multiplexing
hSFC: Hierarchical Service Function Chaining hSFC: Hierarchical Service Function Chaining
IBN: Internal Boundary Node IBN: Internal Boundary Node
MPLS: Multiprotocol Label Switching
TRILL: Transparent Interconnection of Lots of Links MPLS: Multiprotocol Label Switching
CLI: Command Line Interface TRILL: Transparent Interconnection of Lots of Links
CLI: Command-Line Interface
1.2.2. Terminology 1.2.2. Terminology
This document uses the terminologies defined in [RFC7665], [RFC8300], This document uses the terminology defined in [RFC7665] and
and so the readers are expected to be familiar with the [RFC8300], and readers are expected to be familiar with it.
terminologies.
2. SFC Layering Model 2. SFC Layering Model
Multiple layers come into play for implementing the SFC. These Multiple layers come into play for implementing the SFC. These
include the service layer and the underlying layers (Network Layer, include the service layer and the underlying layers (network layer,
Link Layer, etc.). link layer, etc.).
o The service layer, which consists of SFC data plane elements that * The service layer consists of SFC data-plane elements that include
includes classifiers, Service Functions (SF), Service Function classifiers, Service Functions (SFs), Service Function Forwarders
Forwarders (SFF), and SFC Proxies. This layer uses the overlay (SFF), and SFC Proxies. This layer uses the overlay network layer
network layer for ensuring connectivity between SFC data plane for ensuring connectivity between SFC data-plane elements.
elements.
o The overlay network layer, which leverages various overlay network * The overlay network layer leverages various overlay network
technologies (e.g., VxLAN)interconnecting SFC data plane elements technologies (e.g., Virtual eXtensible Local Area Network (VXLAN))
and allows establishing Service Function Paths (SFPs). This layer for interconnecting SFC data-plane elements and allows
is mostly transparent to the SFC data plane elements as not all establishing Service Function Paths (SFPs). This layer is mostly
the data plane elements process the overlay header. transparent to the SFC data-plane elements, as not all the data-
plane elements process the overlay header.
o The underlay network layer, which is dictated by the networking * The underlay network layer is dictated by the networking
technology deployed within a network (e.g., IP, MPLS) technology deployed within a network (e.g., IP, MPLS).
o The link layer, which is tightly coupled with the physical * The link layer is tightly coupled with the physical technology
technology used. Ethernet is one such choice for this layer, but used. Ethernet is one such choice for this layer, but other
other alternatives are deployed (e.g. POS, DWDM). In a virtual alternatives may be deployed (e.g., POS and DWDM). In a virtual
environment, virtualized I/O technologies such as SR-IOV or environment, virtualized I/O technologies, such as Single Root I/O
similar are also applicable for this layer. The same or distinct Virtualization (SR-IOV) or similar, are also applicable for this
link layer technologies may be used in each leg shown in Figure 1. layer. The same or distinct link layer technologies may be used
in each leg shown in Figure 1.
o----------------------Service Layer----------------------o o----------------------Service Layer----------------------o
+------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7|
|fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+
+------+ +------+
<------VM1------> <--VM2--> <--VM3--> <------VM1------> <--VM2--> <--VM3-->
^-----------------^-------------------^---------------^ Overlay ^-----------------^-------------------^---------------^ Overlay
Network Network
o-----------------o-------------------o---------------o Underlay o-----------------o-------------------o---------------o Underlay
Network Network
o--------o--------o--------o----------o-------o-------o Link o--------o--------o--------o----------o-------o-------o Link
Figure 1: SFC Layering Example Figure 1: SFC Layering Example
In Figure 1, the service layer elements such as classifier and SF are In Figure 1, the service-layer elements, such as classifier and SF,
depicted as virtual entities that are interconnected using an overlay are depicted as virtual entities that are interconnected using an
network. The underlay network may comprise multiple intermediate overlay network. The underlay network may comprise multiple
nodes not shown in the figure that provide underlay connectivity intermediate nodes not shown in the figure that provide underlay
between the service layer elements. connectivity between the service-layer elements.
While Figure 1 depicts an example where SFs are enabled as virtual While Figure 1 depicts an example where SFs are enabled as virtual
entities, the SFC architecture does not make any assumptions on how entities, the SFC architecture does not make any assumptions on how
the SFC data plane elements are deployed. The SFC architecture is the SFC data-plane elements are deployed. The SFC architecture is
flexible and accommodates physical or virtual entity deployment. SFC flexible and accommodates physical or virtual entity deployment. SFC
OAM accounts for this flexibility and accordingly it is applicable OAM accounts for this flexibility, and accordingly it is applicable
whether SFC data plane elements are deployed directly on physical whether SFC data-plane elements are deployed directly on physical
hardware, as one or more Virtual entities, or any combination hardware, as one or more virtual entities, or any combination
thereof. thereof.
3. SFC OAM Components 3. SFC OAM Components
The SFC operates at the service layer. For the purpose of defining The SFC operates at the service layer. For the purpose of defining
the OAM framework, the service layer is broken up into three distinct the OAM framework, the service layer is broken up into three distinct
components: components:
1. SF component: OAM functions applicable at this component include SF component:
testing the SFs from any SFC-aware network device (e.g., OAM functions applicable at this component include testing the SFs
classifiers, controllers, other service nodes). Testing an SF from any SFC-aware network device (e.g., classifiers, controllers,
may be more expansive than just checking connectivity to the SF and other service nodes). Testing an SF may be more expansive
such as checking if the SF is providing its intended service. than just checking connectivity to the SF, such as checking if the
Refer to Section 3.1.1 for a more detailed discussion. SF is providing its intended service. Refer to Section 3.1.1 for
a more detailed discussion.
2. SFC component: OAM functions applicable at this component include SFC component:
(but are not limited to) testing the service function chains and OAM functions applicable at this component include (but are not
the SFPs, validation of the correlation between an SFC and the limited to) testing the SFCs and the SFPs, validation of the
actual forwarding path followed by a packet matching that SFC, correlation between an SFC and the actual forwarding path followed
i.e. the Rendered Service Path (RSP). Some of the hops of an SFC by a packet matching that SFC, i.e., the Rendered Service Path
may not be visible when Hierarchical Service Function Chaining (RSP). Some of the hops of an SFC may not be visible when
(hSFC) [RFC8459] is in use. In such schemes, it is the Hierarchical Service Function Chaining (hSFC) [RFC8459] is in use.
responsibility of the Internal Boundary Node (IBN) to glue the In such schemes, it is the responsibility of the Internal Boundary
connectivity between different levels for end-to-end OAM Node (IBN) to glue the connectivity between different levels for
functionality. end-to-end OAM functionality.
3. Classifier component: OAM functions applicable at this component classifier component:
include testing the validity of the classification rules and OAM functions applicable at this component include testing the
detecting any incoherence among the rules installed when more validity of the classification rules and detecting any incoherence
than one classifier is used as explained in Section 2.2 of among the rules installed when more than one classifier is used,
[RFC7665] . as explained in Section 2.2 of [RFC7665].
Figure 2 illustrates an example where OAM for the three defined Figure 2 illustrates an example where OAM for the three defined
components are used within the SFC environment. components are used within the SFC environment.
+-Classifier +-Service Function Chain OAM +-Classifier +-Service Function Chain OAM
| OAM | | OAM |
| | ___________________________________________ | | ___________________________________________
| \ /\ Service Function Chain \ | \ /\ Service Function Chain \
| \ / \ +---+ +---+ +-----+ +---+ \ | \ / \ +---+ +---+ +-----+ +---+ \
| \ / \ |SF1| |SF2| |Proxy|--|SF3| \ | \ / \ |SF1| |SF2| |Proxy|--|SF3| \
| +------+ \/ \ +---+ +---+ +-----+ +---+ \ | +------+ \/ \ +---+ +---+ +-----+ +---+ \
+----> | |....(+-> ) | | | ) +----> | |...(+-> ) | | | )
|Classi| \ / +-----+ +-----+ +-----+ / |Classi| \ / +-----+ +-----+ +-----+ /
|fier | \ / | SFF1|----| SFF2|----| SFF3| / |fier | \ / | SFF1|----| SFF2|----| SFF3| /
| | \ / +--^--+ +-----+ +-----+ / | | \ / +--^--+ +-----+ +-----+ /
+----|-+ \/_________|________________________________/ +----|-+ \/_________|________________________________/
| | | |
+-------SF_OAM-------+ +-------SF_OAM-------+
+---+ +---+ +---+ +---+
+SF_OAM>|SF3| |SF5| +SF_OAM>|SF3| |SF5|
| +-^-+ +-^-+ | +-^-+ +-^-+
+------|---+ | | +------|---+ | |
|Controller| +-SF_OAM+ |Controller| +-SF_OAM+
+----------+ +----------+
Service Function OAM (SF_OAM) Service Function OAM (SF_OAM)
Figure 2: SFC OAM Components Figure 2: SFC OAM Components
It is expected that multiple SFC OAM solutions will be defined, each It is expected that multiple SFC OAM solutions will be defined, each
targeting one specific component of the service layer. However, it targeting one specific component of the service layer. However, it
is critical that SFC OAM solutions together provide the coverage of is critical that SFC OAM solutions together provide the coverage of
all three SFC OAM components: the SF component, the SFC component, all three SFC OAM components: the SF component, the SFC component,
and the classifier component. and the classifier component.
3.1. The SF Component 3.1. The SF Component
3.1.1. SF Availability 3.1.1. SF Availability
One SFC OAM requirement for the SF component is to allow an SFC-aware 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), network device to check the availability of a specific SF (instance),
located on the same or different network device(s). For cases where 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 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 purpose of load sharing, SF availability can be performed by checking
the availability of any one of those instances, or the availability the availability of any one of those instances, or the availability
check may be targeted at a specific instance. SF availability is an check may be targeted at a specific instance. SF availability is an
aspect that raises an interesting question: How does one determine aspect that raises an interesting question: How does one determine
that a service function is available? On one end of the spectrum, that an SF is available? At one end of the spectrum, one might argue
one might argue that an SF is sufficiently available if the service that an SF is sufficiently available if the service node (physical or
node (physical or virtual) hosting the SF is available and is virtual) hosting the SF is available and is functional. At the other
functional. On the other end of the spectrum, one might argue that end of the spectrum, one might argue that the SF's availability can
the SF's availability can only be concluded if the packet, after only be deduced if the packet, after passing through the SF, was
passing through the SF, was examined and it was verified that the examined and it was verified that the packet did indeed get the
packet did indeed get the expected service. expected service.
The former approach will likely not provide sufficient confidence to The former approach will likely not provide sufficient confidence
the actual SF availability, i.e. a service node and an SF are two about the actual SF availability, i.e., a service node and an SF are
different entities. The latter approach is capable of providing an two different entities. The latter approach is capable of providing
extensive verification, but comes at a cost. Some SFs make direct an extensive verification but comes at a cost. Some SFs make direct
modifications to packets, while others do not. Additionally, the modifications to packets, while others do not. Additionally, the
purpose of some SFs may be to, conditionally, drop packets purpose of some SFs may be to drop certain packets intentionally. In
intentionally. In such cases, it is normal behavior that certain such cases, it is normal behavior that certain packets will not be
packets will not be egressing out from the service function. The OAM egressing out from the SF. The OAM mechanism needs to take into
mechanism needs to take into account such SF specifics when assessing account such SF specifics when assessing SF availability. Note that
SF availability. Note that there are many flavors of SFs available, there are many flavors of SFs available and many more that are likely
and many more that are likely be introduced in future. Even a given be introduced in the future. Even a given SF may introduce a new
SF may introduce a new functionality (e.g., a new signature in a functionality (e.g., a new signature in a firewall). The cost of
firewall). The cost of this approach is that the OAM mechanism for this approach is that the OAM mechanism for some SF will need to be
some SF will need to be continuously modified in order to "keep up" continuously modified in order to "keep up" with new functionality
with new functionality being introduced: lack of extensibility. being introduced.
The SF availability check can be performed using a generalized The SF availability check can be performed using a generalized
approach (i.e., an adequate granularity to provide a basic SF approach, i.e., at an adequate granularity to provide a basic SF
service). The task of evaluating the true availability of a Service service. The task of evaluating the true availability of an SF is a
Function is a complex activity, currently having no simple, unified complex activity, currently having no simple, unified solution.
solution. There is currently no standard means of doing so. Any There is currently no standard means of doing so. Any such mechanism
such mechanism would be far from a typical OAM function, so it is not would be far from a typical OAM function, so it is not explored as
explored as part of the analysis in Sections 4 and 5. part of the analysis in Sections 4 and 5.
3.1.2. SF Performance Measurement 3.1.2. SF Performance Measurement
The second SFC OAM requirement for the SF component is to allow an The second SFC OAM requirement for the SF component is to allow an
SFC-aware network device to check the performance metrics such as SFC-aware network device to check the performance metrics, such as
loss and delay induced by a specific SF for processing legitimate loss and delay induced by a specific SF for processing legitimate
traffic. The performance can be a passive measurement by using live traffic. Performance measurement can be passive by using live
traffic, an active measurement by using synthetic probe packets or traffic, an active measurement by using synthetic probe packets, or a
can be a hybrid method that use a combination of active and passive hybrid method that uses a combination of active and passive
measurement. More details about this OAM function is explained in measurement. More details about this OAM function is explained in
Section 4.4. Section 4.4.
On the one hand, the performance of any specific SF can be quantified On the one hand, the performance of any specific SF can be quantified
by measuring the loss and delay metrics of the traffic from SFF to by measuring the loss and delay metrics of the traffic from the SFF
the respective SF, while on the other hand, the performance can be to the respective SF, while on the other hand, the performance can be
measured by leveraging the loss and delay metrics from the respective measured by leveraging the loss and delay metrics from the respective
SFs. The latter requires SF involvement to perform the measurement SFs. The latter requires SF involvement to perform the measurement,
while the former does not. For cases where multiple instances of an 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 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 performance can be quantified by measuring the metrics for any one
instance of SF or by measuring the metrics for a specific instance. instance of SF or by measuring the metrics for a specific instance.
The metrics measured to quantify the performance of the SF component The metrics measured to quantify the performance of the SF component
are not just limited to loss and delay. Other metrics such as are not just limited to loss and delay. Other metrics, such as
throughput also exist and the choice of metrics for performance throughput, also exist and the choice of metrics for performance
measurement is outside the scope of this document. measurement is outside the scope of this document.
3.2. The SFC Component 3.2. The SFC Component
3.2.1. SFC Availability 3.2.1. SFC Availability
An SFC could comprise varying SFs and so the OAM layer is required to An SFC could comprise varying SFs, and so the OAM layer is required
perform validation and verification of SFs within an SFP, in addition to perform validation and verification of SFs within an SFP, in
to connectivity verification and fault isolation. addition to connectivity verification and fault isolation.
In order to perform service connectivity verification of an SFC/SFP, In order to perform service connectivity verification of an SFC/SFP,
the OAM functions could be initiated from any SFC-aware network the OAM functions could be initiated from any SFC-aware network
device of an SFC-enabled domain for end-to-end paths, or partial 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 paths terminating on a specific SF, within the SFC/SFP. The goal of
this OAM function is to ensure the SFs chained together have this OAM function is to ensure the SFs chained together have
connectivity as was intended at the time when the SFC was connectivity, as was intended at the time when the SFC was
established. The necessary return codes should be defined for established. The necessary return codes should be defined for
sending back in the response to the OAM packet, in order to complete sending back in the response to the OAM packet, in order to complete
the verification. the verification.
When ECMP is in use at the service layer for any given SFC, there 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. must be the ability to discover and traverse all available paths.
A detailed explanation of the mechanism is outside the scope of this A detailed explanation of the mechanism is outside the scope of this
document and is expected to be included in the actual solution document and is expected to be included in the actual solution
document. document.
3.2.2. SFC Performance Measurement 3.2.2. SFC Performance Measurement
Any SFC-aware network device should have the ability to make Any SFC-aware network device should have the ability to make
performance measurements over the entire SFC (i.e., end-to-end) or to performance measurements over the entire SFC (i.e., end-to-end) or on
a specific segment of SFs within the SFC. a specific segment of SFs within the SFC.
3.3. Classifier Component 3.3. Classifier Component
A classifier maintains the classification rules that map a flow to a A classifier maintains the classification rules that map a flow to a
specific SFC. It is vital that the classifier is correctly specific SFC. It is vital that the classifier is correctly
configured with updated classification rules and is functioning as configured with updated classification rules and is functioning as
expected. The SFC OAM must be able to validate the classification expected. The SFC OAM must be able to validate the classification
rules by assessing whether a flow is appropriately mapped to the rules by assessing whether a flow is appropriately mapped to the
relevant SFC and detect any misclassification. Sample OAM packets relevant SFC and detect any misclassification. Sample OAM packets
skipping to change at page 10, line 39 skipping to change at line 452
to perform availability checking of the classifier component for each to perform availability checking of the classifier component for each
SFC. SFC.
Any SFC-aware network device should have the ability to perform Any SFC-aware network device should have the ability to perform
performance measurement of the classifier component for each SFC. performance measurement of the classifier component for each SFC.
The performance can be quantified by measuring the performance The performance can be quantified by measuring the performance
metrics of the traffic from the classifier for each SFC/SFP. metrics of the traffic from the classifier for each SFC/SFP.
3.4. Underlay Network 3.4. Underlay Network
The underlay network provides connectivity between the SFC components The underlay network provides connectivity between the SFC
so the availability or the performance of the underlay network components, so the availability or the performance of the underlay
directly impacts the SFC OAM. network directly impacts the SFC OAM.
Any SFC-aware network device may have the ability to perform Any SFC-aware network device may have the ability to perform an
availability check or performance measurement of the underlay network availability check or performance measurement of the underlay network
using any existing OAM functions listed in Section 5.1. using any existing OAM functions listed in Section 5.1.
3.5. Overlay Network 3.5. Overlay Network
The overlay network provides connectivity for service plane between The overlay network provides connectivity for the service plane
the SFC components and is mostly transparent to the SFC data plane between the SFC components and is mostly transparent to the SFC data-
elements. plane elements.
Any SFC-aware network device may have the ability to perform Any SFC-aware network device may have the ability to perform an
availability check or performance measurement of the overlay network availability check or performance measurement of the overlay network
using any existing OAM functions listed in Section 5.1. using any existing OAM functions listed in Section 5.1.
4. SFC OAM Functions 4. SFC OAM Functions
Section 3 described SFC OAM components and the associated OAM Section 3 described SFC OAM components and the associated OAM
operations on each of them. This section explores SFC OAM functions operations on each of them. This section explores SFC OAM functions
that are applicable for more than one SFC component. that are applicable for more than one SFC component.
The various SFC OAM requirements listed in Section 3 highlighted the The various SFC OAM requirements listed in Section 3 highlight the
need for various OAM functions at the service layer. As listed in need for various OAM functions at the service layer. As listed in
Section 5.1, various OAM functions are in existence that are defined Section 5.1, various OAM functions are in existence that are defined
to perform OAM functionality at different layers. In order to apply to perform OAM functionality at different layers. In order to apply
such OAM functions at the service layer, they need to be enhanced to such OAM functions at the service layer, they need to be enhanced to
operate a single SF/SFF to multiple SFs/SFFs spanning across one or operate on a single SF/SFF or multiple SFs/SFFs spanning across one
more SFCs. or more SFCs.
4.1. Connectivity Functions 4.1. Connectivity Functions
Connectivity is mainly an on-demand function to verify that the Connectivity is mainly an on-demand function to verify that
connectivity exists between certain network elements and that the SFs connectivity exists between certain network elements and that the SFs
are available. For example, LSP Ping [RFC8029] is a common tool used are available. For example, Label Switched Path (LSP) Ping [RFC8029]
to perform this function for an MPLS network. Some of the OAM is a common tool used to perform this function for an MPLS network.
functions performed by connectivity functions are as follows: Some of the OAM functions performed by connectivity functions are as
follows:
o Verify the Path MTU from a source to the destination SF or through * Verify the Path MTU from a source to the destination SF or through
the SFC. This requires the ability for the OAM packet to be of the SFC. This requires the ability for the OAM packet to be of
variable length. variable length.
o Detect any packet re-ordering and corruption. * Detect any packet reordering and corruption.
o Verify that an SFC or SF is applying the expected policy. * Verify that an SFC or SF is applying the expected policy.
o Verification and validation of forwarding paths. * Verify and validate forwarding paths.
o Proactively test alternate or protected paths to ensure * Proactively test alternate or protected paths to ensure
reliability of network configurations. reliability of network configurations.
4.2. Continuity Functions 4.2. Continuity Functions
Continuity is a model where OAM messages are sent periodically to Continuity is a model where OAM messages are sent periodically to
validate or verify the reachability of a given SF within an SFC or validate or verify the reachability of a given SF within an SFC or
for the entire SFC. This allows a monitoring network device (such as for the entire SFC. This allows a monitoring network device (such as
the classifier or controller) to quickly detect failures such as link the classifier or controller) to quickly detect failures, such as
failures, network element failures, SF outages, or SFC outages. BFD link failures, network element failures, SF outages, or SFC outages.
[RFC5880] is one such function which helps in detecting failures BFD [RFC5880] is one such protocol that helps in detecting failures
quickly. OAM functions supported by continuity functions are as quickly. OAM functions supported by continuity functions are as
follows: follows:
o Ability to provision a continuity check to a given SF within an * Provision a continuity check to a given SF within an SFC or for
SFC or for the entire SFC. the entire SFC.
o Proactively test alternate or protected paths to ensure * Proactively test alternate or protected paths to ensure
reliability of network configurations. reliability of network configurations.
o Notifying other OAM functions or applications of the detected * Notifying other OAM functions or applications of the detected
failures so they can take appropriate action. failures so they can take appropriate action.
4.3. Trace Functions 4.3. Trace Functions
Tracing is an OAM function that allows the operation to trigger an Tracing is an OAM function that allows the operation to trigger an
action (e.g. response generation) from every transit device (e.g. action (e.g., response generation) from every transit device (e.g.,
SFF, SF, SFC Proxy) on the tested layer. This function is typically SFF, SF, and SFC Proxy) on the tested layer. This function is
useful for gathering information from every transit device or for typically useful for gathering information from every transit device
isolating the failure point to a specific SF within an SFC or for an or for isolating the failure point to a specific SF within an SFC or
entire SFC. Some of the OAM functions supported by trace functions for an entire SFC. Some of the OAM functions supported by trace
are: functions are:
o Ability to trigger an action from every transit device at the SFC * the ability to trigger an action from every transit device at the
layer, using TTL or other means. SFC layer, using TTL or other means,
o Ability to trigger every transit device at the SFC layer to * the ability to trigger every transit device at the SFC layer to
generate a response with OAM code(s), using TTL or other means. generate a response with OAM code(s), using TTL or other means,
o Ability to discover and traverse ECMP paths within an SFC. * the ability to discover and traverse ECMP paths within an SFC, and
o Ability to skip SFs that do not support OAM while tracing SFs in * the ability to skip SFs that do not support OAM while tracing SFs
an SFC. in an SFC.
4.4. Performance Measurement Functions 4.4. Performance Measurement Functions
Performance measurement functions involve measuring of packet loss, Performance measurement functions involve measuring of packet loss,
delay, delay variance, etc. These performance metrics may be delay, delay variance, etc. These performance metrics may be
measured pro-actively or on-demand. measured proactively or on demand.
SFC OAM should provide the ability to measure packet loss for an SFC. SFC OAM should provide the ability to measure packet loss for an SFC.
On-demand measurement can be used to estimate packet loss using On-demand measurement can be used to estimate packet loss using
statistical methods. To ensure accurate estimations, one needs to statistical methods. To ensure accurate estimations, one needs to
ensure that OAM packets are treated the same and also share the same ensure that OAM packets are treated the same and also share the same
fate as regular data traffic. fate as regular data traffic.
Delay within an SFC could be measured based on the time it takes for Delay within an SFC could be measured based on the time it takes for
a packet to traverse the SFC from the ingress SFC node to the egress a packet to traverse the SFC from the ingress SFC node to the egress
SFF. Measurement protocols such as One-way Active Measurement SFF. Measurement protocols, such as the One-Way Active Measurement
Protocol (OWAMP) [RFC4656] and Two-way Active Measurement Protocol Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement
(TWAMP) [RFC5357] can be used to measure the characteristics. As Protocol (TWAMP) [RFC5357], can be used to measure delay
SFCs are unidirectional in nature, measurement of one-way delay characteristics. As SFCs are unidirectional in nature, measurement
[RFC7679] is important. In order to measure one-way delay, time of one-way delay [RFC7679] is important. In order to measure one-way
synchronization must be supported by means such as NTP, GPS, delay, time synchronization must be supported by means such as NTP,
Precision Time Protocol (PTP), etc. GPS, Precision Time Protocol (PTP), etc.
One-way delay variation [RFC3393] could also be calculated by sending One-way delay variation [RFC3393] could also be calculated by sending
OAM packets and measuring the jitter for traffic passing through an OAM packets and measuring the jitter for traffic passing through an
SFC. SFC.
Some of the OAM functions supported by the performance measurement Some of the OAM functions supported by the performance measurement
functions are: functions are:
o Ability to measure the packet processing delay induced by a single * the ability to measure the packet processing delay induced by a
SF or the one-way delay to traverse an SFP bound to a given SFC. single SF or the one-way delay to traverse an SFP bound to a given
SFC, and
o Ability to measure the packet loss [RFC7680] within an SF or an * the ability to measure the packet loss [RFC7680] within an SF or
SFP bound to a given SFC. an SFP bound to a given SFC.
5. Gap Analysis 5. Gap Analysis
This section identifies various OAM functions available at different This section identifies various OAM functions available at different
layers introduced in Section 2. It also identifies various gaps that layers introduced in Section 2. It also identifies various gaps that
exist within the current toolset for performing OAM functions exist within the current toolset for performing OAM functions
required for SFC. required for SFC.
5.1. Existing OAM Functions 5.1. Existing OAM Functions
There are various OAM tool sets available to perform OAM functions There are various OAM toolsets available to perform OAM functions
within various layers. These OAM functions may be used to validate within various layers. These OAM functions may be used to validate
some of the underlay and overlay networks. Tools like ping and trace some of the underlay and overlay networks. Tools like ping and trace
are in existence to perform connectivity check and tracing of are in existence to perform connectivity checks and trace
intermediate hops in a network. These tools support different intermediate hops in a network. These tools support different
network types like IP, MPLS, TRILL, etc. Ethernet OAM (E-OAM) network types, like IP, MPLS, TRILL, etc. Ethernet OAM (E-OAM)
[Y.1731] [EFM] and Connectivity Fault Management (CFM) [DOT1Q] offer [Y.1731] [EFM] and Connectivity Fault Management (CFM) [DOT1Q] offer
OAM mechanisms such as an Ethernet continuity check for Ethernet OAM mechanisms, such as a continuity check for Ethernet links. There
links. There is an effort around NVO3 OAM to provide connectivity is an effort around NVO3 OAM to provide connectivity and continuity
and continuity checks for networks that use NVO3. BFD is used for checks for networks that use NVO3. BFD is used for the detection of
the detection of data plane forwarding failures. The IPPM framework data-plane forwarding failures. The IPPM framework [RFC2330] offers
[RFC2330] offers tools such as OWAMP [RFC4656] and TWAMP [RFC5357] tools such as OWAMP [RFC4656] and TWAMP [RFC5357] (collectively
(collectively referred as IPPM in this section) to measure various referred as IPPM in this section) to measure various performance
performance metrics. MPLS Packet Loss Measurement (LM) and Packet metrics. MPLS Packet Loss Measurement (LM) and Packet Delay
Delay Measurement (DM) (collectively referred as MPLS_PM in this Measurement (DM) (collectively referred as MPLS_PM in this section)
section) [RFC6374] offers the ability to measure performance metrics [RFC6374] offer the ability to measure performance metrics in MPLS
in MPLS network. There is also an effort to extend the tool set to networks. There is also an effort to extend the toolset to provide
provide connectivity and continuity checks within overlay networks. connectivity and continuity checks within overlay networks. BFD is
another tool that helps in detecting data forwarding failures.
Table 1 below is not exhaustive.
BFD is another tool which helps in detecting data forwarding +============+==============+============+=======+=============+
failures. Table 3 below is not exhaustive. | Layer | Connectivity | Continuity | Trace | Performance |
+============+==============+============+=======+=============+
| Underlay | Ping | E-OAM, BFD | Trace | IPPM, |
| network | | | | MPLS_PM |
+------------+--------------+------------+-------+-------------+
| Overlay | Ping | BFD, NVO3 | Trace | IPPM |
| network | | OAM | | |
+------------+--------------+------------+-------+-------------+
| Classifier | Ping | BFD | Trace | None |
+------------+--------------+------------+-------+-------------+
| SF | None | None | None | None |
+------------+--------------+------------+-------+-------------+
| SFC | None | None | None | None |
+------------+--------------+------------+-------+-------------+
Table 3: OAM Tool GAP Analysis Table 1: OAM Tool Gap Analysis
+----------------+--------------+-------------+--------+------------+
| Layer | Connectivity | Continuity | Trace | Performance|
+----------------+--------------+-------------+--------+------------+
| Underlay N/w | Ping |E-OAM, BFD | Trace | IPPM, |
| | | | | MPLS_PM |
+----------------+--------------+-------------+--------+------------+
| Overlay N/w | Ping | BFD, | | |
| | | NVO3 OAM | Trace | IPPM |
+----------------+--------------+-------------+--------+------------+
| Classifier | Ping | BFD | Trace | None |
+----------------+--------------+-------------+--------+------------+
| SF | None | None | None | None |
+----------------+--------------+-------------+--------+------------+
| SFC | None | None | None | None |
+----------------+--------------+-------------+--------+------------+
5.2. Missing OAM Functions 5.2. Missing OAM Functions
As shown in Table 3, there are no standards-based tools available at As shown in Table 1, there are no standards-based tools available at
the time of this writing that can be used natively (i.e. without the time of this writing that can be used natively (i.e., without
enhancement) for the verification of SFs and SFCs. enhancement) for the verification of SFs and SFCs.
5.3. Required OAM Functions 5.3. Required OAM Functions
Primary OAM functions exist for underlying layers. Tools like ping, Primary OAM functions exist for underlying layers. Tools like ping,
trace, BFD, etc. exist in order to perform these OAM functions. trace, BFD, etc. exist in order to perform these OAM functions.
As depicted in Table 3, toolsets and solutions are required to As depicted in Table 1, toolsets and solutions are required to
perform the OAM functions at the service layer. perform the OAM functions at the service layer.
6. Operational Aspects of SFC OAM at the Service Layer 6. Operational Aspects of SFC OAM at the Service Layer
This section describes the operational aspects of SFC OAM at the This section describes the operational aspects of SFC OAM at the
service layer to perform the SFC OAM function defined in Section 4 service layer to perform the SFC OAM function defined in Section 4
and analyzes the applicability of various existing OAM toolsets in and analyzes the applicability of various existing OAM toolsets in
the service layer. the service layer.
6.1. SFC OAM Packet Marker 6.1. SFC OAM Packet Marker
SFC OAM messages should be encapsulated with necessary SFC header and SFC OAM messages should be encapsulated with the necessary SFC header
with OAM markings when testing the SFC component. SFC OAM messages and with OAM markings when testing the SFC component. SFC OAM
may be encapsulated with the necessary SFC header and with OAM messages may be encapsulated with the necessary SFC header and with
markings when testing the SF component. OAM markings when testing the SF component.
The SFC OAM function described in Section 4 performed at the service The SFC OAM function described in Section 4 performed at the service
layer or overlay network layer must mark the packet as an OAM packet layer or overlay network layer must mark the packet as an OAM packet
so that relevant nodes can differentiate an OAM packet from data so that relevant nodes can differentiate OAM packets from data
packets. The base header defined in Section 2.2 of [RFC8300] assigns 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 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. service layer, the O bit must be set to differentiate the OAM packet.
Any other overlay encapsulations used at the service layer must have Any other overlay encapsulations used at the service layer must have
a way to mark the packet as OAM packet. a way to mark the packet as an OAM packet.
6.2. OAM Packet Processing and Forwarding Semantic 6.2. OAM Packet Processing and Forwarding Semantic
Upon receiving an OAM packet, SFC-aware SFs may choose to discard the Upon receiving an OAM packet, an SFC-aware SF may choose to discard
packet if it does not support OAM functionality or if the local the packet if it does not support OAM functionality or if the local
policy prevents them from processing the OAM packet. When an SF policy prevents it from processing the OAM packet. When an SF
supports OAM functionality, it is desirable to process the packet and supports OAM functionality, it is desirable to process the packet and
provide an appropriate response to allow end-to-end verification. To provide an appropriate response to allow end-to-end verification. To
limit performance impact due to OAM, SFC-aware SFs should rate limit limit performance impact due to OAM, SFC-aware SFs should rate-limit
the number of OAM packets processed. the number of OAM packets processed.
An SFF may choose not to forward the OAM packet to an SF if the SF An SFF may choose to not forward the OAM packet to an SF if the SF
does not support OAM or if the policy does not allow to forward OAM does not support OAM or if the policy does not allow the forwarding
packets to an SF. The SFF may choose to skip the SF, modify the of OAM packets to that SF. The SFF may choose to skip the SF, modify
header and forward to the next SFC node in the chain. It should be the packet's header, and forward the packet to the next SFC node in
noted that skipping an SF might have implications on some OAM the chain. It should be noted that skipping an SF might have
functions (e.g. the delay measurement may not be accurate). The implications on some OAM functions (e.g., the delay measurement may
method by which an SFF detects if the connected SF supports or is not be accurate). The method by which an SFF detects if the
allowed to process OAM packets is outside the scope of this document. connected SF supports or is allowed to process OAM packets is outside
It could be a configuration parameter instructed by the controller or the scope of this document. It could be a configuration parameter
it can be done by dynamic negotiation between the SF and SFF. instructed by the controller, or it can be done by dynamic
negotiation between the SF and SFF.
If the SFF receiving the OAM packet bound to a given SFC is the last 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 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 of the OAM packet. Depending on the type of OAM solution and toolset
set used, the response could be a simple response (such as ICMP used, the response could be a simple response (such as ICMP reply) or
reply) or could include additional data from the received OAM packet could include additional data from the received OAM packet (like
(like statistical data consolidated along the path). The details are statistical data consolidated along the path). The details are
expected to be covered in the solution documents. expected to be covered in the solution documents.
Any SFC-aware node that initiates an OAM packet must set the OAM Any SFC-aware node that initiates an OAM packet must set the OAM
marker in the overlay encapsulation. marker in the overlay encapsulation.
6.3. OAM Function Types 6.3. OAM Function Types
As described in Section 4, there are different OAM functions that may As described in Section 4, there are different OAM functions that may
require different OAM solutions. While the presence of the OAM require different OAM solutions. While the presence of the OAM
marker in the overlay header (e.g., O bit in the NSH header) marker in the overlay header (e.g., O bit in the NSH header)
indicates it as an OAM packet, it is not sufficient to indicate what indicates it as an OAM packet, it is not sufficient to indicate what
OAM function the packet is intended for. The Next Protocol field in OAM function the packet is intended for. The Next Protocol field in
the NSH header may be used to indicate what OAM function is intended the NSH header may be used to indicate what OAM function is intended
or what toolset is used. Any other overlay encapsulations used at or what toolset is used. Any other overlay encapsulations used at
the service layer must have a similar way to indicate the intended the service layer must have a similar way to indicate the intended
OAM function. OAM function.
7. Candidate SFC OAM Tools 7. Candidate SFC OAM Tools
As described in Section 5.1, there are different tool sets available As described in Section 5.1, there are different toolsets available
to perform OAM functions at different layers. This section describe to perform OAM functions at different layers. This section describe
the applicability of some of the available toolsets in the service the applicability of some of the available toolsets in the service
layer. layer.
7.1. ICMP 7.1. ICMP
[RFC0792] and [RFC4443] describe the use of ICMP in IPv4 and IPv6 [RFC0792] and [RFC4443] describe the use of ICMP in IPv4 and IPv6
networks respectively. It explains how ICMP messages can be used to networks respectively. It explains how ICMP messages can be used to
test the network reachability between different end points and test the network reachability between different end points and
perform basic network diagnostics. perform basic network diagnostics.
ICMP could be leveraged for connectivity functions (defined in ICMP could be leveraged for connectivity functions (defined in
Section 4.1) to verify the availability of an SF or SFC. The Section 4.1) to verify the availability of an SF or SFC. The
Initiator can generate an ICMP echo request message and control the initiator can generate an ICMP echo request message and control the
service layer encapsulation header to get the response from the service-layer encapsulation header to get the response from the
relevant node. For example, a classifier initiating OAM can generate relevant node. For example, a classifier initiating OAM can generate
an ICMP echo request message, can set the TTL field in the NSH header an ICMP echo request message, set the TTL field in the NSH header
[RFC8300] to 63 to get the response from the last SFF, and thereby [RFC8300] to 63 to get the response from the last SFF, and thereby
test the SFC availability. Alternatively, the initiator can set the test the SFC availability. Alternatively, the initiator can set the
TTL to some other value to get the response from a specific SFs and TTL to some other value to get the response from a specific SF and
thereby partially test SFC availability or the initiator could send thereby partially test SFC availability, or the initiator could send
OAM packets with sequentially incrementing TTL in the NSH to trace OAM packets with sequentially incrementing TTL in the NSH to trace
the SFP. the SFP.
It could be observed that ICMP at its current stage may not be able It could be observed that ICMP as currently defined may not be able
to perform all required SFC OAM functions, but as explained above, it to perform all required SFC OAM functions, but as explained above, it
can be used for some of the connectivity functions. can be used for some of the connectivity functions.
7.2. BFD/Seamless-BFD 7.2. BFD / Seamless BFD
[RFC5880] defines the Bidirectional Forwarding Detection (BFD) [RFC5880] defines the Bidirectional Forwarding Detection (BFD)
mechanism for failure detection. [RFC5881] and [RFC5884] define the mechanism for failure detection. [RFC5881] and [RFC5884] define the
applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] applicability of BFD in IPv4, IPv6, and MPLS networks. [RFC7880]
defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. defines Seamless BFD (S-BFD), a simplified mechanism of using BFD.
[RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. [RFC7881] explains its applicability in IPv4, IPv6, and MPLS
networks.
BFD or S-BFD could be leveraged to perform the continuity function BFD or S-BFD could be leveraged to perform the continuity function
for SF or SFC. An initiator could generate a BFD control packet and for SF or SFC. An initiator could generate a BFD control packet and
set the "Your Discriminator" value to identify the last SFF in the set the "Your Discriminator" value in the control packet to identify
control packet. Upon receiving the control packet, the last SFF in the last SFF. Upon receiving the control packet, the last SFF in the
the SFC will reply back with the relevant DIAG code. The TTL field SFC will reply back with the relevant DIAG code. The TTL field in
in the NSH header could be used to perform a partial SFC availability the NSH header could be used to perform a partial SFC availability
check. For example, the initiator can set the "Your Discriminator" check. For example, the initiator can set the "Your Discriminator"
value to identify the SF that is intended to be tested and set the value to identify the SF that is intended to be tested and set the
TTL field in the NSH header in a way that it expires at the relevant TTL field in the NSH header in a way that it expires at the relevant
SF. How the initiator gets the Discriminator value to identify the SF. How the initiator gets the Discriminator value to identify the
SF is outside the scope of this document. SF is outside the scope of this document.
7.3. In-Situ OAM 7.3. In Situ OAM
[I-D.ietf-sfc-ioam-nsh] defines how In-Situ OAM data fields [IOAM-NSH] defines how In situ OAM data fields [IPPM-IOAM-DATA] are
[I-D.ietf-ippm-ioam-data] are transported using the NSH header. transported using the NSH header. [PROOF-OF-TRANSIT] defines a
[I-D.ietf-sfc-proof-of-transit] defines a mechanism to perform proof mechanism to perform proof of transit to securely verify if a packet
of transit to securely verify if a packet traversed the relevant SFP traversed the relevant SFP or SFC. While the mechanism is defined
or SFC. While the mechanism is defined inband (i.e., it will be inband (i.e., it will be included in data packets), IOAM Option-
included in data packets), IOA Option-Types such as IOAM Trace Types, such as IOAM Trace Option-Types, can also be used to perform
Option-Types can also be used to perform other SFC OAM function such other SFC OAM functions, such as SFC tracing.
as SFC tracing.
In-Situ OAM could be leveraged to perform SF availability and SFC In situ OAM could be leveraged to perform SF availability and SFC
availability or performance measurement. For example, if SFC is availability or performance measurement. For example, if SFC is
realized using NSH, the O-bit in the NSH header could be set to realized using NSH, the O bit in the NSH header could be set to
indicate the OAM traffic as defined in Section 4.2 indicate the OAM traffic, as defined in Section 4.2 of [IOAM-NSH].
[I-D.ietf-sfc-ioam-nsh].
7.4. SFC Traceroute 7.4. SFC Traceroute
[I-D.penno-sfc-trace] defines a protocol that checks for path [SFC-TRACE] defines a protocol that checks for path liveliness and
liveliness and traces the service hops in any SFP. Section 3 of traces the service hops in any SFP. Section 3 of [SFC-TRACE] defines
[I-D.penno-sfc-trace] defines the SFC trace packet format while the SFC trace packet format, while Sections 4 and 5 of [SFC-TRACE]
Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF define the behavior of SF and SFF respectively. While [SFC-TRACE]
and SFF respectively. While [I-D.penno-sfc-trace] has expired, the has expired, the proposal is implemented in Open Daylight and is
proposal is implemented in Open Daylight and is available. available.
An initiator can control the Service Index Limit (SIL) in SFC trace An initiator can control the Service Index Limit (SIL) in an SFC
packet to perform SF and SFC availability test. trace packet to perform SF and SFC availability tests.
8. Manageability Considerations 8. Manageability Considerations
This document does not define any new manageability tools but This document does not define any new manageability tools but
consolidates the manageability tool gap analysis for SF and SFC. consolidates the manageability tool gap analysis for SF and SFC.
Table 4 below is not exhaustive. Table 2 below is not exhaustive.
Table 4: OAM Tool GAP Analysis +===========+===============+===============+========+==============+
+----------------+--------------+-------------+--------+-------------+ |Layer | Configuration | Orchestration |Topology|Notification |
| Layer |Configuration |Orchestration|Topology|Notification | +===========+===============+===============+========+==============+
+----------------+--------------+-------------+--------+-------------+ |Underlay | CLI, NETCONF | CLI, NETCONF |SNMP |SNMP, Syslog, |
| Underlay N/w |CLI, NETCONF | CLI, NETCONF| SNMP |SNMP, Syslog,| |network | | | |NETCONF |
| | | | |NETCONF | +-----------+---------------+---------------+--------+--------------+
+----------------+--------------+-------------+--------+-------------+ |Overlay | CLI, NETCONF | CLI, NETCONF |SNMP |SNMP, Syslog, |
| Overlay N/w |CLI, NETCONF | CLI, NETCONF| SNMP |SNMP, Syslog | |network | | | |NETCONF |
| | | | |NETCONF | +-----------+---------------+---------------+--------+--------------+
+----------------+--------------+-------------+--------+-------------+ |Classifier | CLI, NETCONF | CLI, NETCONF |None |None |
| Classifier |CLI, NETCONF | CLI, NETCONF| None | None | +-----------+---------------+---------------+--------+--------------+
+----------------+--------------+-------------+--------+-------------+ |SF | CLI, NETCONF | CLI, NETCONF |None |None |
| SF |CLI, NETCONF | CLI, NETCONF| None | None | +-----------+---------------+---------------+--------+--------------+
+----------------+--------------+-------------+--------+-------------+ |SFC | CLI, NETCONF | CLI, NETCONF |None |None |
| SFC |CLI, NETCONF | CLI, NETCONF| None | None | +-----------+---------------+---------------+--------+--------------+
+----------------+--------------+-------------+--------+-------------+
Configuration, orchestration and other manageability tasks of SF and Table 2: OAM Tool Gap Analysis
SFC could be performed using CLI, NETCONF [RFC6241] , etc.
While the NETCONF capabilities are readily available as depicted in Configuration, orchestration, and other manageability tasks of SF and
Table 4, the information and data models are needed for SFC could be performed using CLI, NETCONF [RFC6241], etc.
configuration, manageability and orchestration for SFC. With
While the NETCONF capabilities are readily available, as depicted in
Table 2, the information and data models are needed for
configuration, manageability, and orchestration for SFC. With
virtualized SF and SFC, manageability needs to be done virtualized SF and SFC, manageability needs to be done
programmatically. programmatically.
9. Security Considerations 9. Security Considerations
Any security considerations defined in [RFC7665] and [RFC8300] is Any security considerations defined in [RFC7665] and [RFC8300] are
applicable for this document. applicable for this document.
The OAM information from the service layer at different components The OAM information from the service layer at different components
may collectively or independently reveal sensitive information. The may collectively or independently reveal sensitive information. The
information may reveal the type of service functions hosted in the information may reveal the type of service functions hosted in the
network, the classification rules and the associated service chains, network, the classification rules and the associated service chains,
specific service function paths, etc. The sensitivity of the specific service function paths, etc. The sensitivity of the
information from the SFC layer raises a need for careful security information from the SFC layer raises a need for careful security
considerations. considerations.
The mapping and the rules information at the classifier component may The mapping and the rules information at the classifier component may
reveal the traffic rules and the traffic mapped to the SFC. The SFC reveal the traffic rules and the traffic mapped to the SFC. The SFC
information collected at an SFC component may reveal the SFs information collected at an SFC component may reveal the SFs
associated within each chain and this information together with associated within each chain, and this information together with
classifier rules may be used to manipulate the header of synthetic classifier rules may be used to manipulate the header of synthetic
attack packets that may be used to bypass the SFC and trigger any attack packets that may be used to bypass the SFC and trigger any
internal attacks. internal attacks.
The SF information at the SF component may be used by a malicious The SF information at the SF component may be used by a malicious
user to trigger Denial of Service (DoS) attack by overloading any user to trigger a Denial of Service (DoS) attack by overloading any
specific SF using rogue OAM traffic. specific SF using rogue OAM traffic.
To address the above concerns, SFC and SF OAM should provide To address the above concerns, SFC and SF OAM should provide
mechanisms for mitigating: mechanisms for mitigating:
o Misuse of the OAM channel for denial-of-services, * misuse of the OAM channel for denial of services,
o Leakage of OAM packets across SFC instances, and * leakage of OAM packets across SFC instances, and
o Leakage of SFC information beyond the SFC domain. * leakage of SFC information beyond the SFC domain.
The documents proposing the OAM solution for SF components should The documents proposing the OAM solution for SF components should
provide rate-limiting the OAM probes at a frequency guided by the provide rate-limiting the OAM probes at a frequency guided by the
implementation choice. Rate-limiting may be applied at the implementation choice. Rate-limiting may be applied at the
Classifier, SFF or the SF . The OAM initiator may not receive a classifier, SFF, or the SF. The OAM initiator may not receive a
response for the probes that are rate-limited resulting in false response for the probes that are rate-limited resulting in false
negatives and the implementation should be aware of this. To negatives, and the implementation should be aware of this. To
mitigate any attacks that leverage OAM packets, future documents mitigate any attacks that leverage OAM packets, future documents
proposing OAM solutions should describe the use of any technique to proposing OAM solutions should describe the use of any technique to
detect and mitigate anomalies and various security attacks. detect and mitigate anomalies and various security attacks.
The documents proposing the OAM solution for any service layer The documents proposing the OAM solution for any service-layer
components should consider some form of message filtering to control components should consider some form of message filtering to control
the OAM packets entering the administrative domain or prevent leaking the OAM packets entering the administrative domain or prevent leaking
any internal service layer information outside the administrative any internal service-layer information outside the administrative
domain. domain.
10. IANA Considerations 10. IANA Considerations
No action is required by IANA for this document. This document has no IANA actions.
11. Acknowledgements
We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky,
Tal Mizrahi, Martin Vigoureux, Tirumaleswar Reddy, Carlos Bernados,
Martin Duke, Barry Leiba, Eric Vyncke, Roman Danyliw, Erik Kline,
Benjamin Kaduk, Robert Wilton, Frank Brockner, Alvaro Retana, Murray
Kucherawy, and Alissa Cooper for their review and comments.
12. Contributing Authors
Nobo Akiya
Ericsson
Email: nobo.akiya.dev@gmail.com
13. Informative References 11. Informative References
[DOT1Q] IEEE, "Standard for Local and Metropolitan Area Networks-- [DOT1Q] IEEE, "IEEE Standard for Local and metropolitan area
Bridges and Bridged Networks, IEEE Std 802.1Q-2014, networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
November 2014". DOI 10.1109/IEEESTD.2014.6991462, November 2014,
<https://doi.org/10.1109/IEEESTD.2014.6991462>.
[EFM] IEEE, "IEEE Standard for Ethernet (Clause 57 for [EFM] IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018,
Operations, Administration, and Maintenance), IEEE Std DOI 10.1109/IEEESTD.2018.8457469, June 2018,
802.3-2018, June 2018". <https://doi.org/10.1109/IEEESTD.2018.8457469>.
[I-D.ietf-ippm-ioam-data] [IOAM-NSH] Brockners, F. and S. Bhandari, "Network Service Header
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-04, 16
P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, June 2020,
d., and J. Lemon, "Data Fields for In-situ OAM", draft- <https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-04>.
ietf-ippm-ioam-data-09 (work in progress), March 2020.
[I-D.ietf-sfc-ioam-nsh] [IPPM-IOAM-DATA]
Brockners, F. and S. Bhandari, "Network Service Header Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
(NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- for In-situ OAM", Work in Progress, Internet-Draft, draft-
ietf-sfc-ioam-nsh-03 (work in progress), March 2020. ietf-ippm-ioam-data-10, 13 July 2020,
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-
10>.
[I-D.ietf-sfc-proof-of-transit] [PROOF-OF-TRANSIT]
Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S.
Youell, "Proof of Transit", draft-ietf-sfc-proof-of- Youell, "Proof of Transit", Work in Progress, Internet-
transit-04 (work in progress), November 2019. Draft, draft-ietf-sfc-proof-of-transit-06, 16 June 2020,
<https://tools.ietf.org/html/draft-ietf-sfc-proof-of-
[I-D.penno-sfc-trace] transit-06>.
Penno, R., Quinn, P., Pignataro, C., and D. Zhou,
"Services Function Chaining Traceroute", draft-penno-sfc-
trace-03 (work in progress), September 2015.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
skipping to change at page 23, line 10 skipping to change at line 1016
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", RFC 8459, "Hierarchical Service Function Chaining (hSFC)", RFC 8459,
DOI 10.17487/RFC8459, September 2018, DOI 10.17487/RFC8459, September 2018,
<https://www.rfc-editor.org/info/rfc8459>. <https://www.rfc-editor.org/info/rfc8459>.
[Y.1731] ITU-T, "OAM Functions and mechanisms for Ethernet based [SFC-TRACE]
networks", Penno, R., Quinn, P., Pignataro, C., and D. Zhou,
"Services Function Chaining Traceroute", Work in Progress,
Internet-Draft, draft-penno-sfc-trace-03, 30 September
2015,
<https://tools.ietf.org/html/draft-penno-sfc-trace-03>.
[Y.1731] ITU-T, "G.8013: Operations, administration and maintenance
(OAM) functions and mechanisms for Ethernet-based
networks", August 2015,
<https://www.itu.int/rec/T-REC-G.8013-201508-I/en>. <https://www.itu.int/rec/T-REC-G.8013-201508-I/en>.
Acknowledgements
We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky,
Tal Mizrahi, Martin Vigoureux, Tirumaleswar Reddy, Carlos Bernados,
Martin Duke, Barry Leiba, Éric Vyncke, Roman Danyliw, Erik Kline,
Benjamin Kaduk, Robert Wilton, Frank Brockner, Alvaro Retana, Murray
Kucherawy, and Alissa Cooper for their review and comments.
Contributors
Nobo Akiya
Ericsson
Email: nobo.akiya.dev@gmail.com
Authors' Addresses Authors' Addresses
Sam K. Aldrin Sam K. Aldrin
Google Google
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Carlos Pignataro (editor) Carlos Pignataro (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 148 change blocks. 
413 lines changed or deleted 424 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/