draft-ietf-sfc-multi-layer-oam-10.txt   draft-ietf-sfc-multi-layer-oam-11.txt 
SFC WG G. Mirsky SFC WG G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Updates: 8300 (if approved) W. Meng Updates: 8300 (if approved) W. Meng
Intended status: Standards Track ZTE Corporation Intended status: Standards Track ZTE Corporation
Expires: 1 October 2021 B. Khasnabish Expires: 26 November 2021 B. Khasnabish
C. Wang C. Wang
Individual contributor Individual contributor
30 March 2021 25 May 2021
Active OAM for Service Function Chaining Active OAM for Service Function Chaining
draft-ietf-sfc-multi-layer-oam-10 draft-ietf-sfc-multi-layer-oam-11
Abstract Abstract
A set of requirements for active Operation, Administration, and A set of requirements for active Operation, Administration, and
Maintenance (OAM) of Service Function Chains (SFCs) in a network is Maintenance (OAM) of Service Function Chains (SFCs) in a network is
presented in this document. Based on these requirements, an presented in this document. Based on these requirements, an
encapsulation of active OAM messages in SFC and a mechanism to detect encapsulation of active OAM messages in SFC and a mechanism to detect
and localize defects are described. and localize defects are described.
This document updates RFC 8300 in the definition of O (OAM) bit in This document updates RFC 8300. Particularly, it updates the
the Network Service Header (NSH) and defines how an active OAM definition of O (OAM) bit in the Network Service Header (NSH) and
message is identified in the NSH. defines how an active OAM message is identified in the NSH.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 October 2021. This Internet-Draft will expire on 26 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for Active OAM in SFC Network . . . . . . . . . 4 3. Requirements for Active OAM in SFC Network . . . . . . . . . 5
4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 6 4. Active OAM Identification in the NSH . . . . . . . . . . . . 7
5. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8 5. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8
5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Authentication in Echo Request/Reply . . . . . . . . . . 11 5.2. Authentication in Echo Request/Reply . . . . . . . . . . 11
5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 11 5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 11
5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 12 5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 12
5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 12 5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 13
5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 13 5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 13
5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 14 5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.7. Tracing an SFP . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 16
8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 16 8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 16
8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 16 8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 17
8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 16 8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 17
8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 17 8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 18
8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 19 8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 20
8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 19 8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 21
8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 20 8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
[RFC7665] defines components necessary to implement a Service [RFC7665] defines data plane elements necessary to implement a
Function Chain (SFC). These include: Service Function Chaining (SFC). These include:
1. Classifiers that perform the classification of incoming packets.
Such classification may result in associating a received packet
to a service function chain.
1. a classifier that performs the classification of incoming packets
2. Service Function Forwarders (SFFs) that are responsible for 2. Service Function Forwarders (SFFs) that are responsible for
forwarding traffic to one or more connected Service Functions forwarding traffic to one or more connected Service Functions
(SFs) according to the information carried in the SFC service (SFs) according to the information carried in the SFC
encapsulation and handling traffic coming back from the SF and encapsulation and handling traffic coming back from the SFs and
forwarding it to the next SFF. forwarding it to the next SFF.
3. SFs that are responsible for the executing specific service 3. SFs that are responsible for executing specific service treatment
treatment on received packets. on received packets.
There are different views from different levels of the SFC. One is There are different views from different levels of the SFC. One is
the SFC, an entirely abstract view, which defines an ordered set of the service function chain, an entirely abstract view, which defines
SFs that must be applied to packets selected based on classification an ordered set of SFs that must be applied to packets selected based
rules. But service function chain doesn't specify the exact mapping on classification rules. But service function chain doesn't specify
between SFFs and SFs. Thus, another logical construct used in SFC is the exact mapping between SFFs and SFs. Thus, another logical
a Service Function Path (SFP). According to [RFC7665], SFP is the construct used in SFC is a Service Function Path (SFP). According to
instantiation of the SFC in the network and provides a level of [RFC7665], SFP is the instantiation of the SFC in the network and
indirection between the entirely abstract SFCs and a fully specified provides a level of indirection between the entirely abstract SFCs
ordered list of SFFs and SFs identities that the packet will visit and a fully specified ordered list of SFFs and SFs identities that
when it traverses the SFC. The latter entity is referred to as the packet will visit when it traverses the SFC. The latter entity
Rendered Service Path (RSP). The main difference between SFP and RSP is referred to as Rendered Service Path (RSP). The main difference
is that the former is the logical construct, while the latter is the between SFP and RSP is that the former is the logical construct,
realization of the SFP via the sequence of specific SFC elements. while the latter is the realization of the SFP via the sequence of
specific SFC data plane elements.
This document defines how active Operation, Administration and This document defines how active Operation, Administration and
Maintenance (OAM), per [RFC7799] definition of active OAM, is Maintenance (OAM), per [RFC7799] definition of active OAM, is
identified in Network Service Header (NSH) SFC. Following the identified when Network Service Header (NSH) is used as the SFC
analysis of SFC OAM in [RFC8924], this document lists requirements to encapsulation. Following the analysis of SFC OAM in [RFC8924], this
improve troubleshooting efficiency and defect localization in SFP. document applies and, when necessary, extends requirements listed in
Section 4 of [RFC8924] for the use of active OAM in an SFP supporting
fault management and performance monitoring. Active OAM tools,
conformant to the requirements listed in Section 3, improve, for
example, troubleshooting efficiency and defect localization in SFP
because they specifically address architectural principles of NSH.
For that purpose, SFC Echo Request and Echo Reply are specified in For that purpose, SFC Echo Request and Echo Reply are specified in
the document. This mechanism enables on-demand Continuity Check, the document. This mechanism enables on-demand Continuity Check,
Connectivity Verification among other operations over SFC in Connectivity Verification among other operations over SFC in
networks, thus providing one of the most common SFC OAM functions networks, addresses functionalities discussed in Sections 4.1, 4.2,
identified in [RFC8924]. Also, this document updates Section 2.2 of and 4.3 of [RFC8924]. Also, this document updates Section 2.2 of
[RFC8300] in part of the definition of O bit in the (NSH). [RFC8300] in part of the definition of O bit in the (NSH).
2. Terminology and Conventions 2. Terminology and Conventions
The terminology defined in [RFC7665] is used extensively throughout The terminology defined in [RFC7665] is used extensively throughout
this document. A reader is expected to be familiar with it. this document. The reader is expected to be familiar with it.
In this document, SFC OAM refers to an active OAM, as defined in In this document, SFC OAM refers to an active OAM [RFC7799] in an SFC
[RFC7799]. in an SFC architecture. architecture.
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Acronyms 2.2. Acronyms
skipping to change at page 4, line 29 skipping to change at page 4, line 37
NSH: Network Service Header NSH: Network Service Header
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
PRNG: Pseudorandom number generator PRNG: Pseudorandom number generator
RDI: Remote Defect Indication RDI: Remote Defect Indication
RSP: Rendered Service Path RSP: Rendered Service Path
SMI Structure of Management Information
SF: Service Function SF: Service Function
SFC: Service Function Chain SFC: Service Function Chain
SFF: Service Function Forwarder SFF: Service Function Forwarder
SFP: Service Function Path SFP: Service Function Path
MAC: Message Authentication Code MAC: Message Authentication Code
3. Requirements for Active OAM in SFC Network 3. Requirements for Active OAM in SFC Network
As discussed in [RFC8924], SFC-specific means are needed to perform As discussed in [RFC8924], SFC-specific means are needed to perform
the OAM task of fault management (FM) in an SFC architecture, the OAM task of fault management (FM) in an SFC architecture,
including failure detection, defect characterization, and including failure detection, defect characterization, and
localization. This document defines the set of requirements for localization. This document defines the set of requirements for
active FM OAM mechanisms to be used in an SFC architecture. active FM OAM mechanisms to be used in an SFC architecture.
+---+ +---+ +---+ +---+ +---+ +---+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|SF1| |SF2| |SF3| |SF4| |SF5| |SF6| |SFI11| |SFI12| |SFI21| |SFI22| |SFI31| |SFI32|
+---+ +---+ +---+ +---+ +---+ +---+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\ / \ / \ / \ / \ / \ /
+----------+ +----+ +----+ +----+ +----------+ +----+ +----+ +----+
|Classifier|-------|SFF1|---------|SFF2|--------|SFF3| |Classifier|---|SFF1|---------|SFF2|----------|SFF3|
+----------+ +----+ +----+ +----+ +----------+ +----+ +----+ +----+
Figure 1: SFC Data Plane Reference Model Figure 1: An Example of SFC Data Plane
Regarding the reference model depicted in Figure 1, consider a Regarding the reference model depicted in Figure 1, consider a
service function chain that includes three distinct service service function chain that includes three distinct service
functions. In this example, the SFP traverses SFF1, SFF2, and SFF3, functions. In this example, the SFP traverses SFF1, SFF2, and SFF3,
each SFF being connected to two instances of the same service each SFF being connected to two instances of the same service
function. End-to-end (e2e) SFC OAM, in this example, has the function. End-to-end (E2E) SFC OAM has the Classifier as the
Classifier as the ingress of the SFC OAM domain, and SFF3 - as its ingress, and SFF3 - as its egress. Segment SFC OAM is between two
egress. Segment SFC OAM is always within the E2E SFC OAM domain elements that are part of the same SFP. Following are the
between two elements that are part of the same SFP. Following are requirements for an FM SFC OAM, whether with the E2E or segment
the requirements for an FM SFC OAM, whether with the E2E or segment
scope: scope:
REQ#1: Packets of active SFC OAM in SFC SHOULD be fate sharing REQ#1: Packets of active SFC OAM in SFC SHOULD be fate sharing
with the monitored SFC data, in the forward direction from ingress with the monitored SFC data, in the forward direction from ingress
toward egress endpoint(s) of the OAM test. toward egress endpoint(s) of the OAM test.
The fate sharing, in the SFC environment, is achieved when a test The fate sharing, in the SFC environment, is achieved when a test
packet traverses the same path and receives the same treatment in the packet traverses the same path and receives the same treatment in the
transport layer as an SFC NSH packet. transport layer as an SFC NSH packet.
skipping to change at page 6, line 19 skipping to change at page 6, line 33
changes from the detection of a defect to defect characterization and changes from the detection of a defect to defect characterization and
localization. localization.
REQ#5: SFC OAM MUST support fault localization of the Loss of REQ#5: SFC OAM MUST support fault localization of the Loss of
Continuity Check within an SFP. Continuity Check within an SFP.
REQ#6: SFC OAM MUST support an SFP tracing to discover the RSP. REQ#6: SFC OAM MUST support an SFP tracing to discover the RSP.
In the example presented in Figure 1, two distinct instances of the In the example presented in Figure 1, two distinct instances of the
same service function share the same SFF. In this example, the SFP same service function share the same SFF. In this example, the SFP
can be realized over several RSPs, for instance, RSP1(SF1--SF3--SF5) can be realized over several RSPs that use different instances of SF
and RSP2(SF2--SF4--SF6). Available RSPs can be discovered using the of the same type. For example, RSP1(SFI11--SFI21--SFI31) and
trace function discussed in Section 4.3 [RFC8924]. RSP2(SFI12--SFI22--SFI32). Available RSPs can be discovered using
the trace function discussed in Section 4.3 [RFC8924].
REQ#7: SFC OAM MUST have the ability to discover and exercise all REQ#7: SFC OAM MUST have the ability to discover and exercise all
available RSPs in the network. available RSPs in the network.
The SFC OAM layer model described in [RFC8924] offers an efficient The SFC OAM layer model described in [RFC8924] offers an approach for
approach for a defect localization within a service function chain. a defect localization within a service function chain. As the first
As the first step, the SFP's continuity for SFFs that are part of the step, the SFP's continuity for SFFs that are part of the same SFP
same SFP could be verified. After the reachability of SFFs has could be verified. After the reachability of SFFs has already been
already been verified, SFFs that serve an SF may be used as a test verified, SFFs that serve an SF may be used as a test packet source.
packet source. In such a case, SFF can act as a proxy for another In such a case, SFF can act as a proxy for another element within the
element within the service function chain. service function chain.
REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses
being directed towards the initiator of such proxy request. being directed towards the initiator of such proxy request.
4. Active OAM Identification in SFC NSH 4. Active OAM Identification in the NSH
The O bit in the NSH header is defined in [RFC8300] as follows: The O bit in the NSH is defined in [RFC8300] as follows:
O bit: Setting this bit indicates an OAM packet. O bit: Setting this bit indicates an OAM packet.
This document updates that definition as follows: This document updates that definition as follows:
O bit: Setting this bit indicates an OAM command and/or data in O bit: Setting this bit indicates an OAM command and/or data in
the NSH Context Header or packet payload. the NSH Context Header or packet payload.
Active SFC OAM is defined as a combination of OAM commands and/or Active SFC OAM is defined as a combination of OAM commands and/or
data included in a message that immediately follows the NSH. To data included in a message that immediately follows the NSH. To
identify the active OAM message, the Next Protocol field's value MUST identify the active OAM message, the Next Protocol field's value MUST
be set to Active SFC OAM (TBA1) (Section 8.1). The rules for be set to Active SFC OAM (TBA1) (Section 8.1). The rules for
interpreting the values of O bit and the Next Protocol field are as interpreting the values of the O bit and the Next Protocol field are
follows: as follows:
* O bit set and the Next Protocol value is not one of identifying * O bit set and the Next Protocol value is not one of identifying
active or hybrid OAM protocol (per [RFC7799] definitions), e.g., active or hybrid OAM protocol (per [RFC7799] definitions), e.g.,
defined in this specification Active SFC OAM: defined in this specification Active SFC OAM:
- a Fixed-Length Context Header or Variable-Length Context - a Fixed-Length Context Header or Variable-Length Context
Header(s) contain an OAM command or data. Header(s) contain an OAM command or data.
- the type of payload is determined by the Next Protocol field. - the type of payload is determined by the Next Protocol field.
* O bit set and the Next Protocol value is one of identifying active * O bit set and the Next Protocol value is one of identifying active
or hybrid OAM protocol: or hybrid OAM protocol:
- the payload that immediately follows SFC NSH MUST contain an - the payload that immediately follows the NSH MUST contain an
OAM command or data. OAM command or data.
* O bit is clear: * O bit is clear:
- no OAM in a Fixed-Length Context Header or Variable-Length - no OAM in a Fixed-Length Context Header or Variable-Length
Context Header(s). Context Header(s).
- the payload determined by the Next Protocol field's value - the payload determined by the Next Protocol field's value
MUST be present. MUST be present.
* O bit is clear and the Next Protocol field's value identifies * O bit is clear and the Next Protocol field's value identifies
active or hybrid OAM protocol MUST be identified and reported as active or hybrid OAM protocol MUST be identified and reported as
the erroneous combination. An implementation MAY have control to the erroneous combination. An implementation MAY have control to
enable processing of the OAM payload. enable processing of the OAM payload.
One conclusion from the above-listed rules of processing O bit and One conclusion from the above-listed rules of processing the O bit
the Next Protocol field's value is to avoid the combination of OAM in and the Next Protocol field's value is to avoid the combination of
an NSH Context Header (Fixed-Length or Variable-Length) and the OAM in an NSH Context Header (Fixed-Length or Variable-Length) and
payload immediately following the SFC NSH because there is no the payload immediately following the NSH because there is no
unambiguous way to identify such combination using the O bit and the unambiguous way to identify such combination using the O bit and the
Next Protocol field. Next Protocol field.
As demonstrated in Section 4 [RFC8924] and Section 3 of this As demonstrated in Section 4 [RFC8924] and Section 3 of this
document, SFC OAM is required to perform multiple tasks. Several document, SFC OAM is required to perform multiple tasks. Several
active OAM protocols could be used to address all the requirements. active OAM protocols could be used to address all the requirements.
When IP/UDP encapsulation of an SFC OAM control message is used, When IP/UDP encapsulation of an SFC OAM control message is used,
protocols can be demultiplexed using the Destination UDP port number. protocols can be demultiplexed using the Destination UDP port number.
But extra IP/UDP headers, especially in an IPv6 network, add But extra IP/UDP headers, especially in an IPv6 network, add
noticeable overhead. This document defines Active OAM Header noticeable overhead. This document defines Active OAM Header
skipping to change at page 11, line 34 skipping to change at page 11, line 41
been defined to protect the integrity of the NSH and the payload. been defined to protect the integrity of the NSH and the payload.
The header can also be used for the optional encryption of the The header can also be used for the optional encryption of the
sensitive metadata. MAC#1 Context Header is more suitable for the sensitive metadata. MAC#1 Context Header is more suitable for the
integrity protection of active SFC OAM, particularly of the defined integrity protection of active SFC OAM, particularly of the defined
in this document SFC Echo Request and Echo Reply. On the other hand, in this document SFC Echo Request and Echo Reply. On the other hand,
using MAC#2 Context Header allows the detection of mishandling of the using MAC#2 Context Header allows the detection of mishandling of the
O-bit by a transient SFC element. O-bit by a transient SFC element.
5.3. SFC Echo Request Transmission 5.3. SFC Echo Request Transmission
SFC Echo Request control packet MUST use the appropriate SFC Echo Request control packet MUST use the appropriate transport
encapsulation of the monitored SFP. If the NSH is used, Echo Request encapsulation of the monitored SFP. If the NSH is used, Echo Request
MUST set O bit, as defined in [RFC8300]. SFC NSH MUST be immediately MUST set O bit, as defined in [RFC8300]. NSH MUST be immediately
followed by the SFC Active OAM Header defined in Section 4. The followed by the SFC Active OAM Header defined in Section 4. The
Message Type field's value in the SFC Active OAM Header MUST be set Message Type field's value in the SFC Active OAM Header MUST be set
to SFC Echo Request/Echo Reply value (TBA2) per Section 8.2. to SFC Echo Request/Echo Reply value (TBA2) per Section 8.2.
Value of the Reply Mode field MAY be set to: Value of the Reply Mode field MAY be set to:
* Do Not Reply (TBA5) if one-way monitoring is desired. If the Echo * Do Not Reply (TBA5) if one-way monitoring is desired. If the Echo
Request is used to measure synthetic packet loss; the receiver may Request is used to measure synthetic packet loss; the receiver may
report loss measurement results to a remote node. report loss measurement results to a remote node. Note that ways
of learning the identy of that node is otside the scope of this
specification.
* Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the * Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the
most used. most used.
* Reply via Application Level Control Channel (TBA7) value if the * Reply via Application Level Control Channel (TBA7) value if the
SFP may have bi-directional paths. SFP may have bi-directional paths.
* Reply via Specified Path (TBA8) value to enforce the use of the * Reply via Specified Path (TBA8) value to enforce the use of the
particular return path specified in the included TLV to verify bi- particular return path specified in the included TLV to verify bi-
directional continuity and also increase the robustness of the directional continuity and also increase the robustness of the
monitoring by selecting a more stable path. monitoring by selecting a more stable path.
5.4. SFC Echo Request Reception 5.4. SFC Echo Request Reception
Sending an SFC Echo Request to the control plane is triggered by one Sending an SFC Echo Request to the control plane is triggered by one
of the following packet processing exceptions: NSH TTL expiration, of the following packet processing exceptions: NSH TTL expiration,
NSH Service Index (SI) expiration or the receiver is the terminal SFF NSH Service Index (SI) expiration, or the receiver is the terminal
for an SFP. SFF for an SFP.
Firstly, if the SFC Echo Request is authenticated, the receiving SFF Firstly, if the SFC Echo Request is authenticated, the receiving SFF
MUST verify the authentication. If the verification fails, the MUST verify the authentication. If the verification fails, the
receiver SFF MUST send an SFC Echo Reply with the Return Code set to receiver SFF MUST send an SFC Echo Reply with the Return Code set to
"Authentication failed" and the Subcode set to zero. Then, the SFF "Authentication failed" and the Subcode set to zero. Then, the SFF
that has received an SFC Echo Request verifies the received packet's that has received an SFC Echo Request verifies the received packet's
general sanity. If the packet is not well-formed, the receiver SFF general sanity. If the packet is not well-formed, the receiver SFF
SHOULD send an SFC Echo Reply with the Return Code set to "Malformed SHOULD send an SFC Echo Reply with the Return Code set to "Malformed
Echo Request received" and the Subcode set to zero. If there are any Echo Request received" and the Subcode set to zero. If there are any
TLVs that SFF does not understand, the SFF MUST send an SFC Echo TLVs that SFF does not understand, the SFF MUST send an SFC Echo
Reply with the Return Code set to 2 ("One or more TLVs was not Reply with the Return Code set to 2 ("One or more TLVs was not
understood") and set the Subcode to zero. In the latter case, the understood") and set the Subcode to zero. In the latter case, the
SFF MAY include an Errored TLVs TLV (Section 5.4.1) that as sub-TLVs SFF MAY include an Errored TLVs TLV (Section 5.4.1) that, as sub-
contains only the misunderstood TLVs. The header field's Sender's TLVs, contains only the misunderstood TLVs. The header field's
Handle, Sequence Number are not examined but are included in the SFC Sender's Handle, Sequence Number are not examined but are included in
Echo Reply message. the SFC Echo Reply message. If the sanity check of the received Echo
Request succeeded, then the SFF at the end of the SFP MUST set the
Return Code value to 5 ("End of the SFP") and the Subcode set to
zero. If the SFF is not at theend of the SFP and the TTL value is 1,
the value of the Return Code MUST be set to 4 ("TTL Exceeded") and
the Subcode set to zero.
5.4.1. Errored TLVs TLV 5.4.1. Errored TLVs TLV
If the Return Code for the Echo Reply is determined as 2 ("One or If the Return Code for the Echo Reply is determined as 2 ("One or
more TLVs was not understood"), then the Errored TLVs TLV MAY be more TLVs was not understood"), then the Errored TLVs TLV MAY be
included in an Echo Reply. The use of this TLV allows informing the included in an Echo Reply. The use of this TLV allows informing the
sender of an Echo Request of mandatory TLVs either not supported by sender of an Echo Request of mandatory TLVs either not supported by
an implementation or parsed and found to be in error. an implementation or parsed and found to be in error.
0 1 2 3 0 1 2 3
skipping to change at page 13, line 30 skipping to change at page 13, line 51
The Reply Mode field directs whether and how the Echo Reply message The Reply Mode field directs whether and how the Echo Reply message
should be sent. The sender of the Echo Request MAY use TLVs to should be sent. The sender of the Echo Request MAY use TLVs to
request that the corresponding Echo Reply is transmitted over the request that the corresponding Echo Reply is transmitted over the
specified path. Value TBA3 is referred to as the "Do not reply" mode specified path. Value TBA3 is referred to as the "Do not reply" mode
and suppresses the Echo Reply packet transmission. The default value and suppresses the Echo Reply packet transmission. The default value
(TBA6) for the Reply mode field requests the responder to send the (TBA6) for the Reply mode field requests the responder to send the
Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet. Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet.
Responder to the SFC Echo Request sends the Echo Reply over IP Responder to the SFC Echo Request sends the Echo Reply over IP
network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet. network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet.
Because SFC NSH does not identify the ingress of the SFP, the Echo Because the NSH does not identify the ingress node that generated the
Request, the source ID MUST be included in the message and used as Echo Request, the source ID MUST be included in the message and used
the IP destination address for IP/UDP encapsulation of the SFC Echo as the IP destination address for IP/UDP encapsulation of the SFC
Reply. The sender of the SFC Echo Request MUST include SFC Source Echo Reply. The sender of the SFC Echo Request MUST include SFC
TLV Figure 6. Source TLV Figure 6.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | Reserved | Length | | Source ID | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SFC Source TLV Figure 6: SFC Source TLV
skipping to change at page 14, line 27 skipping to change at page 14, line 46
An SFF SHOULD NOT accept SFC Echo Reply unless the received passes An SFF SHOULD NOT accept SFC Echo Reply unless the received passes
the following checks: the following checks:
* the received SFC Echo Reply is well-formed; * the received SFC Echo Reply is well-formed;
* it has an outstanding SFC Echo Request sent from the UDP port that * it has an outstanding SFC Echo Request sent from the UDP port that
matches destination UDP port number of the received packet; matches destination UDP port number of the received packet;
* if the matching to the Echo Request found, the value of the * if the matching to the Echo Request found, the value of the
Sender's Handle n the Echo Request sent is equal to the value of Sender's Handle in the Echo Request sent is equal to the value of
Sender's Handle in the Echo Reply received; Sender's Handle in the Echo Reply received;
* if all checks passed, the SFF checks if the Sequence Number in the * if all checks passed, the SFF checks if the Sequence Number in the
Echo Request sent matches to the Sequence Number in the Echo Reply Echo Request sent matches to the Sequence Number in the Echo Reply
received. received.
5.7. Tracing an SFP
SFP Echo Request/Reply can be used to isolate a defect detected in
the SFP and trace an RSP. As for ICMP echo request/reply [RFC0792]
and MPLS echo request/reply [RFC8029], this mode is referred to as
"traceroute". In the traceroute mode, the sender transmits a
sequence of SFP Echo Request messages starting with the NSH TTL value
set to 1 and is incremented by 1 in each next Echo Request packet.
The sender stops transmitting SFP Echo Request packets when the
Return Code in the received Echo Reply equals 5 ("End of the SFP").
To trace a particular RSP, the sender may use NSH MD Type 2 Flow ID
TLV [I-D.ietf-sfc-nsh-tlv]. The value of the Flow ID field of the
SFP Echo Request packet MUST be set to the same value as of the
monitored flow.
6. Security Considerations 6. Security Considerations
When the integrity protection for SFC active OAM, and SFC Echo When the integrity protection for SFC active OAM, and SFC Echo
Request/Reply in particular, is required, it is RECOMMENDED to use Request/Reply in particular, is required, it is RECOMMENDED to use
one of Context Headers defined in [I-D.ietf-sfc-nsh-integrity]. one of Context Headers defined in [I-D.ietf-sfc-nsh-integrity].
MAC#1 (Message Authentication Code) Context Header could be more MAC#1 (Message Authentication Code) Context Header could be more
suitable for active SFC OAM because it does not require re- suitable for active SFC OAM because it does not require re-
calculation of the MAC when the value of the NSH Base Header's TTL calculation of the MAC when the value of the NSH Base Header's TTL
field is changed. The integrity protection for SFC active OAM can field is changed. The integrity protection for SFC active OAM can
also be achieved using mechanisms in the underlay data plane. For also be achieved using mechanisms in the underlay data plane. For
skipping to change at page 19, line 40 skipping to change at page 20, line 40
+=======+=================================+===============+ +=======+=================================+===============+
| 0 | No Return Code | This document | | 0 | No Return Code | This document |
+-------+---------------------------------+---------------+ +-------+---------------------------------+---------------+
| 1 | Malformed Echo Request received | This document | | 1 | Malformed Echo Request received | This document |
+-------+---------------------------------+---------------+ +-------+---------------------------------+---------------+
| 2 | One or more of the TLVs was not | This document | | 2 | One or more of the TLVs was not | This document |
| | understood | | | | understood | |
+-------+---------------------------------+---------------+ +-------+---------------------------------+---------------+
| 3 | Authentication failed | This document | | 3 | Authentication failed | This document |
+-------+---------------------------------+---------------+ +-------+---------------------------------+---------------+
| 4 | TTL Exceeded | This document |
+-------+---------------------------------+---------------+
| 5 | End of the SFP | This document |
+-------+---------------------------------+---------------+
Table 10: SFC Echo Return Codes Values Table 10: SFC Echo Return Codes Values
8.7. SFC TLV Type 8.7. SFC TLV Type
IANA is requested to create the SFC OAM TLV Type registry. All code IANA is requested to create the SFC OAM TLV Type registry. All code
points in the range 1 through 175 in this registry shall be allocated points in the range 1 through 175 in this registry shall be allocated
according to the "IETF Review" procedure specified in [RFC8126]. according to the "IETF Review" procedure specified in [RFC8126].
Code points in the range 176 through 239 in this registry shall be Code points in the range 176 through 239 in this registry shall be
allocated according to the "First Come First Served" procedure allocated according to the "First Come First Served" procedure
skipping to change at page 21, line 30 skipping to change at page 22, line 41
9.2. Informative References 9.2. Informative References
[I-D.ietf-sfc-nsh-integrity] [I-D.ietf-sfc-nsh-integrity]
Boucadair, M., Reddy, T., and D. Wing, "Integrity Boucadair, M., Reddy, T., and D. Wing, "Integrity
Protection for the Network Service Header (NSH) and Protection for the Network Service Header (NSH) and
Encryption of Sensitive Context Headers", Work in Encryption of Sensitive Context Headers", Work in
Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05, Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05,
23 March 2021, <https://tools.ietf.org/html/draft-ietf- 23 March 2021, <https://tools.ietf.org/html/draft-ietf-
sfc-nsh-integrity-05>. sfc-nsh-integrity-05>.
[I-D.ietf-sfc-nsh-tlv]
Wei, Y. (., Elzur, U., Majee, S., and C. Pignataro,
"Network Service Header Metadata Type 2 Variable-Length
Context Headers", Work in Progress, Internet-Draft, draft-
ietf-sfc-nsh-tlv-06, 12 May 2021,
<https://tools.ietf.org/html/draft-ietf-sfc-nsh-tlv-06>.
[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>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
 End of changes. 41 change blocks. 
102 lines changed or deleted 144 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/