diff options
Diffstat (limited to 'doc/rfc/rfc8924.txt')
| -rw-r--r-- | doc/rfc/rfc8924.txt | 1081 |
1 files changed, 1081 insertions, 0 deletions
diff --git a/doc/rfc/rfc8924.txt b/doc/rfc/rfc8924.txt new file mode 100644 index 0000000..972afd6 --- /dev/null +++ b/doc/rfc/rfc8924.txt @@ -0,0 +1,1081 @@ + + + + +Internet Engineering Task Force (IETF) S. Aldrin +Request for Comments: 8924 Google +Category: Informational C. Pignataro, Ed. +ISSN: 2070-1721 N. Kumar, Ed. + Cisco + R. Krishnan + VMware + A. Ghanwani + Dell + October 2020 + + + Service Function Chaining (SFC) Operations, Administration, and + Maintenance (OAM) Framework + +Abstract + + This document provides a reference framework for Operations, + Administration, and Maintenance (OAM) for Service Function Chaining + (SFC). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + 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. + + 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 (c) 2020 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. + +Table of Contents + + 1. Introduction + 1.1. Document Scope + 1.2. Acronyms and Terminology + 1.2.1. Acronyms + 1.2.2. Terminology + 2. SFC Layering Model + 3. SFC OAM Components + 3.1. The SF Component + 3.1.1. SF Availability + 3.1.2. SF Performance Measurement + 3.2. The SFC Component + 3.2.1. SFC Availability + 3.2.2. SFC Performance Measurement + 3.3. Classifier Component + 3.4. Underlay Network + 3.5. Overlay Network + 4. SFC OAM Functions + 4.1. Connectivity Functions + 4.2. Continuity Functions + 4.3. Trace Functions + 4.4. Performance Measurement Functions + 5. Gap Analysis + 5.1. Existing OAM Functions + 5.2. Missing OAM Functions + 5.3. Required OAM Functions + 6. Operational Aspects of SFC OAM at the Service Layer + 6.1. SFC OAM Packet Marker + 6.2. OAM Packet Processing and Forwarding Semantic + 6.3. OAM Function Types + 7. Candidate SFC OAM Tools + 7.1. ICMP + 7.2. BFD / Seamless BFD + 7.3. In Situ OAM + 7.4. SFC Traceroute + 8. Manageability Considerations + 9. Security Considerations + 10. IANA Considerations + 11. Informative References + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + Service Function Chaining (SFC) enables the creation of composite + services that consist of an ordered set of Service Functions (SFs) + that are to be applied to any traffic selected as a result of + classification [RFC7665]. SFC 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: + + * SFC Problem Statement [RFC7498] + + * SFC Architecture [RFC7665] + + The reader is assumed to be familiar with the material in [RFC7665]. + + This document provides a reference framework for Operations, + Administration, and Maintenance (OAM) [RFC6291] of SFC. + Specifically, this document provides: + + * an SFC layering model (Section 2), + + * aspects monitored by SFC OAM (Section 3), + + * functional requirements for SFC OAM (Section 4), + + * a gap analysis for SFC OAM (Section 5), + + * operational aspects of SFC OAM at the service layer (Section 6), + + * applicability of various OAM tools (Section 7), and + + * manageability considerations for SF and SFC (Section 8). + + SFC OAM solution documents should refer to this document to indicate + the SFC OAM component and the functionality they target. + + OAM controllers are SFC-aware network devices that are capable of + generating OAM packets. They should be within the same + administrative domain as the target SFC-enabled domain. + +1.1. Document Scope + + 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. + +1.2. Acronyms and Terminology + +1.2.1. Acronyms + + BFD Bidirectional Forwarding Detection + + CLI Command-Line Interface + + DWDM Dense Wavelength Division Multiplexing + + E-OAM Ethernet OAM + + hSFC Hierarchical Service Function Chaining + + IBN Internal Boundary Node + + IPPM IP Performance Metrics + + MPLS Multiprotocol Label Switching + + MPLS_PM MPLS Performance Measurement + + NETCONF Network Configuration Protocol + + NSH Network Service Header + + NVO3 Network Virtualization over Layer 3 + + OAM Operations, Administration, and Maintenance + + POS Packet over SONET + + RSP Rendered Service Path + + SF Service Function + + SFC Service Function Chain + + SFF Service Function Forwarder + + SFP Service Function Path + + SNMP Simple Network Management Protocol + + TRILL Transparent Interconnection of Lots of Links + + VM Virtual Machine + +1.2.2. Terminology + + This document uses the terminology defined in [RFC7665] and + [RFC8300], and readers are expected to be familiar with it. + +2. SFC Layering Model + + Multiple layers come into play for implementing the SFC. These + include the service layer and the underlying layers (network layer, + link layer, etc.). + + * The service layer consists of SFC data-plane elements that include + classifiers, Service Functions (SFs), Service Function Forwarders + (SFF), and SFC Proxies. This layer uses the overlay network layer + for ensuring connectivity between SFC data-plane elements. + + * The overlay network layer leverages various overlay network + technologies (e.g., Virtual eXtensible Local Area Network (VXLAN)) + for interconnecting SFC data-plane elements and allows + establishing Service Function Paths (SFPs). This layer is mostly + transparent to the SFC data-plane elements, as not all the data- + plane elements process the overlay header. + + * The underlay network layer is dictated by the networking + technology deployed within a network (e.g., IP, MPLS). + + * The link layer is tightly coupled with the physical technology + used. Ethernet is one such choice for this layer, but other + alternatives may be deployed (e.g., POS and DWDM). In a virtual + environment, virtualized I/O technologies, such as Single Root I/O + Virtualization (SR-IOV) or similar, are also applicable for this + layer. The same or distinct link layer technologies may be used + in each leg shown in Figure 1. + + + o----------------------Service Layer----------------------o + + +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ + |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| + |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ + +------+ + <------VM1------> <--VM2--> <--VM3--> + + ^-----------------^-------------------^---------------^ Overlay + Network + + o-----------------o-------------------o---------------o Underlay + Network + + o--------o--------o--------o----------o-------o-------o Link + + Figure 1: SFC Layering Example + + In Figure 1, the service-layer elements, such as classifier and SF, + are depicted as virtual entities that are interconnected using an + overlay network. The underlay network may comprise multiple + intermediate nodes not shown in the figure that provide underlay + connectivity between the service-layer elements. + + While Figure 1 depicts an example where SFs are enabled as virtual + entities, the SFC architecture does not make any assumptions on how + the SFC data-plane elements are deployed. The SFC architecture is + flexible and accommodates physical or virtual entity deployment. SFC + OAM accounts for this flexibility, and accordingly it is applicable + whether SFC data-plane elements are deployed directly on physical + hardware, as one or more virtual entities, or any combination + thereof. + +3. SFC OAM Components + + 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: + + SF component: + 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. + + SFC component: + 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) [RFC8459] 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. + + Classifier component: + 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 [RFC7665]. + + Figure 2 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 Components + + 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. + +3.1. The SF Component + +3.1.1. SF Availability + + 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. + +3.1.2. SF Performance Measurement + + 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. + +3.2. The SFC Component + +3.2.1. SFC Availability + + 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. + +3.2.2. SFC Performance Measurement + + 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. + +3.3. Classifier Component + + 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. + +3.4. Underlay Network + + 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. + +3.5. Overlay Network + + 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. + +4. SFC OAM Functions + + Section 3 described SFC OAM components and the associated OAM + operations on each of them. This section explores SFC OAM functions + that are applicable for more than one SFC component. + + The various SFC OAM requirements listed in Section 3 highlight the + need for various OAM functions at the service layer. As listed in + Section 5.1, various OAM functions are in existence that are defined + to perform OAM functionality at different layers. In order to apply + such OAM functions at the service layer, they need to be enhanced to + operate on a single SF/SFF or multiple SFs/SFFs spanning across one + or more SFCs. + +4.1. Connectivity Functions + + Connectivity is mainly an on-demand function to verify that + connectivity exists between certain network elements and that the SFs + are available. For example, Label Switched Path (LSP) Ping [RFC8029] + is a common tool used to perform this function for an MPLS network. + Some of the OAM functions performed by connectivity functions are as + follows: + + * 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 + variable length. + + * Detect any packet reordering and corruption. + + * Verify that an SFC or SF is applying the expected policy. + + * Verify and validate forwarding paths. + + * Proactively test alternate or protected paths to ensure + reliability of network configurations. + +4.2. Continuity Functions + + Continuity is a model where OAM messages are sent periodically to + 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 + the classifier or controller) to quickly detect failures, such as + link failures, network element failures, SF outages, or SFC outages. + BFD [RFC5880] is one such protocol that helps in detecting failures + quickly. OAM functions supported by continuity functions are as + follows: + + * Provision a continuity check to a given SF within an SFC or for + the entire SFC. + + * Proactively test alternate or protected paths to ensure + reliability of network configurations. + + * Notifying other OAM functions or applications of the detected + failures so they can take appropriate action. + +4.3. Trace Functions + + Tracing is an OAM function that allows the operation to trigger an + action (e.g., response generation) from every transit device (e.g., + SFF, SF, and SFC Proxy) on the tested layer. This function is + typically useful for gathering information from every transit device + or for isolating the failure point to a specific SF within an SFC or + for an entire SFC. Some of the OAM functions supported by trace + functions are: + + * the ability to trigger an action from every transit device at the + SFC layer, using TTL or other means, + + * the ability to trigger every transit device at the SFC layer to + generate a response with OAM code(s) using TTL or other means, + + * the ability to discover and traverse ECMP paths within an SFC, and + + * the ability to skip SFs that do not support OAM while tracing SFs + in an SFC. + +4.4. Performance Measurement Functions + + Performance measurement functions involve measuring of packet loss, + delay, delay variance, etc. These performance metrics may be + measured proactively or on demand. + + SFC OAM should provide the ability to measure packet loss for an SFC. + On-demand measurement can be used to estimate packet loss using + statistical methods. To ensure accurate estimations, one needs to + ensure that OAM packets are treated the same and also share the same + fate as regular data traffic. + + 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 + SFF. Measurement protocols, such as the One-Way Active Measurement + Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement + Protocol (TWAMP) [RFC5357], can be used to measure delay + characteristics. As SFCs are 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 such as NTP, + GPS, Precision Time Protocol (PTP), etc. + + One-way delay variation [RFC3393] could also be calculated by sending + OAM packets and measuring the jitter for traffic passing through an + SFC. + + Some of the OAM functions supported by the performance measurement + functions are: + + * the ability to measure the packet processing delay induced by a + single SF or the one-way delay to traverse an SFP bound to a given + SFC, and + + * the ability to measure the packet loss [RFC7680] within an SF or + an SFP bound to a given SFC. + +5. Gap Analysis + + This section identifies various OAM functions available at different + layers introduced in Section 2. It also identifies various gaps that + exist within the current toolset for performing OAM functions + required for SFC. + +5.1. Existing OAM Functions + + There are various OAM toolsets available to perform OAM functions + within various layers. These OAM functions may be used to validate + some of the underlay and overlay networks. Tools like ping and trace + are in existence to perform connectivity checks and trace + intermediate hops in a network. These tools support different + network types, like IP, MPLS, TRILL, etc. Ethernet OAM (E-OAM) + [Y.1731] [EFM] and Connectivity Fault Management (CFM) [DOT1Q] offer + OAM mechanisms, such as a continuity check for Ethernet links. There + is an effort around NVO3 OAM to provide connectivity and continuity + checks for networks that use NVO3. BFD is used for the detection of + data-plane forwarding failures. The IPPM framework [RFC2330] offers + tools such as OWAMP [RFC4656] and TWAMP [RFC5357] (collectively + referred to as IPPM in this section) to measure various performance + metrics. MPLS Packet Loss Measurement (LM) and Packet Delay + Measurement (DM) (collectively referred to as MPLS_PM in this + section) [RFC6374] offer the ability to measure performance metrics + in MPLS networks. There is also an effort to extend the toolset to + provide connectivity and continuity checks within overlay networks. + BFD is another tool that helps in detecting data forwarding failures. + Table 1 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 1: OAM Tool Gap Analysis + +5.2. Missing OAM Functions + + 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 + enhancement) for the verification of SFs and SFCs. + +5.3. Required OAM Functions + + Primary OAM functions exist for underlying layers. Tools like ping, + trace, BFD, etc. exist in order to perform these OAM functions. + + As depicted in Table 1, toolsets and solutions are required to + perform the OAM functions 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 + service layer to perform the SFC OAM function defined in Section 4 + and analyzes the applicability of various existing OAM toolsets in + the service layer. + +6.1. SFC OAM Packet Marker + + SFC OAM messages should be encapsulated with the necessary SFC header + and with OAM markings when testing the SFC component. SFC OAM + messages may be encapsulated with the necessary SFC header and with + OAM markings when testing the SF component. + + 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 + so that relevant nodes can differentiate OAM packets 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 at the service layer must have + a way to mark the packet as an OAM packet. + +6.2. OAM Packet Processing and Forwarding Semantic + + Upon receiving an OAM packet, an SFC-aware SF may choose to discard + the packet if it does not support OAM functionality or if the local + policy prevents it from processing the OAM packet. When an SF + supports OAM functionality, it is desirable to process the packet and + provide an appropriate response to allow end-to-end verification. To + limit performance impact due to OAM, SFC-aware SFs should rate-limit + the number of OAM packets processed. + + 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 the forwarding + of OAM packets to that SF. The SFF may choose to skip the SF, modify + the packet's header, and forward the packet to the next SFC node in + the chain. It should be noted that skipping an SF might have + implications on some OAM functions (e.g., the delay measurement may + not be accurate). The method by which an SFF detects if the + connected SF supports or is allowed to process OAM packets is outside + the scope of this document. It could be a configuration parameter + 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 + 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 toolset + used, the response could be a simple response (such as ICMP reply) or + could include additional data from the received OAM packet (like + statistical data consolidated along the path). The details are + expected to be covered in the solution documents. + + Any SFC-aware node that initiates an OAM packet must set the OAM + marker in the overlay encapsulation. + +6.3. OAM Function Types + + As described in Section 4, there are different OAM functions that may + require different OAM solutions. While the presence of the OAM + 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 + 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 + or what toolset is used. Any other overlay encapsulations used at + the service layer must have a similar way to indicate the intended + OAM function. + +7. Candidate SFC OAM Tools + + As described in Section 5.1, there are different toolsets available + to perform OAM functions at different layers. This section describe + the applicability of some of the available toolsets in the service + layer. + +7.1. ICMP + + [RFC0792] and [RFC4443] describe the use of ICMP in IPv4 and IPv6 + networks 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 connectivity functions (defined in + Section 4.1) to verify the availability of an SF or SFC. The + initiator can generate an ICMP echo request message and control the + service-layer encapsulation header to get the response from the + relevant node. For example, a classifier initiating OAM can generate + 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 + test the SFC availability. Alternatively, the initiator can set the + TTL to some other value to get the response from a specific SF and + thereby partially test SFC availability, or the initiator could send + OAM packets with sequentially incrementing TTL in the NSH to trace + the SFP. + + 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 + can be used for some of the connectivity functions. + +7.2. BFD / Seamless BFD + + [RFC5880] defines the Bidirectional Forwarding Detection (BFD) + mechanism for failure detection. [RFC5881] and [RFC5884] define 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 + networks. + + 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 + set the "Your Discriminator" value in the control packet to identify + the last SFF. Upon receiving the control packet, the last SFF in the + SFC will reply back with the relevant DIAG code. The TTL field in + the NSH header could be used to perform a partial SFC availability + check. For example, the initiator can set the "Your Discriminator" + 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 + SF. How the initiator gets the Discriminator value to identify the + SF is outside the scope of this document. + +7.3. In Situ OAM + + [IOAM-NSH] defines how In situ OAM data fields [IPPM-IOAM-DATA] are + transported using the NSH header. [PROOF-OF-TRANSIT] defines a + mechanism to perform proof of transit to securely verify if a packet + traversed the relevant SFP or SFC. While the mechanism is defined + inband (i.e., it will be included in data packets), IOAM Option- + Types, such as IOAM Trace Option-Types, can also be used to perform + other SFC OAM functions, such as SFC tracing. + + In situ OAM could be leveraged to perform SF availability and SFC + availability or performance measurement. For example, if SFC is + realized using NSH, the O bit in the NSH header could be set to + indicate the OAM traffic, as defined in Section 4.2 of [IOAM-NSH]. + +7.4. SFC Traceroute + + [SFC-TRACE] defines a protocol that checks for path liveliness and + traces the service hops in any SFP. Section 3 of [SFC-TRACE] defines + the SFC trace packet format, while Sections 4 and 5 of [SFC-TRACE] + define the behavior of SF and SFF respectively. While [SFC-TRACE] + has expired, the proposal is implemented in Open Daylight and is + available. + + An initiator can control the Service Index Limit (SIL) in an SFC + trace packet to perform SF and SFC availability tests. + +8. Manageability Considerations + + This document does not define any new manageability tools but + consolidates the manageability tool gap analysis for SF and SFC. + Table 2 below is not exhaustive. + + + +===========+===============+===============+========+==============+ + |Layer | Configuration | Orchestration |Topology|Notification | + +===========+===============+===============+========+==============+ + |Underlay | CLI, NETCONF | CLI, NETCONF |SNMP |SNMP, Syslog, | + |network | | | |NETCONF | + +-----------+---------------+---------------+--------+--------------+ + |Overlay | CLI, NETCONF | CLI, NETCONF |SNMP |SNMP, Syslog, | + |network | | | |NETCONF | + +-----------+---------------+---------------+--------+--------------+ + |Classifier | CLI, NETCONF | CLI, NETCONF |None |None | + +-----------+---------------+---------------+--------+--------------+ + |SF | CLI, NETCONF | CLI, NETCONF |None |None | + +-----------+---------------+---------------+--------+--------------+ + |SFC | CLI, NETCONF | CLI, NETCONF |None |None | + +-----------+---------------+---------------+--------+--------------+ + + Table 2: OAM Tool Gap Analysis + + Configuration, orchestration, and other manageability tasks of SF and + SFC could be performed using CLI, NETCONF [RFC6241], etc. + + 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 + programmatically. + +9. Security Considerations + + Any security considerations defined in [RFC7665] and [RFC8300] are + applicable for this document. + + The OAM information from the service layer at different components + may collectively or independently reveal sensitive information. The + information may reveal the type of service functions hosted in the + network, the classification rules and the associated service chains, + specific service function paths, etc. The sensitivity of the + information from the SFC layer raises a need for careful security + considerations. + + The mapping and the rules information at the classifier component may + reveal the traffic rules and the traffic mapped to the SFC. The SFC + information collected at an SFC component may reveal the SFs + associated within each chain, and this information together with + classifier rules may be used to manipulate the header of synthetic + attack packets that may be used to bypass the SFC and trigger any + internal attacks. + + The SF information at the SF component may be used by a malicious + user to trigger a Denial of Service (DoS) attack by overloading any + specific SF using rogue OAM traffic. + + To address the above concerns, SFC and SF OAM should provide + mechanisms for mitigating: + + * misuse of the OAM channel for denial of services, + + * leakage of OAM packets across SFC instances, and + + * leakage of SFC information beyond the SFC domain. + + The documents proposing the OAM solution for SF components should + provide rate-limiting the OAM probes at a frequency guided by the + implementation choice. Rate-limiting may be applied at the + classifier, SFF, or the SF. The OAM initiator may not receive a + response for the probes that are rate-limited resulting in false + negatives, and the implementation should be aware of this. To + mitigate any attacks that leverage OAM packets, future documents + proposing OAM solutions should describe the use of any technique to + detect and mitigate anomalies and various security attacks. + + The documents proposing the OAM solution for any service-layer + components should consider some form of message filtering to control + the OAM packets entering the administrative domain or prevent leaking + any internal service-layer information outside the administrative + domain. + +10. IANA Considerations + + This document has no IANA actions. + +11. Informative References + + [DOT1Q] IEEE, "IEEE Standard for Local and metropolitan area + networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, + DOI 10.1109/IEEESTD.2014.6991462, November 2014, + <https://doi.org/10.1109/IEEESTD.2014.6991462>. + + [EFM] IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018, + DOI 10.1109/IEEESTD.2018.8457469, June 2018, + <https://doi.org/10.1109/IEEESTD.2018.8457469>. + + [IOAM-NSH] Brockners, F. and S. Bhandari, "Network Service Header + (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in + Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-04, 16 + June 2020, + <https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-04>. + + [IPPM-IOAM-DATA] + Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields + for In-situ OAM", Work in Progress, Internet-Draft, draft- + ietf-ippm-ioam-data-10, 13 July 2020, + <https://tools.ietf.org/html/draft-ietf-ippm-ioam-data- + 10>. + + [PROOF-OF-TRANSIT] + Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. + Youell, "Proof of Transit", Work in Progress, Internet- + Draft, draft-ietf-sfc-proof-of-transit-06, 16 June 2020, + <https://tools.ietf.org/html/draft-ietf-sfc-proof-of- + transit-06>. + + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, DOI 10.17487/RFC0792, September 1981, + <https://www.rfc-editor.org/info/rfc792>. + + [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, + "Framework for IP Performance Metrics", RFC 2330, + DOI 10.17487/RFC2330, May 1998, + <https://www.rfc-editor.org/info/rfc2330>. + + [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation + Metric for IP Performance Metrics (IPPM)", RFC 3393, + DOI 10.17487/RFC3393, November 2002, + <https://www.rfc-editor.org/info/rfc3393>. + + [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet + Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification", STD 89, + RFC 4443, DOI 10.17487/RFC4443, March 2006, + <https://www.rfc-editor.org/info/rfc4443>. + + [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. + Zekauskas, "A One-way Active Measurement Protocol + (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, + <https://www.rfc-editor.org/info/rfc4656>. + + [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. + Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", + RFC 5357, DOI 10.17487/RFC5357, October 2008, + <https://www.rfc-editor.org/info/rfc5357>. + + [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, + <https://www.rfc-editor.org/info/rfc5880>. + + [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, + DOI 10.17487/RFC5881, June 2010, + <https://www.rfc-editor.org/info/rfc5881>. + + [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, + "Bidirectional Forwarding Detection (BFD) for MPLS Label + Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, + June 2010, <https://www.rfc-editor.org/info/rfc5884>. + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <https://www.rfc-editor.org/info/rfc6241>. + + [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, + D., and S. Mansfield, "Guidelines for the Use of the "OAM" + Acronym in the IETF", BCP 161, RFC 6291, + DOI 10.17487/RFC6291, June 2011, + <https://www.rfc-editor.org/info/rfc6291>. + + [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay + Measurement for MPLS Networks", RFC 6374, + DOI 10.17487/RFC6374, September 2011, + <https://www.rfc-editor.org/info/rfc6374>. + + [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for + Service Function Chaining", RFC 7498, + DOI 10.17487/RFC7498, April 2015, + <https://www.rfc-editor.org/info/rfc7498>. + + [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function + Chaining (SFC) Architecture", RFC 7665, + DOI 10.17487/RFC7665, October 2015, + <https://www.rfc-editor.org/info/rfc7665>. + + [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, + Ed., "A One-Way Delay Metric for IP Performance Metrics + (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January + 2016, <https://www.rfc-editor.org/info/rfc7679>. + + [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, + Ed., "A One-Way Loss Metric for IP Performance Metrics + (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January + 2016, <https://www.rfc-editor.org/info/rfc7680>. + + [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. + Pallagatti, "Seamless Bidirectional Forwarding Detection + (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, + <https://www.rfc-editor.org/info/rfc7880>. + + [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless + Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, + and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, + <https://www.rfc-editor.org/info/rfc7881>. + + [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., + Aldrin, S., and M. Chen, "Detecting Multiprotocol Label + Switched (MPLS) Data-Plane Failures", RFC 8029, + DOI 10.17487/RFC8029, March 2017, + <https://www.rfc-editor.org/info/rfc8029>. + + [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., + "Network Service Header (NSH)", RFC 8300, + DOI 10.17487/RFC8300, January 2018, + <https://www.rfc-editor.org/info/rfc8300>. + + [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, + "Hierarchical Service Function Chaining (hSFC)", RFC 8459, + DOI 10.17487/RFC8459, September 2018, + <https://www.rfc-editor.org/info/rfc8459>. + + [SFC-TRACE] + 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>. + +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 + + Sam K. Aldrin + Google + + Email: aldrin.ietf@gmail.com + + + Carlos Pignataro (editor) + Cisco Systems, Inc. + + Email: cpignata@cisco.com + + + Nagendra Kumar (editor) + Cisco Systems, Inc. + + Email: naikumar@cisco.com + + + Ram Krishnan + VMware + + Email: ramkri123@gmail.com + + + Anoop Ghanwani + Dell + + Email: anoop@alumni.duke.edu |