idnits 2.17.1 draft-xuclad-spring-sr-service-chaining-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 (March 5, 2018) is 2243 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 1228 == Missing Reference: 'SL' is mentioned on line 1230, but not defined == Outdated reference: A later version (-05) exists of draft-farrel-mpls-sfc-04 == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-05 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-03 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-12 == Outdated reference: A later version (-09) exists of draft-xu-mpls-payload-protocol-identifier-04 == Outdated reference: A later version (-01) exists of draft-xu-mpls-sr-over-ip-00 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING F. Clad, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track X. Xu, Ed. 5 Expires: September 6, 2018 Alibaba 6 C. Filsfils 7 Cisco Systems, Inc. 8 D. Bernier 9 Bell Canada 10 C. Li 11 Huawei 12 B. Decraene 13 Orange 14 S. Ma 15 Juniper 16 C. Yadlapalli 17 AT&T 18 W. Henderickx 19 Nokia 20 S. Salsano 21 Universita di Roma "Tor Vergata" 22 March 5, 2018 24 Segment Routing for Service Chaining 25 draft-xuclad-spring-sr-service-chaining-01 27 Abstract 29 This document defines data plane functionality required to implement 30 service segments and achieve service chaining in SR-enabled MPLS and 31 IP networks, as described in the Segment Routing architecture. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 6, 2018. 56 Copyright Notice 58 Copyright (c) 2018 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Classification and steering . . . . . . . . . . . . . . . . . 5 76 4. Service Functions . . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. SR-aware SFs . . . . . . . . . . . . . . . . . . . . . . 6 78 4.2. SR-unaware SFs . . . . . . . . . . . . . . . . . . . . . 6 79 5. Service function chaining . . . . . . . . . . . . . . . . . . 7 80 5.1. SR-MPLS data plane . . . . . . . . . . . . . . . . . . . 8 81 5.1.1. Encoding SFP Information by an MPLS Label Stack . . . 8 82 5.1.2. Encoding SFC Information by an MPLS Label Stack . . . 11 83 5.2. SRv6 data plane . . . . . . . . . . . . . . . . . . . . . 14 84 5.2.1. Encoding SFP Information by an SRv6 SRH . . . . . . . 14 85 5.2.2. Encoding SFC Information by an IPv6 SRH . . . . . . . 16 86 6. SR proxy behaviors . . . . . . . . . . . . . . . . . . . . . 17 87 6.1. Static SR proxy . . . . . . . . . . . . . . . . . . . . . 20 88 6.1.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 21 89 6.1.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 22 90 6.2. Dynamic SR proxy . . . . . . . . . . . . . . . . . . . . 25 91 6.2.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 25 92 6.2.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 26 93 6.3. Shared memory SR proxy . . . . . . . . . . . . . . . . . 26 94 6.4. Masquerading SR proxy . . . . . . . . . . . . . . . . . . 27 95 6.4.1. SRv6 masquerading proxy pseudocode . . . . . . . . . 28 96 6.4.2. Variant 1: Destination NAT . . . . . . . . . . . . . 28 97 6.4.3. Variant 2: Caching . . . . . . . . . . . . . . . . . 29 98 7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 7.1. MPLS data plane . . . . . . . . . . . . . . . . . . . . . 29 100 7.2. IPv6 data plane . . . . . . . . . . . . . . . . . . . . . 29 101 7.2.1. SRH TLV objects . . . . . . . . . . . . . . . . . . . 29 102 7.2.2. SRH tag . . . . . . . . . . . . . . . . . . . . . . . 30 103 8. Implementation status . . . . . . . . . . . . . . . . . . . . 30 104 9. Related works . . . . . . . . . . . . . . . . . . . . . . . . 31 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 106 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 107 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 108 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 109 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 110 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 111 14.2. Informative References . . . . . . . . . . . . . . . . . 32 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 114 1. Introduction 116 Segment Routing (SR) is an architecture based on the source routing 117 paradigm that seeks the right balance between distributed 118 intelligence and centralized programmability. SR can be used with an 119 MPLS or an IPv6 data plane to steer packets through an ordered list 120 of instructions, called segments. These segments may encode simple 121 routing instructions for forwarding packets along a specific network 122 path, or rich behaviors to support use-cases such as Service Function 123 Chaining (SFC). 125 In the context of SFC, each Service Function (SF), running either on 126 a physical appliance or in a virtual environment, is associated with 127 a segment, which can then be used in a segment list to steer packets 128 through the SF. Such service segments may be combined together in a 129 segment list to achieve SFC, but also with other types of segments as 130 defined in [I-D.ietf-spring-segment-routing]. SR thus provides a 131 fully integrated solution for SFC, overlay and underlay optimization. 132 Furthermore, the IPv6 dataplane natively supports metadata 133 transportation as part of the SR information attached to the packets. 135 This document describes how SR enables SFC in a simple and scalable 136 manner, from the segment association to the SF up to the traffic 137 classification and steering into the service chain. Several SR proxy 138 behaviors are also defined to support SR SFC through legacy, SR- 139 unaware, SFs in various circumstances. 141 The definition of an SR Policy and the steering of traffic into an SR 142 Policy is outside the scope of this document. These aspects are 143 covered in [I-D.filsfils-spring-segment-routing-policy]. 145 The definition of control plane components, such as service segment 146 discovery, is outside the scope of this data plane document. BGP 147 extensions to support SR-based SFC are proposed in 148 [I-D.dawra-idr-bgp-sr-service-chaining]. 150 Familiarity with the following IETF documents is assumed: 152 o Segment Routing Architecture [I-D.ietf-spring-segment-routing] 154 o Segment Routing with MPLS data plane 155 [I-D.ietf-spring-segment-routing-mpls] 157 o Segment Routing Traffic Engineering Policy 158 [I-D.filsfils-spring-segment-routing-policy] 160 o Segment Routing Header [I-D.ietf-6man-segment-routing-header] 162 o SRv6 Network Programming 163 [I-D.filsfils-spring-srv6-network-programming] 165 o SR-MPLS over IP [I-D.xu-mpls-sr-over-ip] 167 o Service Function Chaining Architecture [RFC7665] 169 2. Terminology 171 This document leverages the terminology introduced in 172 [I-D.ietf-spring-segment-routing], 173 [I-D.filsfils-spring-segment-routing-policy] and [RFC7665]. It also 174 introduces the following new terminology. 176 SR-aware SF: Service Function fully capable of processing SR traffic 178 SR-unaware SF: Service Function unable to process SR traffic or 179 behaving incorrectly for such traffic 181 SR proxy: Proxy handling the SR processing on behalf of an SR-unaware 182 SF 184 Service Segment: Segment associated with an SF, either directly or 185 via an SR proxy 187 SR SFC policy: SR policy, as defined in 188 [I-D.filsfils-spring-segment-routing-policy], that includes at least 189 one Service Segment. An SR SFC policy may also contain other types 190 of segments, such as VPN or TE segments. 192 3. Classification and steering 194 Classification and steering mechanisms are defined in section 8 of 195 [I-D.filsfils-spring-segment-routing-policy] and are independent from 196 the purpose of the SR policy. From a headend perspective, there is 197 no difference whether a policy contains IGP, BGP, peering, VPN and 198 service segments, or any combination of these. 200 As documented in the above reference, traffic is classified when 201 entering an SR domain. The SR policy head-end may, depending on its 202 capabilities, classify the packets on a per-destination basis, via 203 simple FIB entries, or apply more complex policy routing rules 204 requiring to look deeper into the packet. These rules are expected 205 to support basic policy routing such as 5-tuple matching. In 206 addition, the IPv6 SRH tag field defined in 207 [I-D.ietf-6man-segment-routing-header] can be used to identify and 208 classify packets sharing the same set of properties. Classified 209 traffic is then steered into the appropriate SR policy, which is 210 associated with a weighted set of segment lists. 212 SR traffic can be re-classified by an SR endpoint along the original 213 SR policy (e.g., DPI service) or a transit node intercepting the 214 traffic. This node is the head-end of a new SR policy that is 215 imposed onto the packet, either as a stack of MPLS labels or as an 216 IPv6 and SRH encapsulation. 218 4. Service Functions 220 A Service Function (SF) may be a physical appliance running on 221 dedicated hardware, a virtualized service inside an isolated 222 environment such as a VM, container or namespace, or any process 223 running on a compute element. An SF may also comprise multiple sub- 224 components running in different processes or containers. Unless 225 otherwise stated, this document does not make any assumption on the 226 type or execution environment of an SF. 228 SR enables SFC by assigning a segment identifier, or SID, to each SF 229 and sequencing these service SIDs in a segment list. A service SID 230 may be of local significance or directly reachable from anywhere in 231 the routing domain. The latter is realized with SR-MPLS by assigning 232 a SID from the global label block 233 ([I-D.ietf-spring-segment-routing-mpls]), or with SRv6 by advertising 234 the SID locator in the routing protocol 235 ([I-D.filsfils-spring-srv6-network-programming]). It is up to the 236 network operator to define the scope and reachability of each service 237 SID. This decision can be based on various considerations such as 238 infrastructure dynamicity, available control plane or orchestration 239 system capabilities. 241 This document categorizes SFs in two types, depending on whether they 242 are able to behave properly in the presence of SR information or not. 243 These are respectively named SR-aware and SR-unaware SFs. An SR- 244 aware SF can process the SR information in the packets it receives. 245 This means being able to identify the active segment as a local 246 instruction and move forward in the segment list, but also that the 247 SF own behavior is not hindered due to the presence of SR 248 information. For example, an SR-aware firewall filtering SRv6 249 traffic based on its final destination must retrieve that information 250 from the last entry in the SRH rather than the Destination Address 251 field of the IPv6 header. Any SF that does not meet these criteria 252 is considered as SR-unaware. 254 4.1. SR-aware SFs 256 An SR-aware SF is associated with a locally instantiated service 257 segment, which is used to steer traffic through it. 259 If the SF is configured to intercept all the packets passing through 260 the appliance, the underlying routing system only has to implement a 261 default SR endpoint behavior (SR-MPLS node segment or SRv6 End 262 function), and the corresponding SID will be used to steer traffic 263 through the SF. 265 If the SF requires the packets to be directed to a specific virtual 266 interface, networking queue or process, a dedicated SR behavior may 267 be required to steer the packets to the appropriate location. The 268 definition of such SF-specific functions is out of the scope of this 269 document. 271 An SRv6-aware SF may also retrieve, store or modify information in 272 the SRH TLVs. 274 4.2. SR-unaware SFs 276 An SR-unaware SF is not able to process the SR information in the 277 traffic that it receives. It may either drop the traffic or take 278 erroneous decisions due to the unrecognized routing information. In 279 order to include such SFs in an SR SC policy, it is thus required to 280 remove the SR information as well as any other encapsulation header 281 before the SF receives the packet, or to alter it in such a way that 282 the SF can correctly process the packet. 284 In this document, we define the concept of an SR proxy as an entity, 285 separate from the SF, that performs these modifications and handle 286 the SR processing on behalf of an SF. The SR proxy can run as a 287 separate process on the SF appliance, on a virtual switch or router 288 on the compute node or on a remote host. In this document, we only 289 assume that the proxy is connected to the SF via a layer-2 link. 291 An SR-unaware SF is associated with a service segment instantiated on 292 the SR proxy, which is used to steer traffic through the SF. 293 Section 6 describes several SR proxy behaviors to handle the 294 encapsulation headers and SR information under various circumstances. 296 5. Service function chaining 298 When applying a particular Service Function Chain (SFC) [RFC7665] to 299 the traffic selected by a service classifier, the traffic need to be 300 steered through an ordered set of Service Functions (SF) in the 301 network. This ordered set of SFs in the network indicates the 302 Service Function Path (SFP) associated with the above SFC. In order 303 to steer the selected traffic through the required ordered list of 304 SFs, the service classifier needs to attach information to the packet 305 specifying exactly which Service Function Forwarders (SFFs) and which 306 SFs are to be visited by traffic, the SFC, or the partially specified 307 SFP which is in between the former two extremes. 309 The SR source routing mechanisms can be used to steer traffic through 310 an ordered set of devices (i.e., an explicit path) and instruct those 311 nodes to execute specific operations on the packet. 313 This section describes how to leverage SR to realize a transport- 314 independent service function chaining by encoding the service 315 function path information or service function chain information as an 316 MPLS label stack or an IPv6 SRH. 318 +-----------------------------------------------------+ 319 | SR network | 320 | +---------+ +---------+ | 321 | | SF1 | | SF2 | | 322 | +----+----+ +----+----+ | 323 | ^ | |(3) ^ | |(6) | 324 | (1) (2)| | V (4) (5)| | V (7) | 325 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+ 326 | A +------+ SFF1 +-------+ SFF2 +-------+ B | 327 | Head-end | | | | | | Tail-end | 328 +----------+ +---------+ +---------+ +----+-----+ 329 | | 330 +-----------------------------------------------------+ 332 Figure 1: Service Function Chaining in SR networks 334 As shown in Figure 1, SFF1 and SFF2 are two SR-capable nodes. They 335 are also SFFs, each with one SF attached. In addition, they have 336 allocated and advertised segments for their locally attached SFs. 337 For example, SFF1 allocates and advertises a SID (i.e., S(SF1)) for 338 SF1 while SFF2 allocates and advertises a SID (i.e., S(SF2)) for SF2. 339 These SIDs, which are used to indicate SFs, are referred to as 340 service segments, while the SFFs are identified by either node or 341 adjacency segments depending on how strictly the network path needs 342 to be specified. In this example, we assume that the traffic is 343 steered to both SFFs using their node segments S(SFF1) and S(SFF2), 344 respectively. 346 Now assume that a given traffic flow is steered in an SR policy 347 instantiated on node A with an endpoint B, hereafter referred to as 348 the SR policy head-end and tail-end respectively, and associated with 349 particular SFC requirements (i.e., SF1-> SF2). From an SR policy 350 perspective, SFC is only a particular case of traffic engineering 351 where the SR path includes service functions. An SR-SFC policy 352 inherits all the properties of SR-TE policies as defined in 353 [I-D.filsfils-spring-segment-routing-policy]. Section 5.1 and 354 Section 5.2 describe approaches of leveraging the SR-MPLS and SRv6 355 mechanisms to realize stateless service function chaining. The 356 complete SFP and SFC information is encoded within an MPLS label 357 stack or an IPv6 SRH carried by the packets, so that no per-chain 358 state is required at the intermediate hops. Since the encoding of 359 the partially specified SFP is just a simple combination of the 360 encoding of the SFP and the encoding of the SFC, this document would 361 not describe how to encode the partially specified SFP anymore. 363 5.1. SR-MPLS data plane 365 5.1.1. Encoding SFP Information by an MPLS Label Stack 366 +-----------------------------------------------------+ 367 | SR-MPLS network | 368 | +---------+ +---------+ | 369 | | SF1 | | SF2 | | 370 | +----+----+ +----+----+ | 371 | +---------+ | | +---------+ | 372 | | S(SFF2) | | | | S(T) | | 373 | +---------+ | | +---------+ | 374 | | S(SF2) | | | |Inner pkt| | 375 | +---------+ | | +---------+ | 376 | | S(T) | | | | 377 | +---------+ | ^ | | | 378 | |Inner pkt| ^ | | | | | | 379 | +---------+ | | | (5)| | |(6) | 380 | (2)| | |(3) | | V | 381 | (1) | | V (4) | (7) | 382 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+ 383 | Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end | 384 +----------+ +---------+ +---------+ +----+-----+ 385 | +---------+ +---------+ +---------+ | 386 | | S(SFF1) | | S(SFF2) | | S(T) | | 387 | +---------+ +---------+ +---------+ | 388 | | S(SF1) | | S(SF2) | |Inner pkt| | 389 | +---------+ +---------+ +---------+ | 390 | | S(SFF2) | | S(T) | | 391 | +---------+ +---------+ | 392 | | S(SF2) | |Inner pkt| | 393 | +---------+ +---------+ | 394 | | S(T) | | 395 | +---------+ | 396 | |Inner pkt| | 397 | +---------+ | 398 +-----------------------------------------------------+ 400 Figure 2: Packet walk in MPLS underlay 402 As shown in Figure 2, the head-end, acting as a service classifier, 403 determines that the selected packet needs to travel through an SFC 404 (SF1->SF2) and steers this packet into the appropriate SR policy as 405 described in [I-D.filsfils-spring-segment-routing-policy]. As a 406 result, the packet is encapsulated with an MPLS label stack 407 containing the segment list . This segment 408 list encodes in a stateless manner the SFP corresponding to the above 409 SFC as an MPLS label stack where each service segment is a local MPLS 410 label allocated from SFFs' label spaces. To some extent, the MPLS 411 label stack here could be looked as a specific implementation of the 412 SFC encapsulation used for containing the SFP information [RFC7665], 413 which does not require the SFF to maintain per-chain state. 415 When the encapsulated packet arrives at SFF1, SFF1 knows how to send 416 the packet to SF1 based on the top label (i.e., S(SF1)) of the 417 received MPLS packet. We first consider the case where SF1 is an SR- 418 aware SF, i.e., it understands how to process a packet with a pre- 419 pended SR-MPLS label stack. In this case the packet would be sent to 420 SF1 by SFF1 with the label stack S(SFF2)->S(SF2). SF1 would perform 421 the required service function on the received MPLS packet where the 422 payload type is determined using the first nibble of the MPLS 423 payload. After the MPLS packet is returned from SF1, SFF1 would send 424 it to SFF2 according to the top label (i.e., S(SFF2)). 426 If SF1 is an SR-unaware SF, i.e. one that is unable to process the 427 MPLS label stack, the remaining MPLS label stack (i.e., 428 S(SFF2)->S(SF2)) MUST be stripped from the packet before sending the 429 packet to SF1. When the packet is returned from SF1, SFF1 would re- 430 impose the MPLS label stack which had been previously stripped and 431 then send the packet to SFF2 according to the current top label 432 (i.e., S(SFF2)). Proxy mechanisms to support SR-unaware SFs are 433 proposed in section 6 of this document. 435 When the encapsulated packet arrives at SFF2, SFF2 would perform the 436 similar action to that described above. 438 By leveraging the SR-MPLS data plane, [I-D.xu-mpls-sr-over-ip] 439 describes a source routing instruction which works across both IPv4 440 and IPv6 underlays in addition to the MPLS underlay. As shown in 441 Figure 3, if there is no MPLS LSP towards the next node segment 442 (i.e., the next SFF identified by the current top label), the 443 corresponding IP-based tunnel for MPLS (e.g., MPLS-in-IP/GRE tunnel 444 [RFC4023], MPLS-in-UDP tunnel [RFC7510] or MPLS-in-L2TPv3 tunnel 445 [RFC4817]) would be used. 447 +-----------------------------------------------------+ 448 | IP network | 449 | +---------+ +---------+ | 450 | | SF1 | | SF2 | | 451 | +----+----+ +----+----+ | 452 | +---------+ | | +---------+ | 453 | | S(SFF2) | | | | S(T) | | 454 | +---------+ | | +---------+ | 455 | | S(SF2) | | | |Inner pkt| | 456 | +---------+ | | +---------+ | 457 | | S(T) | | | | 458 | +---------+ | ^ | | | 459 | |Inner pkt| ^ | | | | | | 460 | +---------+ | | | (5)| | |(6) | 461 | (2)| | |(3) | | V | 462 | (1) | | V (4) | (7) | 463 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+ 464 | Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end | 465 +----------+ +---------+ +---------+ +----+-----+ 466 | +---------+ +---------+ | 467 | |IP Tunnel| |IP Tunnel| +---------+ | 468 | |to SFF1 | | to SFF2 | | S(T) | | 469 | +---------+ +---------+ +---------+ | 470 | | S(SF1) | | S(SF2) | |Inner pkt| | 471 | +---------+ +---------+ +---------+ | 472 | | S(SFF2) | | S(T) | | 473 | +---------+ +---------+ | 474 | | S(SF2) | |Inner pkt| | 475 | +---------+ +---------+ | 476 | | S(T) | | 477 | +---------+ | 478 | |Inner pkt| | 479 | +---------+ | 480 +-----------------------------------------------------+ 482 Figure 3: Packet walk in IP underlay 484 Since the transport (i.e., the underlay) could be IPv4, IPv6 or even 485 MPLS networks, the above approach of encoding the SFP information by 486 an MPLS label stack is fully transport-independent which is one of 487 the major requirements for the SFC encapsulation [RFC7665]. 489 5.1.2. Encoding SFC Information by an MPLS Label Stack 491 The head-end, acting as a service classifier, determines that the 492 selected packet needs to travel through an SFC (SF1->SF2) and steers 493 this packet into the appropriate SR policy as described in 494 [I-D.filsfils-spring-segment-routing-policy]. This results in the 495 packet being encapsulated with an MPLS label stack containing the 496 segment list , which encodes that SFC. Those SF labels 497 MUST be domain-wide unique MPLS labels. Since it is known to the 498 service classifier that SFF1 is attached with an instance of SF1, the 499 service classifier would therefore send the MPLS encapsulated packet 500 through either an MPLS LSP tunnel or an IP-based tunnel towards SFF1 501 (as shown in Figure 4 and Figure 5 respectively). When the MPLS 502 encapsulated packet arrives at SFF1, SFF1 would know which SF should 503 be performed according to the current top label (i.e., S(SF1)). 504 Similarly, SFF1 would send the packet returned from SF1 to SFF2 505 through either an MPLS LSP tunnel or an IP-based tunnel towards SFF2 506 since it's known to SFF1 that SFF2 is attached with an instance of 507 SF2. When the encapsulated packet arrives at SFF2, SFF2 would do the 508 similar action as what has been done by SFF1. Since the transport 509 (i.e., the underlay) could be IPv4, IPv6 or even MPLS networks, the 510 above approach of encoding the SFC information by an MPLS label stack 511 is fully transport-independent which is one of the major requirements 512 for the SFC encapsulation [RFC7665]. 514 +-----------------------------------------------------+ 515 | MPLS Network | 516 | +---------+ +---------+ | 517 | | SF1 | | SF2 | | 518 | +----+----+ +----+----+ | 519 | +---------+ | | +---------+ | 520 | | S(SF2) | | | | S(T) | | 521 | +---------+ | | +---------+ | 522 | | S(T) | | | |Inner pkt| | 523 | +---------+ | ^ | | +---------+ | 524 | |Inner pkt| ^ | | | | | | 525 | +---------+ | | | (5)| | |(6) | 526 | (2)| | |(3) | | V | 527 | (1) | | V (4) | (7) | 528 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+ 529 | Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end | 530 +----------+ +---------+ +---------+ +----+-----+ 531 | +---------+ +---------+ +---------+ | 532 | | S(SFF1) | | S(SFF2) | | S(T) | | 533 | +---------+ +---------+ +---------+ | 534 | | S(SF1) | | S(SF2) | |Inner pkt| | 535 | +---------+ +---------+ +---------+ | 536 | | S(SF2) | | S(T) | | 537 | +---------+ +---------+ | 538 | | S(T) | |Inner pkt| | 539 | +---------+ +---------+ | 540 | |Inner pkt| | 541 | +---------+ | 542 +-----------------------------------------------------+ 544 Figure 4: Packet walk in MPLS underlay 546 +-----------------------------------------------------+ 547 | IP Network | 548 | +---------+ +---------+ | 549 | | SF1 | | SF2 | | 550 | +----+----+ +----+----+ | 551 | +---------+ | | +---------+ | 552 | | S(SF2) | | | | S(T) | | 553 | +---------+ | | +---------+ | 554 | | S(T) | | | |Inner pkt| | 555 | +---------+ | ^ | | +---------+ | 556 | |Inner pkt| ^ | | | | | | 557 | +---------+ | | | (5)| | |(6) | 558 | (2)| | |(3) | | V | 559 | (1) | | V (4) | (7) | 560 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+ 561 | Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end | 562 +----------+ +---------+ +---------+ +----+-----+ 563 | +---------+ +---------+ | 564 | |IP Tunnel| |IP Tunnel| +---------+ | 565 | |to SFF1 | | to SFF2 | | S(T) | | 566 | +---------+ +---------+ +---------+ | 567 | | S(SF1) | | S(SF2) | |Inner pkt| | 568 | +---------+ +---------+ +---------+ | 569 | | S(SF2) | | S(T) | | 570 | +---------+ +---------+ | 571 | | S(T) | |Inner pkt| | 572 | +---------+ +---------+ | 573 | |Inner pkt| | 574 | +---------+ | 575 +-----------------------------------------------------+ 577 Figure 5: Packet walk in IP underlay 579 5.2. SRv6 data plane 581 5.2.1. Encoding SFP Information by an SRv6 SRH 582 +----------------------------------------------------+ 583 | SRv6 network | 584 | +---------+ +---------+ | 585 | | SF1 | | SF2 | | 586 | +----+----+ +----+----+ | 587 | ^ | |(3) ^ | |(6) | 588 | (1) (2)| | V (4) (5)| | V (7) | 589 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+ 590 | Head-end +------+ SFF1 +-------+ SFF2 +------+ Tail-end | 591 +----------+ +---------+ +---------+ +----+-----+ 592 | +---------+ +---------+ +---------+ | 593 | |IP6 (H, | |IP6 (H, | |IP6 (H,T)| | 594 | | SFF1)| | SFF2)| +---------+ | 595 | +---------+ +---------+ |SRH (T, | | 596 | |SRH (T, | |SRH (T, | |SFF2:SF2,| | 597 | |SFF2:SF2,| |SFF2:SF2,| |SFF1:SF1;| | 598 | |SFF1:SF1;| |SFF1:SF1;| |SL=0) | | 599 | |SL=2) | |SL=1) | +---------+ | 600 | +---------+ +---------+ |Inner pkt| | 601 | |Inner pkt| |Inner pkt| +---------+ | 602 | +---------+ +---------+ | 603 +----------------------------------------------------+ 605 Figure 6: Packet walk in SRv6 network 607 As shown in Figure 6, the head-end, acting as a service classifier, 608 determines that the selected packet needs to travel through an SFC 609 (SF1->SF2) and steers this packet into the appropriate SR policy as 610 described in [I-D.filsfils-spring-segment-routing-policy]. As a 611 result, the packet is encapsulated with an IPv6 header and an SRH 612 containing the segment list . The 613 intermediate segments in this list leverage the SRv6 locator-function 614 concept introduced in [I-D.filsfils-spring-srv6-network-programming] 615 to encode both the SFF and the SF in a single IPv6 SID. The traffic 616 is steered via regular IPv6 forwarding up to the SFF represented in 617 the locator part of the SID and then passed to the SF identified by 618 the SID function. This SRH thus indicates in a stateless manner the 619 SFP corresponding to the above SFC. To some extent, the SRH here 620 could be looked as a specific implementation of the SFC encapsulation 621 used for containing the SFP information [RFC7665], which does not 622 require the SFF to maintain per-chain state. 624 When the encapsulated packet arrives at SFF1, SFF1 knows how to send 625 the packet to the SF based on the active segment. We first consider 626 the case where SF1 is an SR-aware SF, i.e., it understands how to 627 process an IPv6 encapsulated packet with an SRH. In this case the 628 packet is sent to SF1 by SFF1 with the IP and SR headers 629 (H,SFF2:SF2)(T,SFF2:SF2,SFF1:SF1;SL=1). SF1 performs the required 630 service function on the received packet, where the payload is 631 determined based on the Next Header field value of last extension 632 header and/or the active segment. After the packet is returned from 633 SF1, SFF1 simply forwards it to SFF2 according to the IPv6 634 destination address. 636 If SF1 is an SR-unaware SF, i.e. one that is unable to process IPv6 637 encapsulated packets with an SRH, the encapsulation headers (i.e., 638 outer IPv6 with any extension header) MUST be stripped from the 639 packet before it is sent to SF1. When the packet is returned from 640 SF1, SFF1 would re-encapsulate the packet with the IPv6 and SR 641 headers that had been previously stripped and then send the packet to 642 SFF2 according to the IPv6 destination address. Proxy mechanisms to 643 support SR-unaware SFs are proposed in section 6 of this document. 645 When the encapsulated packet arrives at SFF2, SFF2 would perform the 646 similar action to that described above. 648 5.2.2. Encoding SFC Information by an IPv6 SRH 650 The head-end, acting as a service classifier, determines that the 651 selected packet needs to travel through an SFC (SF1->SF2) and steers 652 this packet into the appropriate SR policy. This results in the 653 packet being encapsulated with an IPv6 header and an SRH containing 654 the segment list . In this case, the locator 655 parts A1 and A2 of the intermediate service segments are anycast 656 prefixes advertised by several SFFs attached to SF1 and SF2, 657 respectively. The policy head-end may thus let the traffic be 658 steered to the closest instance of each SF or add intermediate 659 segments to select a particular SF instance. Furthermore, since it 660 is known to the head-end that SFF1 is attached to an instance of SF1, 661 the encapsulated packet may be sent to SFF1 through an MPLS LSP or an 662 IP-based tunnel. Similar tunneling can then be performed between 663 SFF1 and SFF1, and between SFF2 and the tail-end, as illustrated on 664 Figure 7. Since the transport (i.e., the underlay) could be IPv4, 665 IPv6 or even MPLS, the above approach of encoding the SFC information 666 by an IPv6 SRH is fully transport-independent which is one of the 667 major requirements for the SFC encapsulation [RFC7665]. 669 +----------------------------------------------------+ 670 | Underlay network | 671 | +---------+ +---------+ | 672 | | SF1 | | SF2 | | 673 | +----+----+ +----+----+ | 674 | ^ | |(3) ^ | |(6) | 675 | (1) (2)| | V (4) (5)| | V (7) | 676 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+ 677 | Head-end +------+ SFF1 +-------+ SFF2 +------+ Tail-end | 678 +----------+ +---------+ +---------+ +----+-----+ 679 | +---------+ +---------+ +---------+ | 680 | |Tunnel to| |Tunnel to| |Tunnel to| | 681 | |SFF1 | |SFF2 | |T | | 682 | +---------+ +---------+ +---------+ | 683 | |IP6 (H, | |IP6 (H, | |IP6 (H,T)| | 684 | | SF1)| | SFF2)| +---------+ | 685 | +---------+ +---------+ |SRH (T, | | 686 | |SRH (T, | |SRH (T, | |SF2, SF1;| | 687 | |SF2, SF1;| |SF2, SF1;| |SL=0) | | 688 | |SL=2) | |SL=1) | +---------+ | 689 | +---------+ +---------+ |Inner pkt| | 690 | |Inner pkt| |Inner pkt| +---------+ | 691 | +---------+ +---------+ | 692 +----------------------------------------------------+ 694 Figure 7: Packet walk in underlay network 696 6. SR proxy behaviors 698 This section describes several SR proxy behaviors designed to enable 699 SR SFC through SR-unaware SFs. A system implementing one of these 700 functions may handle the SR processing on behalf of an SR-unaware SF 701 and allows the SF to properly process the traffic that is steered 702 through it. 704 An SF may be located at any hop in an SR policy, including the last 705 segment. However, the SR proxy behaviors defined in this section are 706 dedicated to supporting SR-unaware SFs at intermediate hops in the 707 segment list. In case an SR-unaware SF is at the last segment, it is 708 sufficient to ensure that the SR information is ignored (IPv6 routing 709 extension header with Segments Left equal to 0) or removed before the 710 packet reaches the SF (MPLS PHP, SRv6 End.D or PSP). 712 As illustrated on Figure 8, the generic behavior of an SR proxy has 713 two parts. The first part is in charge of passing traffic from the 714 network to the SF. It intercepts the SR traffic destined for the SF 715 via a locally instantiated service segment, modifies it in such a way 716 that it appears as non-SR traffic to the SF, then sends it out on a 717 given interface, IFACE-OUT, connected to the SF. The second part 718 receives the traffic coming back from the SF on IFACE-IN, restores 719 the SR information and forwards it according to the next segment in 720 the list. IFACE-OUT and IFACE-IN are respectively the proxy 721 interface used for sending traffic to the SF and the proxy interface 722 that receives the traffic coming back from the SF. These can be 723 physical interfaces or sub-interfaces (VLANs) and, unless otherwise 724 stated, IFACE-OUT and IFACE-IN can represent the same interface. 726 +----------------------------+ 727 | | 728 | Service Function | 729 | | 730 +----------------------------+ 731 ^ Non SR | 732 | traffic | 733 | v 734 +-----------+----------+ 735 +--| IFACE OUT | IFACE IN |--+ 736 SR traffic | +-----------+----------+ | SR traffic 737 ---------->| SR proxy |----------> 738 | | 739 +----------------------------+ 741 Figure 8: Generic SR proxy 743 In the next subsections, the following SR proxy mechanisms are 744 defined: 746 o Static proxy 748 o Dynamic proxy 750 o Shared-memory proxy 752 o Masquerading proxy 754 Each mechanism has its own characteristics and constraints, which are 755 summarized in the below table. It is up to the operator to select 756 the best one based on the proxy node capabilities, the SF behavior 757 and the traffic type. It is also possible to use different proxy 758 mechanisms within the same service chain. 760 +-----+-----+-----+-----+ 761 | | | | M | 762 | | | S | a | 763 | | | h | s | 764 | | | a | q | 765 | | | r | u | 766 | | D | e | e | 767 | S | y | d | r | 768 | t | n | | a | 769 | a | a | m | d | 770 | t | m | e | i | 771 | i | i | m | n | 772 | c | c | . | g | 773 +---------------------------------------+-----+-----+-----+-----+ 774 | | SR-MPLS | Y | Y | Y | - | 775 | | | | | | | 776 | SR flavors | SRv6 insertion | P | P | P | Y | 777 | | | | | | | 778 | | SRv6 encapsulation | Y | Y | Y | - | 779 +----------------+----------------------+-----+-----+-----+-----+ 780 | | Ethernet | Y | Y | Y | - | 781 | | | | | | | 782 | Inner header | IPv4 | Y | Y | Y | - | 783 | | | | | | | 784 | | IPv6 | Y | Y | Y | - | 785 +----------------+----------------------+-----+-----+-----+-----+ 786 | Chain agnostic configuration | N | N | Y | Y | 787 +---------------------------------------+-----+-----+-----+-----+ 788 | Transparent to chain changes | N | Y | Y | Y | 789 +----------------+----------------------+-----+-----+-----+-----+ 790 | | DA modification | Y | Y | Y | NAT | 791 | | | | | | | 792 | | Payload modification | Y | Y | Y | Y | 793 | | | | | | | 794 | SF support | Packet generation | Y | Y |cache|cache| 795 | | | | | | | 796 | | Packet deletion | Y | Y | Y | Y | 797 | | | | | | | 798 | | Transport endpoint | Y | Y |cache|cache| 799 +----------------+----------------------+-----+-----+-----+-----+ 801 Figure 9: SR proxy summary 803 Note: The use of a shared memory proxy requires both the SF and the 804 proxy to be running on the same node. 806 6.1. Static SR proxy 808 The static proxy is an SR endpoint behavior for processing SR-MPLS or 809 SRv6 encapsulated traffic on behalf of an SR-unaware SF. This proxy 810 thus receives SR traffic that is formed of an MPLS label stack or an 811 IPv6 header on top of an inner packet, which can be Ethernet, IPv4 or 812 IPv6. 814 A static SR proxy segment is associated with the following mandatory 815 parameters: 817 o INNER-TYPE: Inner packet type 819 o S-ADDR: Ethernet or IP address of the SF (only for inner type IPv4 820 and IPv6) 822 o IFACE-OUT: Local interface for sending traffic towards the SF 824 o IFACE-IN: Local interface receiving the traffic coming back from 825 the SF 827 o CACHE: SR information to be attached on the traffic coming back 828 from the SF, including at least 830 * CACHE.SA: IPv6 source address (SRv6 only) 832 * CACHE.LIST: Segment list expressed as MPLS labels or IPv6 833 address 835 A static SR proxy segment is thus defined for a specific SF, inner 836 packet type and cached SR information. It is also bound to a pair of 837 directed interfaces on the proxy. These may be both directions of a 838 single interface, or opposite directions of two different interfaces. 839 The latter is recommended in case the SF is to be used as part of a 840 bi-directional SR SC policy. If the proxy and the SF both support 841 802.1Q, IFACE-OUT and IFACE-IN can also represent sub-interfaces. 843 The first part of this behavior is triggered when the proxy node 844 receives a packet whose active segment matches a segment associated 845 with the static proxy behavior. It removes the SR information from 846 the packet then sends it on a specific interface towards the 847 associated SF. This SR information corresponds to the full label 848 stack for SR-MPLS or to the encapsulation IPv6 header with any 849 attached extension header in the case of SRv6. 851 The second part is an inbound policy attached to the proxy interface 852 receiving the traffic returning from the SF, IFACE-IN. This policy 853 attaches to the incoming traffic the cached SR information associated 854 with the SR proxy segment. If the proxy segment uses the SR-MPLS 855 data plane, CACHE contains a stack of labels to be pushed on top the 856 packets. With the SRv6 data plane, CACHE is defined as a source 857 address, an active segment and an optional SRH (tag, segments left, 858 segment list and metadata). The proxy encapsulates the packets with 859 an IPv6 header that has the source address, the active segment as 860 destination address and the SRH as a routing extension header. After 861 the SR information has been attached, the packets are forwarded 862 according to the active segment, which is represented by the top MPLS 863 label or the IPv6 Destination Address. 865 In this scenario, there are no restrictions on the operations that 866 can be performed by the SF on the stream of packets. It may operate 867 at all protocol layers, terminate transport layer connections, 868 generate new packets and initiate transport layer connections. This 869 behavior may also be used to integrate an IPv4-only SF into an SRv6 870 policy. However, a static SR proxy segment can be used in only one 871 service chain at a time. As opposed to most other segment types, a 872 static SR proxy segment is bound to a unique list of segments, which 873 represents a directed SR SC policy. This is due to the cached SR 874 information being defined in the segment configuration. This 875 limitation only prevents multiple segment lists from using the same 876 static SR proxy segment at the same time, but a single segment list 877 can be shared by any number of traffic flows. Besides, since the 878 returning traffic from the SF is re-classified based on the incoming 879 interface, an interface can be used as receiving interface (IFACE-IN) 880 only for a single SR proxy segment at a time. In the case of a bi- 881 directional SR SC policy, a different SR proxy segment and receiving 882 interface are required for the return direction. 884 6.1.1. SR-MPLS pseudocode 886 6.1.1.1. Static proxy for inner type Ethernet 888 Upon receiving an MPLS packet with top label L, where L is an MPLS L2 889 static proxy segment, a node N does: 891 1. IF payload type is Ethernet THEN 892 2. Pop all labels 893 3. Forward the exposed frame on IFACE-OUT 894 4. ELSE 895 5. Drop the packet 897 Upon receiving on IFACE-IN an Ethernet frame with a destination 898 address different than the interface address, a node N does: 900 1. Push labels in CACHE on top of the frame Ethernet header 901 2. Lookup the top label and proceed accordingly 902 The receiving interface must be configured in promiscuous mode in 903 order to accept those Ethernet frames. 905 6.1.1.2. Static proxy for inner type IPv4 907 Upon receiving an MPLS packet with top label L, where L is an MPLS 908 IPv4 static proxy segment, a node N does: 910 1. IF payload type is IPv4 THEN 911 2. Pop all labels 912 3. Forward the exposed packet on IFACE-OUT towards S-ADDR 913 4. ELSE 914 5. Drop the packet 916 Upon receiving a non link-local IPv4 packet on IFACE-IN, a node N 917 does: 919 1. Decrement TTL and update checksum 920 2. Push labels in CACHE on top of the packet IPv4 header 921 3. Lookup the top label and proceed accordingly 923 6.1.1.3. Static proxy for inner type IPv6 925 Upon receiving an MPLS packet with top label L, where L is an MPLS 926 IPv6 static proxy segment, a node N does: 928 1. IF payload type is IPv6 THEN 929 2. Pop all labels 930 3. Forward the exposed packet on IFACE-OUT towards S-ADDR 931 4. ELSE 932 5. Drop the packet 934 Upon receiving a non link-local IPv6 packet on IFACE-IN, a node N 935 does: 937 1. Decrement Hop Limit 938 2. Push labels in CACHE on top of the packet IPv6 header 939 3. Lookup the top label and proceed accordingly 941 6.1.2. SRv6 pseudocode 943 6.1.2.1. Static proxy for inner type Ethernet 945 Upon receiving an IPv6 packet destined for S, where S is an IPv6 946 static proxy segment for Ethernet traffic, a node N does: 948 1. IF ENH == 59 THEN ;; Ref1 949 2. Remove the (outer) IPv6 header and its extension headers 950 3. Forward the exposed frame on IFACE-OUT 951 4. ELSE 952 5. Drop the packet 954 Ref1: 59 refers to "no next header" as defined by IANA allocation for 955 Internet Protocol Numbers. 957 Upon receiving on IFACE-IN an Ethernet frame with a destination 958 address different than the interface address, a node N does: 960 1. Retrieve CACHE entry matching IFACE-IN and traffic type 961 2. Push SRH with CACHE.LIST on top of the Ethernet header ;; Ref2 962 3. Push IPv6 header with 963 SA = CACHE.SA 964 DA = CACHE.LIST[0] ;; Ref3 965 Next Header = 43 ;; Ref4 966 4. Set outer payload length and flow label 967 5. Lookup outer DA in appropriate table and proceed accordingly 969 Ref2: Unless otherwise specified, the segments in CACHE.LIST should 970 be encoded in reversed order, Segment Left and Last Entry values 971 should be set of the length of CACHE.LIST minus 1, and Next Header 972 should be set to 59. 974 Ref3: CACHE.LIST[0] represents the first IPv6 SID in CACHE.LIST. 976 Ref4: If CACHE.LIST contains a single entry, the SRH can be omitted 977 and the Next Header value must be set to 59. 979 The receiving interface must be configured in promiscuous mode in 980 order to accept those Ethernet frames. 982 6.1.2.2. Static proxy for inner type IPv4 984 Upon receiving an IPv6 packet destined for S, where S is an IPv6 985 static proxy segment for IPv4 traffic, a node N does: 987 1. IF ENH == 4 THEN ;; Ref1 988 2. Remove the (outer) IPv6 header and its extension headers 989 3. Forward the exposed packet on IFACE-OUT towards S-ADDR 990 4. ELSE 991 5. Drop the packet 993 Ref1: 4 refers to IPv4 encapsulation as defined by IANA allocation 994 for Internet Protocol Numbers. 996 Upon receiving a non link-local IPv4 packet on IFACE-IN, a node N 997 does: 999 1. Decrement TTL and update checksum 1000 2. IF CACHE.SRH THEN ;; Ref2 1001 3. Push CACHE.SRH on top of the existing IPv4 header 1002 4. Set NH value of the pushed SRH to 4 1003 5. Push outer IPv6 header with SA, DA and traffic class from CACHE 1004 6. Set outer payload length and flow label 1005 7. Set NH value to 43 if an SRH was added, or 4 otherwise 1006 8. Lookup outer DA in appropriate table and proceed accordingly 1008 Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the 1009 static SR proxy segment associated with IFACE-IN. 1011 6.1.2.3. Static proxy for inner type IPv6 1013 Upon receiving an IPv6 packet destined for S, where S is an IPv6 1014 static proxy segment for IPv6 traffic, a node N does: 1016 1. IF ENH == 41 THEN ;; Ref1 1017 2. Remove the (outer) IPv6 header and its extension headers 1018 3. Forward the exposed packet on IFACE-OUT towards S-ADDR 1019 4. ELSE 1020 5. Drop the packet 1022 Ref1: 41 refers to IPv6 encapsulation as defined by IANA allocation 1023 for Internet Protocol Numbers. 1025 Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N 1026 does: 1028 1. Decrement Hop Limit 1029 2. IF CACHE.SRH THEN ;; Ref2 1030 3. Push CACHE.SRH on top of the existing IPv6 header 1031 4. Set NH value of the pushed SRH to 41 1032 5. Push outer IPv6 header with SA, DA and traffic class from CACHE 1033 6. Set outer payload length and flow label 1034 7. Set NH value to 43 if an SRH was added, or 41 otherwise 1035 8. Lookup outer DA in appropriate table and proceed accordingly 1037 Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the 1038 static SR proxy segment associated with IFACE-IN. 1040 6.2. Dynamic SR proxy 1042 The dynamic proxy is an improvement over the static proxy that 1043 dynamically learns the SR information before removing it from the 1044 incoming traffic. The same information can then be re-attached to 1045 the traffic returning from the SF. As opposed to the static SR 1046 proxy, no CACHE information needs to be configured. Instead, the 1047 dynamic SR proxy relies on a local caching mechanism on the node 1048 instantiating this segment. Therefore, a dynamic proxy segment 1049 cannot be the last segment in an SR SC policy. As mentioned at the 1050 beginning of Section 6, a different SR behavior should be used if the 1051 SF is meant to be the final destination of an SR SC policy. 1053 Upon receiving a packet whose active segment matches a dynamic SR 1054 proxy function, the proxy node pops the top MPLS label or applies the 1055 SRv6 End behavior, then compares the updated SR information with the 1056 cache entry for the current segment. If the cache is empty or 1057 different, it is updated with the new SR information. The SR 1058 information is then removed and the inner packet is sent towards the 1059 SF. 1061 The cache entry is not mapped to any particular packet, but instead 1062 to an SR SC policy identified by the receiving interface (IFACE-IN). 1063 Any non-link-local IP packet or non-local Ethernet frame received on 1064 that interface will be re-encapsulated with the cached headers as 1065 described in Section 6.1. The SF may thus drop, modify or generate 1066 new packets without affecting the proxy. 1068 6.2.1. SR-MPLS pseudocode 1070 The dynamic proxy SR-MPLS pseudocode is obtained by inserting the 1071 following instructions between lines 1 and 2 of the static SR-MPLS 1072 pseudocode. 1074 1. IF top label S bit is 0 THEN 1075 2. Pop top label 1076 3. IF C(IFACE-IN) different from remaining labels THEN ;; Ref1 1077 4. Copy all remaining labels into C(IFACE-IN) ;; Ref2 1078 5. ELSE 1079 6. Drop the packet 1081 Ref1: A TTL margin can be configured for the top label stack entry to 1082 prevent constant cache updates when multiple equal-cost paths with 1083 different hop counts are used towards the SR proxy node. In that 1084 case, a TTL difference smaller than the configured margin should not 1085 trigger a cache update (provided that the labels are the same). 1087 Ref2: C(IFACE-IN) represents the cache entry associated to the 1088 dynamic SR proxy segment. It is identified with IFACE-IN in order to 1089 efficiently retrieve the right SR information when a packet arrives 1090 on this interface. 1092 In addition, the inbound policy should check that C(IFACE-IN) has 1093 been defined before attempting to restore the MPLS label stack, and 1094 drop the packet otherwise. 1096 6.2.2. SRv6 pseudocode 1098 The dynamic proxy SRv6 pseudocode is obtained by inserting the 1099 following instructions between lines 1 and 2 of the static proxy SRv6 1100 pseudocode. 1102 1. IF NH=SRH & SL > 0 THEN 1103 2. Decrement SL and update the IPv6 DA with SRH[SL] 1104 3. IF C(IFACE-IN) different from IPv6 encaps THEN ;; Ref1 1105 4. Copy the IPv6 encaps into C(IFACE-IN) ;; Ref2 1106 5. ELSE 1107 6. Drop the packet 1109 Ref1: "IPv6 encaps" represents the IPv6 header and any attached 1110 extension header. 1112 Ref2: C(IFACE-IN) represents the cache entry associated to the 1113 dynamic SR proxy segment. It is identified with IFACE-IN in order to 1114 efficiently retrieve the right SR information when a packet arrives 1115 on this interface. 1117 In addition, the inbound policy should check that C(IFACE-IN) has 1118 been defined before attempting to restore the IPv6 encapsulation, and 1119 drop the packet otherwise. 1121 6.3. Shared memory SR proxy 1123 The shared memory proxy is an SR endpoint behavior for processing SR- 1124 MPLS or SRv6 encapsulated traffic on behalf of an SR-unaware SF. 1125 This proxy behavior leverages a shared-memory interface with the SF 1126 in order to hide the SR information from an SR-unaware SF while 1127 keeping it attached to the packet. We assume in this case that the 1128 proxy and the SF are running on the same compute node. A typical 1129 scenario is an SR-capable vrouter running on a container host and 1130 forwarding traffic to virtual SFs isolated within their respective 1131 container. 1133 More details will be added in a future revision of this document. 1135 6.4. Masquerading SR proxy 1137 The masquerading proxy is an SR endpoint behavior for processing SRv6 1138 traffic on behalf of an SR-unaware SF. This proxy thus receives SR 1139 traffic that is formed of an IPv6 header and an SRH on top of an 1140 inner payload. The masquerading behavior is independent from the 1141 inner payload type. Hence, the inner payload can be of any type but 1142 it is usually expected to be a transport layer packet, such as TCP or 1143 UDP. 1145 A masquerading SR proxy segment is associated with the following 1146 mandatory parameters: 1148 o S-ADDR: Ethernet or IPv6 address of the SF 1150 o IFACE-OUT: Local interface for sending traffic towards the SF 1152 o IFACE-IN: Local interface receiving the traffic coming back from 1153 the SF 1155 A masquerading SR proxy segment is thus defined for a specific SF and 1156 bound to a pair of directed interfaces or sub-interfaces on the 1157 proxy. As opposed to the static and dynamic SR proxies, a 1158 masquerading segment can be present at the same time in any number of 1159 SR SC policies and the same interfaces can be bound to multiple 1160 masquerading proxy segments. The only restriction is that a 1161 masquerading proxy segment cannot be the last segment in an SR SC 1162 policy. 1164 The first part of the masquerading behavior is triggered when the 1165 proxy node receives an IPv6 packet whose Destination Address matches 1166 a masquerading proxy segment. The proxy inspects the IPv6 extension 1167 headers and substitutes the Destination Address with the last segment 1168 in the SRH attached to the IPv6 header, which represents the final 1169 destination of the IPv6 packet. The packet is then sent out towards 1170 the SF. 1172 The SF receives an IPv6 packet whose source and destination addresses 1173 are respectively the original source and final destination. It does 1174 not attempt to inspect the SRH, as RFC8200 specifies that routing 1175 extension headers are not examined or processed by transit nodes. 1176 Instead, the SF simply forwards the packet based on its current 1177 Destination Address. In this scenario, we assume that the SF can 1178 only inspect, drop or perform limited changes to the packets. For 1179 example, Intrusion Detection Systems, Deep Packet Inspectors and non- 1180 NAT Firewalls are among the SFs that can be supported by a 1181 masquerading SR proxy. Variants of the masquerading behavior are 1182 defined in Section 6.4.2 and Section 6.4.3 to support a wider range 1183 of SFs. 1185 The second part of the masquerading behavior, also called de- 1186 masquerading, is an inbound policy attached to the proxy interface 1187 receiving the traffic returning from the SF, IFACE-IN. This policy 1188 inspects the incoming traffic and triggers a regular SRv6 endpoint 1189 processing (End) on any IPv6 packet that contains an SRH. This 1190 processing occurs before any lookup on the packet Destination Address 1191 is performed and it is sufficient to restore the right active segment 1192 as the Destination Address of the IPv6 packet. 1194 6.4.1. SRv6 masquerading proxy pseudocode 1196 Masquerading: Upon receiving a packet destined for S, where S is an 1197 IPv6 masquerading proxy segment, a node N processes it as follows. 1199 1. IF NH=SRH & SL > 0 THEN 1200 2. Update the IPv6 DA with SRH[0] 1201 3. Forward the packet on IFACE-OUT 1202 4. ELSE 1203 5. Drop the packet 1205 De-masquerading: Upon receiving a non-link-local IPv6 packet on 1206 IFACE-IN, a node N processes it as follows. 1208 1. IF NH=SRH & SL > 0 THEN 1209 2. Decrement SL 1210 3. Update the IPv6 DA with SRH[SL] ;; Ref1 1211 4. Lookup DA in appropriate table and proceed accordingly 1213 Ref2: This pseudocode can be augmented to support the Penultimate 1214 Segment Popping (PSP) endpoint flavor. The exact pseudocode 1215 modification are provided in 1216 [I-D.filsfils-spring-srv6-network-programming]. 1218 6.4.2. Variant 1: Destination NAT 1220 SFs modifying the destination address in the packets they process, 1221 such as NATs, can be supported by a masquerading proxy with the 1222 following modification to the de-masquerading pseudocode. 1224 De-masquerading - NAT: Upon receiving a non-link-local IPv6 packet on 1225 IFACE-IN, a node N processes it as follows. 1227 1. IF NH=SRH & SL > 0 THEN 1228 2. Update SRH[0] with the IPv6 DA 1229 3. Decrement SL 1230 4. Update the IPv6 DA with SRH[SL] 1231 5. Lookup DA in appropriate table and proceed accordingly 1233 6.4.3. Variant 2: Caching 1235 SFs generating packets or acting as endpoints for transport 1236 connections can be supported by adding a dynamic caching mechanism 1237 similar to the one described in Section 6.2. 1239 More details will be added in a future revision of this document. 1241 7. Metadata 1243 7.1. MPLS data plane 1245 Since the MPLS encapsulation has no explicit protocol identifier 1246 field to indicate the protocol type of the MPLS payload, how to 1247 indicate the presence of metadata (i.e., the NSH which is only used 1248 as a metadata containner) in an MPLS packet is a potential issue to 1249 be addressed. One possible way to address the above issue is: SFFs 1250 allocate two different labels for a given SF, one indicates the 1251 presence of NSH while the other indicates the absence of NSH. This 1252 approach has no change to the current MPLS architecture but it would 1253 require more than one label binding for a given SF. Another possible 1254 way is to introduce a protocol identifier field within the MPLS 1255 packet as described in [I-D.xu-mpls-payload-protocol-identifier]. 1257 More details about how to contain metadata within an MPLS packet 1258 would be considered in the future version of this draft. 1260 7.2. IPv6 data plane 1262 7.2.1. SRH TLV objects 1264 The IPv6 SRH TLV objects are designed to carry all sorts of metadata. 1265 In particular, [I-D.ietf-6man-segment-routing-header] defines the NSH 1266 carrier TLV as a container for NSH metadata. 1268 TLV objects can be imposed by the ingress edge router that steers the 1269 traffic into the SR SC policy. 1271 An SR-aware SF may impose, modify or remove any TLV object attached 1272 to the first SRH, either by directly modifying the packet headers or 1273 via a control channel between the SF and its forwarding plane. 1275 An SR-aware SF that re-classifies the traffic and steers it into a 1276 new SR SC policy (e.g. DPI) may attach any TLV object to the new 1277 SRH. 1279 Metadata imposition and handling will be further discussed in a 1280 future version of this document. 1282 7.2.2. SRH tag 1284 The SRH tag identifies a packet as part of a group or class of 1285 packets [I-D.ietf-6man-segment-routing-header]. 1287 In an SFC context, this field can be used to encode basic metadata in 1288 the SRH. 1290 8. Implementation status 1292 The static SR proxy is available for SR-MPLS and SRv6 on various 1293 Cisco hardware and software platforms. Furthermore, the following 1294 proxies are available on open-source software. 1296 +-------------+-------------+ 1297 | VPP | Linux | 1298 +---+-----------------------------------+-------------+-------------+ 1299 | M | Static proxy | Available | In progress | 1300 | P | | | | 1301 | L | Dynamic proxy | In progress | In progress | 1302 | S | | | | 1303 | | Shared memory proxy | In progress | In progress | 1304 +---+-----------------------------------+-------------+-------------+ 1305 | | Static proxy | Available | In progress | 1306 | | | | | 1307 | |Dynamic proxy - Inner type Ethernet| In progress | In progress | 1308 | | | | | 1309 | | Dynamic proxy - Inner type IPv4 | Available | Available | 1310 | S | | | | 1311 | R | Dynamic proxy - Inner type IPv6 | Available | Available | 1312 | v | | | | 1313 | 6 | Shared memory proxy | In progress | In progress | 1314 | | | | | 1315 | | Masquerading proxy | Available | Available | 1316 | | | | | 1317 | | Masquerading proxy - NAT variant | In progress | In progress | 1318 | | | | | 1319 | |Masquerading proxy - Cache variant | In progress | In progress | 1320 +---+-----------------------------------+-------------+-------------+ 1322 Open-source implementation status table 1324 9. Related works 1326 The Segment Routing solution addresses a wide problem that covers 1327 both topological and service chaining policies. The topological and 1328 service instructions can be either deployed in isolation or in 1329 combination. SR has thus a wider applicability than the architecture 1330 defined in [RFC7665]. Furthermore, the inherent property of SR is a 1331 stateless network fabric. In SR, there is no state within the fabric 1332 to recognize a flow and associate it with a policy. State is only 1333 present at the ingress edge of the SR domain, where the policy is 1334 encoded into the packets. This is completely different from other 1335 proposals such as [RFC8300] and the MPLS label swapping mechanism 1336 described in [I-D.farrel-mpls-sfc], which rely on state configured at 1337 every hop of the service chain. 1339 10. IANA Considerations 1341 This I-D requests the IANA to allocate, within the "SRv6 Endpoint 1342 Types" sub-registry belonging to the top-level "Segment-routing with 1343 IPv6 dataplane (SRv6) Parameters" registry, the following 1344 allocations: 1346 +-------------+-----+-----------------------------------+-----------+ 1347 | Value/Range | Hex | Endpoint function | Reference | 1348 +-------------+-----+-----------------------------------+-----------+ 1349 | TBA | TBA | End.AN - SR-aware function | [This.ID] | 1350 | | | (native) | | 1351 | TBA | TBA | End.AS - Static proxy | [This.ID] | 1352 | TBA | TBA | End.AD - Dynamic proxy | [This.ID] | 1353 | TBA | TBA | End.AM - Masquerading proxy | [This.ID] | 1354 +-------------+-----+-----------------------------------+-----------+ 1356 Table 1: SRv6 SFC Endpoint Types 1358 11. Security Considerations 1360 The security requirements and mechanisms described in 1361 [I-D.ietf-spring-segment-routing] and 1362 [I-D.ietf-6man-segment-routing-header] also apply to this document. 1364 Furthermore, it is fundamental to the SFC design that the classifier 1365 is a trusted resource which determines the processing that the packet 1366 will be subject to, including for example the firewall. Where an SF 1367 is not SR-aware the packet may exist as an IP packet, however this is 1368 an intrinsic part of the SFC design which needs to define how a 1369 packet is protected in that environment. Where a tunnel is used to 1370 link two non-MPLS domains, the tunnel design needs to specify how it 1371 is secured. 1373 Thus the security vulnerabilities are addressed in the underlying 1374 technologies used by this design, which itself does not introduce any 1375 new security vulnerabilities. 1377 12. Acknowledgements 1379 The authors would like to thank Loa Andersson, Andrew G. Malis, 1380 Adrian Farrel, Alexander Vainshtein and Joel M. Halpern for their 1381 valuable comments and suggestions on the document. 1383 13. Contributors 1385 P. Camarillo (Cisco), B. Peirens (Proximus), D. Steinberg 1386 (Steinberg Consulting), A. AbdelSalam (Gran Sasso Science 1387 Institute), G. Dawra (Cisco), S. Bryant (Huawei), H. Assarpour 1388 (Broadcom), H. Shah (Ciena), L. Contreras (Telefonica I+D), J. 1389 Tantsura (Individual), M. Vigoureux (Nokia) and J. Bhattacharya 1390 (Cisco) substantially contributed to the content of this document. 1392 14. References 1394 14.1. Normative References 1396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1397 Requirement Levels", BCP 14, RFC 2119, 1398 DOI 10.17487/RFC2119, March 1997, 1399 . 1401 14.2. Informative References 1403 [I-D.dawra-idr-bgp-sr-service-chaining] 1404 Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d., 1405 Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F., 1406 and K. Talaulikar, "BGP Control Plane Extensions for 1407 Segment Routing based Service Chaining", draft-dawra-idr- 1408 bgp-sr-service-chaining-02 (work in progress), January 1409 2018. 1411 [I-D.farrel-mpls-sfc] 1412 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1413 Forwarding Plane for Service Function Chaining", draft- 1414 farrel-mpls-sfc-04 (work in progress), March 2018. 1416 [I-D.filsfils-spring-segment-routing-policy] 1417 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 1418 F., Talaulikar, K., Ali, Z., Hegde, S., 1419 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 1420 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 1421 Litkowski, S., and P. Mattes, "Segment Routing Policy for 1422 Traffic Engineering", draft-filsfils-spring-segment- 1423 routing-policy-05 (work in progress), February 2018. 1425 [I-D.filsfils-spring-srv6-network-programming] 1426 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 1427 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1428 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1429 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 1430 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 1431 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 1432 Camarillo, "SRv6 Network Programming", draft-filsfils- 1433 spring-srv6-network-programming-03 (work in progress), 1434 December 2017. 1436 [I-D.ietf-6man-segment-routing-header] 1437 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 1438 Field, B., daniel.voyer@bell.ca, d., 1439 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 1440 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 1441 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 1442 Header (SRH)", draft-ietf-6man-segment-routing-header-08 1443 (work in progress), January 2018. 1445 [I-D.ietf-spring-segment-routing] 1446 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1447 Litkowski, S., and R. Shakir, "Segment Routing 1448 Architecture", draft-ietf-spring-segment-routing-15 (work 1449 in progress), January 2018. 1451 [I-D.ietf-spring-segment-routing-mpls] 1452 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1453 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1454 data plane", draft-ietf-spring-segment-routing-mpls-12 1455 (work in progress), February 2018. 1457 [I-D.xu-mpls-payload-protocol-identifier] 1458 Xu, X., Assarpour, H., and S. Ma, "MPLS Payload Protocol 1459 Identifier", draft-xu-mpls-payload-protocol-identifier-04 1460 (work in progress), January 2018. 1462 [I-D.xu-mpls-sr-over-ip] 1463 Xu, X., Bryant, S., Farrel, A., Bashandy, A., Henderickx, 1464 W., and Z. Li, "SR-MPLS over IP", draft-xu-mpls-sr-over- 1465 ip-00 (work in progress), February 2018. 1467 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 1468 "Encapsulating MPLS in IP or Generic Routing Encapsulation 1469 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 1470 . 1472 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 1473 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 1474 Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 1475 2007, . 1477 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 1478 "Encapsulating MPLS in UDP", RFC 7510, 1479 DOI 10.17487/RFC7510, April 2015, 1480 . 1482 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1483 Chaining (SFC) Architecture", RFC 7665, 1484 DOI 10.17487/RFC7665, October 2015, 1485 . 1487 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1488 "Network Service Header (NSH)", RFC 8300, 1489 DOI 10.17487/RFC8300, January 2018, 1490 . 1492 Authors' Addresses 1494 Francois Clad (editor) 1495 Cisco Systems, Inc. 1496 France 1498 Email: fclad@cisco.com 1500 Xiaohu Xu (editor) 1501 Alibaba 1503 Email: xiaohu.xxh@alibaba-inc.com 1504 Clarence Filsfils 1505 Cisco Systems, Inc. 1506 Belgium 1508 Email: cf@cisco.com 1510 Daniel Bernier 1511 Bell Canada 1512 Canada 1514 Email: daniel.bernier@bell.ca 1516 Cheng Li 1517 Huawei 1519 Email: chengli13@huawei.com 1521 Bruno Decraene 1522 Orange 1523 France 1525 Email: bruno.decraene@orange.com 1527 Shaowen Ma 1528 Juniper 1530 Email: mashaowen@gmail.com 1532 Chaitanya Yadlapalli 1533 AT&T 1534 USA 1536 Email: cy098d@att.com 1538 Wim Henderickx 1539 Nokia 1540 Belgium 1542 Email: wim.henderickx@nokia.com 1543 Stefano Salsano 1544 Universita di Roma "Tor Vergata" 1545 Italy 1547 Email: stefano.salsano@uniroma2.it