idnits 2.17.00 (12 Aug 2021) /tmp/idnits31133/draft-ietf-sfc-multi-layer-oam-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (31 March 2022) is 44 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-ietf-sfc-oam-packet-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sfc-oam-packet' == Outdated reference: A later version (-15) exists of draft-ietf-sfc-nsh-tlv-14 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track W. Meng 5 Expires: 2 October 2022 ZTE Corporation 6 B. Khasnabish 7 Individual contributor 8 T. Ao 9 China Mobile 10 K. Leung 11 Cisco System 12 G. Mishra 13 Verizon Inc. 14 31 March 2022 16 Active OAM for Service Function Chaining 17 draft-ietf-sfc-multi-layer-oam-19 19 Abstract 21 A set of requirements for active Operation, Administration, and 22 Maintenance (OAM) of Service Function Chains (SFCs) in a network is 23 presented in this document. Based on these requirements, an 24 encapsulation of active OAM messages in SFC and a mechanism to detect 25 and localize defects are described. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 2 October 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Requirements for Active OAM in SFC . . . . . . . . . . . . . 5 65 4. Active OAM Identification in the NSH . . . . . . . . . . . . 7 66 5. Active SFC OAM Header . . . . . . . . . . . . . . . . . . . . 7 67 6. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8 68 6.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 10 69 6.2. Authentication in Echo Request/Reply . . . . . . . . . . 11 70 6.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 11 71 6.3.1. Source TLV . . . . . . . . . . . . . . . . . . . . . 12 72 6.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 13 73 6.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 14 74 6.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 15 75 6.5.1. SFC Reply Path TLV . . . . . . . . . . . . . . . . . 15 76 6.5.2. Theory of Operation . . . . . . . . . . . . . . . . . 17 77 6.5.3. SFC Echo Reply Reception . . . . . . . . . . . . . . 18 78 6.5.4. Tracing an SFP . . . . . . . . . . . . . . . . . . . 18 79 6.6. Verification of the SFP Consistency . . . . . . . . . . . 19 80 6.6.1. SFP Consistency Verification packet . . . . . . . . . 19 81 6.6.2. SFF Information Record TLV . . . . . . . . . . . . . 19 82 6.6.3. SF Information Sub-TLV . . . . . . . . . . . . . . . 20 83 6.6.4. SF Information Sub-TLV Construction . . . . . . . . . 22 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 8. Operational Considerations . . . . . . . . . . . . . . . . . 24 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 88 10.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . 25 89 10.2. SFC Active OAM . . . . . . . . . . . . . . . . . . . . . 25 90 10.2.1. SFC Active OAM Message Type . . . . . . . . . . . . 25 91 10.2.2. SFC Active OAM Header Flags . . . . . . . . . . . . 26 92 10.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 26 93 10.3.1. SFC Echo Request Flags . . . . . . . . . . . . . . . 27 94 10.3.2. SFC Echo Request/Echo Reply Message Types . . . . . 27 95 10.3.3. SFC Echo Reply Modes . . . . . . . . . . . . . . . . 28 96 10.3.4. SFC Echo Return Codes . . . . . . . . . . . . . . . 29 98 10.4. SFC Active OAM TLV Type . . . . . . . . . . . . . . . . 30 99 10.5. SF Identifier Types . . . . . . . . . . . . . . . . . . 31 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 102 11.2. Informative References . . . . . . . . . . . . . . . . . 33 103 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 106 1. Introduction 108 [RFC7665] defines data plane elements necessary to implement a 109 Service Function Chaining (SFC). These include: 111 1. Classifiers that perform the classification of incoming packets. 112 Such classification may result in associating a received packet 113 to a service function chain. 115 2. Service Function Forwarders (SFFs) that are responsible for 116 forwarding traffic to one or more connected Service Functions 117 (SFs) according to the information carried in the SFC 118 encapsulation and handling traffic coming back from the SFs and 119 forwarding it to the next SFF. 121 3. SFs that are responsible for executing specific service treatment 122 on received packets. 124 There are different views from different levels of the SFC. One is 125 the service function chain, an entirely abstract view, which defines 126 an ordered set of SFs that must be applied to packets selected based 127 on classification rules. But service function chain doesn't specify 128 the exact mapping between SFFs and SFs. Thus, another logical 129 construct used in SFC is a Service Function Path (SFP). According to 130 [RFC7665], SFP is the instantiation of the SFC in the network and 131 provides a level of indirection between the entirely abstract SFCs 132 and a fully specified ordered list of SFFs and SFs identities that 133 the packet will visit when it traverses the SFC. The latter entity 134 is referred to as Rendered Service Path (RSP). The main difference 135 between SFP and RSP is that the former is the logical construct, 136 while the latter is the realization of the SFP via the sequence of 137 specific SFC data plane elements. 139 This document defines how active Operation, Administration and 140 Maintenance (OAM), per [RFC7799] definition of active OAM, is 141 identified when Network Service Header (NSH) is used as the SFC 142 encapsulation. Following the analysis of SFC OAM in [RFC8924], this 143 document applies and, when necessary, extends requirements listed in 144 Section 4 of [RFC8924] for the use of active OAM in an SFP supporting 145 fault management and performance monitoring. Active OAM tools, 146 conformant to the requirements listed in Section 3, improve, for 147 example, troubleshooting efficiency and defect localization in SFP 148 because they specifically address the architectural principles of 149 NSH. For that purpose, SFC Echo Request and Echo Reply are specified 150 in Section 6. This mechanism enables on-demand Continuity Check, 151 Connectivity Verification, among other operations over SFC in 152 networks, addresses functionalities discussed in Sections 4.1, 4.2, 153 and 4.3 of [RFC8924]. SFC Echo Request and Echo Reply, defined in 154 this document, can be used with encapsulations other than NSH, for 155 example, using MPLS encapsulation, as described in [RFC8595]. The 156 applicability of the SFC Echo Request/Reply mechanism in SFC 157 encapsulations other than NSH is outside the scope of this document. 159 2. Terminology and Conventions 161 The terminology defined in [RFC7665] is used extensively throughout 162 this document, and the reader is expected to be familiar with it. 164 In this document, SFC OAM refers to an active OAM [RFC7799] in an SFC 165 architecture. In this document, "Echo Request/Reply" and "SFC Echo 166 Request/Reply" are used interchangeably. 168 2.1. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119] [RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 2.2. Acronyms 178 E2E: End-to-End 180 FM: Fault Management 182 NSH: Network Service Header 184 OAM: Operations, Administration, and Maintenance 186 RSP: Rendered Service Path 188 SF: Service Function 190 SFC: Service Function Chain 192 SFF: Service Function Forwarder 193 SFP: Service Function Path 195 MAC: Message Authentication Code 197 3. Requirements for Active OAM in SFC 199 As discussed in [RFC8924], SFC-specific means are needed to perform 200 the OAM task of fault management (FM) in an SFC architecture, 201 including failure detection, defect characterization, and 202 localization. This document defines the set of requirements for 203 active FM OAM mechanisms to be used in an SFC architecture. 205 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 206 |SFI11| |SFI12| |SFI21| |SFI22| |SFI31| |SFI32| 207 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 208 \ / \ / \ / 209 +----------+ +----+ +----+ +----+ 210 |Classifier|---|SFF1|---------|SFF2|----------|SFF3| 211 +----------+ +----+ +----+ +----+ 213 Figure 1: An Example of SFC Data Plane Architecture 215 The architecture example depicted in Figure 1 considers a service 216 function chain that includes three distinct service functions. In 217 this example, the SFP traverses SFF1, SFF2, and SFF3. Each SFF is 218 connected to two instances of the same service function. End-to-end 219 (E2E) SFC OAM has the Classifier as the ingress and SFF3 as its 220 egress. Segment SFC OAM is between two elements that are part of the 221 same SFP. Following are the requirements for an FM SFC OAM, whether 222 with the E2E or segment scope: 224 REQ#1: Packets of active SFC OAM SHOULD be fate sharing with the 225 monitored SFC data in the forward direction from ingress toward 226 egress endpoint(s) of the OAM test. 228 The fate sharing, in the SFC environment, is achieved when a test 229 packet traverses the same path and receives the same treatment in the 230 underlay network layer as an SFC-encapsulated packet (e.g., NSH). 232 REQ#2: SFC OAM MUST support monitoring of the continuity of the 233 SFP between any of its elements. 235 An SFC failure might be declared when several consecutive test 236 packets are not received within a pre-determined time. For example, 237 in the E2E FM SFC OAM case, the egress, SFF3, in the example in 238 Figure 1, could be the entity that detects the SFP's failure by 239 monitoring a flow of periodic test packets. The ingress may be 240 capable of recovering from the failure, e.g., using redundant SFC 241 elements. Thus, it is beneficial for the egress to signal the new 242 defect state to the ingress, which in this example is the Classifier. 243 Hence the following requirement: 245 REQ#3: SFC OAM MUST support Remote Defect Indication notification 246 by the egress to the ingress. 248 REQ#4: SFC OAM MUST support connectivity verification of the SFP. 249 Definition of the misconnection defect, entry, and exit criteria 250 are outside the scope of this document. 252 Once the SFF1 detects the defect, the objective of the SFC OAM 253 changes from the detection of a defect to defect characterization and 254 localization. 256 REQ#5: SFC OAM MUST support fault localization of the Loss of 257 Continuity Check within an SFP. 259 REQ#6: SFC OAM MUST support an SFP tracing to discover the RSP. 261 In the example presented in Figure 1, two distinct instances of the 262 same service function share the same SFF. In this example, the SFP 263 can be realized over several RSPs that use different instances of SF 264 of the same type. For instance, RSP1(SFI11--SFI21--SFI31) and 265 RSP2(SFI12--SFI22--SFI32). Available RSPs can be discovered using 266 the trace function discussed in Section 4.3 [RFC8924] or the 267 procedure defined in Section 6.5.4. 269 REQ#7: SFC OAM MUST have the ability to discover and exercise all 270 available RSPs in the network. 272 The SFC OAM layer model described in [RFC8924] offers an approach for 273 defect localization within a service function chain. As the first 274 step, the SFP's continuity for SFFs that are part of the same SFP 275 could be verified. After the reachability of SFFs has already been 276 verified, SFFs that serve an SF may be used as a test packet source. 277 In such a case, SFF can act as a proxy for another element within the 278 service function chain. 280 REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses 281 being directed towards the initiator of such proxy request. 283 4. Active OAM Identification in the NSH 285 Active SFC OAM combines OAM commands and/or data included in a 286 message that immediately follows the NSH. To identify the active SFC 287 OAM message, the "Next Protocol" field MUST be set to Active SFC OAM 288 (TBA1) (Section 10.1). The O bit in NSH MUST be set, according to 289 [I-D.ietf-sfc-oam-packet]. A case when the O bit is clear and the 290 "Next Protocol" field value is set to Active SFC OAM (TBA1) is 291 considered an erroneous combination. An implementation MUST report 292 it. The notification mechanism is outside the scope of this 293 specification. The packet SHOULD be dropped. An implementation MAY 294 have control to enable the processing of the OAM payload. 296 5. Active SFC OAM Header 298 As demonstrated in Section 4 [RFC8924] and Section 3 of this 299 document, SFC OAM is required to perform multiple tasks. Several 300 active OAM protocols could be used to address all the requirements. 301 When IP/UDP encapsulation of an SFC OAM control message is used, 302 protocols can be demultiplexed using the destination UDP port number. 303 But extra IP/UDP headers, especially in an IPv6 network, add 304 noticeable overhead. This document defines Active OAM Header 305 (Figure 2) to demultiplex active OAM protocols on an SFC. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | V | Msg Type | Flags | Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 ~ SFC Active OAM Control Packet ~ 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 2: SFC Active OAM Header 317 V - two-bit-long field indicates the current version of the SFC 318 active OAM header. The current value is 0. The version number is 319 to be incremented whenever a change is made that affects the 320 ability of an implementation to parse or process the SFC Active 321 OAM header correctly. For example, if syntactic or semantic 322 changes are made to any of the fixed fields. 324 Msg Type - six bits long field identifies OAM protocol, e.g., Echo 325 Request/Reply. 327 Flags - eight bits long field carries bit flags that define 328 optional capability and thus processing of the SFC active OAM 329 control packet, e.g., optional timestamping. No flags are defined 330 in this document, and therefore, the bit flags MUST be zeroed on 331 transmission and ignored on receipt. 333 Length - two octets long field that is the length of the SFC 334 active OAM control packet in octets. 336 6. Echo Request/Echo Reply for SFC 338 Echo Request/Reply is a well-known active OAM mechanism extensively 339 used to verify a path's continuity, detect inconsistencies between a 340 state in control and the data planes, and localize defects in the 341 data plane. ICMP ([RFC0792] for IPv4 and [RFC4443] for IPv6 342 networks, respectively) and [RFC8029] are examples of broadly used 343 active OAM protocols based on the Echo Request/Reply principle. The 344 SFC Echo Request/Reply defined in this document addresses several 345 requirements listed in Section 3. Specifically, it can be used to 346 check the continuity of an SFP, trace an SFP, or localize the failure 347 within an SFP. The SFC Echo Request/Reply control message format is 348 presented in Figure 3. 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | V | Reserved | Echo Request Flags | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Message Type | Reply mode | Return Code |Return Subcode | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Sender's Handle | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Sequence Number | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 ~ TLVs ~ 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 3: SFC Echo Request/Reply Format 366 The interpretation of the fields is as follows: 368 Version (V) is a two-bit field that indicates the current version 369 of the SFC Echo Request/Reply. The current value is 0. The 370 version number is to be incremented whenever a change is made that 371 affects the ability of an implementation to parse or process the 372 control packet correctly. If a packet presumed to carry an SFC 373 Echo Request/Reply is received at an SFF, and the SFF does not 374 understand the Version field value, the packet MUST be discarded, 375 and the event SHOULD be logged. 377 Reserved - fourteen-bit field. It MUST be zeroed on transmission 378 and ignored on receipt. 380 The Echo Request Flags is a two-octet bit vector field. Note that 381 a flag defined in the Flags field of the SFC Active OAM header in 382 Figure 2 has no implication of those defined in the Echo Request 383 Flags field of an Echo Request/Reply message. 385 The Message Type is a one-octet field that reflects the packet 386 type. Value 1 identifies Echo Request and 2 - Echo Reply. 388 The Reply Mode is a one-octet field. It defines the type of the 389 return path requested by the sender of the Echo Request. 391 Return Codes and Subcodes are one-octet fields each. These can be 392 used to inform the sender about the result of processing its 393 request. Initial Return Code values are provided in Table 1. For 394 all Return Code values defined in this document, the value of the 395 Return Subcode field MUST be set to zero. 397 The Sender's Handle is a four-octet field. It MUST be filled in 398 by the sender of the Echo Request and returned unchanged by the 399 Echo Reply sender (if a reply mandated). The sender of the Echo 400 Request SHOULD use a pseudo-random number generator to set the 401 value of the Sender's Handle field. 403 The Sequence Number is a four-octet field, and it is assigned by 404 the sender and can be, for example, used to detect missed replies. 405 Initial Sequence Number MUST be randomly generated and then SHOULD 406 be monotonically increasing in the course of the test session. 408 TLV is a variable-length construct. Multiple TLVs MAY be placed in 409 an SFC Echo Request/Reply packet. None, one or more sub-TLVs may be 410 enclosed in a TLV, subject to the semantics of the (outer) TLV. 411 Figure 4 presents the format of an SFC Echo Request/Reply TLV, where 412 fields are defined as follows: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Reserved | Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 ~ Value ~ 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Figure 4: SFC Echo Request/Reply TLV Format 424 Type - a one-octet field that characterizes the interpretation of 425 the Value field. The value of the Type field determines its 426 interpretation and encoding. Type values allocated according to 427 Section 10.4. 429 Reserved - a one-octet field. The field MUST be zeroed on 430 transmission and ignored on receipt. 432 Length - a two-octet field equal to the Value field's length in 433 octets. 435 Value - a variable-length field. The value of the Type field 436 determines its interpretation and encoding. 438 6.1. Return Codes 440 The value of the Return Code field is set to zero by the sender of an 441 Echo Request. The receiver of said Echo Request can set it to one of 442 the values listed in Table 1 in the corresponding Echo Reply that it 443 generates (in cases when the reply is requested). 445 +=======+============================================+ 446 | Value | Description | 447 +=======+============================================+ 448 | 0 | No Return Code | 449 +-------+--------------------------------------------+ 450 | 1 | Malformed Echo Request received | 451 +-------+--------------------------------------------+ 452 | 2 | One or more of the TLVs was not understood | 453 +-------+--------------------------------------------+ 454 | 3 | Authentication failed | 455 +-------+--------------------------------------------+ 457 Table 1: SFC Echo Return Codes 459 6.2. Authentication in Echo Request/Reply 461 Authentication can be used to protect the integrity of the 462 information in SFC Echo Request and/or Echo Reply. In the [RFC9145] 463 a variable-length Context Header has been defined to protect the 464 integrity of the NSH and the payload. The header can also be used 465 for the optional encryption of sensitive metadata. MAC#1 (Message 466 Authentication Code) Context Header is more suitable for the 467 integrity protection of active SFC OAM, particularly of the defined 468 in this document SFC Echo Request and Echo Reply. On the other hand, 469 using MAC#2 Context Header allows the detection of mishandling of the 470 O-bit by a transient SFC element. 472 6.3. SFC Echo Request Transmission 474 SFC Echo Request control packet MUST use the appropriate underlay 475 network encapsulation of the monitored SFP. If the NSH is used, Echo 476 Request MUST set O bit, as defined in [I-D.ietf-sfc-oam-packet]. NSH 477 MUST be immediately followed by the SFC Active OAM Header defined in 478 Section 4. The Message Type field's value in the SFC Active OAM 479 Header MUST be set to SFC Echo Request/Echo Reply value (1) per 480 Section 10.2.1. 482 Value of the Reply Mode field MAY be set to: 484 * Do Not Reply (1) if one-way monitoring is desired. If the Echo 485 Request is used to measure synthetic packet loss, the receiver may 486 report loss measurement results to a remote node. Note that ways 487 of learning the identity of that node are outside the scope of 488 this specification. 490 * Reply via an IPv4/IPv6 UDP Packet (2) value likely will be the 491 most used. 493 * Reply via Application-Level Control Channel (3) value if the SFP 494 may have bi-directional paths. 496 * Reply via Specified Path (4) value to enforce the use of the 497 particular return path specified in the included TLV to verify bi- 498 directional continuity and also increase the robustness of the 499 monitoring by selecting a more stable path. Section 6.5.1 500 provides an example of communicating an explicit path for the Echo 501 Reply. 503 6.3.1. Source TLV 505 Responder to the SFC Echo Request encapsulates the SFC Echo Reply 506 message in IP/UDP packet if the Reply mode is "Reply via an IPv4/IPv6 507 UDP Packet". Because the NSH does not identify the ingress node that 508 generated the Echo Request, the source ID MUST be included in the 509 message and used as the IP destination address and destination UDP 510 port number of the SFC Echo Reply. The sender of the SFC Echo 511 Request MUST include an SFC Source TLV (Figure 5). 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Source ID | Reserved1 | Length | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Port Number | Reserved2 | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | IP Address | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 5: SFC Source TLV 525 where 527 Source ID Type is a one-octet field and has the value of 1 528 Section 10.4. 530 Reserved1 - one-octet field. The field MUST be zeroed on 531 transmission and ignored on receipt. 533 Length is a two-octet field, and the value equals the length of 534 the data following the Length field counted in octets. The value 535 of the Length field can be 8 or 20. If the value of the field is 536 neither, the Source TLV is considered to be malformed. 538 Port Number is a two-octet field. It contains the UDP port number 539 of the sender of the SFC OAM control message. The value of the 540 field MUST be used as the destination UDP port number in the IP/ 541 UDP encapsulation of the SFC Echo Reply message. 543 Reserved2 is a two-octet field. The field MUST be zeroed on 544 transmit and ignored on receipt. 546 IP Address field contains the IP address of the sender of the SFC 547 OAM control message, IPv4 or IPv6. The value of the field MUST be 548 used as the destination IP address in the IP/UDP encapsulation of 549 the SFC Echo Reply message. 551 A single Source ID TLV for each address family, i.e., IPv4 and IPv6, 552 MAY be present in an SFC Echo Request message. If the Source TLVs 553 for both address families are present in an SFC Echo Request message, 554 the SFF MUST NOT replicate an SFC Echo Reply but choose the 555 destination IP address for the SFC Echo Reply based on the local 556 policy. If more than one Source ID TLV per the address family is 557 present, the receiver MUST use the first TLV and ignore the rest. 559 6.4. SFC Echo Request Reception 561 Punting received SFC Echo Request to the control plane is triggered 562 by one of the following packet processing exceptions: NSH TTL 563 expiration, NSH Service Index (SI) expiration, or the receiver is the 564 terminal SFF for an SFP. 566 Firstly, if the SFC Echo Request is integrity-protected, the 567 receiving SFF first MUST verify the authentication. Then the 568 receiver SFF MUST validate the Source TLV, as defined in 569 Section 6.3.1. Suppose the authentication validation has failed and 570 the Source TLV is considered properly formatted. In that case, the 571 SFF MUST send to the system identified in the Source TLV (see 572 Section 6.5), according to a rate-limit control mechanism, an SFC 573 Echo Reply with the Return Code set to "Authentication failed" and 574 the Subcode set to zero. If the Source TLV is determined malformed, 575 the received SFC Echo Request processing is stopped, the message is 576 dropped, and the event SHOULD be logged, according to a rate-limiting 577 control for logging. Then, the SFF that has received an SFC Echo 578 Request verifies the rest of the received packet's general sanity. 579 If the packet is not well-formed, the receiver SFF SHOULD send an SFC 580 Echo Reply with the Return Code set to "Malformed Echo Request 581 received" and the Subcode set to zero under the control of the rate- 582 limiting mechanism to the system identified in the Source TLV (see 583 Section 6.5). If there are any TLVs that the SFF does not 584 understand, the SFF MUST send an SFC Echo Reply with the Return Code 585 set to 2 ("One or more TLVs was not understood") and set the Subcode 586 to zero. In the latter case, the SFF MAY include an Errored TLVs TLV 587 (Section 6.4.1) that, as sub-TLVs, contains only the misunderstood 588 TLVs. Sender's Handle and Sequence Number fields are not examined 589 but are included in the SFC Echo Reply message. If the sanity check 590 of the received Echo Request succeeded, then the SFF at the end of 591 the SFP MUST set the Return Code value to 5 ("End of the SFP") and 592 the Subcode set to zero. If the SFF is not at the end of the SFP and 593 the TTL value is 1, the value of the Return Code MUST be set to 4 594 ("TTL Exceeded") and the Subcode set to zero. In all other cases, 595 SFF MUST set the Return Code value to 0 ("No Return Code") and the 596 Subcode set to zero. 598 6.4.1. Errored TLVs TLV 600 If the Return Code for the Echo Reply is determined as 2 ("One or 601 more TLVs was not understood"), the Errored TLVs TLV might be 602 included in an Echo Reply. The use of this TLV is meant to inform 603 the sender of an Echo Request of TLVs either not supported by an 604 implementation or parsed and found to be in error. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Errored TLVs | Reserved | Length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Value | 612 . . 613 . . 614 . . 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Figure 6: Errored TLVs TLV 620 where 622 The Errored TLVs Type MUST be set to 2 Section 10.4. 624 Reserved - one-octet field. The field MUST be zeroed on 625 transmission and ignored on receipt. 627 Length - two-octet field equal to the length of the Value field in 628 octets. 630 The Value field contains the TLVs, encoded as sub-TLVs (as shown 631 in Figure 7), that were not understood or failed to be parsed 632 correctly. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Sub-TLV Type | Reserved | Sub-TLV Length | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 ~ Sub-TLV Value ~ 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 7: Not Understood or Failed TLV as Sub-TLV 644 where 646 The Sub-TLV's Type the copy of the first octet of the not 647 understood or failed to be parced TLV. 649 Reserved - one-octet field. The field MUST be zeroed on 650 transmission and ignored on receipt. 652 Sub-TLV Length - two-octet field equal to the value of the Length 653 field of the errored TLV. 655 The Sub-TLV Value field contains data that follow the Legth field 656 in the errored TLV. 658 6.5. SFC Echo Reply Transmission 660 The "Reply Mode" field directs whether and how the Echo Reply message 661 should be sent. The Echo Request sender MAY use TLVs to request that 662 the corresponding Echo Reply be transmitted over the specified path. 663 Section 6.5.1 provides an example of a TLV that specifies the return 664 path of the Echo Reply. Value 1 is the "Do not reply" mode and 665 suppresses the Echo Reply packet transmission. The default value (2) 666 for the Reply mode field requests the responder to send the Echo 667 Reply packet out-of-band as IPv4 or IPv6 UDP packet. 669 6.5.1. SFC Reply Path TLV 671 While SFC Echo Request always traverses the SFP it is directed to by 672 using NSH, the corresponding Echo Reply usually is sent without NSH. 673 In some cases, an operator might choose to direct the responder to 674 send the Echo Reply with NSH over a particular SFP. This section 675 defines a new Type-Length-Value (TLV), Reply Service Function Path 676 TLV, for Reply via Specified Path mode of SFC Echo Reply. 678 The Reply Service Function Path TLV can provide an efficient 679 mechanism to test SFCs, such as bidirectional and hybrid SFC, as 680 defined in Section 2.2 [RFC7665]. For example, it allows an operator 681 to test both directions of the bidirectional or hybrid SFP with a 682 single SFC Echo Request/Echo Reply operation. 684 The SFC Reply Path TLV carries the information that sufficiently 685 identifies the return SFP that the SFC Echo Reply message is expected 686 to follow. The format of SFC Reply Path TLV is shown in Figure 8. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 |SFC Reply Path | Reserved | Length | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Reply Service Function Path | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Figure 8: SFC Reply TLV Format 698 where: 700 * SFC Reply Path Type: is a one-octet field, indicates the TLV that 701 contains information about the SFC Reply path. IANA is requested 702 to assign value 3, 704 * Reserved - one-octet field. The field MUST be zeroed on 705 transmission and ignored on receipt. 707 * Length: is a two-octet field, MUST be equal to 4 709 * Reply Service Function Path is used to describe the return path 710 that an SFC Echo Reply is requested to follow. 712 The format of the Reply Service Function Path field displayed in 713 Figure 9. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Reply Service Function Path Identifier | Service Index | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Figure 9: Reply Service Function Path Field Format 723 where: 725 * Reply Service Function Path Identifier: SFP identifier for the 726 path that the SFC Echo Reply message is requested to be sent over. 728 * Service Index: the value for the Service Index field in the NSH of 729 the SFC Echo Reply message. 731 6.5.2. Theory of Operation 733 [RFC7110] defined mechanism to control return path for MPLS LSP Echo 734 Reply. In SFC's case, the return path is an SFP along which the SFC 735 Echo Reply message MUST be transmitted. Hence, the SFC Reply Path 736 TLV included in the SFC Echo Request message MUST sufficiently 737 identify the SFP that the sender of the Echo Request message expects 738 the receiver to use for the corresponding SFC Echo Reply. 740 When sending an Echo Request, the sender MUST set the value of Reply 741 Mode field to "Reply via Specified Path", defined in Section 6.3, and 742 if the specified path is an SFC path, the Request MUST include SFC 743 Reply Path TLV. The SFC Reply Path TLV consists of the identifier of 744 the reverse SFP and an appropriate Service Index. 746 If the NSH of the received SFC Echo Request includes the MAC Context 747 Header, the packet's authentication MUST be verified before using any 748 data. If the verification fails, the receiver MUST stop processing 749 the SFC Return Path TLV and MUST send the SFC Echo Reply with the 750 Return Codes value set to the value Authentication failed from the 751 IANA's Return Codes sub-registry of the SFC Echo Request/Echo Reply 752 Parameters registry. 754 The destination SFF of the SFP being tested or the SFF at which SFC 755 TTL expired (as per [RFC8300]) may be sending the Echo Reply. The 756 processing described below equally applies to both cases and is 757 referred to as responding SFF. 759 If the Echo Request message with SFC Reply Path TLV, received by the 760 responding SFF, has Reply Mode value of "Reply via Specified Path" 761 but no SFC Reply Path TLV is present, then the responding SFF MUST 762 send Echo Reply with Return Code set to 6 ("Reply Path TLV is 763 missing"). If the responding SFF cannot find the requested SFP it 764 MUST send Echo Reply with Return Code set to 7 ("Reply SFP was not 765 found") and include the SFC Reply Path TLV from the Echo Request 766 message. 768 Suppose the SFC Echo Request receiver cannot determine whether the 769 specified return path SFP has the route to the initiator. In that 770 case, it SHOULD set the value of the Return Codes field to 8 771 ("Unverifiable Reply Path"). The receiver MAY drop the Echo Request 772 when it cannot determine whether SFP's return path has the route to 773 the initiator. When sending Echo Request, the sender SHOULD choose a 774 proper source address according to the specified return path SFP to 775 help the receiver find the viable return path. 777 6.5.2.1. Bi-directional SFC Case 779 The ability to specify the return path for an Echo Reply might be 780 used in the case of bi-directional SFC. The egress SFF of the 781 forward SFP might not be co-located with a classifier of the reverse 782 SFP, and thus the egress SFF has no information about the reverse 783 path of an SFC. Because of that, even for bi-directional SFC, a 784 reverse SFP needs to be indicated in a Reply Path TLV in the Echo 785 Request message. 787 6.5.3. SFC Echo Reply Reception 789 An SFF SHOULD NOT accept SFC Echo Reply unless the received message 790 passes the following checks: 792 * the received SFC Echo Reply is well-formed; 794 * if the matching to the Echo Request found, the value of the 795 Sender's Handle in the Echo Request sent is equal to the value of 796 Sender's Handle in the Echo Reply received; 798 * if all checks passed, the SFF checks if the Sequence Number in the 799 Echo Request sent matches to the Sequence Number in the Echo Reply 800 received. 802 6.5.4. Tracing an SFP 804 SFC Echo Request/Reply can be used to isolate a defect detected in 805 the SFP and trace an RSP. As with ICMP echo request/reply [RFC0792] 806 and MPLS echo request/reply [RFC8029], this mode is referred to as 807 "traceroute". In the traceroute mode, the sender transmits a 808 sequence of SFC Echo Request messages starting with the NSH TTL value 809 set to 1 and is incremented by 1 in each next Echo Request packet. 810 The sender stops transmitting SFC Echo Request packets when the 811 Return Code in the received Echo Reply equals 5 ("End of the SFP"). 813 Suppose a specialized information element (e.g., IPv6 Flow Label 814 [RFC6437] or Flow ID [I-D.ietf-sfc-nsh-tlv]) is used for distributing 815 the load across Equal Cost Multi-Path or Link Aggregation Group 816 paths. In that case, such an element MAY also be used for the SFC 817 OAM traffic. Doing so is meant to induce the SFC Echo Request to 818 follow the same RSP as the monitored flow. 820 6.6. Verification of the SFP Consistency 822 The consistency of an SFP can be verified by comparing the view of 823 the SFP from the control or management plane with information 824 collected from traversed by an SFC NSH Echo Request message. Every 825 SFF that receives the Consistency Verification Request (CVReq) 826 (specified in Section 6.6.1) MUST perform the following actions: 828 * Collect information of the traversed by the CVReq packet SFs and 829 send it to the ingress SFF as CVRep packet over IP network; 831 * Forward the CVReq to the next downstream SFF if the one exists. 833 As a result, the ingress SFF collects information about all traversed 834 SFFs and SFs, information on the actual path the CVReq packet has 835 traveled. That information is used to verify the SFC's path 836 consistency. The mechanism for the SFP consistency verification is 837 outside the scope of this document. 839 6.6.1. SFP Consistency Verification packet 841 For the verification of an SFP consistency, two new types of messages 842 to the SFC Echo Request/Reply operation defined in Section 6 with the 843 following values detailed in Section 10.3.2: 845 * 3 - SFP Consistency Verification Request 847 * 4 - SFP Consistency Verification Reply 849 Upon receiving the CVReq, the SFF MUST respond with the Consistency 850 Verification Reply (CVRep). The SFF MUST include the SFs 851 information, as described in Section 6.6.3 and Section 6.6.2. 853 6.6.2. SFF Information Record TLV 855 For the received CVReq, an SFF is expected to include in the CVRep 856 message the information about SFs that are mapped to that SFF. The 857 SFF MUST include SFF Information Record TLV (Figure 10) in CVRep 858 message. Every SFF sends back a single CVRep message, including 859 information on all the SFs attached to the SFF on the SFP, as 860 requested in the received CVReq message using the SF Information sub- 861 TLV (Section 6.6.3). 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 |SFF Record TLV | Reserved | Length | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Service Path Identifier (SPI) | Reserved | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | | 871 | SF Information Sub-TLV | 872 ~ ~ 873 | | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 Figure 10: SFF Information Record TLV 878 The SFF Information Record TLV is a variable-length TLV that includes 879 the information of all SFs mapped to the particular SFF instance for 880 the specified SFP. Figure 10 presents the format of an SFF 881 Information Record TLV, where fields are defined as the following: 883 SFF Record TLV - one-octet field. The value is (4) 884 (Section 10.4). 886 Reserved - one-octet field. The field MUST be zeroed on 887 transmission and ignored on receipt. 889 Service Path Identifier (SPI): The identifier of SFP to which all 890 the SFs in this TLV belong. 892 SF Information Sub-TLV: The sub-TLV is as defined in Figure 11. 894 If the NSH of the received SFC Echo Reply includes the MAC Context 895 Header [RFC9145], the authentication of the packet MUST be verified 896 before using any data. If the verification fails, the receiver MUST 897 stop processing the SFF Information Record TLV and notify an 898 operator. The notification mechanism SHOULD include control of rate- 899 limiting messages. Specification of the notification mechanism is 900 outside the scope of this document. 902 6.6.3. SF Information Sub-TLV 904 Every SFF receiving CVReq packet MUST include the SF characteristic 905 data into the CVRep packet. The format of an SF Information sub-TLV, 906 included in a CVRep packet, is shown in Figure 11. 908 After the CVReq message traverses the SFP, all the information about 909 the SFs on the SFP is available from the TLVs included in CVRep 910 messages. 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | SF sub-TLV | Reserved | Length | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 |Service Index | SF Type | SF ID Type | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | SF Identifier | 920 ~ ~ 921 | | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 Figure 11: Service Function Information Sub-TLV 926 SF sub-TLV Type: Two-octets long field. The value is (5) 927 (Section 10.4). 929 Reserved - one-octet field. The field MUST be zeroed on 930 transmission and ignored on receipt. 932 Length - two-octet long field. The value of this field is the 933 length of the data following the Length field counted in octets. 935 Service Index - indicates the SF's position on the SFP. 937 SF Type - two-octet field. It is defined in [RFC9015] and 938 indicates the type of SF, e.g., Firewall, Deep Packet Inspection, 939 WAN optimization controller, etc. 941 SF ID Type - one-octet field with values defined as Section 10.5. 943 SF Identifier - an identifier of the SF. The length of the SF 944 Identifier depends on the type of the SF ID Type. For example, if 945 the SF Identifier is its IPv4 address, the SF Identifier should be 946 32 bits. 948 6.6.4. SF Information Sub-TLV Construction 950 Each SFF in the SFP MUST send one and only one CVRep corresponding to 951 the CVReq. If only one SF is attached to the SFF in such SFP, only 952 one SF information sub-TLV is included in the CVRep. If several SFs 953 attached to the SFF in the SFP, SF Information sub-TLV MUST be 954 constructed as described below in either Section 6.6.4.1 and 955 Section 6.6.4.2. 957 6.6.4.1. Multiple SFs as Hops of an SFP 959 Multiple SFs attached to the same SFF can be the hops of the SFP. 960 The service indexes of these SFs on thatSFP will be different. 961 Service function types of these SFs could be different or be the 962 same. Information about all SFs MAY be included in the CVRep 963 message. Information about each SF MUST be listed as separate SF 964 Information sub-TLVs in the CVRep message. 966 An example of the SFP consistency verification procedure for this 967 case is shown in Figure 12. The Service Function Path (SPI=x) is 968 SF1->SF2->SF4->SF3. The SF1, SF2, and SF3 are attached to SFF1, and 969 SF4 is attached to SFF2. The CVReq message is sent to the SFFs in 970 the sequence of the SFP(SFF1->SFF2->SFF1). Every SFF(SFF1, SFF2) 971 replies with the information of SFs belonging to the SFP. The SF 972 information Sub-TLV in Figure 11 contains information for each SF 973 (SF1, SF2, SF3, and SF4). 975 SF1 SF2 SF4 SF3 976 +------+------+ | | 977 CVReq ......> SFF1 ......> SFF2 ......> SFF1 978 (SPI=x) . . . 979 <............ <.......... <........... 980 CVRep1(SF1,SF2) CVRep2(SF4) CVRep3(SF3) 982 Figure 12: Example 1 for CVRep with multiple SFs 984 6.6.4.2. Multiple SFs for load balance 986 Multiple SFs may be attached to the same SFF to spread the load; in 987 other words, that means that the particular traffic flow will 988 traverse only one of these SFs. These SFs have the same Service 989 Function Type and Service Index. For this case, the SF identifiers 990 and SF ID Type of all these SFs will be listed in the SF Identifiers 991 field and SF ID Type in a single SF information sub-TLV of the CVRep 992 message. The number of these SFs can be calculated using the SF ID 993 Type and the value of the Length field of the sub-TLV. 995 An example of the SFP consistency verification procedure for this 996 case is shown in Figure 13. The Service Function Path (SPI=x) is 997 SF1a/SF1b->SF2a/SF2b. The Service Functions SF1a and SF1b are 998 attached to SFF1, which balances the load among them. The Service 999 Functions SF2a and SF2b are attached to SFF2, which, in turn, 1000 balances its load between them. The CVReq message is sent to the 1001 SFFs in the sequence of the SFP (i.e. SFF1->SFF2). Every SFF (SFF1, 1002 SFF2) replies with the information of SFs belonging to the SFP. The 1003 SF information Sub-TLV in Figure 11 contains information for all SFs 1004 at that hop. 1006 /SF1a /SF2a 1007 \SF1b \SF2b 1008 | | 1009 SFF1 SFF2 1010 CVReq .........> . .........> . 1011 (SPI=x) . . 1012 <............ <............... 1013 CVRep1({SF1a,SF1b}) CVRep2({SF2a,SF2b}) 1015 Figure 13: Example 2 for CVRep with multiple SFs 1017 7. Security Considerations 1019 When the integrity protection for SFC active OAM, and SFC Echo 1020 Request/Reply in particular, is required, using one of the Context 1021 Headers defined in [RFC9145] is RECOMMENDED. MAC#1 Context Header 1022 could be more suitable for active SFC OAM because it does not require 1023 re-calculation of the MAC when the value of the NSH Base Header's TTL 1024 field is changed. Integrity protection for SFC active OAM can also 1025 be achieved using mechanisms in the underlay data plane. For 1026 example, if the underlay is an IPv6 network, IP Authentication Header 1027 [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can 1028 be used to provide integrity protection. Confidentiality for the SFC 1029 Echo Request/Reply exchanges can be achieved using the IP 1030 Encapsulating Security Payload Header [RFC4303]. Also, the security 1031 needs for SFC Echo Request/Reply are similar to those of ICMP ping 1032 [RFC0792], [RFC4443] and MPLS LSP ping [RFC8029]. 1034 There are at least three approaches to attacking a node in the 1035 overlay network using the mechanisms defined in the document. One is 1036 a Denial-of-Service attack, sending SFC Echo Requests to overload an 1037 element of the SFC. The second may use spoofing, hijacking, 1038 replying, or otherwise tampering with SFC Echo Requests and/or 1039 replies to misrepresent, alter the operator's view of the state of 1040 the SFC. The third is an unauthorized source using an SFC Echo 1041 Request/Reply to obtain information about the SFC and/or its 1042 elements, e.g., SFFs and/or SFs. 1044 It is RECOMMENDED that implementations throttle the SFC ping traffic 1045 going to the control plane to mitigate potential Denial-of-Service 1046 attacks. 1048 Reply and spoofing attacks involving faking or replying to SFC Echo 1049 Reply messages would have to match the Sender's Handle and Sequence 1050 Number of an outstanding SFC Echo Request message, which is highly 1051 unlikely for off-path attackers. A non-matching reply would be 1052 discarded. 1054 To protect against unauthorized sources trying to obtain information 1055 about the overlay and/or underlay, an implementation MAY check that 1056 the source of the Echo Request is indeed part of the SFP. 1058 Also, since the Service Function Information sub-TLV discloses 1059 information about the SFP, the spoofed CVReq packet may be used to 1060 obtain network information. Thus it is RECOMMENDED that 1061 implementations provide a means of checking the source addresses of 1062 CVReq messages, specified in SFC Source TLV Section 6.3.1, against an 1063 access list before accepting the message. 1065 8. Operational Considerations 1067 This section provides information about operational aspects of the 1068 SFC NSH Echo Request/Reply according to recommendations in [RFC5706]. 1070 SFC NSH Echo Request/Reply provides essential OAM functions for 1071 network operators. SFC NSH Echo Request/Reply is intended to detect 1072 and localize defects in an SFC. For example, by comparing results of 1073 the trace function in operational and failed states, an operator can 1074 locate the defect, e.g., the connection between SFF1 and SFF2 1075 (Figure 1). Note that a more specific failure location can be 1076 determined using OAM tools in the underlay network. The mechanism 1077 defined in this document can be used on-demand or for periodic 1078 validation of an SFP or RSP. Because the protocol uses information 1079 in the SFC control plane, an operator must have the ability to 1080 control the frequency of transmitted Echo Request and Reply messages. 1081 A reasonably selected default interval between Echo Request control 1082 packets can provide additional benefit for an operator. If the 1083 protocol is incrementally deployed in the NSH domain, SFC elements, 1084 e.g., Classifier or SFF, that don't support Active SFC OAM will 1085 discard protocol's packets. SFC NSH Echo Request/Reply also can be 1086 used in combination with the existing mechanisms discussed in 1087 [RFC8924], filling the gaps and extending their functionalities. 1089 Management of the SFC NSH Echo Request/Reply protocol can be provided 1090 by a proprietary tool, e.g., command line interface, or based on a 1091 data model, structured or standardized. 1093 9. Acknowledgments 1095 The authors greatly appreciate the thorough review and the most 1096 helpful comments from Dan Wing, Dirk von Hugo, Mohamed Boucadair, 1097 Donald Eastlake, Carlos Pignataro, and Frank Brockners. The authors 1098 are thankful to John Drake for his review and the reference to the 1099 work on BGP Control Plane for NSH SFC. The authors express their 1100 appreciation to Joel M. Halpern for his suggestion about the load- 1101 balancing scenario. 1103 10. IANA Considerations 1105 10.1. SFC Active OAM Protocol 1107 IANA is requested to assign a new type from the SFC Next Protocol 1108 registry as follows: 1110 +=======+================+===============+ 1111 | Value | Description | Reference | 1112 +=======+================+===============+ 1113 | TBA1 | SFC Active OAM | This document | 1114 +-------+----------------+---------------+ 1116 Table 2: SFC Active OAM Protocol 1118 10.2. SFC Active OAM 1120 IANA is requested to create a new SFC Active OAM registry. 1122 10.2.1. SFC Active OAM Message Type 1124 IANA is requested to create in the SFC Active OAM registry a new sub- 1125 registry as follows: 1127 Sub-registry Name: SFC Active OAM Message Type. 1129 Assignment Policy: 1131 2-32767 IETF Consensus 1133 32768-65530 First Come First Served 1135 Reference: [this document] 1137 +===============+=============================+===============+ 1138 | Value | Description | Reference | 1139 +===============+=============================+===============+ 1140 | 0 | Reserved | This document | 1141 +---------------+-----------------------------+---------------+ 1142 | 1 | SFC Echo Request/Echo Reply | This document | 1143 +---------------+-----------------------------+---------------+ 1144 | 2 - 32767 | Unassigned | This document | 1145 +---------------+-----------------------------+---------------+ 1146 | 32768 - 65530 | Unassigned | This document | 1147 +---------------+-----------------------------+---------------+ 1148 | 65531 - 65534 | Unassigned | This document | 1149 +---------------+-----------------------------+---------------+ 1150 | 65535 | Reserved | This document | 1151 +---------------+-----------------------------+---------------+ 1153 Table 3: SFC Active OAM Message Type 1155 10.2.2. SFC Active OAM Header Flags 1157 IANA is requested to create in the SFC Active OAM registry the new 1158 sub-registry SFC Active OAM Flags. 1160 This sub-registry tracks the assignment of 8 flags in the Flags field 1161 of the SFC Active OAM Header. The flags are numbered from 0 (most 1162 significant bit, transmitted first) to 7. 1164 New entries are assigned by Standards Action. 1166 +============+=============+===============+ 1167 | Bit Number | Description | Reference | 1168 +============+=============+===============+ 1169 | 7-0 | Unassigned | This document | 1170 +------------+-------------+---------------+ 1172 Table 4: SFC Active OAM Header Flags 1174 10.3. SFC Echo Request/Echo Reply Parameters 1176 IANA is requested to create a new SFC Echo Request/Echo Reply 1177 Parameters registry. 1179 10.3.1. SFC Echo Request Flags 1181 IANA is requested to create in the SFC Echo Request/Echo Reply 1182 Parameters registry the new sub-registry SFC Echo Request Flags. 1184 This sub-registry tracks the assignment of 16 flags in the SFC Echo 1185 Request Flags field of the SFC Echo Request message. The flags are 1186 numbered from 0 (most significant bit, transmitted first) to 15. 1188 New entries are assigned by Standards Action. 1190 +============+=============+===============+ 1191 | Bit Number | Description | Reference | 1192 +============+=============+===============+ 1193 | 15-0 | Unassigned | This document | 1194 +------------+-------------+---------------+ 1196 Table 5: SFC Echo Request Flags 1198 10.3.2. SFC Echo Request/Echo Reply Message Types 1200 IANA is requested to create in the SFC Echo Request/Echo Reply 1201 Parameters registry the new sub-registry as follows: 1203 Sub-registry Name: Message Types 1205 Assignment Policy: 1207 5 - 175 IETF Consensus 1209 176 - 239 First Come First Served 1211 240 - 251 Experimental 1213 252 - 254 Private Use 1215 Reference: [this document] 1217 +===========+======================================+===============+ 1218 | Value | Description | Reference | 1219 +===========+======================================+===============+ 1220 | 0 | Reserved | This document | 1221 +-----------+--------------------------------------+---------------+ 1222 | 1 | SFC Echo Request | This document | 1223 +-----------+--------------------------------------+---------------+ 1224 | 2 | SFC Echo Reply | This document | 1225 +-----------+--------------------------------------+---------------+ 1226 | 3 | SFP Consistency Verification Request | This document | 1227 +-----------+--------------------------------------+---------------+ 1228 | 4 | SFP Consistency Verification Reply | This document | 1229 +-----------+--------------------------------------+---------------+ 1230 | 5 - 175 | Unassigned | This document | 1231 +-----------+--------------------------------------+---------------+ 1232 | 176 - 239 | Unassigned | This document | 1233 +-----------+--------------------------------------+---------------+ 1234 | 240 - 251 | Unassigned | This document | 1235 +-----------+--------------------------------------+---------------+ 1236 | 252 - 254 | Unassigned | This document | 1237 +-----------+--------------------------------------+---------------+ 1238 | 255 | Reserved | This document | 1239 +-----------+--------------------------------------+---------------+ 1241 Table 6: SFC Echo Request/Echo Reply Message Types 1243 10.3.3. SFC Echo Reply Modes 1245 IANA is requested to create in the SFC Echo Request/Echo Reply 1246 Parameters registry the new sub-registry as follows: 1248 Sub-registry Name: Reply Mode 1250 Assignment Policy: 1252 8 - 175 IETF Consensus 1254 176 - 239 First Come First Served 1256 240 - 251 Experimental 1258 252 - 254 Private Use 1260 Reference: [this document] 1261 +=======+====================================+===============+ 1262 | Value | Description | Reference | 1263 +=======+====================================+===============+ 1264 | 0 | Reserved | This document | 1265 +-------+------------------------------------+---------------+ 1266 | 1 | Do Not Reply | This document | 1267 +-------+------------------------------------+---------------+ 1268 | 2 | Reply via an IPv4/IPv6 UDP Packet | This document | 1269 +-------+------------------------------------+---------------+ 1270 | 3 | Reply via Application-Level | This document | 1271 | | Control Channel | | 1272 +-------+------------------------------------+---------------+ 1273 | 4 | Reply via Specified Path | This document | 1274 +-------+------------------------------------+---------------+ 1275 | 5 | Reply via an IPv4/IPv6 UDP Packet | This document | 1276 | | with the data integrity protection | | 1277 +-------+------------------------------------+---------------+ 1278 | 6 | Reply via Application-Level | This document | 1279 | | Control Channel with the data | | 1280 | | integrity protection | | 1281 +-------+------------------------------------+---------------+ 1282 | 7 | Reply via Specified Path with the | This document | 1283 | | data integrity protection | | 1284 +-------+------------------------------------+---------------+ 1285 | 8 - | Unassigned | IETF Review | 1286 | 175 | | | 1287 +-------+------------------------------------+---------------+ 1288 | 176 - | Unassigned | First Come | 1289 | 239 | | First Served | 1290 +-------+------------------------------------+---------------+ 1291 | 240 - | Unassigned | Experimental | 1292 | 251 | | | 1293 +-------+------------------------------------+---------------+ 1294 | 252 - | Unassigned | Private Use | 1295 | 254 | | | 1296 +-------+------------------------------------+---------------+ 1297 | 255 | Reserved | This document | 1298 +-------+------------------------------------+---------------+ 1300 Table 7: SFC Echo Reply Mode 1302 10.3.4. SFC Echo Return Codes 1304 IANA is requested to create in the SFC Echo Request/Echo Reply 1305 Parameters registry the new sub-registry as follows: 1307 Sub-registry Name: Return Codes 1308 Assignment Policy: 1310 9 - 191 IETF Consensus 1312 192 - 251 First Come First Served 1314 252 - 254 Private Use 1316 Reference: [this document] 1318 +=========+=================================+===============+ 1319 | Value | Description | Reference | 1320 +=========+=================================+===============+ 1321 | 0 | No Return Code | This document | 1322 +---------+---------------------------------+---------------+ 1323 | 1 | Malformed Echo Request received | This document | 1324 +---------+---------------------------------+---------------+ 1325 | 2 | One or more of the TLVs was not | This document | 1326 | | understood | | 1327 +---------+---------------------------------+---------------+ 1328 | 3 | Authentication failed | This document | 1329 +---------+---------------------------------+---------------+ 1330 | 4 | TTL Exceeded | This document | 1331 +---------+---------------------------------+---------------+ 1332 | 5 | End of the SFP | This document | 1333 +---------+---------------------------------+---------------+ 1334 | 6 | Reply Path TLV is missing | This document | 1335 +---------+---------------------------------+---------------+ 1336 | 7 | Reply SFP was not found | This document | 1337 +---------+---------------------------------+---------------+ 1338 | 8 | Unverifiable Reply Path | This document | 1339 +---------+---------------------------------+---------------+ 1340 | 9 -191 | Unassigned | This document | 1341 +---------+---------------------------------+---------------+ 1342 | 192-251 | Unassigned | This document | 1343 +---------+---------------------------------+---------------+ 1344 | 252-254 | Unassigned | This document | 1345 +---------+---------------------------------+---------------+ 1346 | 255 | Reserved | | 1347 +---------+---------------------------------+---------------+ 1349 Table 8: SFC Echo Return Codes 1351 10.4. SFC Active OAM TLV Type 1353 IANA is requested to create the new registry as follows: 1355 Registry Name: SFC Active OAM TLV Type 1356 Assignment Policy: 1358 6 -175 IETF Consensus 1360 176 - 239 First Come First Served 1362 240 - 251 Experimental 1364 252 - 254 Private Use 1366 Reference: [this document] 1368 +===========+=============================+===============+ 1369 | Value | Description | Reference | 1370 +===========+=============================+===============+ 1371 | 0 | Reserved | This document | 1372 +-----------+-----------------------------+---------------+ 1373 | 1 | Source ID TLV | This document | 1374 +-----------+-----------------------------+---------------+ 1375 | 2 | Errored TLVs | This document | 1376 +-----------+-----------------------------+---------------+ 1377 | 3 | SFC Reply Path Type | This document | 1378 +-----------+-----------------------------+---------------+ 1379 | 4 | SFF Information Record Type | This document | 1380 +-----------+-----------------------------+---------------+ 1381 | 5 | SF Information | This document | 1382 +-----------+-----------------------------+---------------+ 1383 | 6 - 175 | Unassigned | This document | 1384 +-----------+-----------------------------+---------------+ 1385 | 176 - 239 | Unassigned | This document | 1386 +-----------+-----------------------------+---------------+ 1387 | 240 - 251 | Unassigned | This document | 1388 +-----------+-----------------------------+---------------+ 1389 | 252 - 254 | Unassigned | This document | 1390 +-----------+-----------------------------+---------------+ 1391 | 255 | Reserved | This document | 1392 +-----------+-----------------------------+---------------+ 1394 Table 9: SFC Active OAM TLV Type Registry 1396 10.5. SF Identifier Types 1398 IANA is requested to create in the SF Types registry the new sub- 1399 registry as follows: 1401 Registry Name: SF Identifier Types 1403 Assignment Policy: 1405 4 -191 IETF Consensus 1407 192 - 251 First Come First Served 1409 252 - 254 Private Use 1411 Reference: [this document] 1413 +=========+=============+===============+ 1414 | Value | Description | Reference | 1415 +=========+=============+===============+ 1416 | 0 | Reserved | This document | 1417 +---------+-------------+---------------+ 1418 | 1 | IPv4 | This document | 1419 +---------+-------------+---------------+ 1420 | 2 | IPv6 | This document | 1421 +---------+-------------+---------------+ 1422 | 3 | MAC | This document | 1423 +---------+-------------+---------------+ 1424 | 4 -191 | Unassigned | This document | 1425 +---------+-------------+---------------+ 1426 | 192-251 | Unassigned | This document | 1427 +---------+-------------+---------------+ 1428 | 252-254 | Unassigned | This document | 1429 +---------+-------------+---------------+ 1430 | 255 | Reserved | This document | 1431 +---------+-------------+---------------+ 1433 Table 10: SF Identifier Type 1435 11. References 1437 11.1. Normative References 1439 [I-D.ietf-sfc-oam-packet] 1440 Boucadair, M., "OAM Packet and Behavior in the Network 1441 Service Header (NSH)", Work in Progress, Internet-Draft, 1442 draft-ietf-sfc-oam-packet-00, 25 March 2022, 1443 . 1446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1447 Requirement Levels", BCP 14, RFC 2119, 1448 DOI 10.17487/RFC2119, March 1997, 1449 . 1451 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1452 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1453 May 2017, . 1455 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1456 "Network Service Header (NSH)", RFC 8300, 1457 DOI 10.17487/RFC8300, January 2018, 1458 . 1460 11.2. Informative References 1462 [I-D.ietf-sfc-nsh-tlv] 1463 Wei, Y., Elzur, U., Majee, S., Pignataro, C., and D. E. 1464 Eastlake, "Network Service Header Metadata Type 2 1465 Variable-Length Context Headers", Work in Progress, 1466 Internet-Draft, draft-ietf-sfc-nsh-tlv-14, 30 March 2022, 1467 . 1470 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1471 RFC 792, DOI 10.17487/RFC0792, September 1981, 1472 . 1474 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1475 DOI 10.17487/RFC4302, December 2005, 1476 . 1478 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1479 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1480 . 1482 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1483 Control Message Protocol (ICMPv6) for the Internet 1484 Protocol Version 6 (IPv6) Specification", STD 89, 1485 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1486 . 1488 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1489 Management of New Protocols and Protocol Extensions", 1490 RFC 5706, DOI 10.17487/RFC5706, November 2009, 1491 . 1493 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1494 "IPv6 Flow Label Specification", RFC 6437, 1495 DOI 10.17487/RFC6437, November 2011, 1496 . 1498 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 1499 "Return Path Specified Label Switched Path (LSP) Ping", 1500 RFC 7110, DOI 10.17487/RFC7110, January 2014, 1501 . 1503 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1504 Chaining (SFC) Architecture", RFC 7665, 1505 DOI 10.17487/RFC7665, October 2015, 1506 . 1508 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1509 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1510 May 2016, . 1512 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1513 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1514 Switched (MPLS) Data-Plane Failures", RFC 8029, 1515 DOI 10.17487/RFC8029, March 2017, 1516 . 1518 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1519 Forwarding Plane for Service Function Chaining", RFC 8595, 1520 DOI 10.17487/RFC8595, June 2019, 1521 . 1523 [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, 1524 R., and A. Ghanwani, "Service Function Chaining (SFC) 1525 Operations, Administration, and Maintenance (OAM) 1526 Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, 1527 . 1529 [RFC9015] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 1530 Jalil, "BGP Control Plane for the Network Service Header 1531 in Service Function Chaining", RFC 9015, 1532 DOI 10.17487/RFC9015, June 2021, 1533 . 1535 [RFC9145] Boucadair, M., Reddy.K, T., and D. Wing, "Integrity 1536 Protection for the Network Service Header (NSH) and 1537 Encryption of Sensitive Context Headers", RFC 9145, 1538 DOI 10.17487/RFC9145, December 2021, 1539 . 1541 Contributors' Addresses 1543 Cui Wang 1544 Individual contributor 1545 Email: lindawangjoy@gmail.com 1546 Zhonghua Chen 1547 China Telecom 1548 No.1835, South PuDong Road 1549 Shanghai 1550 201203 1551 China 1552 Phone: +86 18918588897 1553 Email: chenzhongh@chinatelecom.cn 1555 Authors' Addresses 1557 Greg Mirsky 1558 Ericsson 1559 Email: gregimirsky@gmail.com 1561 Wei Meng 1562 ZTE Corporation 1563 No.50 Software Avenue, Yuhuatai District 1564 Nanjing, 1565 China 1566 Email: meng.wei2@zte.com.cn 1568 Bhumip Khasnabish 1569 Individual contributor 1570 Email: vumip1@gmail.com 1572 Ting Ao 1573 China Mobile 1574 No.889, BiBo Road 1575 Shanghai 1576 201203 1577 China 1578 Phone: +86 17721209283 1579 Email: 18555817@qq.com 1581 Kent Leung 1582 Cisco System 1583 170 West Tasman Drive 1584 San Jose, CA 95134, 1585 United States of America 1586 Email: kleung@cisco.com 1587 Gyan Mishra 1588 Verizon Inc. 1589 Email: gyan.s.mishra@verizon.com