idnits 2.17.1 draft-ietf-spring-nsh-sr-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8402], [RFC7665], [RFC8300]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 11, 2020) is 1225 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) -- Looks like a reference, but probably isn't: '0' on line 515 == Missing Reference: 'ThisDocument' is mentioned on line 610, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Informational RFC: RFC 8596 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING J. Guichard, Ed. 3 Internet-Draft Futurewei Technologies 4 Intended status: Standards Track J. Tantsura, Ed. 5 Expires: June 14, 2021 Apstra inc. 6 December 11, 2020 8 Integration of Network Service Header (NSH) and Segment Routing for 9 Service Function Chaining (SFC) 10 draft-ietf-spring-nsh-sr-04 12 Abstract 14 This document describes the integration of Network Service Header 15 (NSH) [RFC8300] and Segment Routing (SR) [RFC8402], as well as 16 encapsulation details, to support Service Function Chaining (SFC) 17 [RFC7665] in an efficient manner while maintaining separation of the 18 service and transport planes as originally intended by the SFC 19 architecture. 21 Combining these technologies allows SR to be used for steering 22 packets between Service Function Forwarders (SFF) along a given 23 Service Function Path (SFP) while NSH has the responsibility for 24 maintaining the integrity of the service plane, the SFC instance 25 context, and any associated metadata. 27 The integration described in this document demonstrates that NSH and 28 SR can work jointly and complement each other leaving the network 29 operator with the flexibility to use whichever transport technology 30 makes sense in specific areas of their network infrastructure, and 31 still maintain an end-to-end service plane using NSH. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 14, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 2 69 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4 71 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5 72 4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9 73 5. Packet Processing Details . . . . . . . . . . . . . . . . . . 11 74 6. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11 75 6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 11 76 6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 8.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 14 80 8.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 15 81 8.3. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 15 82 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 10.2. Informative References . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 1.1. SFC Overview and Rationale 92 The dynamic enforcement of a service-derived and adequate forwarding 93 policy for packets entering a network that supports advanced Service 94 Functions (SFs) has become a key challenge for network operators. 95 Particularly, cascading SFs at the so-called Third Generation 96 Partnership Project (3GPP) Gi interface (N6 interface in 5G 97 architecture) in the context of mobile network infrastructure, have 98 shown their limitations, such as the same redundant classification 99 features must be supported by many SFs to execute their function, 100 some SFs receive traffic that they are not supposed to process (e.g., 101 TCP proxies receiving UDP traffic), which inevitably affects their 102 dimensioning and performance, an increased design complexity related 103 to the properly ordered invocation of several SFs, etc. 105 In order to solve those problems and to decouple the services 106 topology from the underlying physical network while allowing for 107 simplified service delivery, Service Function Chaining (SFC) 108 techniques have been introduced [RFC7665]. 110 SFC techniques are meant to rationalize the service delivery logic 111 and master the companion complexity while optimizing service 112 activation time cycles for operators that need more agile service 113 delivery procedures to better accommodate ever-demanding customer 114 requirements. Indeed, SFC allows to dynamically create service 115 planes that can be used by specific traffic flows. Each service 116 plane is realized by invoking and chaining the relevant service 117 functions in the right sequence. [RFC7498] provides an overview of 118 the overall SFC problem space and [RFC7665] specifies an SFC data 119 plane architecture. The SFC architecture does not make assumptions 120 on how advanced features (e.g., load-balancing, loose or strict 121 service paths) could be enabled within a domain. Various deployment 122 options are made available to operators with the SFC architecture and 123 this approach is fundamental to accommodate various and heterogeneous 124 deployment contexts. 126 Many approaches can be considered for encoding the information 127 required for SFC purposes (e.g., communicate a service chain pointer, 128 encode a list of loose/explicit paths, or disseminate a service chain 129 identifier together with a set of context information). Likewise, 130 many approaches can also be considered for the channel to be used to 131 carry SFC-specific information (e.g., define a new header, re-use 132 existing packet header fields, or define an IPv6 extension header). 133 Among all these approaches, the IETF created a transport-independent 134 SFC encapsulation scheme: NSH. This design is pragmatic as it does 135 not require replicating the same specification effort as a function 136 of underlying transport encapsulation. Moreover, this design 137 approach encourages consistent SFC-based service delivery in networks 138 enabling distinct transport protocols in various network segments or 139 even between SFFs vs SF-SFF hops. 141 1.2. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 147 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 148 as shown here. 150 2. SFC within Segment Routing Networks 152 As described in [RFC8402], SR leverages the source routing technique. 153 Concretely, a node steers a packet through an SR policy instantiated 154 as an ordered list of instructions called segments. While initially 155 designed for policy-based source routing, SR also finds its 156 application in supporting SFC 157 [I-D.ietf-spring-sr-service-programming]. 159 The two SR data plane encapsulations, namely SR-MPLS [RFC8660] and 160 SRv6 [RFC8754], can both encode an SF as a segment so that an SFC can 161 be specified as a segment list. Nevertheless, and as discussed in 162 [RFC7498], traffic steering is only a subset of the issues that 163 motivated the design of the SFC architecture. Further considerations 164 such as simplifying classification at intermediate SFs and allowing 165 for coordinated behaviors among SFs by means of supplying context 166 information (a.k.a. metadata) should be considered when designing an 167 SFC data plane solution. 169 While each scheme (i.e., NSH-based SFC and SR-based SFC) can work 170 independently, this document describes how the two can be used 171 together in concert and complement each other through two 172 representative application scenarios. Both application scenarios may 173 be supported using either SR-MPLS or SRv6: 175 o NSH-based SFC with SR-based transport plane: in this scenario SR- 176 MPLS or SRv6 provides the transport encapsulation between SFFs 177 while NSH is used to convey and trigger SFC policies. 179 o SR-based SFC with integrated NSH service plane: in this scenario 180 each service hop of the SFC is represented as a segment of the SR 181 segment-list. SR is thus responsible for steering traffic through 182 the necessary SFFs as part of the segment routing path while NSH 183 is responsible for maintaining the service plane and holding the 184 SFC instance context (including associated metadata). 186 It is of course possible to combine both of these two scenarios to 187 support specific deployment requirements and use cases. 189 A classifier SHOULD assign an NSH Service Path Identifier (SPI) per 190 SR policy so that different traffic flows that use the same NSH 191 Service Function Path (SFP) but different SR policy can coexist on 192 the same SFP without conflict during SFF processing. 194 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel 196 Because of the transport-independent nature of NSH-based service 197 function chains, it is expected that the NSH has broad applicability 198 across different network domains (e.g., access, core). By way of 199 illustration the various SFs involved in a service function chain may 200 be available in a single data center, or spread throughout multiple 201 locations (e.g., data centers, different POPs), depending upon the 202 network operator preference and/or availability of service resources. 203 Regardless of where the SFs are deployed it is necessary to provide 204 traffic steering through a set of SFFs, and when NSH and SR are 205 integrated, this is provided by SR-MPLS or SRv6. 207 The following three figures provide an example of an SFC established 208 flow F that has SF instances located in different data centers, DC1 209 and DC2. For the purpose of illustration, let the SFC's NSH SPI be 210 100 and the initial Service Index (SI) be 255. 212 Referring to Figure 1, packets of flow F in DC1 are classified into 213 an NSH-based SFC and encapsulated after classification as and forwarded to SFF1 215 (which is the first SFF hop for this service function chain). 217 After removing the outer transport encapsulation, SFF1 uses the SPI 218 and SI carried within the NSH encapsulation to determine that it 219 should forward the packet to SF1. SF1 applies its service, 220 decrements the SI by 1, and returns the packet to SFF1. SFF1 221 therefore has when the packet comes back from SF1. 222 SFF1 does a lookup on which results in and forwards the packet to DC1-GW1. 225 +--------------------------- DC1 ----------------------------+ 226 | +-----+ | 227 | | SF1 | | 228 | +--+--+ | 229 | | | 230 | | | 231 | +------------+ | +------------+ | 232 | | N(100,255) | | | F:Inner Pkt| | 233 | +------------+ | +------------+ | 234 | | F:Inner Pkt| | | N(100,254) | | 235 | +------------+ ^ | | +------------+ | 236 | (2) | | | (3) | 237 | | | v | 238 | (1) | (4) | 239 |+------------+ ----> +--+---+ ----> +---------+ | 240 || | NSH | | NSH | | | 241 || Classifier +------------+ SFF1 +--------------+ DC1-GW1 + | 242 || | | | | | | 243 |+------------+ +------+ +---------+ | 244 | | 245 | +------------+ +------------+ | 246 | | N(100,255) | | N(100,254) | | 247 | +------------+ +------------+ | 248 | | F:Inner Pkt| | F:Inner Pkt| | 249 | +------------+ +------------+ | 250 | | 251 +------------------------------------------------------------+ 253 Figure 1: SR for inter-DC SFC - Part 1 255 Referring now to Figure 2, DC1-GW1 performs a lookup using the 256 information conveyed in the NSH which results in . The SR encapsulation, which may be SR-MPLS or 258 SRv6, has the SR segment-list to forward the packet across the inter- 259 DC network to DC2. 261 +----------- Inter DC ----------------+ 262 | (5) | 263 +------+ ----> | +---------+ ----> +---------+ | 264 | | NSH | | | SR | | | 265 + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | 266 | | | | | | | | 267 +------+ | +---------+ +---------+ | 268 | | 269 | +------------+ | 270 | | S(DC2-GW1) | | 271 | +------------+ | 272 | | N(100,254) | | 273 | +------------+ | 274 | | F:Inner Pkt| | 275 | +------------+ | 276 +-------------------------------------+ 278 Figure 2: SR for inter-DC SFC - Part 2 280 When the packet arrives at DC2, as shown in Figure 3, the SR 281 encapsulation is removed and DC2-GW1 performs a lookup on the NSH 282 which results in next hop: SFF2. When SFF2 receives the packet, it 283 performs a lookup on and determines to forward 284 the packet to SF2. SF2 applies its service, decrements the SI by 1, 285 and returns the packet to SFF2. SFF2 therefore has when the packet comes back from SF2. SFF2 does a lookup on 287 which results in end of service function 288 chain. 290 +------------------------ DC2 ----------------------+ 291 | +-----+ | 292 | | SF2 | | 293 | +--+--+ | 294 | | | 295 | | | 296 | +------------+ | +------------+ | 297 | | N(100,254) | | | F:Inner Pkt| | 298 | +------------+ | +------------+ | 299 | | F:Inner Pkt| | | N(100,253) | | 300 | +------------+ ^ | | +------------+ | 301 | (7) | | | (8) | 302 | | | v | 303 | (6) | (9) | 304 |+----------+ ----> +--+---+ ----> | 305 || | NSH | | IP | 306 || DC2-GW1 +------------+ SFF2 | | 307 || | | | | 308 |+----------+ +------+ | 309 | | 310 | +------------+ +------------+ | 311 | | N(100,254) | | F:Inner Pkt| | 312 | +------------+ +------------+ | 313 | | F:Inner Pkt| | 314 | +------------+ | 315 +---------------------------------------------------+ 317 Figure 3: SR for inter-DC SFC - Part 3 319 The benefits of this scheme are listed hereafter: 321 o The network operator is able to take advantage of the transport- 322 independent nature of the NSH encapsulation, while the service is 323 provisioned end2end. 325 o The network operator is able to take advantage of the traffic 326 steering (traffic engineering) capability of SR where appropriate. 328 o Clear responsibility division and scope between NSH and SR. 330 Note that this scenario is applicable to any case where multiple 331 segments of a service function chain are distributed across multiple 332 domains or where traffic-engineered paths are necessary between SFFs 333 (strict forwarding paths for example). Further note that the above 334 example can also be implemented using end to end segment routing 335 between SFF1 and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the 336 packets based on segment routing instructions and are not looking at 337 the NSH header for forwarding). 339 4. SR-based SFC with Integrated NSH Service Plane 341 In this scenario we assume that the SFs are NSH-aware and therefore 342 it should not be necessary to implement an SFC proxy to achieve SFC. 343 The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF 344 transport and NSH to provide the service plane between SFs thereby 345 maintaining SFC context (e.g., the service plane path referenced by 346 the SPI) and any associated metadata. 348 When a service function chain is established, a packet associated 349 with that chain will first carry an NSH that will be used to maintain 350 the end-to-end service plane through use of the SFC context. The SFC 351 context is used by an SFF to determine the SR segment list for 352 forwarding the packet to the next-hop SFFs. The packet is then 353 encapsulated using the SR header and forwarded in the SR domain 354 following normal SR operations. 356 When a packet has to be forwarded to an SF attached to an SFF, the 357 SFF performs a lookup on the SID associated with the SF. In the case 358 of SR-MPLS this will be a prefix SID [RFC8402]. In the case of SRv6, 359 the behavior described within this document is assigned the name 360 END.NSH, and section 8.3 requests allocation of a code point by IANA. 361 The result of this lookup allows the SFF to retrieve the next hop 362 context between the SFF and SF (e.g., the destination MAC address in 363 case native Ethernet encapsulation is used between SFF and SF). In 364 addition the SFF strips the SR information from the packet, updates 365 the SR information, and saves it to a cache indexed by the NSH 366 Service Path Identifier (SPI) and the Service Index (SI) decremented 367 by 1. This saved SR information is used to encapsulate and forward 368 the packet(s) coming back from the SF. 370 The behavior of remembering the SR stack occurs at the end of the 371 regularly defined logic. The behavior of reattaching the stack 372 occurs before the SR process of forwarding the packet to the next 373 entry in the segment-list. Both behaviors are further detailed in 374 section 5. 376 When the SF receives the packet, it processes it as usual and sends 377 it back to the SFF. Once the SFF receives this packet, it extracts 378 the SR information using the NSH SPI and SI as the index into the 379 cache. The SFF then pushes the retrieved SR header on top of the NSH 380 header, and forwards the packet to the next segment in the segment 381 list. 383 Figure 4 illustrates an example of this scenario. 385 +-----+ +-----+ 386 | SF1 | | SF2 | 387 +--+--+ +--+--+ 388 | | 389 | | 390 +-----------+ | +-----------+ +-----------+ | +-----------+ 391 |N(100,255) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt| 392 +-----------+ | +-----------+ +-----------+ | +-----------+ 393 |F:Inner Pkt| | |N(100,254) | |F:Inner Pkt| | |N(100,253) | 394 +-----------+ | +-----------+ +-----------+ | +-----------+ 395 (2) ^ | (3) | (5) ^ | (6) | 396 | | | | | | 397 | | v | | v 398 +------------+ (1)--> +-+----+ (4)--> +---+--+ (7)-->IP 399 | | NSHoSR | | NSHoSR | | 400 | Classifier +--------+ SFF1 +---------------------+ SFF2 | 401 | | | | | | 402 +------------+ +------+ +------+ 404 +------------+ +------------+ 405 | S(SF1) | | S(SF2) | 406 +------------+ +------------+ 407 | S(SFF2) | | N(100,254) | 408 +------------+ +------------+ 409 | S(SF2) | | F:Inner Pkt| 410 +------------+ +------------+ 411 | N(100,255) | 412 +------------+ 413 | F:Inner Pkt| 414 +------------+ 416 Figure 4: NSH over SR for SFC 418 The benefits of this scheme include: 420 o It is economically sound for SF vendors to only support one 421 unified SFC solution. The SF is unaware of the SR. 423 o It simplifies the SFF (i.e., the SR router) by nullifying the 424 needs for re-classification and SR proxy. 426 o SR is also used for forwarding purposes including between SFFs. 428 o It takes advantage of SR to eliminate the NSH forwarding state in 429 SFFs. This applies each time strict or loose SFPs are in use. 431 o It requires no interworking as would be the case if SR-MPLS based 432 SFC and NSH-based SFC were deployed as independent mechanisms in 433 different parts of the network. 435 5. Packet Processing Details 437 This section describes the End.NSH behavior and NSH processing logic. 438 The pseudo code is shown below. 440 When N receives a packet destined to S and S is a local End.NSH SID, 441 the processing is the same as that specified by RFC 8754 section 442 4.3.1.1, up through line S.16. 444 After S.15, if S is a local End.NSH SID, then: 446 S15.1. Remove and store IPv6 and SRH headers in local cache indexed 447 by 449 S15.2. Submit the packet to the NSH FIB lookup and transmit to the 450 destination associated with 452 Note: The End.NSH behavior interrupts the normal SRH packet 453 processing as described in RFC8754 section 4.3.1.1, which does not 454 continue to S16 at this time. 456 When a packet is returned to the SFF from the SF, reattach the cached 457 IPv6 and SRH headers based on the from 458 the NSH header. Then resume processing from RFC 8754 section 4.3.1.1 459 with line S.16. 461 6. Encapsulation Details 463 6.1. NSH using SR-MPLS Transport 465 SR-MPLS instantiates Segment IDs (SIDs) as MPLS labels and therefore 466 the segment routing header is a stack of MPLS labels. 468 When carrying NSH within an SR-MPLS transport, the full encapsulation 469 headers are as illustrated in Figure 5. 471 +------------------+ 472 ~ MPLS-SR Labels ~ 473 +------------------+ 474 | NSH Base Hdr | 475 +------------------+ 476 | Service Path Hdr | 477 +------------------+ 478 ~ Metadata ~ 479 +------------------+ 481 Figure 5: NSH using SR-MPLS Transport 483 As described in [RFC8402], the IGP signaling extension for IGP-Prefix 484 segment includes a flag to indicate whether directly connected 485 neighbors of the node on which the prefix is attached should perform 486 the NEXT operation or the CONTINUE operation when processing the SID. 487 When NSH is carried beneath SR-MPLS it is necessary to terminate the 488 NSH-based SFC at the tail-end node of the SR-MPLS label stack. This 489 is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore 490 the prefix-SID associated with the tail-end of the SFC MUST be 491 advertised with the CONTINUE operation so that the penultimate hop 492 node does not pop the top label of the SR-MPLS label stack and 493 thereby expose NSH to the wrong SFF. This is realized by setting No- 494 PHP flag in Prefix-SID Sub-TLV [RFC8667], [RFC8665]. It is 495 RECOMMENDED that a specific prefix-SID be allocated at each node for 496 use by the SFC application for this purpose. 498 At the end of the SR-MPLS path it is necessary to provide an 499 indication to the tail-end that NSH follows the SR-MPLS label stack 500 as described by [RFC8596]. 502 6.2. NSH using SRv6 Transport 504 When carrying NSH within an SRv6 transport the full encapsulation is 505 as illustrated in Figure 6. 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Last Entry | Flags | Tag | S 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 514 | | g 515 | Segment List[0] (128 bits IPv6 address) | m 516 | | e 517 | | n 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t 519 | | 520 | | R 521 ~ ... ~ o 522 | | u 523 | | t 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 525 | | n 526 | Segment List[n] (128 bits IPv6 address) | g 527 | | 528 | | S 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 530 // // H 531 // Optional Type Length Value objects (variable) // 532 // // 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 536 | Service Path Identifier | Service Index | S 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 538 | | 539 ~ Variable-Length Context Headers (opt.) ~ 540 | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 6: NSH using SRv6 Transport 545 Encapsulation of NSH following SRv6 may be indicated either by 546 encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the 547 Next Header field of the SRH, or by indicating an IP protocol number 548 for NSH in the Next Header of the SRH. The behavior for 549 encapsulating NSH over UDP, including the selection of the source 550 port number in particular, adheres to similar considerations as those 551 discussed in [RFC8086]. 553 7. Security Considerations 555 Generic SFC-related security considerations are discussed in 556 [RFC7665]. 558 NSH-specific security considerations are discussed in [RFC8300]. 560 NSH-in-UDP with DTLS [RFC6347] should follow the considerations 561 discussed in Section 5 of [RFC8086], with a destination port number 562 set to TBA2. 564 Generic segment routing related security considerations are discussed 565 in section 7 of [RFC8754] and section 5 of [RFC8663]. 567 8. IANA Considerations 569 8.1. UDP Port Number for NSH 571 IANA is requested to assign the UDP port numbers TBA1 and TBA2 to the 572 NSH from the "Service Name and Transport Protocol Port Number Registry" 573 available at 574 https://www.iana.org/assignments/service-names-port-numbers/ 575 service-names-port-numbers.xhtml: 577 Service Name: NSH-in-UDP 578 Transport Protocol(s): UDP 579 Assignee: IESG iesg@ietf.org 580 Contact: IETF Chair chair@ietf.org 581 Description: NSH-in-UDP Encapsulation 582 Reference: [ThisDocument] 583 Port Number: TBA1 584 Service Code: N/A 585 Known Unauthorized Uses: N/A 586 Assignment Notes: N/A 588 Service Name: NSH-UDP-DTLS 589 Transport Protocol(s): UDP 590 Assignee: IESG iesg@ietf.org 591 Contact: IETF Chair chair@ietf.org 592 Description: NSH-in-UDP with DTLS Encapsulation 593 Reference: [ThisDocument] 594 Port Number: TBA2 595 Service Code: N/A 596 Known Unauthorized Uses: N/A 597 Assignment Notes: N/A 599 8.2. Protocol Number for NSH 601 IANA is requested to assign a protocol number TBA3 for the NSH from the 602 "Assigned Internet Protocol Numbers" registry available at 603 https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 605 +---------+---------+--------------+---------------+----------------+ 606 | Decimal | Keyword | Protocol | IPv6 | Reference | 607 | | | | Extension | | 608 | | | | Header | | 609 +---------+---------+--------------+---------------+----------------+ 610 | TBA3 | NSH | Network | N | [ThisDocument] | 611 | | | Service | | | 612 | | | Header | | | 613 +---------+---------+--------------+---------------+----------------+ 615 8.3. SRv6 Endpoint Behavior for NSH 617 This I-D requests IANA to allocate, within the "SRv6 Endpoint Behaviors" 618 sub-registry belonging to the top-level "Segment-routing with IPv6 data 619 plane (SRv6) Parameters" registry, the following allocations: 621 Value Description Reference 622 -------------------------------------------------------------- 623 TBA4 End.NSH - NSH Segment [This.ID] 625 9. Contributing Authors 626 The following co-authors, along with their respective affiliations at 627 the time of WG adoption, provided valuable inputs and text contributions 628 to this document. 630 Mohamed Boucadair 631 Orange 632 mohamed.boucadair@orange.com 634 Joel Halpern 635 Ericsson 636 joel.halpern@ericsson.com 638 Syed Hassan 639 Cisco System, inc. 640 shassan@cisco.com 642 Wim Henderickx 643 Nokia 644 wim.henderickx@nokia.com 646 Haoyu Song 647 Futurewei Technologies 648 haoyu.song@futurewei.com 650 10. References 652 10.1. Normative References 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, 656 DOI 10.17487/RFC2119, March 1997, 657 . 659 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 660 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 661 January 2012, . 663 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 664 Chaining (SFC) Architecture", RFC 7665, 665 DOI 10.17487/RFC7665, October 2015, 666 . 668 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 669 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 670 March 2017, . 672 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 673 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 674 May 2017, . 676 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 677 "Network Service Header (NSH)", RFC 8300, 678 DOI 10.17487/RFC8300, January 2018, 679 . 681 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 682 Decraene, B., Litkowski, S., and R. Shakir, "Segment 683 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 684 July 2018, . 686 [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 687 "MPLS Transport Encapsulation for the Service Function 688 Chaining (SFC) Network Service Header (NSH)", RFC 8596, 689 DOI 10.17487/RFC8596, June 2019, 690 . 692 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 693 Decraene, B., Litkowski, S., and R. Shakir, "Segment 694 Routing with the MPLS Data Plane", RFC 8660, 695 DOI 10.17487/RFC8660, December 2019, 696 . 698 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 699 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 700 DOI 10.17487/RFC8663, December 2019, 701 . 703 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 704 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 705 Extensions for Segment Routing", RFC 8665, 706 DOI 10.17487/RFC8665, December 2019, 707 . 709 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 710 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 711 Extensions for Segment Routing", RFC 8667, 712 DOI 10.17487/RFC8667, December 2019, 713 . 715 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 716 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 717 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 718 . 720 10.2. Informative References 722 [I-D.ietf-spring-sr-service-programming] 723 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 724 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 725 Henderickx, W., and S. Salsano, "Service Programming with 726 Segment Routing", draft-ietf-spring-sr-service- 727 programming-03 (work in progress), September 2020. 729 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 730 Service Function Chaining", RFC 7498, 731 DOI 10.17487/RFC7498, April 2015, 732 . 734 Authors' Addresses 736 James N Guichard (editor) 737 Futurewei Technologies 738 2330 Central Express Way 739 Santa Clara 740 USA 742 Email: james.n.guichard@futurewei.com 744 Jeff Tantsura (editor) 745 Apstra inc. 746 USA 748 Email: jefftant.ietf@gmail.com