< draft-ietf-sfc-multi-layer-oam-08.txt | draft-ietf-sfc-multi-layer-oam-09.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: July 23, 2021 B. Khasnabish | Expires: August 15, 2021 B. Khasnabish | |||
C. Wang | C. Wang | |||
Individual contributor | Individual contributor | |||
January 19, 2021 | February 11, 2021 | |||
Active OAM for Service Function Chains in Networks | Active OAM for Service Function Chaining | |||
draft-ietf-sfc-multi-layer-oam-08 | draft-ietf-sfc-multi-layer-oam-09 | |||
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 networks is | Maintenance (OAM) of Service Function Chains (SFCs) in a network is | |||
presented. Based on these requirements, an encapsulation of active | presented in this document. Based on these requirements, an | |||
OAM message in SFC and a mechanism to detect and localize defects | encapsulation of active OAM messages in SFC and a mechanism to detect | |||
described. Also, this document updates RFC 8300 in the definition of | and localize defects are described. | |||
O (OAM) bit in the Network Service Header (NSH) and defines how the | ||||
active OAM message is identified in SFC NSH. | This document updates RFC 8300 in the definition of O (OAM) bit in | |||
the Network Service Header (NSH) and 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 July 23, 2021. | This Internet-Draft will expire on August 15, 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 | 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 | |||
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Requirements for Active OAM in SFC Network . . . . . . . . . 4 | 3. Requirements for Active OAM in SFC Network . . . . . . . . . 4 | |||
4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 5 | 4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 6 | |||
5. Echo Request/Echo Reply for SFC in Networks . . . . . . . . . 7 | 5. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8 | |||
5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 9 | 5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 10 | |||
5.2. Authentication in Echo Request/Reply . . . . . . . . . . 9 | 5.2. Authentication in Echo Request/Reply . . . . . . . . . . 11 | |||
5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 9 | 5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 11 | |||
5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 10 | 5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 12 | |||
5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 10 | 5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 12 | |||
5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 11 | 5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 13 | |||
5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 12 | 5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 14 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 14 | 8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 15 | |||
8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 14 | 8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 15 | |||
8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 15 | 8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 16 | |||
8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 15 | 8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 16 | |||
8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 15 | 8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 17 | |||
8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 16 | 8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 18 | |||
8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 17 | 8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 19 | |||
8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 18 | 8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 20 | |||
8.9. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 18 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 | 9.2. Informative References . . . . . . . . . . . . . . . . . 20 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 19 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
1. Introduction | 1. Introduction | |||
[RFC7665] defines components necessary to implement a Service | [RFC7665] defines components necessary to implement a Service | |||
Function Chain (SFC). These include a classifier that performs the | Function Chain (SFC). These include: | |||
classification of incoming packets. A Service Function Forwarder | ||||
(SFF) is responsible for forwarding traffic to one or more connected | ||||
Service Functions (SFs) according to the information carried in the | ||||
SFC encapsulation. SFF also handles traffic coming back from the SF | ||||
and transports the data packets to the next SFF. And the SFF serves | ||||
as a termination element of the Service Function Path (SFP). SF is | ||||
responsible for the specific treatment of received packets. | ||||
Resulting from that SFC is constructed by a number of these | 1. a classifier that performs the classification of incoming packets | |||
components, there are different views from different levels of the | 2. Service Function Forwarders (SFFs) that are responsible for | |||
SFC. One is the SFC, an entirely abstract entity, which defines an | forwarding traffic to one or more connected Service Functions | |||
ordered set of SFs that must be applied to packets selected due to | (SFs) according to the information carried in the SFC service | |||
classification. But SFC doesn't specify the exact mapping between | encapsulation and handling traffic coming back from the SF and | |||
SFFs and SFs. Thus there exists another semi-abstract entity | forwarding it to the next SFF. | |||
referred to as SFP. SFP is the instantiation of the SFC in the | ||||
network and provides a level of indirection between the entirely | 3. SFs that are responsible for the executing specific service | |||
abstract SFC and a fully specified ordered list of SFFs and SFs | treatment on received packets. | |||
identities that the packet will visit when it traverses the SFC. The | ||||
latter entity is being referred to as Rendered Service Path (RSP). | There are different views from different levels of the SFC. One is | |||
The main difference between SFP and RSP is that in the former the | the SFC, an entirely abstract view, which defines an ordered set of | |||
authority to select the SFF/SF has been delegated to the network. | SFs that must be applied to packets selected based on classification | |||
rules. But service function chain doesn't specify the exact mapping | ||||
between SFFs and SFs. Thus, another logical construct used in SFC is | ||||
a Service Function Path (SFP). According to [RFC7665], SFP is the | ||||
instantiation of the SFC in the network and provides a level of | ||||
indirection between the entirely abstract SFCs and a fully specified | ||||
ordered list of SFFs and SFs identities that the packet will visit | ||||
when it traverses the SFC. The latter entity is referred to as | ||||
Rendered Service Path (RSP). The main difference between SFP and RSP | ||||
is that the former is the logical construct, while the latter is the | ||||
realization of the SFP via the sequence of specific SFC 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, identified | Maintenance (OAM), per [RFC7799] definition of active OAM, is | |||
in Network Service Header (NSH) SFC. The document lists requirements | identified in Network Service Header (NSH) SFC. Following the | |||
to improve troubleshooting efficiency. It defines SFC Echo Request | analysis of SFC OAM in [RFC8924], this document lists requirements to | |||
and Echo reply that enables on-demand Continuity Check, Connectivity | improve troubleshooting efficiency and defect localization in SFP. | |||
Verification among other operations over SFC in networks addressing | For that purpose, SFC Echo Request and Echo Reply are specified in | |||
essential SFC OAM functions identified in [RFC8924]. Also, this | the document. This mechanism enables on-demand Continuity Check, | |||
document updates Section 2.2 of [RFC8300] in part of the definition | Connectivity Verification among other operations over SFC in | |||
of O bit in the (NSH). | networks, thus providing one of the most common SFC OAM functions | |||
identified in [RFC8924]. Also, this document updates Section 2.2 of | ||||
[RFC8300] in part of the definition of O bit in the (NSH). | ||||
2. Conventions | 2. Terminology and Conventions | |||
The terminology defined in [RFC7665] is used extensively throughout | ||||
this document. A reader is expected to be familiar with it. | ||||
In this document, SFC OAM refers to an active OAM, as defined in | ||||
[RFC7799]. in an SFC 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 | |||
Unless explicitly specified in this document, active OAM in SFC and | E2E: End-to-End | |||
SFC OAM are being used interchangeably. | ||||
e2e: End-to-End | ||||
FM: Fault Management | FM: Fault Management | |||
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 | SMI Structure of Management Information | |||
skipping to change at page 4, line 26 ¶ | skipping to change at page 4, line 37 ¶ | |||
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 | |||
To perform the OAM task of fault management (FM) in an SFC, that | As discussed in [RFC8924], SFC-specific means are needed to perform | |||
includes failure detection, defect characterization and localization, | the OAM task of fault management (FM) in an SFC architecture, | |||
this document defines the set of requirements for active OAM | including failure detection, defect characterization, and | |||
mechanisms to be used on an SFC. | localization. This document defines the set of requirements for | |||
active FM OAM mechanisms to be used in an SFC architecture. | ||||
+---+ +---+ +---+ +---+ +---+ +---+ | +---+ +---+ +---+ +---+ +---+ +---+ | |||
|SF1| |SF2| |SF3| |SF4| |SF5| |SF6| | |SF1| |SF2| |SF3| |SF4| |SF5| |SF6| | |||
+---+ +---+ +---+ +---+ +---+ +---+ | +---+ +---+ +---+ +---+ +---+ +---+ | |||
\ / \ / \ / | \ / \ / \ / | |||
+----------+ +----+ +----+ +----+ | +----------+ +----+ +----+ +----+ | |||
|Classifier|-------|SFF1|---------|SFF2|--------|SFF3| | |Classifier|-------|SFF1|---------|SFF2|--------|SFF3| | |||
+----------+ +----+ +----+ +----+ | +----------+ +----+ +----+ +----+ | |||
Figure 1: SFC reference model | Figure 1: SFC Data Plane Reference Model | |||
In the example presented in Figure 1, the service SFP1 may be | Regarding the reference model depicted in Figure 1, consider a | |||
realized through two independent RSPs, RSP1(SF1--SF3--SF5) and | service function chain that includes three distinct service | |||
RSP2(SF2--SF4--SF5). To perform end-to-end (e2e) FM SFC OAM: | functions. In this example, the SFP traverses SFF1, SFF2, and SFF3, | |||
each SFF being connected to two instances of the same service | ||||
function. End-to-end (e2e) SFC OAM, in this example, has the | ||||
Classifier as the ingress of the SFC OAM domain, and SFF3 - as its | ||||
egress. Segment SFC OAM is always within the E2E SFC OAM domain | ||||
between two elements that are part of the same SFP. Following are | ||||
the requirements for an FM SFC OAM, whether with the E2E or segment | ||||
scope: | ||||
REQ#1: Packets of active OAM in SFC SHOULD be fate sharing with | REQ#1: Packets of active SFC OAM in SFC SHOULD be fate sharing | |||
data traffic, i.e., in-band with the monitored traffic follow the | with the monitored SFC data, in the forward direction from ingress | |||
same RSP, in the forward direction from ingress toward egress | toward egress endpoint(s) of the OAM test. | |||
endpoint(s) of the OAM test. | ||||
REQ#2: SFC OAM MUST support pro-active monitoring of any element | The fate sharing, in the SFC environment, is achieved when a test | |||
in the SFC availability. | packet traverses the same path and receives the same treatment in the | |||
transport layer as an SFC NSH packet. | ||||
The egress, SFF3, in the example in Figure 1, is the entity that | REQ#2: SFC OAM MUST support pro-active monitoring of the | |||
detects the failure of the SFC. It must be able to signal the new | continuity of the SFP between any of its elements. | |||
defect state to the ingress SFF1. Hence the following requirement: | ||||
A network failure might be declared when several consecutive test | ||||
packets are not received within a pre-determined time. For example, | ||||
in the E2E SFC OAM FM case, the egress, SFF3, in the example in | ||||
Figure 1, could be the entity that detects the SFP's failure by | ||||
monitoring a flow of periodic test packets. The ingress may be | ||||
capable of recovering from the failure, e.g., using redundant SFC | ||||
elements. Thus, it is beneficial for the egress to signal the new | ||||
defect state to the ingress, which in this example is the Classifier. | ||||
Hence the following requirement: | ||||
REQ#3: SFC OAM MUST support Remote Defect Indication (RDI) | REQ#3: SFC OAM MUST support Remote Defect Indication (RDI) | |||
notification by the egress to the ingress. | notification by the egress to the ingress. | |||
REQ#4: SFC OAM MUST support connectivity verification. Definition | REQ#4: SFC OAM MUST support connectivity verification of the SFP. | |||
of the misconnection defect, entry and exit criteria are outside | Definition of the misconnection defect, entry and exit criteria | |||
the scope of this document. | are outside the scope of this document. | |||
Once the SFF1 detects the defect objective of OAM switches from | Once the SFF1 detects the defect, the objective of the SFC OAM | |||
failure detection to defect characterization and localization. | changes from the detection of a defect to defect characterization and | |||
localization. | ||||
REQ#5: SFC OAM MUST support fault localization of Loss of | REQ#5: SFC OAM MUST support fault localization of the Loss of | |||
Continuity check in the SFC. | Continuity Check within an SFP. | |||
REQ#6: SFC OAM MUST support tracing an SFP to realize the RSP. | REQ#6: SFC OAM MUST support an SFP tracing to discover the RSP. | |||
It is practical, as presented in Figure 1, that several SFs share the | In the example presented in Figure 1, two distinct instances of the | |||
same SFF. In such a case, SFP1 may be realized over two RSPs, | same service function share the same SFF. In this example, the SFP | |||
RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6). | can be realized over several RSPs, for instance, RSP1(SF1--SF3--SF5) | |||
and RSP2(SF2--SF4--SF6). 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 transport network. | available RSPs in the network. | |||
In the process of localizing the SFC failure, separating SFC OAM | The SFC OAM layer model described in [RFC8924] offers an efficient | |||
layers is an efficient approach. To achieve that continuity among | approach for a defect localization within a service function chain. | |||
SFFs that are part of the same SFP should be verified. Once SFFs | As the first step, the SFP's continuity for SFFs that are part of the | |||
reachability along the particular SFP has been confirmed, the task of | same SFP could be verified. After the reachability of SFFs has | |||
defect localization may focus on SF reachability verification. | already been verified, SFFs that serve an SF may be used as a test | |||
Because reachability of SFFs has already verified, SFF local to the | packet source. In such a case, SFF can act as a proxy for another | |||
SF may be used as a source of the test packets. | element within the 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 SFC NSH | |||
The interpretation of the O bit flag in the NSH header is defined in | The O bit in the NSH header is defined in [RFC8300] as follows: | |||
[RFC8300] as: | ||||
O bit: Setting this bit indicates an OAM packet. | O bit: Setting this bit indicates an OAM packet. | |||
This document updates the definition of O bit 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 value on the Next Protocol field | identify the active OAM message, the Next Protocol field's value MUST | |||
MUST be set to Active SFC OAM (TBA1) according to Section 8.1. The | be set to Active SFC OAM (TBA1) (Section 8.1). The rules for | |||
rules of interpreting the values of O bit and the Next Protocol field | interpreting the values of O bit and the Next Protocol field are as | |||
are as follows: | follows: | |||
o O bit set, and the Next Protocol value is not one of identifying | o 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 - a Fixed-Length | defined in this specification Active SFC OAM: | |||
Context Header or Variable-Length Context Header(s) contain OAM | ||||
command or data. and the type of payload determined by the Next | ||||
Protocol field; | ||||
o O bit set, and the Next Protocol value is one of identifying | - a Fixed-Length Context Header or Variable-Length Context | |||
active or hybrid OAM protocol - the payload that immediately | Header(s) contain an OAM command or data. | |||
follows SFC NSH contains OAM command or data; | ||||
o O bit is clear - no OAM in a Fixed-Length Context Header or | - the type of payload is determined by the Next Protocol field. | |||
Variable-Length Context Header(s) and the payload determined by | ||||
the value of the Next Protocol field; | ||||
o O bit is clear and the Next Protocol value is one of identifying | o O bit set and the Next Protocol value is one of identifying active | |||
or hybrid OAM protocol: | ||||
- the payload that immediately follows SFC NSH MUST contain an | ||||
OAM command or data. | ||||
o O bit is clear: | ||||
- no OAM in a Fixed-Length Context Header or Variable-Length | ||||
Context Header(s). | ||||
- the payload determined by the Next Protocol field's value | ||||
MUST be present. | ||||
o 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. | |||
From the above-listed rules follows the recommendation to avoid | One conclusion from the above-listed rules of processing O bit and | |||
combination of OAM in a Fixed-Length Context Header or Variable- | the Next Protocol field's value is to avoid the combination of OAM in | |||
Length Context Header(s) and in the payload immediately following the | an NSH Context Header (Fixed-Length or Variable-Length) and the | |||
SFC NSH because there is no unambiguous way to identify such | payload immediately following the SFC NSH because there is no | |||
combination using the O bit and the Next Protocol field. | unambiguous way to identify such combination using the O bit and the | |||
Next Protocol field. | ||||
Several active OAM protocols will be needed to address all the | As demonstrated in Section 4 [RFC8924] and Section 3 of this | |||
requirements listed in Section 3. Destination UDP port number may | document, SFC OAM is required to perform multiple tasks. Several | |||
identify protocols if IP/UDP encapsulation is used. But extra IP/UDP | active OAM protocols could be used to address all the requirements. | |||
headers, especially in the case of IPv6, add noticeable overhead. | When IP/UDP encapsulation of an SFC OAM control message is used, | |||
This document defines Active OAM Header Figure 2 to demultiplex | protocols can be demultiplexed using the Destination UDP port number. | |||
active OAM protocols on an SFC. | But extra IP/UDP headers, especially in an IPv6 network, add | |||
noticeable overhead. This document defines Active OAM Header | ||||
(Figure 2) to demultiplex active OAM protocols on an SFC. | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| V | Msg Type | Flags | Length | | | V | Msg Type | Flags | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ SFC Active OAM Control Packet ~ | ~ SFC Active OAM Control Packet ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: SFC Active OAM Header | Figure 2: SFC Active OAM Header | |||
skipping to change at page 7, line 28 ¶ | skipping to change at page 8, line 28 ¶ | |||
Msg Type - six bits long field identifies OAM protocol, e.g., Echo | Msg Type - six bits long field identifies OAM protocol, e.g., Echo | |||
Request/Reply or Bidirectional Forwarding Detection. | Request/Reply or Bidirectional Forwarding Detection. | |||
Flags - eight bits long field carries bit flags that define | Flags - eight bits long field carries bit flags that define | |||
optional capability and thus processing of the SFC active OAM | optional capability and thus processing of the SFC active OAM | |||
control packet, e.g., optional timestamping. | control packet, e.g., optional timestamping. | |||
Length - two octets long field that is the length of the SFC | Length - two octets long field that is the length of the SFC | |||
active OAM control packet in octets. | active OAM control packet in octets. | |||
5. Echo Request/Echo Reply for SFC in Networks | 5. Echo Request/Echo Reply for SFC | |||
Echo Request/Reply is a well-known active OAM mechanism that is | Echo Request/Reply is a well-known active OAM mechanism that is | |||
extensively used to detect inconsistencies between a state in control | extensively used to verify a path's continuity, detect | |||
and the data planes, localize defects in the data plane. The format | inconsistencies between a state in control and the data planes, and | |||
of the Echo request/Echo reply control packet is to support ping and | localize defects in the data plane. ICMP ([RFC0792] for IPv4 and | |||
traceroute functionality in SFC in networks Figure 3 resembles the | [RFC4443] for IPv6 networks respectively) and [RFC8029] are examples | |||
format of MPLS LSP Ping [RFC8029] with some exceptions. | of broadly used active OAM protocols based on Echo Request/Reply | |||
principle. The SFC NSH Echo Request/Reply control message format is | ||||
presented in Figure 3. | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| V | Reserved | Global Flags | | | V | Reserved | Global Flags | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Message Type | Reply mode | Return Code | Return S.code | | | Message Type | Reply mode | Return Code |Return Subcode | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Sender's Handle | | | Sender's Handle | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Sequence Number | | | Sequence Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ TLVs ~ | ~ TLVs ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 3: SFC Echo Request/Reply Format | Figure 3: SFC Echo Request/Reply Format | |||
The interpretation of the fields is as follows: | The interpretation of the fields is as follows: | |||
Version (V) is a two-bit-long field indicates the current version | Version (V) is a two-bit field that indicates the current version | |||
of the SFC Echo Request/Reply. The current value is 0. The | of the SFC Echo Request/Reply. The current value is 0. The | |||
version number is to be incremented whenever a change is made that | version number is to be incremented whenever a change is made that | |||
affects the ability of an implementation to parse or process | affects the ability of an implementation to parse or process | |||
control packet correctly. | control packet correctly. | |||
Reserved - fourteen-bit-long field. It MUST be zeroed on | Reserved - fourteen-bit field. It MUST be zeroed on transmission | |||
transmission and ignored on receipt. | and ignored on receipt. | |||
The Global Flags is a bit vector field. | The Global Flags is a two-octet bit vector field. | |||
The Message Type field reflects the type of the packet. Value | The Message Type is a one-octet field that reflects the packet | |||
TBA3 identifies Echo Request and TBA4 - Echo Reply | type. Value TBA3 identifies Echo Request and TBA4 - Echo Reply. | |||
The Reply Mode defines the type of the return path requested by | The Reply Mode is a one-octet field. It defines the type of the | |||
the sender of the Echo Request. | return path requested by the sender of the Echo Request. | |||
Return Codes and Subcodes can be used to inform the sender about | Return Codes and Subcodes are one-octet fields each. These can be | |||
the result of processing its request. | used to inform the sender about the result of processing its | |||
request. Initial Return Code values are according to Table 1. | ||||
For all Return Code values defined in this document, the value of | ||||
the Return Subcode field MUST be set to zero. | ||||
The Sender's Handle is filled in by the sender and returned | The Sender's Handle is a four-octet field. It is filled in by the | |||
unchanged by the Echo Reply receiver. The sender MAY use a | sender of the Echo Request and returned unchanged by the Echo | |||
pseudo-random number generator (PRNG) to set the value of the | Reply sender. The sender of the Echo Request MAY use a pseudo- | |||
Sender's Handle field. The value of the Sender's Handle field | random number generator (PRNG) to set the value of the Sender's | |||
SHOULD NOT be changed in the course of the test session. | Handle field. | |||
The Sequence Number is assigned by the sender and can be (for | The Sequence Number is a four-octet field. It is assigned by the | |||
example) used to detect missed replies. The value of the Sequence | sender and can be (for example) used to detect missed replies. | |||
Number field SHOULD be monotonically increasing in the course of | The value of the Sequence Number field SHOULD be monotonically | |||
the test session. | increasing in the course of the test session. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Reserved | Length | | | Type | Reserved | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ Value ~ | ~ Value ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 4: SFC Echo Request/Reply TLV Format | Figure 4: SFC Echo Request/Reply TLV Format | |||
skipping to change at page 9, line 9 ¶ | skipping to change at page 10, line 30 ¶ | |||
TLV is a variable-length field. Multiple TLVs MAY be placed in an | TLV is a variable-length field. Multiple TLVs MAY be placed in an | |||
SFC Echo Request/Reply packet. Additional TLVs may be enclosed | SFC Echo Request/Reply packet. Additional TLVs may be enclosed | |||
within a given TLV, subject to the semantics of the (outer) TLV in | within a given TLV, subject to the semantics of the (outer) TLV in | |||
question. If more than one TLV is to be included, the value of the | question. If more than one TLV is to be included, the value of the | |||
Type field of the outmost outer TLV MUST be set to Multiple TLVs Used | Type field of the outmost outer TLV MUST be set to Multiple TLVs Used | |||
(TBA12), as assigned by IANA according to Section 8.7. Figure 4 | (TBA12), as assigned by IANA according to Section 8.7. Figure 4 | |||
presents the format of an SFC Echo Request/Reply TLV, where fields | presents the format of an SFC Echo Request/Reply TLV, where fields | |||
are defined as the following: | are defined as the following: | |||
Type - a one-octet-long field that characterizes the | Type - a one-octet-long field that characterizes the | |||
interpretation of the Value field. TLVs (Type-Length-Value | interpretation of the Value field. Type values allocated | |||
tuples) have the two octets long Type field, two octets long | according to Section 8.7. | |||
Length field is the length of the Value field in octets. Type | ||||
values allocated according to Section 8.7. | ||||
Reserved - one-octet-long field. The value of the Type field | Reserved - one-octet-long field. The value of the Type field | |||
determines its interpretation and encoding. | determines its interpretation and encoding. | |||
Length - two-octet-long field equal to the length of the Value | Length - two-octet-long field equal to the Value field's length in | |||
field in octets. | octets. | |||
Value - a variable-length field. The value of the Type field | Value - a variable-length field. The value of the Type field | |||
determines its interpretation and encoding. | determines its interpretation and encoding. | |||
5.1. Return Codes | 5.1. Return Codes | |||
The value of the Return Code field is set to zero by the sender of an | The value of the Return Code field is set to zero by the sender of an | |||
Echo Request. The receiver of said Echo Request can set it to one of | Echo Request. The receiver of said Echo Request can set it to one of | |||
the values listed in Table 9 in the corresponding Echo Reply that it | the values listed in Table 1 in the corresponding Echo Reply that it | |||
generates. | generates. | |||
+-------+--------------------------------------------+ | ||||
| Value | Description | | ||||
+-------+--------------------------------------------+ | ||||
| 0 | No Return Code | | ||||
| 1 | Malformed Echo Request received | | ||||
| 2 | One or more of the TLVs was not understood | | ||||
| 3 | Authentication failed | | ||||
+-------+--------------------------------------------+ | ||||
Table 1: SFC Echo Return Codes | ||||
5.2. Authentication in Echo Request/Reply | 5.2. Authentication in Echo Request/Reply | |||
Authentication can be used to protect the integrity of the | Authentication can be used to protect the integrity of the | |||
information in SFC Echo Request and/or Echo Reply. In the | information in SFC Echo Request and/or Echo Reply. In the | |||
[I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has | [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has | |||
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 | |||
encapsulation of the monitored SFP. If Network Service Header (NSH) | encapsulation of the monitored SFP. If the NSH is used, Echo Request | |||
is used, Echo Request MUST set O bit, as defined in [RFC8300]. SFC | MUST set O bit, as defined in [RFC8300]. SFC NSH MUST be immediately | |||
NSH MUST be immediately followed by the SFC Active OAM Header defined | followed by the SFC Active OAM Header defined in Section 4. The | |||
in Section 4. The Message Type field's value in the SFC Active OAM | Message Type field's value in the SFC Active OAM Header MUST be set | |||
Header MUST be set to SFC Echo Request/Echo Reply value (TBA2) per | to SFC Echo Request/Echo Reply value (TBA2) per Section 8.2. | |||
Section 8.2. | ||||
Value of the Reply Mode field MAY be set to: | Value of the Reply Mode field MAY be set to: | |||
o Do Not Reply (TBA5) if one-way monitoring is desired. If the Echo | o 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. | |||
o Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the | o Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the | |||
most used. | most used. | |||
skipping to change at page 10, line 34 ¶ | skipping to change at page 12, line 19 ¶ | |||
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 SFF | |||
for an SFP. | 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-TLVs | |||
contains only the misunderstood TLVs. The header field's Sender's | contains only the misunderstood TLVs. The header field's Sender's | |||
Handle, Sequence Number are not examined but are included in the SFC | Handle, Sequence Number are not examined but are included in the SFC | |||
Echo Reply message. | Echo Reply message. | |||
skipping to change at page 11, line 37 ¶ | skipping to change at page 13, line 23 ¶ | |||
The Value field contains the TLVs, encoded as sub-TLVs, that were | The Value field contains the TLVs, encoded as sub-TLVs, that were | |||
not understood or failed to be parsed correctly. | not understood or failed to be parsed correctly. | |||
5.5. SFC Echo Reply Transmission | 5.5. SFC Echo Reply Transmission | |||
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 transmission of Echo Reply packet. 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 SFC NSH does not identify the ingress of the SFP, the Echo | |||
Request, the source ID MUST be included in the message and used as | Request, the source ID MUST be included in the message and used as | |||
the IP destination address for IP/UDP encapsulation of the SFC Echo | the IP destination address for IP/UDP encapsulation of the SFC Echo | |||
Reply. The sender of the SFC Echo Request MUST include SFC Source | Reply. The sender of the SFC Echo Request MUST include SFC Source | |||
TLV Figure 6. | 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 12, line 38 ¶ | skipping to change at page 14, line 21 ¶ | |||
The UDP destination port for SFC Echo Reply TBA15 will be allocated | The UDP destination port for SFC Echo Reply TBA15 will be allocated | |||
by IANA Section 8.8. | by IANA Section 8.8. | |||
5.6. SFC Echo Reply Reception | 5.6. SFC Echo Reply Reception | |||
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: | |||
o the received SFC Echo Reply is well-formed; | o the received SFC Echo Reply is well-formed; | |||
o it has outstanding SFC Echo Request sent from the UDP port that | o 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; | |||
o if the matching to the Echo Request found, the value of the | o 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 n 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; | |||
o if all checks passed, the SFF checks if the Sequence Number in the | o 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. | |||
skipping to change at page 13, line 31 ¶ | skipping to change at page 15, line 9 ¶ | |||
[RFC0792], [RFC4443] and MPLS LSP ping [RFC8029]. | [RFC0792], [RFC4443] and MPLS LSP ping [RFC8029]. | |||
There are at least three approaches to attacking a node in the | There are at least three approaches to attacking a node in the | |||
overlay network using the mechanisms defined in the document. One is | overlay network using the mechanisms defined in the document. One is | |||
a Denial-of-Service attack, sending an SFC Echo Request to overload | a Denial-of-Service attack, sending an SFC Echo Request to overload | |||
an element of the SFC. The second may use spoofing, hijacking, | an element of the SFC. The second may use spoofing, hijacking, | |||
replying, or otherwise tampering with SFC Echo Requests and/or | replying, or otherwise tampering with SFC Echo Requests and/or | |||
replies to misrepresent, alter the operator's view of the state of | replies to misrepresent, alter the operator's view of the state of | |||
the SFC. The third is an unauthorized source using an SFC Echo | the SFC. The third is an unauthorized source using an SFC Echo | |||
Request/Reply to obtain information about the SFC and/or its | Request/Reply to obtain information about the SFC and/or its | |||
elements, e.g. SFF or SF. | elements, e.g., SFF or SF. | |||
It is RECOMMENDED that implementations throttle the SFC ping traffic | It is RECOMMENDED that implementations throttle the SFC ping traffic | |||
going to the control plane to mitigate potential Denial-of-Service | going to the control plane to mitigate potential Denial-of-Service | |||
attacks. | attacks. | |||
Reply and spoofing attacks involving faking or replying to SFC Echo | Reply and spoofing attacks involving faking or replying to SFC Echo | |||
Reply messages would have to match the Sender's Handle and Sequence | Reply messages would have to match the Sender's Handle and Sequence | |||
Number of an outstanding SFC Echo Request message, which is highly | Number of an outstanding SFC Echo Request message, which is highly | |||
unlikely. Thus the non-matching reply would be discarded. | unlikely. Thus the non-matching reply would be discarded. | |||
To protect against unauthorized sources trying to obtain information | To protect against unauthorized sources trying to obtain information | |||
about the overlay and/or underlay, an implementation MAY check that | about the overlay and/or underlay, an implementation MAY check that | |||
the source of the Echo Request is indeed part of the SFP. | the source of the Echo Request is indeed part of the SFP. | |||
7. Acknowledgments | 7. Acknowledgments | |||
Authors greatly appreciate thorough review and the most helpful | Authors greatly appreciate thorough review and the most helpful | |||
comments from Dan Wing and Dirk von Hugo. | comments from Dan Wing, Dirk von Hugo, and Mohamed Boucadair. | |||
8. IANA Considerations | 8. IANA Considerations | |||
8.1. SFC Active OAM Protocol | 8.1. SFC Active OAM Protocol | |||
IANA is requested to assign a new type from the SFC Next Protocol | IANA is requested to assign a new type from the SFC Next Protocol | |||
registry as follows: | registry as follows: | |||
+-------+----------------+---------------+ | +-------+----------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+----------------+---------------+ | +-------+----------------+---------------+ | |||
| TBA1 | SFC Active OAM | This document | | | TBA1 | SFC Active OAM | This document | | |||
+-------+----------------+---------------+ | +-------+----------------+---------------+ | |||
Table 1: SFC Active OAM Protocol | Table 2: SFC Active OAM Protocol | |||
8.2. SFC Active OAM Message Type | 8.2. SFC Active OAM Message Type | |||
IANA is requested to create a new registry called "SFC Active OAM | IANA is requested to create a new registry called "SFC Active OAM | |||
Message Type". All code points in the range 1 through 32767 in this | Message Type". All code points in the range 1 through 32767 in this | |||
registry shall be allocated according to the "IETF Review" procedure | registry shall be allocated according to the "IETF Review" procedure | |||
specified in [RFC8126]. Remaining code points to be allocated | specified in [RFC8126]. The remaining code points to be allocated | |||
according to Table 2: | according to Table 3: | |||
+---------------+-------------+-------------------------+ | +---------------+-------------+-------------------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+---------------+-------------+-------------------------+ | +---------------+-------------+-------------------------+ | |||
| 0 | Reserved | | | | 0 | Reserved | | | |||
| 1 - 32767 | Reserved | IETF Consensus | | | 1 - 32767 | Reserved | IETF Consensus | | |||
| 32768 - 65530 | Reserved | First Come First Served | | | 32768 - 65530 | Reserved | First Come First Served | | |||
| 65531 - 65534 | Reserved | Private Use | | | 65531 - 65534 | Reserved | Private Use | | |||
| 65535 | Reserved | | | | 65535 | Reserved | | | |||
+---------------+-------------+-------------------------+ | +---------------+-------------+-------------------------+ | |||
Table 2: SFC Active OAM Message Type | Table 3: SFC Active OAM Message Type | |||
IANA is requested to assign a new type from the SFC Active OAM | IANA is requested to assign a new type from the SFC Active OAM | |||
Message Type registry as follows: | Message Type registry as follows: | |||
+-------+-----------------------------+---------------+ | +-------+-----------------------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+-----------------------------+---------------+ | +-------+-----------------------------+---------------+ | |||
| TBA2 | SFC Echo Request/Echo Reply | This document | | | TBA2 | SFC Echo Request/Echo Reply | This document | | |||
+-------+-----------------------------+---------------+ | +-------+-----------------------------+---------------+ | |||
Table 3: SFC Echo Request/Echo Reply Type | Table 4: SFC Echo Request/Echo Reply Type | |||
8.3. SFC Echo Request/Echo Reply Parameters | 8.3. SFC Echo Request/Echo Reply Parameters | |||
IANA is requested to create a new SFC Echo Request/Echo Reply | IANA is requested to create a new SFC Echo Request/Echo Reply | |||
Parameters registry. | Parameters registry. | |||
8.4. SFC Echo Request/Echo Reply Message Types | 8.4. SFC Echo Request/Echo Reply Message Types | |||
IANA is requested to create in the SFC Echo Request/Echo Reply | IANA is requested to create in the SFC Echo Request/Echo Reply | |||
Parameters registry the new sub-registry Message Types. All code | Parameters registry the new sub-registry Message Types. 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 | |||
specified in [RFC8126]. The remaining code points are allocated | specified in [RFC8126]. The remaining code points are allocated | |||
according to Table 4: as specified in Table 4. | according to Table 5: as specified in Table 5. | |||
+-----------+--------------+---------------+ | +-----------+--------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-----------+--------------+---------------+ | +-----------+--------------+---------------+ | |||
| 0 | Reserved | This document | | | 0 | Reserved | This document | | |||
| 1- 175 | Unassigned | This document | | | 1- 175 | Unassigned | This document | | |||
| 176 - 239 | Unassigned | This document | | | 176 - 239 | Unassigned | This document | | |||
| 240 - 251 | Experimental | This document | | | 240 - 251 | Experimental | This document | | |||
| 252 - 254 | Private Use | This document | | | 252 - 254 | Private Use | This document | | |||
| 255 | Reserved | This document | | | 255 | Reserved | This document | | |||
+-----------+--------------+---------------+ | +-----------+--------------+---------------+ | |||
Table 4: SFC Echo Request/Echo Reply Message Types | Table 5: SFC Echo Request/Echo Reply Message Types | |||
IANA is requested to assign values as listed in Table 5. | IANA is requested to assign values as listed in Table 6. | |||
+-------+------------------+---------------+ | +-------+------------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+------------------+---------------+ | +-------+------------------+---------------+ | |||
| TBA3 | SFC Echo Request | This document | | | TBA3 | SFC Echo Request | This document | | |||
| TBA4 | SFC Echo Reply | This document | | | TBA4 | SFC Echo Reply | This document | | |||
+-------+------------------+---------------+ | +-------+------------------+---------------+ | |||
Table 5: SFC Echo Request/Echo Reply Message Types Values | Table 6: SFC Echo Request/Echo Reply Message Types Values | |||
8.5. SFC Echo Reply Modes | 8.5. SFC Echo Reply Modes | |||
IANA is requested to create in the SFC Echo Request/Echo Reply | IANA is requested to create in the SFC Echo Request/Echo Reply | |||
Parameters registry the new sub-registry Reply Mode. All code points | Parameters registry the new sub-registry Reply Mode. All code points | |||
in the range 1 through 175 in this registry shall be allocated | 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 | |||
specified in [RFC8126]. The remaining code points are allocated | specified in [RFC8126]. The remaining code points are allocated | |||
according to Table 6: as specified in Table 6. | according to Table 7: as specified in Table 7. | |||
+-----------+--------------+---------------+ | +-----------+--------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-----------+--------------+---------------+ | +-----------+--------------+---------------+ | |||
| 0 | Reserved | This document | | | 0 | Reserved | This document | | |||
| 1- 175 | Unassigned | This document | | | 1- 175 | Unassigned | This document | | |||
| 176 - 239 | Unassigned | This document | | | 176 - 239 | Unassigned | This document | | |||
| 240 - 251 | Experimental | This document | | | 240 - 251 | Experimental | This document | | |||
| 252 - 254 | Private Use | This document | | | 252 - 254 | Private Use | This document | | |||
| 255 | Reserved | This document | | | 255 | Reserved | This document | | |||
+-----------+--------------+---------------+ | +-----------+--------------+---------------+ | |||
Table 6: SFC Echo Reply Mode | Table 7: SFC Echo Reply Mode | |||
All code points in the range 1 through 191 in this registry shall be | All code points in the range 1 through 191 in this registry shall be | |||
allocated according to the "IETF Review" procedure specified in | allocated according to the "IETF Review" procedure specified in | |||
[RFC8126] and assign values as listed in Table 7. | [RFC8126] and assign values as listed in Table 8. | |||
+-------+-----------------------------------------------+-----------+ | +-------+-----------------------------------------------+-----------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+-----------------------------------------------+-----------+ | +-------+-----------------------------------------------+-----------+ | |||
| 0 | Reserved | | | | 0 | Reserved | | | |||
| TBA5 | Do Not Reply | This docu | | | TBA5 | Do Not Reply | This docu | | |||
| | | ment | | | | | ment | | |||
| TBA6 | Reply via an IPv4/IPv6 UDP Packet | This docu | | | TBA6 | Reply via an IPv4/IPv6 UDP Packet | This docu | | |||
| | | ment | | | | | ment | | |||
| TBA7 | Reply via Application Level Control Channel | This docu | | | TBA7 | Reply via Application Level Control Channel | This docu | | |||
skipping to change at page 16, line 44 ¶ | skipping to change at page 18, line 29 ¶ | |||
| TBA8 | Reply via Specified Path | This docu | | | TBA8 | Reply via Specified Path | This docu | | |||
| | | ment | | | | | ment | | |||
| TBA9 | Reply via an IPv4/IPv6 UDP Packet with the | This docu | | | TBA9 | Reply via an IPv4/IPv6 UDP Packet with the | This docu | | |||
| | data integrity protection | ment | | | | data integrity protection | ment | | |||
| TBA10 | Reply via Application Level Control Channel | This docu | | | TBA10 | Reply via Application Level Control Channel | This docu | | |||
| | with the data integrity protection | ment | | | | with the data integrity protection | ment | | |||
| TBA11 | Reply via Specified Path with the data | This docu | | | TBA11 | Reply via Specified Path with the data | This docu | | |||
| | integrity protection | ment | | | | integrity protection | ment | | |||
+-------+-----------------------------------------------+-----------+ | +-------+-----------------------------------------------+-----------+ | |||
Table 7: SFC Echo Reply Mode Values | Table 8: SFC Echo Reply Mode Values | |||
8.6. SFC Echo Return Codes | 8.6. SFC Echo Return Codes | |||
IANA is requested to create in the SFC Echo Request/Echo Reply | IANA is requested to create in the SFC Echo Request/Echo Reply | |||
Parameters registry the new sub-registry Return Codes as described in | Parameters registry the new sub-registry Return Codes as described in | |||
Table 8. | Table 9. | |||
+---------+-------------+-------------------------+ | +---------+-------------+-------------------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+---------+-------------+-------------------------+ | +---------+-------------+-------------------------+ | |||
| 0-191 | Unassigned | IETF Review | | | 0-191 | Unassigned | IETF Review | | |||
| 192-251 | Unassigned | First Come First Served | | | 192-251 | Unassigned | First Come First Served | | |||
| 252-254 | Unassigned | Private Use | | | 252-254 | Unassigned | Private Use | | |||
| 255 | Reserved | | | | 255 | Reserved | | | |||
+---------+-------------+-------------------------+ | +---------+-------------+-------------------------+ | |||
Table 8: SFC Echo Return Codes | Table 9: SFC Echo Return Codes | |||
Values defined for the Return Codes sub-registry are listed in | Values defined for the Return Codes sub-registry are listed in | |||
Table 9. | Table 10. | |||
+-------+-------------------------------------------+---------------+ | +-------+-------------------------------------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+-------------------------------------------+---------------+ | +-------+-------------------------------------------+---------------+ | |||
| 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 | | |||
+-------+-------------------------------------------+---------------+ | +-------+-------------------------------------------+---------------+ | |||
Table 9: 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 | |||
specified in [RFC8126]. The remaining code points are allocated | specified in [RFC8126]. The remaining code points are allocated | |||
according to Table 10: | according to Table 11: | |||
+-----------+--------------+---------------+ | +-----------+--------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-----------+--------------+---------------+ | +-----------+--------------+---------------+ | |||
| 0 | Reserved | This document | | | 0 | Reserved | This document | | |||
| 1- 175 | Unassigned | This document | | | 1- 175 | Unassigned | This document | | |||
| 176 - 239 | Unassigned | This document | | | 176 - 239 | Unassigned | This document | | |||
| 240 - 251 | Experimental | This document | | | 240 - 251 | Experimental | This document | | |||
| 252 - 254 | Private Use | This document | | | 252 - 254 | Private Use | This document | | |||
| 255 | Reserved | This document | | | 255 | Reserved | This document | | |||
+-----------+--------------+---------------+ | +-----------+--------------+---------------+ | |||
Table 10: SFC OAM TLV Type Registry | Table 11: SFC OAM TLV Type Registry | |||
This document defines the following new values in SFC OAM TLV Type | This document defines the following new values in SFC OAM TLV Type | |||
registry: | registry: | |||
+-------+--------------------+---------------+ | +-------+--------------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+--------------------+---------------+ | +-------+--------------------+---------------+ | |||
| TBA12 | Multiple TLVs Used | This document | | | TBA12 | Multiple TLVs Used | This document | | |||
| TBA13 | Source ID TLV | This document | | | TBA13 | Source ID TLV | This document | | |||
| TBA14 | Errored TLVs | This document | | | TBA14 | Errored TLVs | This document | | |||
+-------+--------------------+---------------+ | +-------+--------------------+---------------+ | |||
Table 11: SFC OAM Type Values | Table 12: SFC OAM Type Values | |||
8.8. SFC OAM UDP Port | 8.8. SFC OAM UDP Port | |||
IANA is requested to allocate UDP port number according to | IANA is requested to allocate UDP port number according to | |||
+--------+-------+-----------+-------------+------------+-----------+ | +--------+-------+-----------+-------------+------------+-----------+ | |||
| Servic | Port | Transport | Description | Semantics | Reference | | | Servic | Port | Transport | Description | Semantics | Reference | | |||
| e Name | Numbe | Protocol | | Definition | | | | e Name | Numbe | Protocol | | Definition | | | |||
| | r | | | | | | | | r | | | | | | |||
+--------+-------+-----------+-------------+------------+-----------+ | +--------+-------+-----------+-------------+------------+-----------+ | |||
| SFC | TBA15 | UDP | SFC OAM | Section 5. | This docu | | | SFC | TBA15 | UDP | SFC OAM | Section 5. | This docu | | |||
| OAM | | | | 5 | ment | | | OAM | | | Echo Reply | 5 | ment | | |||
+--------+-------+-----------+-------------+------------+-----------+ | +--------+-------+-----------+-------------+------------+-----------+ | |||
Table 12: SFC OAM Port | Table 13: SFC OAM Port | |||
8.9. HMAC Type Sub-registry | ||||
IANA is requested to create the HMAC Type sub-registry as part of the | ||||
SFC OAM TLV Type registry. All code points in the range 1 through | ||||
127 in this registry shall be allocated according to the "IETF | ||||
Review" procedure specified in [RFC8126]. Code points in the range | ||||
128 through 239 in this registry shall be allocated according to the | ||||
"First Come First Served" procedure specified in [RFC8126]. The | ||||
remaining code points are allocated according to Table 13: | ||||
+-----------+--------------+---------------+ | ||||
| Value | Description | Reference | | ||||
+-----------+--------------+---------------+ | ||||
| 0 | Reserved | This document | | ||||
| 1- 127 | Unassigned | This document | | ||||
| 128 - 239 | Unassigned | This document | | ||||
| 240 - 249 | Experimental | This document | | ||||
| 250 - 254 | Private Use | This document | | ||||
| 255 | Reserved | This document | | ||||
+-----------+--------------+---------------+ | ||||
Table 13: HMAC Type Sub-registry | ||||
This document defines the following new values in the HMAC Type sub- | ||||
registry: | ||||
+-------+-----------------------------+---------------+ | ||||
| Value | Description | Reference | | ||||
+-------+-----------------------------+---------------+ | ||||
| 1 | HMAC-SHA-256 16 octets long | This document | | ||||
+-------+-----------------------------+---------------+ | ||||
Table 14: HMAC Types | ||||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at page 20, line 9 ¶ | skipping to change at page 20, line 44 ¶ | |||
"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>. | |||
9.2. Informative References | 9.2. Informative References | |||
[I-D.ietf-sfc-nsh-integrity] | [I-D.ietf-sfc-nsh-integrity] | |||
Boucadair, M., Reddy.K, T., and D. Wing, "Integrity | Boucadair, M., Reddy.K, 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", draft-ietf-sfc- | Encryption of Sensitive Context Headers", draft-ietf-sfc- | |||
nsh-integrity-02 (work in progress), January 2021. | nsh-integrity-03 (work in progress), January 2021. | |||
[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)", | |||
End of changes. 82 change blocks. | ||||
241 lines changed or deleted | 260 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/ |