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