idnits 2.17.1 draft-clad-spring-segment-routing-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 : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2017) is 2392 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) == Missing Reference: 'SL' is mentioned on line 788, but not defined -- Looks like a reference, but probably isn't: '0' on line 786 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-01 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 Summary: 0 errors (**), 0 flaws (~~), 8 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 C. Filsfils 4 Intended status: Standards Track P. Camarillo 5 Expires: April 9, 2018 Cisco Systems, Inc. 6 D. Bernier 7 Bell Canada 8 B. Decraene 9 Orange 10 B. Peirens 11 Proximus 12 C. Yadlapalli 13 AT&T 14 X. Xu 15 Huawei 16 S. Salsano 17 Universita di Roma "Tor Vergata" 18 A. AbdelSalam 19 Gran Sasso Science Institute 20 G. Dawra 21 Cisco Systems, Inc. 22 October 6, 2017 24 Segment Routing for Service Chaining 25 draft-clad-spring-segment-routing-service-chaining-00 27 Abstract 29 This document defines data plane functionality required to implement 30 service segments and achieve service chaining with MPLS and IPv6, as 31 described in the Segment Routing architecture. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 9, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Classification and steering . . . . . . . . . . . . . . . . . 4 70 4. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. SR-aware services . . . . . . . . . . . . . . . . . . . . 5 72 4.2. SR-unaware services . . . . . . . . . . . . . . . . . . . 6 73 5. SR proxy behaviors . . . . . . . . . . . . . . . . . . . . . 6 74 5.1. Static SR proxy . . . . . . . . . . . . . . . . . . . . . 9 75 5.1.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 10 76 5.1.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 11 77 5.2. Dynamic SR proxy . . . . . . . . . . . . . . . . . . . . 13 78 5.2.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 14 79 5.2.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 15 80 5.3. Shared memory SR proxy . . . . . . . . . . . . . . . . . 15 81 5.4. Masquerading SR proxy . . . . . . . . . . . . . . . . . . 15 82 5.4.1. SRv6 masquerading proxy pseudocode - End.AM . . . . . 17 83 5.4.2. Variant 1: NAT . . . . . . . . . . . . . . . . . . . 17 84 5.4.3. Variant 2: Caching . . . . . . . . . . . . . . . . . 17 85 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 18 86 7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 7.1. MPLS data plane . . . . . . . . . . . . . . . . . . . . . 20 88 7.2. IPv6 - SRH TLV objects . . . . . . . . . . . . . . . . . 20 89 7.3. IPv6 - SRH tag . . . . . . . . . . . . . . . . . . . . . 20 90 8. Implementation status . . . . . . . . . . . . . . . . . . . . 20 91 9. Relationship with RFC 7665 . . . . . . . . . . . . . . . . . 21 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 95 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 98 14.2. Informative References . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 101 1. Introduction 103 Segment Routing (SR) is an architecture based on the source routing 104 paradigm that seeks the right balance between distributed 105 intelligence and centralized programmability. SR can be used with an 106 MPLS or an IPv6 data plane to steer packets through an ordered list 107 of instructions, called segments. These segments may encode simple 108 routing instructions for forwarding packets along a specific network 109 path, or rich behaviors to support use-cases such as service 110 chaining. 112 In the context of service chaining, each service, running either on a 113 physical appliance or in a virtual environment, is associated with a 114 segment, which can then be used in a segment list to steer packets 115 through the service. Such service segments may be combined together 116 in a segment list to achieve service chaining, but also with other 117 types of segments as defined in [I-D.ietf-spring-segment-routing]. 118 SR thus provides a fully integrated solution for service chaining, 119 overlay and underlay optimization. Furthermore, the IPv6 dataplane 120 natively supports metadata transportation as part of the SR 121 information attached to the packets. 123 This document describes how SR enables service chaining in a simple 124 and scalable manner, from the segment association to the service up 125 to the traffic classification and steering into the service chain. 126 Several SR proxy behaviors are also defined to support SR service 127 chaining through legacy, SR-unaware, services in various 128 circumstances. 130 The definition of control plane components, such as segment discovery 131 and SR policy configuration, is outside the scope of this data plane 132 document. These aspects will be defined in a dedicated document. 134 Familiarity with the following IETF documents is assumed: 136 o Segment Routing Architecture [I-D.ietf-spring-segment-routing] 138 o Segment Routing with MPLS data plane 139 [I-D.ietf-spring-segment-routing-mpls] 141 o Segment Routing Header [I-D.ietf-6man-segment-routing-header] 143 o SRv6 Network Programming 144 [I-D.filsfils-spring-srv6-network-programming] 146 2. Terminology 148 SR-aware service: Service fully capable of processing SR traffic 150 SR-unaware service: Service unable to process SR traffic or behaving 151 incorrectly for such traffic 153 SR proxy: Proxy handling the SR processing on behalf of an SR-unaware 154 service 156 Service Segment: Segment associated with a service, either directly 157 or via an SR proxy 159 SR SC policy: SR policy, as defined in 160 [I-D.filsfils-spring-segment-routing-policy], that includes at least 161 one Service Segment. An SR SC policy may also contain other types of 162 segments, such as VPN or TE segments. 164 SR policy head-end: SR node that classifies and steers traffic into 165 an SR policy. 167 3. Classification and steering 169 Classification and steering mechanisms are defined in section 12 of 170 [I-D.filsfils-spring-segment-routing-policy] and are independent from 171 the purpose of the SR policy. From a headend perspective, there is 172 no difference whether a policy contains IGP, BGP, peering, VPN and 173 service segments, or any combination of these. 175 As documented in the above reference, traffic is classified when 176 entering an SR domain. The SR policy head-end may, depending on its 177 capabilities, classify the packets on a per-destination basis, via 178 simple FIB entries, or apply more complex policy routing rules 179 requiring to look deeper into the packet. These rules are expected 180 to support basic policy routing such as 5-tuple matching. In 181 addition, the IPv6 SRH tag field defined in 182 [I-D.ietf-6man-segment-routing-header] can be used to identify and 183 classify packets sharing the same set of properties. Classified 184 traffic is then steered into the appropriate SR policy, which is 185 associated with a weighted set of segment lists. 187 SR traffic can be re-classified by an SR endpoint along the original 188 SR policy (e.g., DPI service) or a transit node intercepting the 189 traffic. This node is the head-end of a new SR policy that is 190 imposed onto the packet, either as a stack of MPLS labels or as an 191 IPv6 and SRH encapsulation. 193 4. Services 195 A service may be a physical appliance running on dedicated hardware, 196 a virtualized service inside an isolated environment such as a VM, 197 container or namespace, or any process running on a compute element. 198 Unless otherwise stated, this document does not make any assumption 199 on the type or execution environment of a service. 201 SR enables service chaining by assigning a segment identifier, or 202 SID, to each service and sequencing these service SIDs in a segment 203 list. A service SID may be of local significance or directly 204 reachable from anywhere in the routing domain. The latter is 205 realized with SR-MPLS by assigning a SID from the global label block 206 ([I-D.ietf-spring-segment-routing-mpls]), or with SRv6 by advertising 207 the SID locator in the routing protocol 208 ([I-D.filsfils-spring-srv6-network-programming]). 210 This document categorizes services in two types, depending on whether 211 they are able to behave properly in the presence of SR information or 212 not. These are respectively named SR-aware and SR-unaware services. 213 An SR-aware service can process the SR information in the packets it 214 receives. This means being able to identify the active segment as a 215 local instruction and move forward in the segment list, but also that 216 the service own behavior is not hindered due to the presence of SR 217 information. For example, an SR-aware firewall filtering SRv6 218 traffic based on its final destination must retrieve that information 219 from the last entry in the SRH rather than the Destination Address 220 field of the IPv6 header. Any service that does not meet these 221 criteria is considered as SR-unaware. 223 4.1. SR-aware services 225 An SR-aware service is associated with a locally instantiated service 226 segment, which is used to steer traffic through it. 228 If the service is configured to intercept all the packets passing 229 through the appliance, the underlying routing system only has to 230 implement a default SR endpoint behavior (SR-MPLS node segment or 231 SRv6 End function), and the corresponding SID will be used to steer 232 traffic through the service. 234 If the service requires the packets to be directed to a specific 235 virtual interface, networking queue or process, a dedicated SR 236 behavior may be required to steer the packets to the appropriate 237 location. The definition of such service-specific functions is out 238 of the scope of this document. 240 An SRv6-aware service may also retrieve, store or modify information 241 in the SRH TLVs. 243 4.2. SR-unaware services 245 An SR-unaware service is not able to process the SR information in 246 the traffic that it receives. It may either drop the traffic or take 247 erroneous decisions due to the unrecognized routing information. In 248 order to include such services in an SR SC policy, it is thus 249 required to remove the SR information before the service receives the 250 packet, or to alter it in such a way that the service can correctly 251 process the packet. 253 In this document, we define the concept of an SR proxy as an entity, 254 separate from the service, that performs these modifications and 255 handle the SR processing on behalf of a service. The SR proxy can 256 run as a separate process on the service appliance, on a virtual 257 switch or router on the compute node or on a remote host. In this 258 document, we only assume that the proxy is connected to the service 259 via a layer-2 link. 261 An SR-unaware service is associated with a service segment 262 instantiated on the SR proxy, which is used to steer traffic through 263 the service. Section 5 describes several SR proxy behaviors to 264 handle the SR information under various circumstances. 266 5. SR proxy behaviors 268 This section describes several SR proxy behaviors designed to enable 269 SR service chaining through SR-unaware services. A system 270 implementing one of these functions may handle the SR processing on 271 behalf of an SR-unaware service and allows the service to properly 272 process the traffic that is steered through it. 274 A service may be located at any hop in an SR policy, including the 275 last segment. However, the SR proxy behaviors defined in this 276 section are dedicated to supporting SR-unaware services at 277 intermediate hops in the segment list. In case an SR-unaware service 278 is at the last segment, it is sufficient to ensure that the SR 279 information is ignored (IPv6 routing extension header with Segments 280 Left equal to 0) or removed before the packet reaches the service 281 (MPLS PHP, SRv6 End.D or PSP). 283 As illustrated on Figure 1, the generic behavior of an SR proxy has 284 two parts. The first part is in charge of passing traffic from the 285 network to the service. It intercepts the SR traffic destined for 286 the service via a locally instantiated service segment, modifies it 287 in such a way that it appears as non-SR traffic to the service, then 288 sends it out on a given interface, IFACE-OUT, connected to the 289 service. The second part receives the traffic coming back from the 290 service on IFACE-IN, restores the SR information and forwards it 291 according to the next segment in the list. Unless otherwise stated 292 IFACE-OUT and IFACE-IN can represent the same interface. 294 +----------------------------+ 295 | | 296 | Service | 297 | | 298 +----------------------------+ 299 ^ Non SR | 300 | traffic | 301 | v 302 +-----------+----------+ 303 +--| IFACE OUT : IFACE IN |--+ 304 SR traffic | +-----------+----------+ | SR traffic 305 ---------->| SR proxy |----------> 306 | | 307 +----------------------------+ 309 Figure 1: Generic SR proxy 311 In the next subsections, the following SR proxy mechanisms are 312 defined: 314 o Static proxy 316 o Dynamic proxy 318 o Shared-memory proxy 320 o Masquerading proxy 322 Each mechanism has its own characteristics and constraints, which are 323 summarized in the below table. It is up to the operator to select 324 the best one based on the proxy node capabilities, the service 325 behavior and the traffic type. It is also possible to use different 326 proxy mechanisms within the same service chain. 328 +-----+-----+-----+-----+ 329 | | | | M | 330 | | | S | a | 331 | | | h | s | 332 | | | a | q | 333 | | | r | u | 334 | | D | e | e | 335 | S | y | d | r | 336 | t | n | | a | 337 | a | a | m | d | 338 | t | m | e | i | 339 | i | i | m | n | 340 | c | c | . | g | 341 +---------------------------------------+-----+-----+-----+-----+ 342 | | SR-MPLS | Y | Y | Y | - | 343 | | | | | | | 344 | SR flavors | SRv6 insertion | P | P | P | Y | 345 | | | | | | | 346 | | SRv6 encapsulation | Y | Y | Y | - | 347 +----------------+----------------------+-----+-----+-----+-----+ 348 | | Ethernet | Y | Y | Y | - | 349 | | | | | | | 350 | Inner header | IPv4 | Y | Y | Y | - | 351 | | | | | | | 352 | | IPv6 | Y | Y | Y | - | 353 +----------------+----------------------+-----+-----+-----+-----+ 354 | Chain agnostic configuration | N | N | Y | Y | 355 +---------------------------------------+-----+-----+-----+-----+ 356 | Transparent to chain changes | N | Y | Y | Y | 357 +----------------+----------------------+-----+-----+-----+-----+ 358 | | DA modification | Y | Y | Y | NAT | 359 | | | | | | | 360 | | Payload modification | Y | Y | Y | Y | 361 | | | | | | | 362 |Service support | Packet generation | Y | Y |cache|cache| 363 | | | | | | | 364 | | Packet deletion | Y | Y | Y | Y | 365 | | | | | | | 366 | | Transport endpoint | Y | Y |cache|cache| 367 +----------------+----------------------+-----+-----+-----+-----+ 369 Figure 2: SR proxy summary 371 Note: The use of a shared memory proxy requires both the service and 372 the proxy to be running on the same node. 374 5.1. Static SR proxy 376 The static proxy is an SR endpoint behavior for processing SR-MPLS or 377 SRv6 encapsulated traffic on behalf of an SR-unaware service. This 378 proxy thus receives SR traffic that is formed of an MPLS label stack 379 or an IPv6 header on top of an inner packet, which can be Ethernet, 380 IPv4 or IPv6. 382 A static SR proxy segment is associated with the following mandatory 383 parameters: 385 o INNER-TYPE: Inner packet type 387 o S-ADDR: Ethernet or IP address of the service (only for inner type 388 IPv4 and IPv6) 390 o IFACE-OUT: Local interface for sending traffic towards the service 392 o IFACE-IN: Local interface receiving the traffic coming back from 393 the service 395 o CACHE: SR information to be attached on the traffic coming back 396 from the service 398 A static SR proxy segment is thus defined for a specific service, 399 inner packet type and cached SR information. It is also bound to a 400 pair of directed interfaces on the proxy. These may be both 401 directions of a single interface, or opposite directions of two 402 different interfaces. The latter is recommended in case the service 403 is to be used as part of a bi-directional SR SC policy. If the proxy 404 and the service both support 802.1Q, IFACE-OUT and IFACE-IN can also 405 represent sub-interfaces. 407 The first part of this behavior is triggered when the proxy node 408 receives a packet whose active segment matches a segment associated 409 with the static proxy behavior. It removes the SR information from 410 the packet then sends it on a specific interface towards the 411 associated service. This SR information corresponds to the full 412 label stack for SR-MPLS or to the encapsulation IPv6 header with any 413 attached extension header in the case of SRv6. 415 The second part is an inbound policy attached to the proxy interface 416 receiving the traffic returning from the service, IFACE-IN. This 417 policy attaches to the incoming traffic the cached SR information 418 associated with the SR proxy segment. If the proxy segment uses the 419 SR-MPLS data plane, CACHE contains a stack of labels to be pushed on 420 top the packets. With the SRv6 data plane, CACHE is defined as a 421 source address, an active segment and an optional SRH (tag, segments 422 left, segment list and metadata). The proxy encapsulates the packets 423 with an IPv6 header that has the source address, the active segment 424 as destination address and the SRH as a routing extension header. 425 After the SR information has been attached, the packets are forwarded 426 according to the active segment, which is represented by the top MPLS 427 label or the IPv6 Destination Address. 429 In this scenario, there are no restrictions on the operations that 430 can be performed by the service on the stream of packets. It may 431 operate at all protocol layers, terminate transport layer 432 connections, generate new packets and initiate transport layer 433 connections. This behavior may also be used to integrate an 434 IPv4-only service into an SRv6 policy. However, a static SR proxy 435 segment can be used in only one service chain at a time. As opposed 436 to most other segment types, a static SR proxy segment is bound to a 437 unique list of segments, which represents a directed SR SC policy. 438 This is due to the cached SR information being defined in the segment 439 configuration. This limitation only prevents multiple segment lists 440 from using the same static SR proxy segment at the same time, but a 441 single segment list can be shared by any number of traffic flows. 442 Besides, since the returning traffic from the service is re- 443 classified based on the incoming interface, an interface can be used 444 as receiving interface (IFACE-IN) only for a single SR proxy segment 445 at a time. In the case of a bi-directional SR SC policy, a different 446 SR proxy segment and receiving interface are required for the return 447 direction. 449 5.1.1. SR-MPLS pseudocode 451 5.1.1.1. Static proxy for inner type Ethernet - MPLS L2 static proxy 452 segment 454 Upon receiving an MPLS packet with top label L, where L is an MPLS L2 455 static proxy segment, a node N does: 457 1. IF payload type is Ethernet THEN 458 2. Pop all labels 459 3. Forward the exposed frame on IFACE-OUT 460 4. ELSE 461 5. Drop the packet 463 Upon receiving on IFACE-IN an Ethernet frame with a destination 464 address different than the interface address, a node N does: 466 1. Push labels in CACHE on top of the frame Ethernet header 467 2. Lookup the top label and proceed accordingly 468 The receiving interface must be configured in promiscuous mode in 469 order to accept those Ethernet frames. 471 5.1.1.2. Static proxy for inner type IPv4 - MPLS IPv4 static proxy 472 segment 474 Upon receiving an MPLS packet with top label L, where L is an MPLS 475 IPv4 static proxy segment, a node N does: 477 1. IF payload type is IPv4 THEN 478 2. Pop all labels 479 3. Forward the exposed packet on IFACE-OUT towards S-ADDR 480 4. ELSE 481 5. Drop the packet 483 Upon receiving a non link-local IPv4 packet on IFACE-IN, a node N 484 does: 486 1. Push labels in CACHE on top of the packet IPv4 header 487 2. Decrement inner TTL and update checksum 488 3. Lookup the top label and proceed accordingly 490 5.1.1.3. Static proxy for inner type IPv6 - MPLS IPv6 static proxy 491 segment 493 Upon receiving an MPLS packet with top label L, where L is an MPLS 494 IPv6 static proxy segment, a node N does: 496 1. IF payload type is IPv6 THEN 497 2. Pop all labels 498 3. Forward the exposed packet on IFACE-OUT towards S-ADDR 499 4. ELSE 500 5. Drop the packet 502 Upon receiving a non link-local IPv6 packet on IFACE-IN, a node N 503 does: 505 1. Push labels in CACHE on top of the packet IPv6 header 506 2. Decrement inner Hop Limit 507 3. Lookup the top label and proceed accordingly 509 5.1.2. SRv6 pseudocode 511 5.1.2.1. Static proxy for inner type Ethernet - End.AS2 513 Upon receiving an IPv6 packet destined for S, where S is an End.AS2 514 SID, a node N does: 516 1. IF ENH == 59 THEN ;; Ref1 517 2. Remove the (outer) IPv6 header and its extension headers 518 3. Forward the exposed frame on IFACE-OUT 519 4. ELSE 520 5. Drop the packet 522 Ref1: 59 refers to "no next header" as defined by IANA allocation for 523 Internet Protocol Numbers. 525 Upon receiving on IFACE-IN an Ethernet frame with a destination 526 address different than the interface address, a node N does: 528 1. IF CACHE.SRH THEN ;; Ref2 529 2. Push CACHE.SRH on top of the existing Ethernet header 530 3. Set NH value of the pushed SRH to 59 531 4. Push outer IPv6 header with SA, DA and traffic class from CACHE 532 5. Set outer payload length and flow label 533 6. Set NH value to 43 if an SRH was added, or 59 otherwise 534 7. Lookup outer DA in appropriate table and proceed accordingly 536 Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the 537 static SR proxy segment associated with IFACE-IN. 539 The receiving interface must be configured in promiscuous mode in 540 order to accept those Ethernet frames. 542 5.1.2.2. Static proxy for inner type IPv4 - End.AS4 544 Upon receiving an IPv6 packet destined for S, where S is an End.AS4 545 SID, a node N does: 547 1. IF ENH == 4 THEN ;; Ref1 548 2. Remove the (outer) IPv6 header and its extension headers 549 3. Forward the exposed packet on IFACE-OUT towards S-ADDR 550 4. ELSE 551 5. Drop the packet 553 Ref1: 4 refers to IPv4 encapsulation as defined by IANA allocation 554 for Internet Protocol Numbers. 556 Upon receiving a non link-local IPv4 packet on IFACE-IN, a node N 557 does: 559 1. IF CACHE.SRH THEN ;; Ref2 560 2. Push CACHE.SRH on top of the existing IPv4 header 561 3. Set NH value of the pushed SRH to 4 562 4. Push outer IPv6 header with SA, DA and traffic class from CACHE 563 5. Set outer payload length and flow label 564 6. Set NH value to 43 if an SRH was added, or 4 otherwise 565 7. Decrement inner TTL and update checksum 566 8. Lookup outer DA in appropriate table and proceed accordingly 568 Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the 569 static SR proxy segment associated with IFACE-IN. 571 5.1.2.3. Static proxy for inner type IPv6 - End.AS6 573 Upon receiving an IPv6 packet destined for S, where S is an End.AS6 574 SID, a node N does: 576 1. IF ENH == 41 THEN ;; Ref1 577 2. Remove the (outer) IPv6 header and its extension headers 578 3. Forward the exposed packet on IFACE-OUT towards S-ADDR 579 4. ELSE 580 5. Drop the packet 582 Ref1: 41 refers to IPv6 encapsulation as defined by IANA allocation 583 for Internet Protocol Numbers. 585 Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N 586 does: 588 1. IF CACHE.SRH THEN ;; Ref2 589 2. Push CACHE.SRH on top of the existing IPv6 header 590 3. Set NH value of the pushed SRH to 41 591 4. Push outer IPv6 header with SA, DA and traffic class from CACHE 592 5. Set outer payload length and flow label 593 6. Set NH value to 43 if an SRH was added, or 41 otherwise 594 7. Decrement inner Hop Limit 595 8. Lookup outer DA in appropriate table and proceed accordingly 597 Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the 598 static SR proxy segment associated with IFACE-IN. 600 5.2. Dynamic SR proxy 602 The dynamic proxy is an improvement over the static proxy that 603 dynamically learns the SR information before removing it from the 604 incoming traffic. The same information can then be re-attached to 605 the traffic returning from the service. As opposed to the static SR 606 proxy, no CACHE information needs to be configured. Instead, the 607 dynamic SR proxy relies on a local caching mechanism on the node 608 instantiating this segment. Therefore, a dynamic proxy segment 609 cannot be the last segment in an SR SC policy. As mentioned at the 610 beginning of Section 5, a different SR behavior should be used if the 611 service is meant to be the final destination of an SR SC policy. 613 Upon receiving a packet whose active segment matches a dynamic SR 614 proxy function, the proxy node pops the top MPLS label or applies the 615 SRv6 End behavior, then compares the updated SR information with the 616 cache entry for the current segment. If the cache is empty or 617 different, it is updated with the new SR information. The SR 618 information is then removed and the inner packet is sent towards the 619 service. 621 The cache entry is not mapped to any particular packet, but instead 622 to an SR SC policy identified by the receiving interface (IFACE-IN). 623 Any non-link-local IP packet or non-local Ethernet frame received on 624 that interface will be re-encapsulated with the cached headers as 625 described in Section 5.1. The service may thus drop, modify or 626 generate new packets without affecting the proxy. 628 5.2.1. SR-MPLS pseudocode 630 The static proxy SR-MPLS pseudocode is augmented by inserting the 631 following instructions between lines 1 and 2. 633 1. IF top label S bit is 0 THEN 634 2. Pop top label 635 3. IF C(IFACE-IN) different from remaining labels THEN ;; Ref1 636 4. Copy all remaining labels into C(IFACE-IN) ;; Ref2 637 5. ELSE 638 6. Drop the packet 640 Ref1: A TTL margin can be configured for the top label stack entry to 641 prevent constant cache updates when multiple equal-cost paths with 642 different hop counts are used towards the SR proxy node. In that 643 case, a TTL difference smaller than the configured margin should not 644 trigger a cache update (provided that the labels are the same). 646 Ref2: C(IFACE-IN) represents the cache entry associated to the 647 dynamic SR proxy segment. It is identified with IFACE-IN in order to 648 efficiently retrieve the right SR information when a packet arrives 649 on this interface. 651 In addition, the inbound policy should check that C(IFACE-IN) has 652 been defined before attempting to restore the MPLS label stack, and 653 drop the packet otherwise. 655 5.2.2. SRv6 pseudocode 657 The static proxy SRv6 pseudocode is augmented by inserting the 658 following instructions between lines 1 and 2. 660 1. IF NH=SRH & SL > 0 THEN 661 2. Decrement SL and update the IPv6 DA with SRH[SL] 662 3. IF C(IFACE-IN) different from IPv6 encaps THEN ;; Ref1 663 4. Copy the IPv6 encaps into C(IFACE-IN) ;; Ref2 664 5. ELSE 665 6. Drop the packet 667 Ref1: "IPv6 encaps" represents the IPv6 header and any attached 668 extension header. 670 Ref2: C(IFACE-IN) represents the cache entry associated to the 671 dynamic SR proxy segment. It is identified with IFACE-IN in order to 672 efficiently retrieve the right SR information when a packet arrives 673 on this interface. 675 In addition, the inbound policy should check that C(IFACE-IN) has 676 been defined before attempting to restore the IPv6 encapsulation, and 677 drop the packet otherwise. 679 5.3. Shared memory SR proxy 681 The shared memory proxy is an SR endpoint behavior for processing SR- 682 MPLS or SRv6 encapsulated traffic on behalf of an SR-unaware service. 683 This proxy behavior leverages a shared-memory interface with the 684 service in order to hide the SR information from an SR-unaware 685 service while keeping it attached to the packet. We assume in this 686 case that the proxy and the service are running on the same compute 687 node. A typical scenario is an SR-capable vrouter running on a 688 container host and forwarding traffic to virtual services isolated 689 within their respective container. 691 More details will be added in a future revision of this document. 693 5.4. Masquerading SR proxy 695 The masquerading proxy is an SR endpoint behavior for processing SRv6 696 traffic on behalf of an SR-unaware service. This proxy thus receives 697 SR traffic that is formed of an IPv6 header and an SRH on top of an 698 inner payload. The masquerading behavior is independent from the 699 inner payload type. Hence, the inner payload can be of any type but 700 it is usually expected to be a transport layer packet, such as TCP or 701 UDP. 703 A masquerading SR proxy segment is associated with the following 704 mandatory parameters: 706 o S-ADDR: Ethernet or IPv6 address of the service 708 o IFACE-OUT: Local interface for sending traffic towards the service 710 o IFACE-IN: Local interface receiving the traffic coming back from 711 the service 713 A masquerading SR proxy segment is thus defined for a specific 714 service and bound to a pair of directed interfaces or sub-interfaces 715 on the proxy. As opposed to the static and dynamic SR proxies, a 716 masquerading segment can be present at the same time in any number of 717 SR SC policies and the same interfaces can be bound to multiple 718 masquerading proxy segments. The only restriction is that a 719 masquerading proxy segment cannot be the last segment in an SR SC 720 policy. 722 The first part of the masquerading behavior is triggered when the 723 proxy node receives an IPv6 packet whose Destination Address matches 724 a masquerading proxy segment. The proxy inspects the IPv6 extension 725 headers and substitutes the Destination Address with the last segment 726 in the SRH attached to the IPv6 header, which represents the final 727 destination of the IPv6 packet. The packet is then sent out towards 728 the service. 730 The service receives an IPv6 packet whose source and destination 731 addresses are respectively the original source and final destination. 732 It does not attempt to inspect the SRH, as RFC2460 specifies that 733 routing extension headers are not examined or processed by transit 734 nodes. Instead, the service simply forwards the packet based on its 735 current Destination Address. In this scenario, we assume that the 736 service can only inspect, drop or perform limited changes to the 737 packets. For example, Intrusion Detection Systems, Deep Packet 738 Inspectors and non-NAT Firewalls are among the services that can be 739 supported by a masquerading SR proxy. Variants of the masquerading 740 behavior are defined in Section 5.4.2 and Section 5.4.3 to support a 741 wider range of services. 743 The second part of the masquerading behavior, also called de- 744 masquerading, is an inbound policy attached to the proxy interface 745 receiving the traffic returning from the service, IFACE-IN. This 746 policy inspects the incoming traffic and triggers a regular SRv6 747 endpoint processing (End) on any IPv6 packet that contains an SRH. 748 This processing occurs before any lookup on the packet Destination 749 Address is performed and it is sufficient to restore the right active 750 segment as the Destination Address of the IPv6 packet. 752 5.4.1. SRv6 masquerading proxy pseudocode - End.AM 754 Masquerading: Upon receiving a packet destined for S, where S is an 755 End.AM SID, a node N processes it as follows. 757 1. IF NH=SRH & SL > 0 THEN 758 2. Update the IPv6 DA with SRH[0] 759 3. Forward the packet on IFACE-OUT 760 4. ELSE 761 5. Drop the packet 763 De-masquerading: Upon receiving a non-link-local IPv6 packet on 764 IFACE-IN, a node N processes it as follows. 766 1. IF NH=SRH & SL > 0 THEN 767 2. Decrement SL 768 3. Update the IPv6 DA with SRH[SL] ;; Ref1 769 4. Lookup DA in appropriate table and proceed accordingly 771 Ref2: This pseudocode can be augmented to support the Penultimate 772 Segment Popping (PSP) endpoint flavor. The exact pseudocode 773 modification are provided in 774 [I-D.filsfils-spring-srv6-network-programming]. 776 5.4.2. Variant 1: NAT 778 Services modifying the destination address in the packets they 779 process, such as NATs, can be supported by a masquerading proxy with 780 the following modification to the de-masquerading pseudocode. 782 De-masquerading - NAT: Upon receiving a non-link-local IPv6 packet on 783 IFACE-IN, a node N processes it as follows. 785 1. IF NH=SRH & SL > 0 THEN 786 2. Update SRH[0] with the IPv6 DA 787 3. Decrement SL 788 4. Update the IPv6 DA with SRH[SL] 789 5. Lookup DA in appropriate table and proceed accordingly 791 5.4.3. Variant 2: Caching 793 Services generating packets or acting as endpoints for transport 794 connections can be supported by adding a dynamic caching mechanism 795 similar to the one described in Section 5.2. 797 More details will be added in a future revision of this document. 799 6. Illustrations 801 We consider the network represented in Figure 3 where: 803 o A and B are two end hosts using IPv4 805 o B advertises the prefix 20.0.0.0/8 807 o 1 to 6 are physical or virtual routers supporting IPv6 and segment 808 routing 810 o S1 is an SR-aware firewall service 812 o S2 is an SR-unaware IPS service 814 --3-- 815 / \ 816 / \ 817 A----1----2----4----5----6----B 818 | | 819 | | 820 S1 S2 822 Figure 3: Network with services 824 All links are configured with an IGP weight of 10 except link 2-3 825 that is set to 20. 827 We assume that the path 2-3-5 has a lower latency than 2-4-5. 829 Nodes 1 to 6 each advertise in the IGP an IPv6 prefix Ck::/64, where 830 k represents the node identifier. 832 Nodes 1 to 6 are each configured with an SRv6 End segment Ck::/128, 833 where k represents the node identifier. 835 Node S1 is configured with an SRv6 SID CF1::/128 such that packets 836 arriving at S1 with the Destination Address CF1:: are processed by 837 the service. This SID is either advertised by S1, if it participates 838 in the IGP, or by node 2 on behalf of S1. 840 Node 5 is also configured with an SRv6 dynamic proxy segments 841 (End.AD) C5::AD:F2 for S2. 843 Node 6 is also configured with an SRv6 End.DX4 segment C6::D4:B 844 decapsulating the SRv6 and sending the inner IPv4 packets towards D. 846 Via BGP signaling or an SDN controller, node 1 is programmed with a 847 route 20.0.0.0/8 via C6::D4:B and a color/community requiring low 848 latency and services S1 and S2. 850 Node 1 either locally computes the path to the egress node or 851 delegates the computation to a PCE. As a result, the SRv6 852 encapsulation policy < CF1::, C3::, C5::AD:F2, C6::D4:B > is 853 associated with the route 20.0.0.0/8 on node 1. 855 Upon receiving a packet P from node A and destined to 20.20.20.20, 856 node 1 finds the above table entry and pushes an outer IPv6 header 857 with (SA = C1::, DA = CF1::, NH = SRH) followed by an SRH (C6::D4:B, 858 C5::AD:F2, C3::, CF1::; SL = 3; NH = IPv4). Node 1 then forwards the 859 packet to the first destination address CF1::. 861 Node 2 forwards P along the shortest path to S1, based on the IPv6 862 destination address CF1::. 864 When S1 receives the packet, it identifies a locally instantiated SID 865 and applies the firewall filtering rules. If the packet is not 866 dropped, the SL value is decremented and the DA is updated to the 867 next segment C3::. S1 then sends back to node 2 the packet P with (SA 868 = C1::, DA = C3::, NH = SRH) (C6::D4:B, C5::AD:F2, C3::, CF1::; SL = 869 2; NH = IPv4). 871 Node 2 forwards P along the shortest path to node 3, based on the 872 IPv6 destination address C3::. 874 When 3 receives the packet, 3 matches the DA in its local SID table 875 and finds the bound End function. It thus decrements the SL value 876 and updates the DA to the next segment: C5::AD:F2. Node 3 then 877 forwards packet P with (SA = C1::, DA = C5::AD:F2, NH = SRH) 878 (C6::D4:B, C5::AD:F2, C3::, CF1::; SL = 1; NH = IPv4) towards node 5. 880 When 5 receives the packet, 5 matches the DA in its local SID table 881 and finds the bound function End.AD(S2). It thus performs the End 882 function (decrement SL and update DA), caches and removes the outer 883 IPv6 header and the SRH, then forwards the inner IPv4 packet towards 884 S2. 886 S2 receives a regular IPv4 packet headed to 20.20.20.20. It applies 887 the IPS rules and forwards the packet back to node 5. 889 When 5 receives the packet on the returning interface (IFACE-IN) for 890 S2, 5 retrieves the corresponding cache entry and pushes the updated 891 IPv6 header and SRH. It then forwards P with (SA = C1::, DA = 892 C6:D4:B, NH = SRH) (C6::D4:B, C5::AD:F2, C3::, CF1::; SL = 0; NH = 893 IPv4) to node 6. 895 When 6 receives the packet, 6 matches the DA in its local SID table 896 and finds the bound function End.DX4. It thus removes the outer IPv6 897 header and forwards the inner IPv4 packet to node B. 899 7. Metadata 901 7.1. MPLS data plane 903 The MPLS data plane does not provide any native mechanism to attach 904 metadata to a packet. 906 Workarounds to carry metadata in an SR-MPLS context will be discussed 907 in a future version of this document. 909 7.2. IPv6 - SRH TLV objects 911 The IPv6 SRH TLV objects are designed to carry all sorts of metadata. 912 In particular, [I-D.ietf-6man-segment-routing-header] defines the NSH 913 carrier TLV as a container for NSH metadata. 915 TLV objects can be imposed by the ingress edge router that steers the 916 traffic into the SR SC policy. 918 An SR-aware service may impose, modify or remove any TLV object 919 attached to the first SRH, either by directly modifying the packet 920 headers or via a control channel between the service and its 921 forwarding plane. 923 An SR-aware service that re-classifies the traffic and steers it into 924 a new SR SC policy (e.g. DPI) may attach any TLV object to the new 925 SRH. 927 Metadata imposition and handling will be further discussed in a 928 future version of this document. 930 7.3. IPv6 - SRH tag 932 The SRH tag identifies a packet as part of a group or class of 933 packets [I-D.ietf-6man-segment-routing-header]. 935 In a service chaining context, this field can be used as a simple 936 man's metadata to encode additional information in the SRH. 938 8. Implementation status 940 The static SR proxy is available for SR-MPLS and SRv6 on various 941 Cisco hardware and software platforms. Furthermore, the following 942 proxies are available on open-source software. 944 +-------------+-------------+ 945 | VPP | Linux | 946 +---+-------------------------------------+-------------+-------------+ 947 | M | Static proxy | Available | In progress | 948 | P | | | | 949 | L | Dynamic proxy | In progress | In progress | 950 | S | | | | 951 | | Shared memory proxy | In progress | In progress | 952 +---+-------------------------------------+-------------+-------------+ 953 | | Static proxy | Available | In progress | 954 | | | | | 955 | | Dynamic proxy - Inner type Ethernet | In progress | In progress | 956 | | | | | 957 | | Dynamic proxy - Inner type IPv4 | Available | Available | 958 | S | | | | 959 | R | Dynamic proxy - Inner type IPv6 | Available | Available | 960 | v | | | | 961 | 6 | Shared memory proxy | In progress | In progress | 962 | | | | | 963 | | Masquerading proxy | Available | Available | 964 | | | | | 965 | | Masquerading proxy - NAT variant | In progress | In progress | 966 | | | | | 967 | | Masquerading proxy - Cache variant | In progress | In progress | 968 +---+-------------------------------------+-------------+-------------+ 970 Open-source implementation status table 972 9. Relationship with RFC 7665 974 The Segment Routing solution addresses a wider problem that covers 975 both topological and service chaining policies. The topological and 976 service instructions can be either deployed in isolation or in 977 combination. SR has thus a wider applicability than the architecture 978 defined in [RFC7665]. Furthermore, the inherent property of SR is a 979 stateless network fabric. In SR, there is no state within the fabric 980 to recognize a flow and associate it with a policy. State is only 981 present at the ingress edge of the SR domain, where the policy is 982 encoded into the packets. This is completely different from NSH that 983 relies on state configured at every hop of the service chain. 985 Hence, there is no linkage between this document and [RFC7665]. 987 10. IANA Considerations 989 This document has no actions for IANA. 991 11. Security Considerations 993 The security requirements and mechanisms described in 994 [I-D.ietf-spring-segment-routing] and 995 [I-D.ietf-6man-segment-routing-header] also apply to this document. 996 Additional considerations will be discussed in future versions of the 997 document. 999 12. Acknowledgements 1001 TBD. 1003 13. Contributors 1005 Jisu Bhattacharya substantially contributed to the content of this 1006 document. 1008 14. References 1010 14.1. Normative References 1012 [I-D.ietf-spring-segment-routing] 1013 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1014 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1015 spring-segment-routing-12 (work in progress), June 2017. 1017 14.2. Informative References 1019 [I-D.filsfils-spring-segment-routing-policy] 1020 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 1021 F., Lin, S., bogdanov@google.com, b., Horneffer, M., 1022 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 1023 Routing Policy for Traffic Engineering", draft-filsfils- 1024 spring-segment-routing-policy-01 (work in progress), July 1025 2017. 1027 [I-D.filsfils-spring-srv6-network-programming] 1028 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 1029 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1030 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1031 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 1032 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 1033 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 1034 Camarillo, "SRv6 Network Programming", draft-filsfils- 1035 spring-srv6-network-programming-01 (work in progress), 1036 June 2017. 1038 [I-D.ietf-6man-segment-routing-header] 1039 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1040 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1041 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1042 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1043 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1044 segment-routing-header-07 (work in progress), July 2017. 1046 [I-D.ietf-spring-segment-routing-mpls] 1047 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1048 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1049 data plane", draft-ietf-spring-segment-routing-mpls-10 1050 (work in progress), June 2017. 1052 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1053 Chaining (SFC) Architecture", RFC 7665, 1054 DOI 10.17487/RFC7665, October 2015, 1055 . 1057 Authors' Addresses 1059 Francois Clad (editor) 1060 Cisco Systems, Inc. 1061 France 1063 Email: fclad@cisco.com 1065 Clarence Filsfils 1066 Cisco Systems, Inc. 1067 Belgium 1069 Email: cf@cisco.com 1071 Pablo Camarillo Garvia 1072 Cisco Systems, Inc. 1073 Spain 1075 Email: pcamaril@cisco.com 1077 Daniel Bernier 1078 Bell Canada 1079 Canada 1081 Email: daniel.bernier@bell.ca 1082 Bruno Decraene 1083 Orange 1084 France 1086 Email: bruno.decraene@orange.com 1088 Bart Peirens 1089 Proximus 1090 Belgium 1092 Email: bart.peirens@proximus.com 1094 Chaitanya Yadlapalli 1095 AT&T 1096 USA 1098 Email: cy098d@att.com 1100 Xiaohu Xu 1101 Huawei 1103 Email: xuxiaohu@huawei.com 1105 Stefano Salsano 1106 Universita di Roma "Tor Vergata" 1107 Italy 1109 Email: stefano.salsano@uniroma2.it 1111 Ahmed AbdelSalam 1112 Gran Sasso Science Institute 1113 Italy 1115 Email: ahmed.abdelsalam@gssi.it 1117 Gaurav Dawra 1118 Cisco Systems, Inc. 1119 USA 1121 Email: gdawra@cisco.com