idnits 2.17.1 draft-ietf-sfc-multi-layer-oam-12.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 28 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 June 2021) is 1029 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 (-09) exists of draft-ietf-sfc-nsh-integrity-05 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-nsh-tlv-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG G. Mirsky 3 Internet-Draft ZTE Corp. 4 Updates: 8300 (if approved) W. Meng 5 Intended status: Standards Track ZTE Corporation 6 Expires: 5 December 2021 B. Khasnabish 7 C. Wang 8 Individual contributor 9 3 June 2021 11 Active OAM for Service Function Chaining 12 draft-ietf-sfc-multi-layer-oam-12 14 Abstract 16 A set of requirements for active Operation, Administration, and 17 Maintenance (OAM) of Service Function Chains (SFCs) in a network is 18 presented in this document. Based on these requirements, an 19 encapsulation of active OAM messages in SFC and a mechanism to detect 20 and localize defects are described. 22 This document updates RFC 8300. Particularly, it updates the 23 definition of O (OAM) bit in the Network Service Header (NSH) and 24 defines how an active OAM message is identified in the NSH. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 5 December 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Requirements for Active OAM in SFC Network . . . . . . . . . 4 64 4. Active OAM Identification in the NSH . . . . . . . . . . . . 6 65 5. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8 66 5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 10 67 5.2. Authentication in Echo Request/Reply . . . . . . . . . . 11 68 5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 11 69 5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 12 70 5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 12 71 5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 13 72 5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 14 73 5.7. Tracing an SFP . . . . . . . . . . . . . . . . . . . . . 15 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 16 78 8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 16 79 8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 17 80 8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 17 81 8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 18 82 8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 20 83 8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 21 84 8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 21 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 87 9.2. Informative References . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 90 1. Introduction 92 [RFC7665] defines data plane elements necessary to implement a 93 Service Function Chaining (SFC). These include: 95 1. Classifiers that perform the classification of incoming packets. 96 Such classification may result in associating a received packet 97 to a service function chain. 99 2. Service Function Forwarders (SFFs) that are responsible for 100 forwarding traffic to one or more connected Service Functions 101 (SFs) according to the information carried in the SFC 102 encapsulation and handling traffic coming back from the SFs and 103 forwarding it to the next SFF. 105 3. SFs that are responsible for executing specific service treatment 106 on received packets. 108 There are different views from different levels of the SFC. One is 109 the service function chain, an entirely abstract view, which defines 110 an ordered set of SFs that must be applied to packets selected based 111 on classification rules. But service function chain doesn't specify 112 the exact mapping between SFFs and SFs. Thus, another logical 113 construct used in SFC is a Service Function Path (SFP). According to 114 [RFC7665], SFP is the instantiation of the SFC in the network and 115 provides a level of indirection between the entirely abstract SFCs 116 and a fully specified ordered list of SFFs and SFs identities that 117 the packet will visit when it traverses the SFC. The latter entity 118 is referred to as Rendered Service Path (RSP). The main difference 119 between SFP and RSP is that the former is the logical construct, 120 while the latter is the realization of the SFP via the sequence of 121 specific SFC data plane elements. 123 This document defines how active Operation, Administration and 124 Maintenance (OAM), per [RFC7799] definition of active OAM, is 125 identified when Network Service Header (NSH) is used as the SFC 126 encapsulation. Following the analysis of SFC OAM in [RFC8924], this 127 document applies and, when necessary, extends requirements listed in 128 Section 4 of [RFC8924] for the use of active OAM in an SFP supporting 129 fault management and performance monitoring. Active OAM tools, 130 conformant to the requirements listed in Section 3, improve, for 131 example, troubleshooting efficiency and defect localization in SFP 132 because they specifically address architectural principles of NSH. 133 For that purpose, SFC Echo Request and Echo Reply are specified in 134 the document. This mechanism enables on-demand Continuity Check, 135 Connectivity Verification among other operations over SFC in 136 networks, addresses functionalities discussed in Sections 4.1, 4.2, 137 and 4.3 of [RFC8924]. Also, this document updates Section 2.2 of 138 [RFC8300] in part of the definition of O bit in the (NSH). 140 2. Terminology and Conventions 142 The terminology defined in [RFC7665] is used extensively throughout 143 this document. The reader is expected to be familiar with it. 145 In this document, SFC OAM refers to an active OAM [RFC7799] in an SFC 146 architecture. 148 2.1. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 2.2. Acronyms 158 E2E: End-to-End 160 FM: Fault Management 162 NSH: Network Service Header 164 OAM: Operations, Administration, and Maintenance 166 RSP: Rendered Service Path 168 SF: Service Function 170 SFC: Service Function Chain 172 SFF: Service Function Forwarder 174 SFP: Service Function Path 176 MAC: Message Authentication Code 178 3. Requirements for Active OAM in SFC Network 180 As discussed in [RFC8924], SFC-specific means are needed to perform 181 the OAM task of fault management (FM) in an SFC architecture, 182 including failure detection, defect characterization, and 183 localization. This document defines the set of requirements for 184 active FM OAM mechanisms to be used in an SFC architecture. 186 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 187 |SFI11| |SFI12| |SFI21| |SFI22| |SFI31| |SFI32| 188 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 189 \ / \ / \ / 190 +----------+ +----+ +----+ +----+ 191 |Classifier|---|SFF1|---------|SFF2|----------|SFF3| 192 +----------+ +----+ +----+ +----+ 194 Figure 1: An Example of SFC Data Plane 196 Regarding the reference model depicted in Figure 1, consider a 197 service function chain that includes three distinct service 198 functions. In this example, the SFP traverses SFF1, SFF2, and SFF3, 199 each SFF being connected to two instances of the same service 200 function. End-to-end (E2E) SFC OAM has the Classifier as the 201 ingress, and SFF3 - as its egress. Segment SFC OAM is between two 202 elements that are part of the same SFP. Following are the 203 requirements for an FM SFC OAM, whether with the E2E or segment 204 scope: 206 REQ#1: Packets of active SFC OAM in SFC SHOULD be fate sharing 207 with the monitored SFC data, in the forward direction from ingress 208 toward egress endpoint(s) of the OAM test. 210 The fate sharing, in the SFC environment, is achieved when a test 211 packet traverses the same path and receives the same treatment in the 212 transport layer as an SFC NSH packet. 214 REQ#2: SFC OAM MUST support monitoring of the continuity of the 215 SFP between any of its elements. 217 A network failure might be declared when several consecutive test 218 packets are not received within a pre-determined time. For example, 219 in the E2E SFC OAM FM case, the egress, SFF3, in the example in 220 Figure 1, could be the entity that detects the SFP's failure by 221 monitoring a flow of periodic test packets. The ingress may be 222 capable of recovering from the failure, e.g., using redundant SFC 223 elements. Thus, it is beneficial for the egress to signal the new 224 defect state to the ingress, which in this example is the Classifier. 225 Hence the following requirement: 227 REQ#3: SFC OAM MUST support Remote Defect Indication notification 228 by the egress to the ingress. 230 REQ#4: SFC OAM MUST support connectivity verification of the SFP. 231 Definition of the misconnection defect, entry and exit criteria 232 are outside the scope of this document. 234 Once the SFF1 detects the defect, the objective of the SFC OAM 235 changes from the detection of a defect to defect characterization and 236 localization. 238 REQ#5: SFC OAM MUST support fault localization of the Loss of 239 Continuity Check within an SFP. 241 REQ#6: SFC OAM MUST support an SFP tracing to discover the RSP. 243 In the example presented in Figure 1, two distinct instances of the 244 same service function share the same SFF. In this example, the SFP 245 can be realized over several RSPs that use different instances of SF 246 of the same type. For example, RSP1(SFI11--SFI21--SFI31) and 247 RSP2(SFI12--SFI22--SFI32). Available RSPs can be discovered using 248 the trace function discussed in Section 4.3 [RFC8924]. 250 REQ#7: SFC OAM MUST have the ability to discover and exercise all 251 available RSPs in the network. 253 The SFC OAM layer model described in [RFC8924] offers an approach for 254 a defect localization within a service function chain. As the first 255 step, the SFP's continuity for SFFs that are part of the same SFP 256 could be verified. After the reachability of SFFs has already been 257 verified, SFFs that serve an SF may be used as a test packet source. 258 In such a case, SFF can act as a proxy for another element within the 259 service function chain. 261 REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses 262 being directed towards the initiator of such proxy request. 264 4. Active OAM Identification in the NSH 266 The O bit in the NSH is defined in [RFC8300] as follows: 268 O bit: Setting this bit indicates an OAM packet. 270 This document updates that definition as follows: 272 O bit: Setting this bit indicates an OAM command and/or data in 273 the NSH Context Header or packet payload. 275 Active SFC OAM is defined as a combination of OAM commands and/or 276 data included in a message that immediately follows the NSH. To 277 identify the active OAM message, the Next Protocol field's value MUST 278 be set to Active SFC OAM (TBA1) (Section 8.1). The rules for 279 interpreting the values of the O bit and the Next Protocol field are 280 as follows: 282 * O bit set and the Next Protocol value is not one of identifying 283 active or hybrid OAM protocol (per [RFC7799] definitions), e.g., 284 defined in this specification Active SFC OAM: 286 - a Fixed-Length Context Header or Variable-Length Context 287 Header(s) contain an OAM command or data. 289 - the type of payload is determined by the Next Protocol field. 291 * O bit set and the Next Protocol value is one of identifying active 292 or hybrid OAM protocol: 294 - the payload that immediately follows the NSH MUST contain an 295 OAM command or data. 297 * O bit is clear: 299 - no OAM in a Fixed-Length Context Header or Variable-Length 300 Context Header(s). 302 - the payload determined by the Next Protocol field's value 303 MUST be present. 305 * O bit is clear and the Next Protocol field's value identifies 306 active or hybrid OAM protocol MUST be identified and reported as 307 the erroneous combination. An implementation MAY have control to 308 enable processing of the OAM payload. 310 One conclusion from the above-listed rules of processing the O bit 311 and the Next Protocol field's value is to avoid the combination of 312 OAM in an NSH Context Header (Fixed-Length or Variable-Length) and 313 the payload immediately following the NSH because there is no 314 unambiguous way to identify such combination using the O bit and the 315 Next Protocol field. 317 As demonstrated in Section 4 [RFC8924] and Section 3 of this 318 document, SFC OAM is required to perform multiple tasks. Several 319 active OAM protocols could be used to address all the requirements. 320 When IP/UDP encapsulation of an SFC OAM control message is used, 321 protocols can be demultiplexed using the Destination UDP port number. 322 But extra IP/UDP headers, especially in an IPv6 network, add 323 noticeable overhead. This document defines Active OAM Header 324 (Figure 2) to demultiplex active OAM protocols on an SFC. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | V | Msg Type | Flags | Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 ~ SFC Active OAM Control Packet ~ 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 2: SFC Active OAM Header 336 V - two-bit-long field indicates the current version of the SFC 337 active OAM header. The current value is 0. 339 Msg Type - six bits long field identifies OAM protocol, e.g., Echo 340 Request/Reply or Bidirectional Forwarding Detection. 342 Flags - eight bits long field carries bit flags that define 343 optional capability and thus processing of the SFC active OAM 344 control packet, e.g., optional timestamping. 346 Length - two octets long field that is the length of the SFC 347 active OAM control packet in octets. 349 5. Echo Request/Echo Reply for SFC 351 Echo Request/Reply is a well-known active OAM mechanism that is 352 extensively used to verify a path's continuity, detect 353 inconsistencies between a state in control and the data planes, and 354 localize defects in the data plane. ICMP ([RFC0792] for IPv4 and 355 [RFC4443] for IPv6 networks respectively) and [RFC8029] are examples 356 of broadly used active OAM protocols based on Echo Request/Reply 357 principle. The SFC NSH Echo Request/Reply defined in this document 358 addresses several requirements listed in Section 3. Specifically, as 359 defined in this specification, it can be used to check the continuity 360 of an SFP, trace an SFP, localize the failure of the SFP. The SFC 361 NSH Echo Request/Reply control message format is presented in 362 Figure 3. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | V | Reserved | Global Flags | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Message Type | Reply mode | Return Code |Return Subcode | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Sender's Handle | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Sequence Number | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 ~ TLVs ~ 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 3: SFC Echo Request/Reply Format 380 The interpretation of the fields is as follows: 382 Version (V) is a two-bit field that indicates the current version 383 of the SFC Echo Request/Reply. The current value is 0. The 384 version number is to be incremented whenever a change is made that 385 affects the ability of an implementation to parse or process 386 control packet correctly. 388 Reserved - fourteen-bit field. It MUST be zeroed on transmission 389 and ignored on receipt. 391 The Global Flags is a two-octet bit vector field. 393 The Message Type is a one-octet field that reflects the packet 394 type. Value TBA3 identifies Echo Request and TBA4 - Echo Reply. 396 The Reply Mode is a one-octet field. It defines the type of the 397 return path requested by the sender of the Echo Request. 399 Return Codes and Subcodes are one-octet fields each. These can be 400 used to inform the sender about the result of processing its 401 request. Initial Return Code values are according to Table 1. 402 For all Return Code values defined in this document, the value of 403 the Return Subcode field MUST be set to zero. 405 The Sender's Handle is a four-octet field. It is filled in by the 406 sender of the Echo Request and returned unchanged by the Echo 407 Reply sender. The sender of the Echo Request MAY use a pseudo- 408 random number generator to set the value of the Sender's Handle 409 field. 411 The Sequence Number is a four-octet field. It is assigned by the 412 sender and can be (for example) used to detect missed replies. 413 The value of the Sequence Number field SHOULD be monotonically 414 increasing in the course of the test session. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Type | Reserved | Length | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 ~ Value ~ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 4: SFC Echo Request/Reply TLV Format 426 TLV is a variable-length field. Multiple TLVs MAY be placed in an 427 SFC Echo Request/Reply packet. Additional TLVs may be enclosed 428 within a given TLV, subject to the semantics of the (outer) TLV in 429 question. If more than one TLV is to be included, the value of the 430 Type field of the outmost outer TLV MUST be set to Multiple TLVs Used 431 (TBA12), as assigned by IANA according to Section 8.7. Figure 4 432 presents the format of an SFC Echo Request/Reply TLV, where fields 433 are defined as the following: 435 Type - a one-octet-long field that characterizes the 436 interpretation of the Value field. Type values allocated 437 according to Section 8.7. 439 Reserved - one-octet-long field. The value of the Type field 440 determines its interpretation and encoding. 442 Length - two-octet-long field equal to the Value field's length in 443 octets. 445 Value - a variable-length field. The value of the Type field 446 determines its interpretation and encoding. 448 5.1. Return Codes 450 The value of the Return Code field is set to zero by the sender of an 451 Echo Request. The receiver of said Echo Request can set it to one of 452 the values listed in Table 1 in the corresponding Echo Reply that it 453 generates. 455 +=======+============================================+ 456 | Value | Description | 457 +=======+============================================+ 458 | 0 | No Return Code | 459 +-------+--------------------------------------------+ 460 | 1 | Malformed Echo Request received | 461 +-------+--------------------------------------------+ 462 | 2 | One or more of the TLVs was not understood | 463 +-------+--------------------------------------------+ 464 | 3 | Authentication failed | 465 +-------+--------------------------------------------+ 467 Table 1: SFC Echo Return Codes 469 5.2. Authentication in Echo Request/Reply 471 Authentication can be used to protect the integrity of the 472 information in SFC Echo Request and/or Echo Reply. In the 473 [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has 474 been defined to protect the integrity of the NSH and the payload. 475 The header can also be used for the optional encryption of the 476 sensitive metadata. MAC#1 Context Header is more suitable for the 477 integrity protection of active SFC OAM, particularly of the defined 478 in this document SFC Echo Request and Echo Reply. On the other hand, 479 using MAC#2 Context Header allows the detection of mishandling of the 480 O-bit by a transient SFC element. 482 5.3. SFC Echo Request Transmission 484 SFC Echo Request control packet MUST use the appropriate transport 485 encapsulation of the monitored SFP. If the NSH is used, Echo Request 486 MUST set O bit, as defined in [RFC8300]. NSH MUST be immediately 487 followed by the SFC Active OAM Header defined in Section 4. The 488 Message Type field's value in the SFC Active OAM Header MUST be set 489 to SFC Echo Request/Echo Reply value (TBA2) per Section 8.2. 491 Value of the Reply Mode field MAY be set to: 493 * Do Not Reply (TBA5) if one-way monitoring is desired. If the Echo 494 Request is used to measure synthetic packet loss; the receiver may 495 report loss measurement results to a remote node. Note that ways 496 of learning the identy of that node is otside the scope of this 497 specification. 499 * Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the 500 most used. 502 * Reply via Application Level Control Channel (TBA7) value if the 503 SFP may have bi-directional paths. 505 * Reply via Specified Path (TBA8) value to enforce the use of the 506 particular return path specified in the included TLV to verify bi- 507 directional continuity and also increase the robustness of the 508 monitoring by selecting a more stable path. 509 [I-D.ao-sfc-oam-return-path-specified] provides an example of the 510 defining a specific path for the Echo Reply. 512 5.4. SFC Echo Request Reception 514 Sending an SFC Echo Request to the control plane is triggered by one 515 of the following packet processing exceptions: NSH TTL expiration, 516 NSH Service Index (SI) expiration, or the receiver is the terminal 517 SFF for an SFP. 519 Firstly, if the SFC Echo Request is authenticated, the receiving SFF 520 MUST verify the authentication. If the verification fails, the 521 receiver SFF MUST send an SFC Echo Reply with the Return Code set to 522 "Authentication failed" and the Subcode set to zero. Then, the SFF 523 that has received an SFC Echo Request verifies the received packet's 524 general sanity. If the packet is not well-formed, the receiver SFF 525 SHOULD send an SFC Echo Reply with the Return Code set to "Malformed 526 Echo Request received" and the Subcode set to zero. If there are any 527 TLVs that SFF does not understand, the SFF MUST send an SFC Echo 528 Reply with the Return Code set to 2 ("One or more TLVs was not 529 understood") and set the Subcode to zero. In the latter case, the 530 SFF MAY include an Errored TLVs TLV (Section 5.4.1) that, as sub- 531 TLVs, contains only the misunderstood TLVs. The header field's 532 Sender's Handle, Sequence Number are not examined but are included in 533 the SFC Echo Reply message. If the sanity check of the received Echo 534 Request succeeded, then the SFF at the end of the SFP MUST set the 535 Return Code value to 5 ("End of the SFP") and the Subcode set to 536 zero. If the SFF is not at theend of the SFP and the TTL value is 1, 537 the value of the Return Code MUST be set to 4 ("TTL Exceeded") and 538 the Subcode set to zero. 540 5.4.1. Errored TLVs TLV 542 If the Return Code for the Echo Reply is determined as 2 ("One or 543 more TLVs was not understood"), then the Errored TLVs TLV MAY be 544 included in an Echo Reply. The use of this TLV allows informing the 545 sender of an Echo Request of mandatory TLVs either not supported by 546 an implementation or parsed and found to be in error. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Errored TLVs | Reserved | Length | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Value | 554 . . 555 . . 556 . . 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Figure 5: Errored TLVs TLV 562 where 564 The Errored TLVs Type MUST be set to TBA14 Section 8.7. 566 Reserved - one-octet-long field. 568 Length - two-octet-long field equal to the length of the Value 569 field in octets. 571 The Value field contains the TLVs, encoded as sub-TLVs, that were 572 not understood or failed to be parsed correctly. 574 5.5. SFC Echo Reply Transmission 576 The Reply Mode field directs whether and how the Echo Reply message 577 should be sent. The sender of the Echo Request MAY use TLVs to 578 request that the corresponding Echo Reply is transmitted over the 579 specified path. [I-D.ao-sfc-oam-return-path-specified] provides an 580 example of a TLV that can be used to specify the path of the Echo 581 Reply. Value TBA3 is referred to as the "Do not reply" mode and 582 suppresses the Echo Reply packet transmission. The default value 583 (TBA6) for the Reply mode field requests the responder to send the 584 Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet. 586 Responder to the SFC Echo Request sends the Echo Reply over IP 587 network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet. 588 Because the NSH does not identify the ingress node that generated the 589 Echo Request, the source ID MUST be included in the message and used 590 as the IP destination address for IP/UDP encapsulation of the SFC 591 Echo Reply. The sender of the SFC Echo Request MUST include SFC 592 Source TLV Figure 6. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Source ID | Reserved | Length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Value | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Figure 6: SFC Source TLV 604 where 606 Source ID Type is a one-octet-long field and has the value of 607 TBA13 Section 8.7. 609 Reserved - one-octet-long field. 611 Length is a two-octets-long field, and the value equals the length 612 of the Value field in octets. 614 Value field contains the IP address of the sender of the SFC OAM 615 control message, IPv4 or IPv6. 617 The UDP destination port for SFC Echo Reply TBA15 will be allocated 618 by IANA Section 8.8. 620 5.6. SFC Echo Reply Reception 622 An SFF SHOULD NOT accept SFC Echo Reply unless the received passes 623 the following checks: 625 * the received SFC Echo Reply is well-formed; 627 * it has an outstanding SFC Echo Request sent from the UDP port that 628 matches destination UDP port number of the received packet; 630 * if the matching to the Echo Request found, the value of the 631 Sender's Handle in the Echo Request sent is equal to the value of 632 Sender's Handle in the Echo Reply received; 634 * if all checks passed, the SFF checks if the Sequence Number in the 635 Echo Request sent matches to the Sequence Number in the Echo Reply 636 received. 638 5.7. Tracing an SFP 640 SFC Echo Request/Reply can be used to isolate a defect detected in 641 the SFP and trace an RSP. As for ICMP echo request/reply [RFC0792] 642 and MPLS echo request/reply [RFC8029], this mode is referred to as 643 "traceroute". In the traceroute mode, the sender transmits a 644 sequence of SFC Echo Request messages starting with the NSH TTL value 645 set to 1 and is incremented by 1 in each next Echo Request packet. 646 The sender stops transmitting SFC Echo Request packets when the 647 Return Code in the received Echo Reply equals 5 ("End of the SFP"). 649 Suppose a specialized information element (e.g., IPv6 Flow Label 650 [RFC6437] or Flow ID [I-D.ietf-sfc-nsh-tlv]) is used for distributing 651 the load across Equal Cost Multi-Path or Link Aggregation Group 652 paths. In that case, such an element MAY also be used for the SFC 653 OAM traffic. Doing so is meant to control whether the SFC Echo 654 Request follows the same RSP as the monitored flow. 656 6. Security Considerations 658 When the integrity protection for SFC active OAM, and SFC Echo 659 Request/Reply in particular, is required, it is RECOMMENDED to use 660 one of Context Headers defined in [I-D.ietf-sfc-nsh-integrity]. 661 MAC#1 (Message Authentication Code) Context Header could be more 662 suitable for active SFC OAM because it does not require re- 663 calculation of the MAC when the value of the NSH Base Header's TTL 664 field is changed. The integrity protection for SFC active OAM can 665 also be achieved using mechanisms in the underlay data plane. For 666 example, if the underlay is an IPv6 network, IP Authentication Header 667 [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can 668 be used to provide integrity protection. Confidentiality for the SFC 669 Echo Request/Reply exchanges can be achieved using the IP 670 Encapsulating Security Payload Header [RFC4303]. Also, the security 671 needs for SFC Echo Request/Reply are similar to those of ICMP ping 672 [RFC0792], [RFC4443] and MPLS LSP ping [RFC8029]. 674 There are at least three approaches to attacking a node in the 675 overlay network using the mechanisms defined in the document. One is 676 a Denial-of-Service attack, sending an SFC Echo Request to overload 677 an element of the SFC. The second may use spoofing, hijacking, 678 replying, or otherwise tampering with SFC Echo Requests and/or 679 replies to misrepresent, alter the operator's view of the state of 680 the SFC. The third is an unauthorized source using an SFC Echo 681 Request/Reply to obtain information about the SFC and/or its 682 elements, e.g., SFF or SF. 684 It is RECOMMENDED that implementations throttle the SFC ping traffic 685 going to the control plane to mitigate potential Denial-of-Service 686 attacks. 688 Reply and spoofing attacks involving faking or replying to SFC Echo 689 Reply messages would have to match the Sender's Handle and Sequence 690 Number of an outstanding SFC Echo Request message, which is highly 691 unlikely. Thus the non-matching reply would be discarded. 693 To protect against unauthorized sources trying to obtain information 694 about the overlay and/or underlay, an implementation MAY check that 695 the source of the Echo Request is indeed part of the SFP. 697 7. Acknowledgments 699 Authors greatly appreciate thorough review and the most helpful 700 comments from Dan Wing, Dirk von Hugo, and Mohamed Boucadair. 702 8. IANA Considerations 704 8.1. SFC Active OAM Protocol 706 IANA is requested to assign a new type from the SFC Next Protocol 707 registry as follows: 709 +=======+================+===============+ 710 | Value | Description | Reference | 711 +=======+================+===============+ 712 | TBA1 | SFC Active OAM | This document | 713 +-------+----------------+---------------+ 715 Table 2: SFC Active OAM Protocol 717 8.2. SFC Active OAM Message Type 719 IANA is requested to create a new registry called "SFC Active OAM 720 Message Type". All code points in the range 1 through 32767 in this 721 registry shall be allocated according to the "IETF Review" procedure 722 specified in [RFC8126]. The remaining code points to be allocated 723 according to Table 3: 725 +===============+=============+=========================+ 726 | Value | Description | Reference | 727 +===============+=============+=========================+ 728 | 0 | Reserved | | 729 +---------------+-------------+-------------------------+ 730 | 1 - 32767 | Reserved | IETF Consensus | 731 +---------------+-------------+-------------------------+ 732 | 32768 - 65530 | Reserved | First Come First Served | 733 +---------------+-------------+-------------------------+ 734 | 65531 - 65534 | Reserved | Private Use | 735 +---------------+-------------+-------------------------+ 736 | 65535 | Reserved | | 737 +---------------+-------------+-------------------------+ 739 Table 3: SFC Active OAM Message Type 741 IANA is requested to assign a new type from the SFC Active OAM 742 Message Type registry as follows: 744 +=======+=============================+===============+ 745 | Value | Description | Reference | 746 +=======+=============================+===============+ 747 | TBA2 | SFC Echo Request/Echo Reply | This document | 748 +-------+-----------------------------+---------------+ 750 Table 4: SFC Echo Request/Echo Reply Type 752 8.3. SFC Echo Request/Echo Reply Parameters 754 IANA is requested to create a new SFC Echo Request/Echo Reply 755 Parameters registry. 757 8.4. SFC Echo Request/Echo Reply Message Types 759 IANA is requested to create in the SFC Echo Request/Echo Reply 760 Parameters registry the new sub-registry Message Types. All code 761 points in the range 1 through 175 in this registry shall be allocated 762 according to the "IETF Review" procedure specified in [RFC8126]. 763 Code points in the range 176 through 239 in this registry shall be 764 allocated according to the "First Come First Served" procedure 765 specified in [RFC8126]. The remaining code points are allocated 766 according to Table 5: as specified in Table 5. 768 +===========+==============+===============+ 769 | Value | Description | Reference | 770 +===========+==============+===============+ 771 | 0 | Reserved | This document | 772 +-----------+--------------+---------------+ 773 | 1- 175 | Unassigned | This document | 774 +-----------+--------------+---------------+ 775 | 176 - 239 | Unassigned | This document | 776 +-----------+--------------+---------------+ 777 | 240 - 251 | Experimental | This document | 778 +-----------+--------------+---------------+ 779 | 252 - 254 | Private Use | This document | 780 +-----------+--------------+---------------+ 781 | 255 | Reserved | This document | 782 +-----------+--------------+---------------+ 784 Table 5: SFC Echo Request/Echo Reply 785 Message Types 787 IANA is requested to assign values as listed in Table 6. 789 +=======+==================+===============+ 790 | Value | Description | Reference | 791 +=======+==================+===============+ 792 | TBA3 | SFC Echo Request | This document | 793 +-------+------------------+---------------+ 794 | TBA4 | SFC Echo Reply | This document | 795 +-------+------------------+---------------+ 797 Table 6: SFC Echo Request/Echo Reply 798 Message Types Values 800 8.5. SFC Echo Reply Modes 802 IANA is requested to create in the SFC Echo Request/Echo Reply 803 Parameters registry the new sub-registry Reply Mode. All code points 804 in the range 1 through 175 in this registry shall be allocated 805 according to the "IETF Review" procedure specified in [RFC8126]. 806 Code points in the range 176 through 239 in this registry shall be 807 allocated according to the "First Come First Served" procedure 808 specified in [RFC8126]. The remaining code points are allocated 809 according to Table 7: as specified in Table 7. 811 +===========+==============+===============+ 812 | Value | Description | Reference | 813 +===========+==============+===============+ 814 | 0 | Reserved | This document | 815 +-----------+--------------+---------------+ 816 | 1- 175 | Unassigned | This document | 817 +-----------+--------------+---------------+ 818 | 176 - 239 | Unassigned | This document | 819 +-----------+--------------+---------------+ 820 | 240 - 251 | Experimental | This document | 821 +-----------+--------------+---------------+ 822 | 252 - 254 | Private Use | This document | 823 +-----------+--------------+---------------+ 824 | 255 | Reserved | This document | 825 +-----------+--------------+---------------+ 827 Table 7: SFC Echo Reply Mode 829 All code points in the range 1 through 191 in this registry shall be 830 allocated according to the "IETF Review" procedure specified in 831 [RFC8126] and assign values as listed in Table 8. 833 +=======+====================================+===============+ 834 | Value | Description | Reference | 835 +=======+====================================+===============+ 836 | 0 | Reserved | | 837 +-------+------------------------------------+---------------+ 838 | TBA5 | Do Not Reply | This document | 839 +-------+------------------------------------+---------------+ 840 | TBA6 | Reply via an IPv4/IPv6 UDP Packet | This document | 841 +-------+------------------------------------+---------------+ 842 | TBA7 | Reply via Application Level | This document | 843 | | Control Channel | | 844 +-------+------------------------------------+---------------+ 845 | TBA8 | Reply via Specified Path | This document | 846 +-------+------------------------------------+---------------+ 847 | TBA9 | Reply via an IPv4/IPv6 UDP Packet | This document | 848 | | with the data integrity protection | | 849 +-------+------------------------------------+---------------+ 850 | TBA10 | Reply via Application Level | This document | 851 | | Control Channel with the data | | 852 | | integrity protection | | 853 +-------+------------------------------------+---------------+ 854 | TBA11 | Reply via Specified Path with the | This document | 855 | | data integrity protection | | 856 +-------+------------------------------------+---------------+ 858 Table 8: SFC Echo Reply Mode Values 860 8.6. SFC Echo Return Codes 862 IANA is requested to create in the SFC Echo Request/Echo Reply 863 Parameters registry the new sub-registry Return Codes as described in 864 Table 9. 866 +=========+=============+=========================+ 867 | Value | Description | Reference | 868 +=========+=============+=========================+ 869 | 0-191 | Unassigned | IETF Review | 870 +---------+-------------+-------------------------+ 871 | 192-251 | Unassigned | First Come First Served | 872 +---------+-------------+-------------------------+ 873 | 252-254 | Unassigned | Private Use | 874 +---------+-------------+-------------------------+ 875 | 255 | Reserved | | 876 +---------+-------------+-------------------------+ 878 Table 9: SFC Echo Return Codes 880 Values defined for the Return Codes sub-registry are listed in 881 Table 10. 883 +=======+=================================+===============+ 884 | Value | Description | Reference | 885 +=======+=================================+===============+ 886 | 0 | No Return Code | This document | 887 +-------+---------------------------------+---------------+ 888 | 1 | Malformed Echo Request received | This document | 889 +-------+---------------------------------+---------------+ 890 | 2 | One or more of the TLVs was not | This document | 891 | | understood | | 892 +-------+---------------------------------+---------------+ 893 | 3 | Authentication failed | This document | 894 +-------+---------------------------------+---------------+ 895 | 4 | TTL Exceeded | This document | 896 +-------+---------------------------------+---------------+ 897 | 5 | End of the SFP | This document | 898 +-------+---------------------------------+---------------+ 900 Table 10: SFC Echo Return Codes Values 902 8.7. SFC TLV Type 904 IANA is requested to create the SFC OAM TLV Type registry. All code 905 points in the range 1 through 175 in this registry shall be allocated 906 according to the "IETF Review" procedure specified in [RFC8126]. 907 Code points in the range 176 through 239 in this registry shall be 908 allocated according to the "First Come First Served" procedure 909 specified in [RFC8126]. The remaining code points are allocated 910 according to Table 11: 912 +===========+==============+===============+ 913 | Value | Description | Reference | 914 +===========+==============+===============+ 915 | 0 | Reserved | This document | 916 +-----------+--------------+---------------+ 917 | 1- 175 | Unassigned | This document | 918 +-----------+--------------+---------------+ 919 | 176 - 239 | Unassigned | This document | 920 +-----------+--------------+---------------+ 921 | 240 - 251 | Experimental | This document | 922 +-----------+--------------+---------------+ 923 | 252 - 254 | Private Use | This document | 924 +-----------+--------------+---------------+ 925 | 255 | Reserved | This document | 926 +-----------+--------------+---------------+ 928 Table 11: SFC OAM TLV Type Registry 930 This document defines the following new values in SFC OAM TLV Type 931 registry: 933 +=======+====================+===============+ 934 | Value | Description | Reference | 935 +=======+====================+===============+ 936 | TBA12 | Multiple TLVs Used | This document | 937 +-------+--------------------+---------------+ 938 | TBA13 | Source ID TLV | This document | 939 +-------+--------------------+---------------+ 940 | TBA14 | Errored TLVs | This document | 941 +-------+--------------------+---------------+ 943 Table 12: SFC OAM Type Values 945 8.8. SFC OAM UDP Port 947 IANA is requested to allocate UDP port number according to 948 +=============+============+===================+============+=====================+=============+ 949 |Service Name |Port Number |Transport Protocol |Description |Semantics Definition |Reference | 950 +=============+============+===================+============+=====================+=============+ 951 |SFC OAM |TBA15 |UDP |SFC OAM Echo|Section 5.5 |This document| 952 | | | |Reply | | | 953 +-------------+------------+-------------------+------------+---------------------+-------------+ 955 Table 13: SFC OAM Port 957 9. References 959 9.1. Normative References 961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 962 Requirement Levels", BCP 14, RFC 2119, 963 DOI 10.17487/RFC2119, March 1997, 964 . 966 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 967 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 968 May 2017, . 970 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 971 "Network Service Header (NSH)", RFC 8300, 972 DOI 10.17487/RFC8300, January 2018, 973 . 975 9.2. Informative References 977 [I-D.ao-sfc-oam-return-path-specified] 978 Mirsky, G., Ao, T., Chen, Z., and G. Mishra, "Controlled 979 Return Path for Service Function Chain (SFC) OAM", Work in 980 Progress, Internet-Draft, draft-ao-sfc-oam-return-path- 981 specified-09, 30 March 2021, . 984 [I-D.ietf-sfc-nsh-integrity] 985 Boucadair, M., Reddy, T., and D. Wing, "Integrity 986 Protection for the Network Service Header (NSH) and 987 Encryption of Sensitive Context Headers", Work in 988 Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05, 989 23 March 2021, . 992 [I-D.ietf-sfc-nsh-tlv] 993 Wei, Y. (., Elzur, U., Majee, S., and C. Pignataro, 994 "Network Service Header Metadata Type 2 Variable-Length 995 Context Headers", Work in Progress, Internet-Draft, draft- 996 ietf-sfc-nsh-tlv-06, 12 May 2021, 997 . 999 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1000 RFC 792, DOI 10.17487/RFC0792, September 1981, 1001 . 1003 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1004 DOI 10.17487/RFC4302, December 2005, 1005 . 1007 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1008 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1009 . 1011 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1012 Control Message Protocol (ICMPv6) for the Internet 1013 Protocol Version 6 (IPv6) Specification", STD 89, 1014 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1015 . 1017 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1018 "IPv6 Flow Label Specification", RFC 6437, 1019 DOI 10.17487/RFC6437, November 2011, 1020 . 1022 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1023 Chaining (SFC) Architecture", RFC 7665, 1024 DOI 10.17487/RFC7665, October 2015, 1025 . 1027 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1028 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1029 May 2016, . 1031 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1032 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1033 Switched (MPLS) Data-Plane Failures", RFC 8029, 1034 DOI 10.17487/RFC8029, March 2017, 1035 . 1037 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1038 Writing an IANA Considerations Section in RFCs", BCP 26, 1039 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1040 . 1042 [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, 1043 R., and A. Ghanwani, "Service Function Chaining (SFC) 1044 Operations, Administration, and Maintenance (OAM) 1045 Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, 1046 . 1048 Authors' Addresses 1050 Greg Mirsky 1051 ZTE Corp. 1053 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 1055 Wei Meng 1056 ZTE Corporation 1057 No.50 Software Avenue, Yuhuatai District 1058 Nanjing, 1059 China 1061 Email: meng.wei2@zte.com.cn 1063 Bhumip Khasnabish 1064 Individual contributor 1066 Email: vumip1@gmail.com 1068 Cui Wang 1069 Individual contributor 1071 Email: lindawangjoy@gmail.com