idnits 2.17.1 draft-eastlake-sfc-parallel-01.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 (July 29, 2021) is 1002 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended status: Proposed Standard Futurewei Technologies 3 Expires: January 26, 2022 July 29, 2021 5 Service Function Chaining (SFC) Parallelism and Diversions 6 8 Abstract 9 Service Function Chaining (SFC) is the processing of packets through 10 a sequence of Service Functions (SFs) within an SFC domain by the 11 addition of path information and metadata on entry to that domain, 12 the use and modification of that path information and metadata to 13 step the packet through a sequence of SFs, and the removal of that 14 path information and metadata on exit from that domain. The IETF has 15 standardized a method for SFC using the Network Service Header 16 specified in RFC 8300. 18 There are requirements for SFC to process packets through parallel 19 sequences of service functions and to easily splice in additional 20 service functions or splice service functions out of a service chain. 21 This document provides use cases for these requirements and 22 extensions to SFC to support them. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Distribution of this document is unlimited. Comments should be sent 30 to the SFC Working Group mailing list or to the 31 authors. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 45 Shadow Directories can be accessed at 46 https://www.ietf.org/shadow.html. 48 Table of Contents 50 1. Introduction............................................3 51 1.1 Conventions Used in This Document......................3 53 2. Service Function Chaining Background....................5 54 2.1 The Network Service Header (NSH).......................6 55 2.2 NSH Metadata and Variable Length Context Headers.......7 57 3. Requirements for Parallelism and Diversions.............9 59 4. Diversion Points and Rendezvous Points.................12 60 4.1 Rendezvous Point Information (RePIn)..................12 61 4.1.1 Packet Identifier...................................13 62 4.1.2 Packet Extent Modified..............................14 63 4.1.3 Saved Metadata......................................15 64 4.1.4 Saved TTL...........................................15 65 4.2 Diversion Point (DP) Behavior.........................16 66 4.3 Rendezvous Point (RP) Behavior........................18 68 5. IANA Considerations....................................20 69 5.1 Variable Length Context Header Type...................20 70 5.2 RePIn VLCH Sub-Types..................................20 72 6. Security Considerations................................21 74 Normative References......................................22 75 Informative References....................................22 77 Appendix: Relation to Hierarchical SFC....................23 78 Acknowledgements..........................................23 79 Authors' Addresses........................................23 81 1. Introduction 83 Service Function Chaining (SFC) is the processing of packets through 84 a sequence of Service Functions (SFs) within an SFC domain by the 85 addition of path information and metadata on entry to that domain, 86 the use and modification of that path information and metadata to 87 step the packet through a sequence of SFs, and the removal of that 88 path information and metadata on exit from that domain. The IETF has 89 standardized a method for SFC using the Network Service Header 90 specified in [RFC8300]. 92 There are requirements for SFC to process packets through parallel 93 sequences of service functions and to easily splice in additional 94 service functions or splice service functions out of a service chain. 95 This document provides use cases for these requirements and 96 extensions to SFC to support them. 98 1.1 Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 Acronyms and terms: 108 downstream - The direction from ingress to egress. 110 diversion - A reclassification of an SFC packet into one or 111 multiple parallel packets with a difference SPI where this 112 reclassified packet or packets are, in the normal case, 113 combined at a downstream rendezvous point which restores the 114 original SPI. 116 DP - Diversion Point - An SF implementing a diversion. 118 MD - Metadata - Part of the NSH. 120 NSH - Network Service Header [RFC8300]. 122 rendezvous - The process of taking one or more corresponding SFC 123 packets that have been diverted at an upstream DP, combining 124 the packets if there are more than one, and restoring the 125 original SPI. 127 RePIn - Rendezvous Point Information. Metadata included in an SFC 128 packet for use at an RP. 130 RP - Rendezvous Point - An SF implementing a rendezvous. 132 SF - Service Function [RFC7665]. 134 SFC - Service Function Chaining [RFC7665]. 136 SFF - Service Function Forwarder [RFC7665] - A type of node that 137 forwards based on the NSH. 139 SFP - Service Function Path. 141 SI - Service Index - Part of the NSH. 143 SPI - Service Path Identifier - Part of the NSH. 145 TLV - Type Length Value. 147 upstream - The direction from egress to ingress. 149 VLCH - Variable Length Context Header - A type of NSH header 150 metadata. 152 2. Service Function Chaining Background 154 Service Function Chaining (SFC) calls for the encapsulation of 155 traffic within a service function chaining domain using a Network 156 Service Header (NSH [RFC8300]) added by the "Classifier" (ingress 157 node) on entry to the domain and the NSH being removed on exit from 158 the domain at the downstream egress node as shown in Figure 1. The 159 NSH controls the path of a packet in an SFC domain and includes 160 additional information. 162 | 163 v 164 +----------+ 165 . .|Classifier|. . . . . . . . . . . . . . 166 . +----------+ . 167 . | +----+ . 168 . | --+ SF | Service . 169 . | / +----+ Function . 170 . v --- Chaining . 171 . +-----+/ +----+ domain . 172 . | SFF |--------+ SF | . 173 . +-----+\ +----+ . 174 . | --- . 175 . | \ +----+ . 176 . | --+ SF | . 177 . v +----+ . 178 . +-----+ +----+ . 179 . | SFF |-----------------+ SF | . 180 . +-----+ +----+ . 181 . | +----+ . 182 . | --+ SF | . 183 . | / +----+ . 184 . v --- . 185 . +-----+/ +----+ . 186 . | SFF |--------+ SF | . 187 . +-----+\ +----+ . 188 . | --- . 189 . | \ +----+ . 190 . | --+ SF | . 191 . v +----+ . 192 . +------+ . 193 . . .| Exit |. . . . . . . . . . . . . . . 194 +------+ 195 | 196 v 198 Figure 1. Example SFC Path Forwarding Nodes 200 Traffic passes through a sequence of Service Function Forwarders 201 (SFFs) each of which sends the traffic to one or, sequentially, more 202 than one Service Functions (SFs). Each SF performs some operation on 203 the traffic, for example firewall or Network Address Translation 204 (NAT) or load balancer, and then returns it to the SFF from which it 205 was received. There may be multiple instances of SFs performing the 206 same function attached to the same or different SFFs. 208 Logically, during the transit of an SFF, the outer transport header 209 that got the packet to the SFF is stripped (see Figure 2), the SFF 210 decides on the next forwarding step, either (1) adding a new 211 transport header or (2) in case of error discarding or logging the 212 packet and not forwarding it or, (3) if the SFF is the exit/egress, 213 removing the NSH header and then adding a new transport header. The 214 transport used may be different in different regions of the SFC 215 domain. For example, a version of the Internet Protocol (IP) could be 216 used in some part and Multi-Protocol Label Switching (MPLS) used in 217 other part of the SFC domain. 219 +-----------------------------------+ 220 | Outer Transport Header | 221 +-----------------------------------+ 222 | Network Service Header (NSH) | 223 | +------------------------------+ | 224 | | Base Header | | 225 | +------------------------------+ | 226 | | Service Path Header | | 227 | +------------------------------+ | 228 | | Metadata (Context Header(s)) | | 229 | +------------------------------+ | 230 +-----------------------------------+ 231 | Original Packet / Frame / Payload | 232 +-----------------------------------+ 234 Figure 2. Data Encapsulation with the NSH 236 An SF can receive one or more SFC packets from an SFF and return to 237 it a larger or smaller number of SFC packets; that is to say, SFC 238 packets can be discarded or created by an SF. 240 2.1 The Network Service Header (NSH) 242 The NSH header is used to encapsulate and control the subsequent path 243 of traffic. It consists of three parts, the initial 32-bit Base 244 Header, the 32-bit Service Path Header, and any Context Headers 245 holding metadata, as shown in more detail in Figure 3 and specified 246 in [RFC8300]. 248 The Base Header includes a Length field whose value is the overall 249 NSH length. Because the Base Header and Service Path Header are fixed 250 length, the length of the Metadata can be computed from this Length 251 field. The Base Header also includes a field indicating the type of 252 metadata in the NSH. 254 The Service Path Header consists of a Service Path Identifier (SPI) 255 and a Service Index (SI). The SPI identifies the logical path the 256 packet should follow while the SI indicates which step along that 257 path the packet is at. 259 An SF anywhere along a Service Function Path can re-classify an SFC 260 packet by replacing the Service Path Identifier (SPI) and Service 261 Index (SI) in the NSH. SFFs can also insert, delete, or change 262 metadata (Context Header(s)) in the NSH. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Service Path Identifier | Service Index | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Optional Context Headers / Metadata ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 274 Figure 3. Network Service Header Details from [RFC8300] 276 2.2 NSH Metadata and Variable Length Context Headers 278 If the MD Type field in the NSH Base Header has the value 1, there is 279 a single fixed length 128-bit Context Header whose format is not 280 further defined by the IETF. In that case, the NSH Length field has 281 the value 6. 283 If the MD Type field has the value 2, there are zero or more 284 Variable-Length Context Headers (VLCHs) as shown in Figure 4 at the 285 end of the NSH. The absence of any Context Headers is indicated by 286 using MD Type 2 and an NSH Length of 2. MD Type 0 is reserved and MD 287 Types 3 through 15 are unassigned. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Metadata Class | Length |U| Type | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Variable Length Metadata ~ 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 297 Figure 4. Variable Length Context Header 299 The minimum size for a VLCH is 32 bits consisting of the Metadata 300 Class, Type, one unused bit, and Length as shown in Figure 4. 302 The Metadata Class field is 16 bits, and its value specifies the 303 organization under which the particular of VLCHs specified. Metadata 304 Class zero is the IETF base class. The 8-bit Type field's value, 305 along with the Metadata Class value, indicates the meaning of the 306 Context Header and its Variable-Length Metadata. The size of the 307 Length field is 7 bits and its value gives the length in octets of 308 the Variable-Length Metadata that follows the initial fixed length 309 portion of the VLCH. A VLCH with no Variable-Length Metadata is 310 indicated by a Length field whose value is zero. VLCHs are padded so 311 that they always start and end at a multiple of 4 bytes from the 312 beginning of the NSH. 314 3. Requirements for Parallelism and Diversions 316 There are requirements to split a Service Function Chain (SFC) into 317 two or more parallel Service Function Paths (SFPs) that later rejoin 318 as shown in Figure 5. 320 +------+ +-----+ 321 ----->|SFF 2a|<---->| SF 2| 322 / +------+\ +-----+ 323 / \____ 324 / \ 325 +-----+/ +------+ ->+-----+ 326 ---->|SFF 1|--------->|SFF 2b|-------->|SFF 3|-----> 327 +-----+\ +------+ ->+-----+ 328 /|\ \ /|\ / /|\ 329 | \ | / | 330 \|/ \ \|/ | \|/ 331 +-----+ \ +-----+ | +-----+ 332 | SF 1| \ | SF 3| / | SF 5| 333 | DP | \ +-----+ / | RP | 334 +-----+ \ / +-----+ 335 \ +------+/ +-----+ 336 ->|SFF 2c|<---->| SF 4| 337 +------+ +-----+ 339 Figure 5: Parallel Service Function Paths 341 For example, there may be two or more Service Functions (SFs) that 342 can be performed in parallel with the goal, for time critical traffic 343 such as some financial or gaming traffic, of delaying the stream of 344 packets only by the amount of time taken by the slowest single SF; if 345 the packets went through the SFs sequentially, the delay would be the 346 sum of the times taken by each of the SFs. An example of such 347 potential parallel processing might be that the SFs operate of 348 different parts of the packet such as one SF operating on packet 349 addressing while another operates on the information payload. Another 350 example might be that one SF creates a signature or integrity code 351 over parts of the packet to be inserted into the packet payload while 352 another SF encrypts parts of the packet (or alternatively, they 353 verify and decrypt in parallel). 355 Another example of desirable parallelism would be improved 356 reliability or accuracy if the SFs executed in parallel were 357 unreliable or were different implementations of doing the same 358 processing. For example, some quantum computers are currently 359 unreliable so it would be desirable to perform some quantum process 360 several times and compare the results to pick the most common value, 361 or a vote could be taken between the results of different 362 implementations of some process. 364 In Figure 5 it could be that any of the parallel paths could have 365 more or less than one SFF, although exactly one is shown in the 366 example for simplicity and any of the SFFs in any of the parallel 367 SFPs could process a packet through more than one SF, although they 368 are shown using only one SF in Figure 5 for simplicity. (Note that 369 while SFFs implement an SFP, SFPs logically consists of the sequence 370 of SFs. Thus, for example, an SFP could divert into multiple parallel 371 SFPs that rejoin at an RP all implemented through SFs off of one and 372 the same SFF.) It could also be that one or more of the parallel 373 paths would themselves further split into parallel paths and so on. 375 There are cases where it is desirable to divert an SFP so as to 376 splice one or more added SFs into that SFP or to divert it so as to 377 slice out one or more sequential SFs that were downstream in that 378 SFP, as shown in Figures 6 and 7. Although SF 3 in each of those two 379 cases could re-classify the packet with a new SPI and SI that include 380 the remainder of the new diverted path, this would require that a new 381 SFP with this new SPI already be configured in all the SFFs for the 382 remainder of the Service Function Path after a diversion. In the case 383 of Figure 7, SF 3 could possibly just adjust the Service Index, but 384 this would require relaxing any checking at SF 5 of the SPI/SI or 385 source address of packets on the main SFP or may otherwise be 386 undesirable. 388 +-----+ +-----+ 389 ->|SFF 3| <---->| SF 4| 390 / +-----+\ +-----+ 391 / \ 392 +-----+ +-----+ ->+-----+ +-----+ 393 --->|SFF 1|----->|SFF 2| - - - - - - >|SFF 4|----->|SFF 5|---> 394 +-----+ +-----+ +-----+ +-----+ 395 /|\ /|\ /|\ /|\ 396 | | | | 397 \|/ \|/ \|/ \|/ 398 +-----+ +-----+ +-----+ +-----+ 399 | SF 1| | SF 3| | SF 5| | SF 6| 400 +-----+ | DP | | RP | +-----+ 401 +-----+ +-----+ 403 Figure 6: Splicing in One or More SFFs 404 ------------\ 405 / \ 406 / \ 407 +-----+ +-----+ +-----+ \->+-----+ 408 --->|SFF 1|----->|SFF 2|- - ->|SFF 4|- - ->|SFF 5|---> 409 +-----+ +-----+ +-----+ +-----+ 410 /|\ /|\ /|\ /|\ 411 | | | | 412 \|/ \|/ \|/ \|/ 413 +-----+ +-----+ +-----+ +-----+ 414 | SF 1| | SF 3| | SF 5| | SF 5| 415 +-----+ | DP | +-----+ | RP | 416 +-----+ +-----+ 418 Figure 7: Splicing out One or More SFFs 420 Combinations of the cases shown in Figures 5, 6, and 7 may be needed 421 where a diversion such as in Figures 6 or 7 occur within a parallel 422 path as in Figure 5 or parallel paths as in Figure 5 occur within a 423 diversion as in Figure 6. Generalizing Figure 6 and 7, a diversion 424 might splice in a path with some number of SFs that cuts out a 425 portion of the original SFP that had some number of SFs. 427 Although DPs and RPs are logically Service Functions (SFs) and shown 428 as separate boxes in the above figures, like any other SF they can be 429 implemented as co-located with an SFF. 431 4. Diversion Points and Rendezvous Points 433 SF 1 in Figure 5 and SF 3 in Figures 6 and 7 are referred to as 434 Diversion Points (DPs) because they are nodes at which an SFP is 435 diverted to one or more SFPs with new SPIs that are intended to 436 rejoint/return to the original SPI at a downstream Rendezvous Point. 437 SF 5 in Figures 5, 6, and 7 is referred to as a Rendezvous Point (RP) 438 because it is the node at which one or more SFPs from an upstream DP 439 rejoin an original SFP and SPI. The packets so received at an RP are 440 merged or coordinated. 442 In general, an RP needs to be configured to expect SFC packets to 443 arrive at that RP on diverted SFPs. An RP may need additional 444 information in the SFC packets, as discussed in Section 4.1, to be 445 included in their NSH. Divergence point behavior is discussed in 446 Section 4.2 and RP behavior is discussed in Section 4.3. 448 4.1 Rendezvous Point Information (RePIn) 450 To recombine packets from divergent SFP(s) at a Rendezvous Point 451 (RP), or rejoin a diverted SFP to the original SFP, additional 452 information may be needed in the packets. This is accomplished 453 through inclusion of the RP Information (RePIn) Variable Length 454 Context Header (VLCH), as shown in Figure 8, in the packet's NSH. 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Metadata Class = 0x0000 | Type=TBD |U| Length | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Saved Service Path Identifier | Saved SI | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Variable Length Sub-TLVs ~ 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 466 Figure 8: RePIn VLCH 468 The Length field is the total length of the Variable Length Sub-TLVs 469 in octets. 471 The Saved Service Path Identifier and Saved SI are the SPI and SI in 472 the NSH of the SFC packet being diverted after entry to the DP SF and 473 the SI has been decremented. 475 The Variable Length Sub-TLVs consist of zero or more RePIn VLCH Sub- 476 TLVs. The format of a RePIn VLCH Sub-TLV is as shown in Figure 9 477 except for Sub-Type 1 as discussed in Section 4.1.1; however, all 478 RePIn VLCH Sub-TLVs are padded at the end up to an even multiple of 4 479 octets. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Sub-Type |X|Sub-Length | Variable Length Metadata ~ 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 487 Figure 9: General RePIn VLCH Sub-TLV 489 The Sub-Type field is an 8-bit unsigned integer that is always 490 present and indicates the format of the rest of the Sub-TLV. The X 491 bit may be assigned a meaning for particular Sub-Types; if no such 492 meaning is assigned for a particular Sub-Type, the X bit MUST be sent 493 as zero and ignored on receipt. Sub-Length is an unsigned integer 494 giving the length of the variable length metadata in octets. 496 Unless the specification for a RePIn VLCH Sub-TLV Sub-Type specifies 497 that there may be multiple occurrences of that Sub-TLV, it may only 498 be included once. If there are multiple instances, the first 499 occurrence is used with any subsequent occurrences being ignored. 501 4.1.1 Packet Identifier 503 When an SFC packet is replicated and diverted to more than one 504 parallel path to be merged back together at a Rendezvous Point (RP), 505 a method of matching packets is needed such as labeling each copy 506 that originated with the same packet before the split using a packet 507 identifier such as a packet counter, fine grained time stamp, or hash 508 code. Such an identifier might already exist in the packet, for 509 example a TCP sequence number. If not, it is included as a VLCH 510 special Sub-TLV as shown below. Use of a packet counter is 511 RECOMMENDED. 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 | Sub-Type=1 | Packet Identifier | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 9: Packet Identifier Special Sub-TLV 521 Because this is expected to be a common RePIn VLCH Sub-TLV, in order 522 to save octets, for this Sub-Type only, the "Sub-TLV" X and Sub- 523 Length fields are subsumed into the Packet Identifier field. 525 4.1.2 Packet Extent Modified 527 If two or more SFPs used in parallel have modified parts of a packet, 528 the RP may need additional information to be able to recombine the 529 different copies of the packet it will be receiving. As an example of 530 the complexities involved, an SF could change the length of part of a 531 packet in a way dependent on the content of that part such as by 532 applying a data compression or de-compression algorithm to part of 533 the packet or by conditionally inserting or removing a VLAN tag 534 depending on addressing information. 536 In simple cases such as parallel SFPs that modify fixed size disjoint 537 parts of a packet without changing the size of those parts, it may be 538 possible for an RP to be configured to recombine the results without 539 added information. But in more complex or variable length cases, 540 parallel SFPs need to add information as to what part of the original 541 packet they modified and how this may have changed the length of that 542 part. Also, with such additional information, in some cases only one 543 of the parallel SFPs would need to forward all of the original packet 544 with modifications to the RP; one or more other parallel SFPs could 545 just forward their modified part and the RP would be able to 546 recombine the results thus saving communications link capacity that 547 would be used if they all sent full packets. 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Sub-Type=2 |X|Sub-Length=6 | Offset | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Priority | Original Size | Modified Size | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Figure 10: Packet Extent Modified Sub-TLV 559 If the X bit is zero, the entire modified packet is present in the 560 SFC packet. If the X bit is a one, only the modified portion appears 561 in the packet which requires any SFs between the SF that modified the 562 packet and the RP to be capable of handling such an abbreviated 563 packet. 565 Offset is the number of bits between the end of the NSH or the last 566 NSH if there are multiple stacked NSHs and the portion of the packet 567 being modified. Original Size and Modified Size are the size in bits 568 of the portion being modified before and after that modification. Any 569 of the Offset, Original Size, and Modified Size fields may have the 570 value zero. 572 If parallel SFPs have modified the same or overlapping parts of a 573 packet, the RP may need some way to resolve this conflict which could 574 include a relative priority for changes made by different SFs 575 configured at the RP and/or indicated in the RP Information (RePIn) 576 or from other sources. The Priority field MAY be used for this 577 purpose; it contains an unsigned integer where a larger magnitude 578 value indicates a higher priority that would prevail over a lower 579 priority. If not used, the Priority field MUST be sent as zero and 580 ignored on receipt. 582 If a path has modified more than one portion of a packet, multiple 583 instance of the Packet Extent Modified Sub-TLV can be included in the 584 RePIn VLCH. 586 4.1.3 Saved Metadata 588 A DP may need to save Metadata so it need not be seen inside a 589 diversion and will be restored at the RP. This Sub-TLV is used for 590 that purpose. See Section 4.2 and 4.3 for further details of use. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Sub-Type=3 |X| Sub-Length | MBZ |MetaTyp| 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Variable Length Saved Metadata ~ 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 600 Figure 10: Saved Metadata Sub-TLV 602 The X and MBZ bits MUST be sent as zero and ignored on receipt. 603 MetaTyp is the MD Type of Metadata saved. The presence of the MBZ 604 field causes the saved metadata to be aligned on a multiple of 4 605 octets. 607 4.1.4 Saved TTL 609 The TTL limits the number of SFs that can be traversed between 610 ingress and egress. The packet is discarded if the TTL is exhausted. 611 This is a safety measure to defend against infinite or very large 612 loops due to malfunctions, configuration error, or other reasons. 613 Thus, the RECOMMENDED mode of operation is to use a TTL value that is 614 decremented continuously from original SFC domain ingress to final 615 SFC egress including throughout any diversions. If the TTL is reset 616 on entry to a diversion, then the Saved TTL Sub-TLV MUST be used so 617 that the previous TTL can be restored at the diversion's RP. 619 Note that resetting the TTL on entry to a diversion opens the 620 possibility for loop where a diversion diverts to itself or there are 621 two diversions X and Y where X diverts to Y and Y diverts to X or 622 more complex scenarios all of which are made safe by using a 623 continuous TTL and unsafe by resetting the TTL on diversion entry. 624 Such loops will result in a growing amount of metadata which might 625 safely lead to packet discard or unsafely cause repeated 626 fragmentation. 628 If, despite the above warning, it is desired to reset the TTL at the 629 DP and restore it at the RP, the Saved TTL Sub-TLV as shown below is 630 used. 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Sub-Type=4 |X| Sub-Length=2| MBZ | Saved TTL | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Figure 11: Saved TTL Sub-TLV 640 The X and MBZ bits MUST be sent as zero and ignored on receipt. The 641 Saved TTL is the value of the TTL field copied from the NSH after its 642 initial decrement on entering the DP SF. 644 4.2 Diversion Point (DP) Behavior 646 If it is desired to simply skip some SFs in an SFP, a diversion may 647 not be necessary. The SI can simply be decreased to that for the next 648 SF desired if the SFF to which the SF/DP that reduces the SI returns 649 the packet can handle that reduced SI value and forward the packet to 650 the appropriate SFF. Otherwise, the procedure below in this section 651 is used and this procedure MAY be used even in cases where simple 652 reduction of the SI would work. 654 If the RP can recognize diverted SFC packets and modify/merge them 655 appropriately to restore them to the original SFP with appropriate 656 Metadata, then inserting a RePIn VLCH might not be needed. In other 657 cases take the steps below. This is a logical procedure and any 658 procedure can be used that results in the same diverted SFC 659 packet(s). 661 1. Construct a RePIn VLCH containing the SPI and SI from the NSH and 662 then change those fields in the NSH to the diversion SPI and SI. 663 If diversion is to multiple parallel SFPs, make a copy of the SFC 664 packet for each diversion, then construct a VLCH and modify the 665 NSH as in the previous sentence for each one of the parallel 666 paths. Then perform the following steps to each modified copy and 667 its corresponding RePIn VLCH. 669 2. If it will be necessary for the RP to merge the modified copies of 670 the original SFC packet sent over parallel paths or if the RP 671 needs to restore a particular ordering to packets, then add a 672 Packet Identification Sub-TLV to the RePIn VLCH unless sufficient 673 information is available in the packet payload for the RP to do so 674 without a Packet Identification Sub-TLV. 676 3. Take any Metadata from the original NSH that should be restored at 677 the RP and add it to the RePIn VLCH as a Saved Metadata Sub-TLV. 678 If the NSH already has any RePIn VLCHs, they need not be saved as 679 they will be masked by the new RePIn VLCH that will be inserted 680 before it (this indicates that a diversion from a diversion is 681 being created). To save space, any Metadata that has been saved in 682 the RePIn VLCH and is not needed in the diversion SFP SHOULD be 683 removed from the NSH if MD Type 2 and MUST be removed from the NSH 684 if MD Type 1. (In the Type 1 case, this converts the NSH to MD 685 Type 2 with no Metadata.) 687 4. If it is desired to use a new value for the NSH TTL in the 688 diversion, with the old value restored at the RP, add a Saved TTL 689 Sub-TLV to the RePIn VLCH and set the TTL in the NSH to a 690 configured value which may be dependent on the diversion being 691 entered. This is NOT RECOMMENDED as discussed in Section 4.1.4. 693 5. The RePIn VLCH constructed as above is inserted into an NSH as in 694 the subpoints below: 695 5.a If, after the above step 3, the initial NSH in the SFC packet 696 is MD Type 2, insert the RePIn VLCH constructed above before 697 any existing RePIn VLCH in the NSH. 698 5.b If, after the above step 3, the initial NSH in the SFC packet 699 is MD Type 1, this implies that there is Type 1 metadata that 700 may be needed by one or more SFs in the diversion. If the SFs 701 in the diversion can handle stacked NSHs, insert an MD Type 2 702 NSH copied from the initial NSH except for metadata, after the 703 initial MD Type 1 NSH to hold the RePIn VLCH. Handling stacks 704 NSHs means the SF (or its proxy) can parse through them to 705 find the needed metadata and the payload to operate on and, if 706 the SF generates packets, can create them with appropriate 707 stacked NSHs. If the SFs in the diversion cannot handle 708 stacked NSHes, the creation of the diversion is beyond the 709 scope of this document. 711 6. Perform such other functions or modifications to the metadata or 712 other parts of the SFC packet as are appropriate based on the 713 saved or new SPI or other factors. 715 The addition of Metadata and possible additional NSH header (see step 716 5.b above) may lead to fragmentation or decreased payload Maximum 717 Transmission Unit (MTU) in some networks. 719 4.3 Rendezvous Point (RP) Behavior 721 A RP will have been configured to know the SFC packet SPI and SI 722 values in diverted packets for which it is to perform the RP service. 723 The SI is decremented when an SFC packet is received by an SF; for an 724 RP this might decrement the SI to zero. The RP performs the steps 725 below. If the RP can restore diverted SFC packets to their former SFP 726 and, to the extent necessary, match and merge diverted packets 727 received over parallel paths and correctly order the resulting SFC 728 packets, without the presence of a RePIn VLCH, it does so and the 729 remainder of this section is inapplicable. If not, the following 730 logical procedure or any procedure resulting in the same SFC packet 731 is used. 733 1. Steps 2 and 3 below are performed on each diverted packet received 734 by the RP. If the RP is merging parallel diversions, step 4 is 735 then performed on the set of matching packets. In this case and 736 any case where the RP should restore packet order, the RP must be 737 prepared to buffer packets until they can be processed and 738 forwarded. Overflow of such a buffer will result in lost packets 739 and should be logged as an error. How long to wait for missing 740 diverted packets and what action to take if it is decided they 741 have been lost are application and implementation dependent. 742 Finally, Step 5 is performed. 744 2. Find and remove the first RePIn VLCH in the diverted packet. This 745 is referred to below as the removed VLCH. It might be in a second 746 stacked NSH if the initial NSH has MD Type 1. 748 3. Restore the packet from the diversion through the sub-steps listed 749 below. 750 3.a If there is a Saved TTL in the removed VLCH, restore it into 751 the initial NSH. 752 3.c Restore the saved SPI and SI from the removed RePIn VLCH into 753 the initial NSH. 754 3.d Restore metadata as follows: 755 3.d.1 Restore any MD Type 2 Saved Metadata from the removed 756 VLCH into the NSH from which that VLCH was removed. 757 3.d.2 If there is MD Type 1 Saved Metadata in the removed VLCH 758 and there is an initial MD Type 1 NSH in the packet, 759 replace the MD Type 1 metadata with the saved MD Type 1 760 metadata. 761 3.d.3 If there is MD Type 1 Saved Metadata in the removed VLCH 762 and there is an initial MD Type 2 NSH in the packet, 763 insert a new initial NSH into the packet which is a copy 764 of that MD Type 2 NSH except that it is MD Type 1 with 765 the saved MD Type 1 metadata. 766 3.e If, at this point, the packet starts with an MD Type 1 NSH 767 followed by an MD Type 2 NSH with no metadata, remove that 2nd 768 NSH. 770 4. Match up SFC packets arriving at the RP through parallel paths 771 using the Packet Identification Sub-TLV in the removed RePIn VLCH 772 or using some other technique. For each matching set, perform the 773 sub-steps below. Arbitrarily select one of the matching diverted 774 packets to modify into the merged packet unless configured to use 775 some particular diverted packet such as the one received over a 776 particular diversion. This is referred to below as the merged 777 packet even before the merger is complete. 778 4.a For error checking, the SPI and SI in the initial NSH of the 779 matching packets SHOULD be compared and an error logged if 780 they are not identical. 781 4.b For safety, it is RECOMMENDED that the minimum NSH TTL from 782 the parallel SFC packets be copied into the merged packet. 783 4.c Depending on the application and implementation, the remaining 784 metadata in the merged packet may be used or updated based on 785 the remaining Metadata in the other packets being merged. How 786 to do this is beyond the scope of this document. 787 4.d The payloads of the other packets being merged, that is the 788 portion after any NSHs, are used to update the payload in the 789 merged packet. This may be based on RP configuration for the 790 application or Packet Extent Modified Sub-TLVs in the removed 791 RePIn VLCHs or a combination of these. 793 5. Perform such other functions or modifications to the metadata or 794 other parts of the SFC packet as are appropriate based on the 795 saved or new SPI or other factors. Then return the packet to the 796 SFF. 798 5. IANA Considerations 800 The following subsections provide IANA assignment considerations. 802 5.1 Variable Length Context Header Type 804 IANA is requested to assign a variable length context header type 805 from the "NSH IETF-Assigned Optional Variable-Length Metadata Types" 806 registry as follows: 808 Value Description Reference 809 ----- ------------------------------------ --------------- 810 TDB Rendezvous Point Information (RePIn) [this document] 812 5.2 RePIn VLCH Sub-Types 814 IANA is requested to create a sub-registry under the "NSH IETF- 815 Assigned Optional Variable-Length Metadata Types" registry as 816 follows: 818 Name: Sub-TLVs under the Type TBD Variable Length Context Header 819 Registration Procedure: Expert Review 820 Reference: [this document] 822 Sub-Type Description Reference 823 -------- ---------------------- --------------- 824 0 reserved [this document] 825 1 Packet Identifier [this document] 826 2 Packet Extent Modified [this document] 827 3 Saved Metadata [this document] 828 4 Saved TTL [this document] 829 5-254 unassigned [this document] 830 255 reserved [this document] 832 6. Security Considerations 834 For general SFC and NSH security considerations, see [RFC8300]. 836 More to be added... 838 Normative References 840 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 841 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 842 March 1997, . 844 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 845 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 846 2017, 848 [RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 849 "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, 850 January 2018, . 852 Informative References 854 [ITU_Liaison] - ITU-T SG11, "LS on recent service function chaining 855 related developments in Q4/SG11: two new draft Supplements", 856 ITU-T SG11-LS-179, March 2021, 857 . 859 [RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service 860 Function Chaining (SFC) Architecture", RFC 7665, DOI 861 10.17487/RFC7665, October 2015, . 864 [RFC8459] - Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 865 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, DOI 866 10.17487/RFC8459, September 2018, . 869 Appendix: Relation to Hierarchical SFC 871 Experimental [RFC8459] describes "Hierarchical SFC" in which SFs in a 872 higher level SFP can be entire lower level SFPs with a different SPI 873 and where the higher level SPI is restored at the end of the lower 874 level SFP. This is similar to a diversion in this document. The 875 Internal Boundary Nodes (IBNs) in [RFC8459] that transition an SFC 876 packet between the higher and lower levels are similar to DPs/RPs in 877 the terminology of this document. 879 Experimental [RFC8459] discusses a wide variety of mechanisms to 880 implement Hierarchical SFC while this document looks toward 881 specifying a more specific set of mechanisms as a Proposed Standard 882 to support parallelism and other types of diversions. 884 Acknowledgements 886 The authors gratefully acknowledge the comments and suggestions of 887 the following persons: 889 (None yet) 891 Authors' Addresses 893 Donald E. Eastlake, 3rd 894 Futurewei Technologies 895 2386 Panoramic Circle 896 Apopka, FL 32703 USA 898 Tel: +1-508-333-2270 899 Email: d3e3e3@gmail.com 901 Copyright and IPR Provisions 903 Copyright (c) 2021 IETF Trust and the persons identified as the 904 document authors. All rights reserved. 906 This document is subject to BCP 78 and the IETF Trust's Legal 907 Provisions Relating to IETF Documents 908 (http://trustee.ietf.org/license-info) in effect on the date of 909 publication of this document. Please review these documents 910 carefully, as they describe your rights and restrictions with respect 911 to this document. Code Components extracted from this document must 912 include Simplified BSD License text as described in Section 4.e of 913 the Trust Legal Provisions and are provided without warranty as 914 described in the Simplified BSD License. The definitive version of 915 an IETF Document is that published by, or under the auspices of, the 916 IETF. Versions of IETF Documents that are published by third parties, 917 including those that are translated into other languages, should not 918 be considered to be definitive versions of IETF Documents. The 919 definitive version of these Legal Provisions is that published by, or 920 under the auspices of, the IETF. Versions of these Legal Provisions 921 that are published by third parties, including those that are 922 translated into other languages, should not be considered to be 923 definitive versions of these Legal Provisions. For the avoidance of 924 doubt, each Contributor to the IETF Standards Process licenses each 925 Contribution that he or she makes as part of the IETF Standards 926 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 927 language to the contrary, or terms, conditions or rights that differ 928 from or are inconsistent with the rights and licenses granted under 929 RFC 5378, shall have any effect and shall be null and void, whether 930 published or posted by such Contributor, or included with or in such 931 Contribution.