idnits 2.17.1 draft-wang-sfc-multi-layer-oam-10.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2017) is 2409 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 (-28) exists of draft-ietf-sfc-nsh-21 == Outdated reference: A later version (-15) exists of draft-ietf-sfc-oam-framework-03 Summary: 0 errors (**), 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 Intended status: Standards Track W. Meng 5 Expires: March 25, 2018 ZTE Corporation 6 B. Khasnabish 7 ZTE TX, Inc. 8 C. Wang 9 September 21, 2017 11 Multi-Layer Active OAM for Service Function Chains in Networks 12 draft-wang-sfc-multi-layer-oam-10 14 Abstract 16 A multi-layer approach to the task of Operation, Administration and 17 Maintenance (OAM) of Service Function Chains (SFCs) in networks is 18 presented. Based on the requirements towards active OAM for SFC, a 19 multi-layer model is introduced. A mechanism to detect and localize 20 defects using the multi-layer model is also described. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 25, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Multi-layer Model of SFC OAM . . . . . . . . . . . . . . . . 4 61 4. Requirements for Multi-layer Model of Active OAM . . . . . . 4 62 5. Active OAM Identification in SFC NSH . . . . . . . . . . . . 6 63 6. SFC OAM multi-layer model . . . . . . . . . . . . . . . . . . 6 64 7. Echo Request/Echo Reply for SFC in Networks . . . . . . . . . 7 65 7.1. SFC Echo Request Transmission . . . . . . . . . . . . . . 9 66 7.2. SFC Echo Request Reception . . . . . . . . . . . . . . . 9 67 7.3. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 9 68 7.4. Overlay Echo Reply Reception . . . . . . . . . . . . . . 10 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 9.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 11 72 9.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 11 73 9.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 12 74 9.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 12 75 9.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 12 76 9.6. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 13 77 9.7. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 14 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 10.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 [RFC7665] defines components necessary to implement Service Function 86 Chain (SFC). These include a classifier which performs 87 classification of incoming packets. A Service Function Forwarder 88 (SFF) is responsible for forwarding traffic to one or more connected 89 Service Functions (SFs) according to the information carried in the 90 SFC encapsulation. SFF also handles traffic coming back from the SF 91 and transports the data packets to the next SFF. And the SFF serves 92 as termination element of the Service Function Path (SFP). SF is 93 responsible for specific treatment of received packets. 95 Resulting from that SFC is constructed by a number of these 96 components, there are different views from different levels of the 97 SFC. One is the SFC, fully abstract entity, that defines an ordered 98 set of SFs that must be applied to packets selected as a result of 99 classification. But SFC doesn't define exact mapping between SFFs 100 and SFs. Thus there exists another semi-abstract entity referred as 101 SFP. SFP is the instantiation of the SFC in the network and provides 102 a level of indirection between the fully abstract SFC and a fully 103 specified ordered list of SFFs and SFs identities that the packet 104 will visit when it traverses the SFC. The latter entity is being 105 referred as Rendered Service Path (RSP). The main difference between 106 SFP and RSP is that in the former the authority to select the SFF/SF 107 has been delegated to the network. 109 This document proposes the multi-layer model of SFC active Operation, 110 Administration and Maintenance (OAM), per [RFC7799] definition of 111 active OAM, lists requirements to improve the troubleshooting 112 efficiency and defines SFC Echo request and Echo reply that enables 113 on-demand Continuity Check, Connectivity Verification among other 114 operations over SFC in networks. 116 2. Conventions 118 2.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 2.2. Terminology 128 Unless explicitly specified in this document, active OAM in SFC and 129 SFC OAM are being used interchangeably. 131 e2e: End-to-End 133 FM: Fault Management 135 NSH: Network Service Header 137 OAM: Operations, Administration, and Maintenance 139 RDI: Remote Defect Indication 141 RSP: Rendered Service Path 143 SF: Service Function 144 SFC: Service Function Chain 146 SFF: Service Function Forwarder 148 SFP: Service Function Path 150 3. Multi-layer Model of SFC OAM 152 As described in [I-D.ietf-sfc-oam-framework], multiple layers come 153 into play to realize the SFC, including the Service layer, the 154 underlying Network layer, as well as the Link layer, which are 155 depicted in Figure 1: 157 o The Service layer consists of classifiers and/or service 158 functions/SFs. 160 o Network and Transport layers leverage various overlay network 161 technologies interconnecting SFs to establish SFP. 163 o The Link layer is technology specific and reflects the technology 164 used in the underlay network. 166 +---+ +---+ +---+ +---+ +---+ 167 |SF1| |SF2| |SF3| |SF4| |SF5| 168 +---+ +---+ +---+ +---+ +---+ 169 \ / \ / | 170 +----------+ +----+ +----+ +----+ 171 |Classifier|-------|SFF1|---------|SFF2|--------|SFF3| 172 +----------+ +----+ +----+ +----+ 173 0---------------------------------------------0 Service layer 174 0----------------0--------------0-------------0 Network layer 175 0-------------0------0-------0------0---------0 Link layer 177 Figure 1: SFC OAM Multi-Layer model 179 4. Requirements for Multi-layer Model of Active OAM 181 To perform the OAM task of fault management (FM) in an SFC, that 182 includes failure detection, defect characterization and localization, 183 this document defines the multi-layer model of OAM, presented in 184 Section 3, and set of requirements towards active OAM mechanisms to 185 be used on an SFC. 187 In example presented in Figure 1 the service SFP1 may be realized 188 through two RSPs, RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6). To 189 perform end-to-end (e2e) FM SFC OAM: 191 REQ#1: Packets of active OAM in SFC SHOULD be fate sharing with 192 data traffic, i.e. in-band with the monitored traffic, i.e. follow 193 exactly the same RSP, in forward direction, i.e. from ingress 194 toward egress end point(s) of the OAM test. 196 REQ#2: SFC OAM MUST support pro-active monitoring of any element 197 in the SFC availability. 199 The egress, SFF3 in example in Figure 1, is the entity that detects 200 the failure of the SFC. It must be able to signal the new defect 201 state to the ingress, i.e. SFF1. Hence the following requirement: 203 REQ#3: SFC OAM MUST support Remote Defect Indication (RDI) 204 notification by egress to the ingress, i.e. source of continuity 205 checking. 207 REQ#4: SFC OAM MUST support connectivity verification. Definition 208 of mis-connectivity defect entry and exit criteria are outside the 209 scope of this document. 211 Once the SFF1 detects the defect objective of OAM switches from 212 failure detection to defect characterization and localization. 214 REQ#5: SFC OAM MUST support fault localization of Loss of 215 Continuity check in the SFC. 217 REQ#6: SFC OAM MUST support tracing an SFP in order to realize the 218 RSP. 220 It is practical, as presented in Figure 1, that several SFs share the 221 same SFF. In such case SFP1 may be realized over two RSPs, 222 RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6). 224 REQ#7: SFC OAM MUST have the ability to discover and exercise all 225 available RSPs in the transport network. 227 In process of localizing the SFC failure separating SFC OAM layers is 228 very attractive and efficient approach. To achieve that continuity 229 among SFFs that are part of the same SFP should be verified. Once 230 SFFs reachability along the particular SFP has been confirmed task of 231 defect localization may focus on SF reachability verification. 232 Because reachability of SFFs has already been verified, SFF local to 233 the SF may be used as source. 235 REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses 236 being directed towards initiator of such proxy request. 238 5. Active OAM Identification in SFC NSH 240 The multi-layer model OAM that confirms to the above listed 241 requirements enables active OAM protocols that are capable to perform 242 efficient defect localization on an SFC. [I-D.ietf-sfc-nsh] does not 243 provide definition for identification of an SFC active OAM packet. 244 This document defines that active OAM packet on SFC MUST have OAM bit 245 set and MUST have the value on the Next Protocol field set to OAM 246 (TBA1) according to Section 9.1. 248 It is very unlikely that a single protocol will address all the 249 requirements listed in Section 4. Protocols may be identified by 250 destination UDP port number if IP/UDP encapsulation used. But extra 251 IP/UDP headers, especially in case of IPv6, add noticeable overhead. 252 This document defines Active OAM Header Figure 2 to demultiplex 253 active OAM protocols on an SFC. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | V | Msg Type | Flags | Length | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 ~ SFC Active OAM Control Packet ~ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 2: SFC Active OAM Header 265 V - two bits long field indicates the current version of the SFC 266 active OAM header. The current value is 0. 268 Msg Type - six bits long field identifies OAM protocol, e.g. Echo 269 Request/Reply or BFD. 271 Flags - eight bits long field carries bit flags that define 272 optional capability and thus processing of the SFC active OAM 273 control packet, e.g. optional timestamping. 275 Length - two octets long field that is length of the SFC active 276 OAM control packet in octets. 278 6. SFC OAM multi-layer model 280 Figure 3 presents a use case of applying the proposed SFC OAM multi- 281 layer model. In this scenario operator needs to discover SFFs and 282 SFs of the same SFC. The Layer 1 includes the SFFs that are part of 283 the SFP. The Layer 2 - the SFs along the RSP. When trying to do SFC 284 OAM, classifier or service nodes select and confirm which SFC OAM 285 layering they plan to do, then encapsulate the layering information 286 in the SFC OAM packets, and send the SFC OAM packets along the 287 service function paths to the destination. When receiving the SFC 288 OAM packets, service nodes analyze the layering information and then 289 decide whether sending these packets to next SFFs directly without 290 being processed by SFs for Layer 1 process or sending to SFs for 291 Layer 2 process. 293 +---+ +---+ +----+ +----+ +-----+ +-----+ +------+ +------+ 294 |SF1|.|SFn| |SF1'|.|SFn'| |SF1''|.|SFn''| |SF1'''|.|SFn'''| 295 +---+ +---+ +----+ +----+ +-----+ +-----+ +------+ +------+ 296 \ / \ / | \ / \ / | 297 +------+ +----+ +----+ | +-----+ +-----+ | 298 |Class.|---|SFF1| ... |SFFn| | |SFF1'| ... |SFFn'| | 299 +------+ +----+ +----+ | +-----+ +-----+ | 300 | | | | 301 | | | | 302 |----|------Layer 1---------------| | 303 | | 304 |-------------Layer 2-------------| 306 Figure 3: SFC OAM multi-layering model 308 7. Echo Request/Echo Reply for SFC in Networks 310 Echo Request/Reply is well-known active OAM mechanism that is 311 extensively used to detect inconsistencies between states in control 312 plane and data plane, localize defects in the data plane. The format 313 of the Echo request/Echo reply control packet is to support ping and 314 traceroute functionality in SFC in networks Figure 4 resembles the 315 format of MPLS LSP Ping [RFC8029] with some exceptions. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Version Number | Global Flags | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Message Type | Reply mode | Return Code | Return S.code | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Sender's Handle | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Sequence Number | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 ~ TLVs ~ 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 4: SFC Echo Request/Reply format 333 The interpretation of the fields is as following: 335 The Version reflects the current version. The version number is 336 to be incremented whenever a change is made that affects the 337 ability of an implementation to correctly parse or process control 338 packet. 340 The Global Flags is a bit vector field 342 The Message Type filed reflects the type of the packet. Value 343 TBA3 identifies echo request and TBA4 - echo reply 345 The Reply Mode defines the type of the return path requested by 346 the sender of the echo request. 348 Return Codes and Subcodes can be used to inform the sender about 349 result of processing its request. 351 The Sender's Handle is filled in by the sender, and returned 352 unchanged by the receiver in the echo reply. 354 The Sequence Number is assigned by the sender and can be (for 355 example) used to detect missed replies. 357 TLVs (Type-Length-Value tuples) have the two octets long Type 358 field, two octets long Length field that is length of the Value 359 field in octets. 361 7.1. SFC Echo Request Transmission 363 SFC echo request control packet MUST use the appropriate 364 encapsulation of the monitored SFP. If Network Service Header (NSH) 365 is used, echo request MUST set O bit, as defined in 366 [I-D.ietf-sfc-nsh]. SFC NSH MUST be immediately followed by the SFC 367 Active OAM Header defined in Section 5. Message Type field in the 368 SFC Active OAM Header MUST be set to SFC Echo Request/Echo Reply 369 value (TBA2) per Section 9.2. 371 Value of the Reply Mode field MAY be set to: 373 o Do Not Reply (TBA5) if one-way monitoring is desired. If echo 374 request is used to measure synthetic packet loss, the receiver may 375 report loss measurement results to a remote node. 377 o Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the 378 most used. 380 o Reply via Application Level Control Channel (TBA7) value if the 381 SFP may have bi-directional paths. 383 o Reply via Specified Path (TBA7) value in order to enforce use of 384 the particular return path specified in the included TLV to verify 385 bi-directional continuity and also increase robustness of the 386 monitoring by selecting more stable path. 388 7.2. SFC Echo Request Reception 390 7.3. SFC Echo Reply Transmission 392 The Reply Mode field directs whether and how the echo reply message 393 should be sent. The sender of the echo request MAY use TLVs to 394 request that corresponding echo reply be sent using the specified 395 path. Value TBA3 is referred as "Do not reply" mode and suppresses 396 transmission of echo reply packet. Default value (TBA6) for the 397 Reply mode field requests the responder to send the echo reply packet 398 out-of-band as IPv4 or IPv6 UDP packet. 400 Responder to the SFC echo request sends the echo reply over IP 401 network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet. 402 Because SFC NSH does not identify the ingress of the SFP the echo 403 request MUST include this information that to be used as IP 404 destination address for IP/UDP encapsulation of the SFC echo reply. 405 Sender of the SFC echo request MUST include SFC Source TLV Figure 5. 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | SFC OAM Source ID Type | Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Value | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 5: SFC Source TLV 417 where 419 SFC OAM Source Id Type is two octets in length and has the value 420 of TBA9 Section 9.6. 422 Length is two octets long field and the values is equal to the 423 length of the Value field. 425 Value field contains IP address of the sender of the SFC OAM 426 control message, IPv4 or IPv6. 428 The UDP destination port for SFC Echo Reply TBA10 will be allocated 429 by IANA Section 9.7. 431 7.4. Overlay Echo Reply Reception 433 8. Security Considerations 435 Overlay Echo Request/Reply operates withing the domain of the overlay 436 network and thus inherits any security considerations that apply to 437 the use of that overlay technology and, consequently, underlay data 438 plane. Also, the security needs for SFC echo request/reply are 439 similar to those of ICMP ping [RFC0792], [RFC4443] and MPLS LSP ping 440 [RFC8029]. 442 There are at least three approaches of attacking a node in the 443 overlay network using the mechanisms defined in the document. One is 444 a Denial-of-Service attack, by sending SFC ping to overload an 445 element of the SFC. The second may use spoofing, hijacking, 446 replying, or otherwise tampering with SFC echo requests and/or 447 replies to misrepresent, alter operator's view of the state of the 448 SFC. The third is an unauthorized source using an SFC echo request/ 449 reply to obtain information about the SFC and/or its elements, e.g. 450 SFF or SF. 452 To mitigate potential Denial-of-Service attacks, it is RECOMMENDED 453 that implementations throttle the SFC ping traffic going to the 454 control plane. 456 Reply and spoofing attacks involving faking or replying SFC echo 457 reply messages would have to match the Sender's Handle and Sequence 458 Number of an outstanding SFC echo request message which is highly 459 unlikely. Thus the non-matching reply would be discarded. 461 To protect against unauthorized sources trying to obtain information 462 about the overlay and/or underlay an implementation MAY check that 463 the source of the echo request is indeed part of the SFP. 465 9. IANA Considerations 467 9.1. SFC Active OAM Protocol 469 IANA is requested to assign new type from the SFC Next Protocol 470 registry as follows: 472 +-------+----------------+---------------+ 473 | Value | Description | Reference | 474 +-------+----------------+---------------+ 475 | TBA1 | SFC Active OAM | This document | 476 +-------+----------------+---------------+ 478 Table 1: SFC Active OAM Protocol 480 9.2. SFC Active OAM Message Type 482 IANA is requested to create new registry called "SFC Active OAM 483 Message Type". All code points in the range 1 through 32767 in this 484 registry shall be allocated according to the "IETF Review" procedure 485 as specified in [RFC8126] . Remaining code points are allocated 486 according to the table Table 2: 488 +---------------+-------------+-------------------------+ 489 | Value | Description | Reference | 490 +---------------+-------------+-------------------------+ 491 | 0 | Reserved | | 492 | 1 - 32767 | Reserved | IETF Consensus | 493 | 32768 - 65530 | Reserved | First Come First Served | 494 | 65531 - 65534 | Reserved | Private Use | 495 | 65535 | Reserved | | 496 +---------------+-------------+-------------------------+ 498 Table 2: SFC Active OAM Message Type 500 IANA is requested to assign new type from the SFC Active OAM Message 501 Type registry as follows: 503 +-------+-----------------------------+---------------+ 504 | Value | Description | Reference | 505 +-------+-----------------------------+---------------+ 506 | TBA2 | SFC Echo Request/Echo Reply | This document | 507 +-------+-----------------------------+---------------+ 509 Table 3: SFC Echo Request/Echo Reply Type 511 9.3. SFC Echo Request/Echo Reply Parameters 513 IANA is requested to create new SFC Echo Request/Echo Reply 514 Parameters registry. 516 9.4. SFC Echo Request/Echo Reply Message Types 518 IANA is requested to create in the SFC Echo Request/Echo Reply 519 Parameters registry the new sub-registry Message Types. All code 520 points in the range 1 through 191 in this registry shall be allocated 521 according to the "IETF Review" procedure as specified in [RFC8126] 522 and assign values as follows: 524 +------------+------------------+-------------------------+ 525 | Value | Description | Reference | 526 +------------+------------------+-------------------------+ 527 | 0 | Reserved | | 528 | TBA3 | SFC Echo Request | This document | 529 | TBA4 | SFC Echo Reply | This document | 530 | TBA4+1-191 | Unassigned | IETF Review | 531 | 192-251 | Unassigned | First Come First Served | 532 | 252-254 | Unassigned | Private Use | 533 | 255 | Reserved | | 534 +------------+------------------+-------------------------+ 536 Table 4: SFC Echo Request/Echo Reply Message Types 538 9.5. SFC Echo Reply Modes 540 IANA is requested to create in the SFC Echo Request/Echo Reply 541 Parameters registry the new sub-registry Reply Modes All code points 542 in the range 1 through 191 in this registry shall be allocated 543 according to the "IETF Review" procedure as specified in [RFC8126] 544 and assign values as follows: 546 +------------+---------------------------------+--------------------+ 547 | Value | Description | Reference | 548 +------------+---------------------------------+--------------------+ 549 | 0 | Reserved | | 550 | TBA5 | Do Not Reply | This document | 551 | TBA6 | Reply via an IPv4/IPv6 UDP | This document | 552 | | Packet | | 553 | TBA7 | Reply via Application Level | This document | 554 | | Control Channel | | 555 | TBA8 | Reply via Specified Path | This document | 556 | TBA8+1-191 | Unassigned | IETF Review | 557 | 192-251 | Unassigned | First Come First | 558 | | | Served | 559 | 252-254 | Unassigned | Private Use | 560 | 255 | Reserved | | 561 +------------+---------------------------------+--------------------+ 563 Table 5: SFC Echo Reply Modes 565 9.6. SFC TLV Type 567 IANA is requested to create SFC OAM TLV Type registry. All code 568 points in the range 1 through 32759 in this registry shall be 569 allocated according to the "IETF Review" procedure as specified in 570 [RFC8126]. Code points in the range 32760 through 65279 in this 571 registry shall be allocated according to the "First Come First 572 Served" procedure as specified in [RFC8126]. Remaining code points 573 are allocated according to the Table 6: 575 +---------------+--------------+-------------------------+ 576 | Value | Description | Reference | 577 +---------------+--------------+-------------------------+ 578 | 0 | Reserved | This document | 579 | 1- 32759 | Unassigned | IETF Review | 580 | 32760 - 65279 | Unassigned | First Come First Served | 581 | 65280 - 65519 | Experimental | This document | 582 | 65520 - 65534 | Private Use | This document | 583 | 65535 | Reserved | This document | 584 +---------------+--------------+-------------------------+ 586 Table 6: SFC TLV Type Registry 588 This document defines the following new value in SFC OAM TLV Type 589 registry: 591 +-------+-------------------+---------------+ 592 | Value | Description | Reference | 593 +-------+-------------------+---------------+ 594 | TBA9 | Source IP Address | This document | 595 +-------+-------------------+---------------+ 597 Table 7: SFC OAM Source IP Address Type 599 9.7. SFC OAM UDP Port 601 IANA is requested to allocate UDP port number according to 603 +---------+--------+------------+---------+--------------+----------+ 604 | Service | Port | Transport | Descrip | Semantics | Referenc | 605 | Name | Number | Protocol | tion | Definition | e | 606 +---------+--------+------------+---------+--------------+----------+ 607 | SFC OAM | TBA10 | UDP | SFC OAM | Section 7.3 | This | 608 | | | | | | document | 609 +---------+--------+------------+---------+--------------+----------+ 611 Table 8: SFC OAM Port 613 10. References 615 10.1. Normative References 617 [I-D.ietf-sfc-nsh] 618 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 619 Header (NSH)", draft-ietf-sfc-nsh-21 (work in progress), 620 September 2017. 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 628 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 629 May 2017, . 631 10.2. Informative References 633 [I-D.ietf-sfc-oam-framework] 634 Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, 635 R., and A. Ghanwani, "Service Function Chaining (SFC) 636 Operation, Administration and Maintenance (OAM) 637 Framework", draft-ietf-sfc-oam-framework-03 (work in 638 progress), September 2017. 640 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 641 RFC 792, DOI 10.17487/RFC0792, September 1981, 642 . 644 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 645 Control Message Protocol (ICMPv6) for the Internet 646 Protocol Version 6 (IPv6) Specification", STD 89, 647 RFC 4443, DOI 10.17487/RFC4443, March 2006, 648 . 650 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 651 Chaining (SFC) Architecture", RFC 7665, 652 DOI 10.17487/RFC7665, October 2015, 653 . 655 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 656 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 657 May 2016, . 659 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 660 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 661 Switched (MPLS) Data-Plane Failures", RFC 8029, 662 DOI 10.17487/RFC8029, March 2017, 663 . 665 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 666 Writing an IANA Considerations Section in RFCs", BCP 26, 667 RFC 8126, DOI 10.17487/RFC8126, June 2017, 668 . 670 Authors' Addresses 672 Greg Mirsky 673 ZTE Corp. 675 Email: gregimirsky@gmail.com 677 Wei Meng 678 ZTE Corporation 679 No.50 Software Avenue, Yuhuatai District 680 Nanjing 681 China 683 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com 684 Bhumip Khasnabish 685 ZTE TX, Inc. 686 55 Madison Avenue, Suite 160 687 Morristown, New Jersey 07960 688 USA 690 Email: bhumip.khasnabish@ztetx.com 692 Cui Wang 694 Email: lindawangjoy@gmail.com