idnits 2.17.1 draft-xuclad-spring-sr-service-programming-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1128: '...e defined in this document. SHOULD be...' RFC 2119 keyword, line 1129: '...transmission and MUST be ignored on re...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2019) is 1801 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 1022 == Missing Reference: 'SL' is mentioned on line 1024, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-18 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-19 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-02 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-03 == Outdated reference: A later version (-09) exists of draft-xu-mpls-payload-protocol-identifier-06 Summary: 1 error (**), 0 flaws (~~), 7 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: October 25, 2019 Alibaba 6 C. Filsfils 7 Cisco Systems, Inc. 8 D. Bernier 9 Bell Canada 10 C. Li 11 Huawei 12 B. Decraene 13 Orange 14 S. Ma 15 Juniper 16 C. Yadlapalli 17 AT&T 18 W. Henderickx 19 Nokia 20 S. Salsano 21 Universita di Roma "Tor Vergata" 22 April 23, 2019 24 Service Programming with Segment Routing 25 draft-xuclad-spring-sr-service-programming-02 27 Abstract 29 This document defines data plane functionality required to implement 30 service segments and achieve service programming in SR-enabled MPLS 31 and IP networks, as 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 October 25, 2019. 50 Copyright Notice 52 Copyright (c) 2019 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. Service segments . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. SR-aware services . . . . . . . . . . . . . . . . . . . . 5 72 4.2. SR-unaware services . . . . . . . . . . . . . . . . . . . 6 73 5. SR service policies . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. SR-MPLS data plane . . . . . . . . . . . . . . . . . . . 8 75 5.2. SRv6 data plane . . . . . . . . . . . . . . . . . . . . . 10 76 6. SR proxy behaviors . . . . . . . . . . . . . . . . . . . . . 11 77 6.1. Static SR proxy . . . . . . . . . . . . . . . . . . . . . 14 78 6.1.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 16 79 6.1.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 17 80 6.2. Dynamic SR proxy . . . . . . . . . . . . . . . . . . . . 19 81 6.2.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 19 82 6.2.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 20 83 6.3. Shared memory SR proxy . . . . . . . . . . . . . . . . . 21 84 6.4. Masquerading SR proxy . . . . . . . . . . . . . . . . . . 21 85 6.4.1. SRv6 masquerading proxy pseudocode . . . . . . . . . 22 86 6.4.2. Variant 1: Destination NAT . . . . . . . . . . . . . 23 87 6.4.3. Variant 2: Caching . . . . . . . . . . . . . . . . . 23 88 7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 7.1. MPLS data plane . . . . . . . . . . . . . . . . . . . . . 23 90 7.2. IPv6 data plane . . . . . . . . . . . . . . . . . . . . . 24 91 7.2.1. SRH TLV objects . . . . . . . . . . . . . . . . . . . 24 92 7.2.2. SRH tag . . . . . . . . . . . . . . . . . . . . . . . 25 93 8. Implementation status . . . . . . . . . . . . . . . . . . . . 25 94 8.1. SR-aware services . . . . . . . . . . . . . . . . . . . . 26 95 8.2. Proxy behaviors . . . . . . . . . . . . . . . . . . . . . 26 96 9. Related works . . . . . . . . . . . . . . . . . . . . . . . . 26 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 98 10.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 27 99 10.2. Segment Routing Header TLVs . . . . . . . . . . . . . . 27 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 101 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 102 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 105 14.2. Informative References . . . . . . . . . . . . . . . . . 29 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 108 1. Introduction 110 Segment Routing (SR) is an architecture based on the source routing 111 paradigm that seeks the right balance between distributed 112 intelligence and centralized programmability. SR can be used with an 113 MPLS or an IPv6 data plane to steer packets through an ordered list 114 of instructions, called segments. These segments may encode simple 115 routing instructions for forwarding packets along a specific network 116 path, but also steer them through VNFs or physical service appliances 117 available in the network. 119 In an SR network, each of these services, running either on a 120 physical appliance or in a virtual environment, are associated with a 121 segment identifier (SID). These service SIDs are then leveraged as 122 part of a SID-list to steer packets through the corresponding 123 services. Service SIDs may be combined together in a SID-list to 124 achieve service programming, but also with other types of segments as 125 defined in [RFC8402]. SR thus provides a fully integrated solution 126 for overlay, underlay and service programming. Furthermore, the IPv6 127 instantiation of SR (SRv6) supports metadata transportation in the 128 Segment Routing header [I-D.ietf-6man-segment-routing-header], either 129 natively in the tag field or with extensions such as TLVs. 131 This document describes how a service can be associated with a SID, 132 including legacy services with no SR capabilities, and how these 133 service SIDs are integrated within an SR policy. The definition of 134 an SR Policy and the traffic steering mechanisms are covered in 135 [I-D.ietf-spring-segment-routing-policy] and hence outside the scope 136 of this document. 138 The definition of control plane components, such as service segment 139 discovery, is outside the scope of this data plane document. For 140 reference, the option of using BGP extensions to support SR service 141 programming is proposed in [I-D.dawra-idr-bgp-sr-service-chaining]. 143 2. Terminology 145 This document leverages the terminology proposed in [RFC8402] and 146 [I-D.ietf-spring-segment-routing-policy]. It also introduces the 147 following new terms. 149 Service segment: A segment associated with a service. The service 150 may either run on a physical appliance or in a virtual environment 151 such as a virtual machine or container. 153 SR-aware service: A service that is fully capable of processing SR 154 traffic. An SR-aware service can be directly associated with a 155 service segment. 157 SR-unaware service: A service that is unable to process SR traffic or 158 may behave incorrectly due to presence of SR information in the 159 packet headers. An SR-unaware service can be associated with a 160 service segment through an SR proxy function. 162 3. Classification and steering 164 Classification and steering mechanisms are defined in section 8 of 165 [I-D.ietf-spring-segment-routing-policy] and are independent from the 166 purpose of the SR policy. From the perspective of a headend node 167 classifying and steering traffic into an SR policy, there is no 168 difference whether this policy contains IGP, BGP, peering, VPN or 169 service segments, or any combination of these. 171 As documented in the above reference, traffic is classified when 172 entering an SR domain. The SR policy headend may, depending on its 173 capabilities, classify the packets on a per-destination basis, via 174 simple FIB entries, or apply more complex policy routing rules 175 requiring to look deeper into the packet. These rules are expected 176 to support basic policy routing such as 5-tuple matching. In 177 addition, the IPv6 SRH tag field defined in 178 [I-D.ietf-6man-segment-routing-header] can be used to identify and 179 classify packets sharing the same set of properties. Classified 180 traffic is then steered into the appropriate SR policy and forwarded 181 as per the SID-list(s) of the active candidate path. 183 SR traffic can be re-classified by an SR endpoint along the original 184 SR policy (e.g., DPI service) or a transit node intercepting the 185 traffic. This node is the head-end of a new SR policy that is 186 imposed onto the packet, either as a stack of MPLS labels or as an 187 IPv6 SRH. 189 4. Service segments 191 In the context of this document, the term service refers to a 192 physical appliance running on dedicated hardware, a virtualized 193 service inside an isolated environment such as a VM, container or 194 namespace, or any process running on a compute element. A service 195 may also comprise multiple sub-components running in different 196 processes or containers. Unless otherwise stated, this document does 197 not make any assumption on the type or execution environment of a 198 service. 200 The execution of a service can be integrated as part of an SR policy 201 by assigning a segment identifier, or SID, to the service and 202 including this service SID in the SR policy SID-list. Such a service 203 SID may be of local or global significance. In the former case, 204 other segments, such as prefix or adjacency segments, can be used to 205 steer the traffic up to the node where the service segment is 206 instantiated. In the latter case, the service is directly reachable 207 from anywhere in the routing domain. This is realized with SR-MPLS 208 by assigning a SID from the global label block 209 ([I-D.ietf-spring-segment-routing-mpls]), or with SRv6 by advertising 210 the SID locator in the routing protocol 211 ([I-D.filsfils-spring-srv6-network-programming]). It is up to the 212 network operator to define the scope and reachability of each service 213 SID. This decision can be based on various considerations such as 214 infrastructure dynamicity, available control plane or orchestration 215 system capabilities. 217 This document categorizes services in two types, depending on whether 218 they are able to behave properly in the presence of SR information or 219 not. These are respectively named SR-aware and SR-unaware services. 221 4.1. SR-aware services 223 An SR-aware service can process the SR information in the packets it 224 receives. This means being able to identify the active segment as a 225 local instruction and move forward in the segment list, but also that 226 the service's own behavior is not hindered due to the presence of SR 227 information. For example, an SR-aware firewall filtering SRv6 228 traffic based on its final destination must retrieve that information 229 from the last entry in the SRH rather than the Destination Address 230 field of the IPv6 header. 232 An SR-aware service is associated with a locally instantiated service 233 segment, which is used to steer traffic through it. 235 If the service is configured to intercept all the packets passing 236 through the appliance, the underlying routing system only has to 237 implement a default SR endpoint behavior (SR-MPLS node segment or 238 SRv6 End function), and the corresponding SID will be used to steer 239 traffic through the service. 241 If the service requires the packets to be directed to a specific 242 virtual interface, networking queue or process, a dedicated SR 243 behavior may be required to steer the packets to the appropriate 244 location. The definition of such service-specific functions is out 245 of the scope of this document. 247 SR-aware services also enable advanced network programming 248 functionalities such as conditional branching and jumping to 249 arbitrary SIDs in the segment list. In addition, SRv6 provides 250 several ways of passing and exchanging information between services 251 (e.g., SID arguments, tag field and TLVs). An example scenario 252 involving these features is described in [IFIP18], which discusses 253 the implementation of an SR-aware Intrusion Detection System. 255 Examples of SR-aware services are provided in section Section 8.1. 257 4.2. SR-unaware services 259 Any service that does not meet the above criteria for SR-awareness is 260 considered as SR-unaware. 262 An SR-unaware service is not able to process the SR information in 263 the traffic that it receives. It may either drop the traffic or take 264 erroneous decisions due to the unrecognized routing information. In 265 order to include such services in an SR policy, it is thus required 266 to remove the SR information as well as any other encapsulation 267 header before the service receives the packet, or to alter it in such 268 a way that the service can correctly process the packet. 270 In this document, we define the concept of an SR proxy as an entity, 271 separate from the service, that performs these modifications and 272 handle the SR processing on behalf of a service. The SR proxy can 273 run as a separate process on the service appliance, on a virtual 274 switch or router on the compute node or on a different host. 276 An SR-unaware service is associated with a service segment 277 instantiated on the SR proxy, which is used to steer traffic through 278 the service. Section 6 describes several SR proxy behaviors to 279 handle the encapsulation headers and SR information under various 280 circumstances. 282 5. SR service policies 284 An SR service policy is an SR policy, as defined in 285 [I-D.ietf-spring-segment-routing-policy], that includes at least one 286 service. This service is represented in the SID-list by its 287 associated service SID. In case the policy should include several 288 services, the service traversal order is indicated by the relative 289 position of each service SID in the SID-list. Using the mechanisms 290 described in [I-D.ietf-spring-segment-routing-policy], it is possible 291 to load balance the traffic over several services, or instances of 292 the same service, by associating with the SR service policy a 293 weighted set of SID-lists, each containing a possible sequence of 294 service SIDs to be traversed. Similarly, several candidate paths can 295 be specified for the SR service policy, each with its own set of SID- 296 lists, for resiliency purposes. 298 Furthermore, binding SIDs (BSIDs) can be leveraged in the context of 299 service policies to reduce the number of SIDs imposed by the headend, 300 provide opacity between domains and improve scalability, as described 301 in [I-D.filsfils-spring-sr-policy-considerations]. For example, a 302 network operator may want a policy in its core domain to include 303 services that are running in one of its datacenters. One option is 304 to define an SR policy at ingress edge of the core domain that 305 explicitly includes all the SIDs needed to steer the traffic through 306 the core and in the DC, but that may result in a long SID-list and 307 requires to update the ingress edge configuration every time the DC 308 part of the policy is modified. Alternatively, a separate policy can 309 be defined at the ingress edge of the datacenter with only the SIDs 310 that needs to be executed there and its BSID included in the core 311 domain policy. That BSID remains stable when the DC policy is 312 modified and can even be shared among several core domain policies 313 that would require the same type of processing in the DC. 315 This section describes how services can be integrated within an SR- 316 MPLS or SRv6 service policy. 318 +------------------------------------------+ 319 | SR network | 320 | | 321 +----+----+ +---------+ +----+-----+ 322 | H +----------+ S +-----------+ E | 323 |(headend)| |(service)| |(endpoint)| 324 +----+----+ +---------+ +----+-----+ 325 | =====================================> | 326 | P1(H,E,C) | 327 +------------------------------------------+ 329 Figure 1: SR service policy 331 Figure 1 illustrates a basic SR service policy instantiated on a 332 headend node H towards an endpoint E and traversing a service S. The 333 SR policy may also include additional requirements, such as traffic 334 engineering or VPN. On the head-end H, the SR policy P1 is created 335 with a color C and endpoint E and associated with an SR path that can 336 either be explicitly configured, dynamically computed on H or 337 provisioned by a network controller. 339 In its most basic form, the SR policy P1 would be resolved into the 340 SID-list < SID(S), SID(E) >. This is assuming that SID(S) and SID(E) 341 are directly reachable from H and S, respectively, and that the 342 forwarding path meets the policy requirement. However, depending on 343 the dataplane and the segments available in the network, additional 344 SIDs may be required to enforce the SR policy. 346 This model applies regardless of the SR-awareness of the service. If 347 it is SR-unaware, then S simply represents the proxy that takes care 348 of transmitting the packet to the actual service. 350 Traffic can then be steered into this policy using any of the 351 mechanisms described in [I-D.ietf-spring-segment-routing-policy]. 353 The following subsections describe the specificities of each SR 354 dataplane. 356 5.1. SR-MPLS data plane 357 +-----------------------------------------------+ 358 | SR-MPLS network | 359 | | 360 +----+----+ ------> +---------+ ------> +----+-----+ 361 | H +-------------+ S +-------------+ E | 362 |(headend)| |(service)| |(endpoint)| 363 +----+----+ +---------+ +----+-----+ 364 | (1) (2) (3) (4) | 365 |+---------+ +---------+ +---------+ +---------+| 366 || ... | | L(S) | | ... | | L(E) || 367 |+---------+ +---------+ +---------+ +---------+| 368 || L(S) | | ... | | L(E) | |Inner pkt|| 369 |+---------+ +---------+ +---------+ +---------+| 370 || ... | | L(E) | |Inner pkt| | 371 |+---------+ +---------+ +---------+ | 372 || L(E) | |Inner pkt| | 373 |+---------+ +---------+ | 374 ||Inner pkt| | 375 |+---------+ | 376 +-----------------------------------------------+ 378 Figure 2: Packet walk in an SR-MPLS network 380 In an SR-MPLS network, the SR policy SID-list is encoded as a stack 381 of MPLS labels[I-D.ietf-spring-segment-routing-mpls] and pushed on 382 top of the packet. 384 In the example shown on Figure 2, the SR policy should steer the 385 traffic from the head-end H to the endpoint E via a service S. This 386 translates into an MPLS label stack that includes at least a label 387 L(S) associated to service S and a label L(E) associated to the 388 endpoint E. The label stack may also include additional intermediate 389 segments if these are required for traffic engineering (e.g., to 390 encode a low latency path between H and S and / or between S and E) 391 or simply for reachability purposes. Indeed, the service SID L(S) 392 may be taken from the global or local SID block of node S and, in the 393 latter case, one or more SIDs might be needed before L(S) in order 394 for the packet to reach node S (e.g., a prefix-SID of S), where L(S) 395 can be interpreted. The same applies for the segment L(E) at the SR 396 policy endpoint. 398 Special consideration must be taken into account when using Local 399 SIDs for service identification due to increased label stack depth 400 and the associated impacts. 402 When the packet arrives at S, this node determines the MPLS payload 403 type and the appropriate behavior for processing the packet based on 404 the semantic locally associated to the top label L(S). If S is an 405 SR-aware service, the SID L(S) may provide additional context or 406 indication on how to process the packet (e.g., a firewall SID may 407 indicate which rule set should be applied onto the packet). If S is 408 a proxy in front of an SR-unaware service, L(S) indicates how and to 409 which service attached to this proxy the packet should be 410 transmitted. At some point in the process, L(S) is also popped from 411 the label stack in order to expose the next SID, which may be L(E) or 412 another intermediate segment. 414 5.2. SRv6 data plane 416 +-----------------------------------------------+ 417 | SRv6 network | 418 | | 419 +----+----+ ------> +---------+ ------> +----+-----+ 420 | H +-------------+ S +-------------+ E | 421 |(headend)| |(service)| |(endpoint)| 422 +----+----+ +---------+ +----+-----+ 423 | (1) (2) (3) (4) | 424 |+---------+ +---------+ +---------+ +---------+| 425 ||IP6(H,..)| |IP6(H, S)| |IP6(H,..)| |IP6(H, E)|| 426 |+---------+ +---------+ +---------+ +---------+| 427 ||SRH(E,..,| |SRH(E,..,| |SRH(E,..,| |SRH(E,..,|| 428 || S,..;| | S,..;| | S,..;| | S,..;|| 429 || SL=i)| | SL=j)| | SL=k)| | SL=0)|| 430 |+---------+ +---------+ +---------+ +---------+| 431 ||Inner pkt| |Inner pkt| |Inner pkt| |Inner pkt|| 432 |+---------+ +---------+ +---------+ +---------+| 433 +-----------------------------------------------+ 435 Figure 3: Packet walk in an SRv6 network 437 In an SRv6 network, the SR Policy is encoded into the packet as an 438 IPv6 header possibly followed by a Segment Routing header (SRH) 439 [I-D.ietf-6man-segment-routing-header]. 441 In the example shown on Figure 3, the SR policy should steer the 442 traffic from the head-end H to the endpoint E via a service S. This 443 translates into an SRH that includes at least a segment SID(S) to the 444 service, or service proxy, S and a segment SID(E) to the endpoint E. 445 The SRH may also include additional intermediate segments if these 446 are required for traffic engineering (e.g., the encode a low latency 447 path between H and S and / or between S and E) or simply for 448 reachability purposes. Indeed, the service segment locator may or 449 may not be advertised in the routing protocol and, in the latter 450 case, one or more SIDs might be needed before SID(S) in order to 451 bring the packet up to node S, where SID(S) can be interpreted. The 452 same applies for the segment SID(E) at the SR policy endpoint. 454 When the packet arrives at S, this node determines how to process the 455 packet based on the semantic locally associated to the active segment 456 SID(S). If S is an SR-aware service, then SID(S) may provide 457 additional context or indication on how to process the packet (e.g., 458 a firewall SID may indicate which rule set should be applied onto the 459 packet). If S is a proxy in front of an SR-unaware service, SID(S) 460 indicates how and to which service attached to this proxy the packet 461 should be transmitted. At some point in the process, the SRv6 End 462 function is also applied in order to make the next SID, which may be 463 SID(E) or another intermediate segment, active. 465 The "Inner pkt" on Figure 3 represents the SRv6 payload, which may be 466 an encapsulated IP packet, an Ethernet frame or a transport-layer 467 payload, for example. 469 6. SR proxy behaviors 471 This section describes several SR proxy behaviors designed to enable 472 SR service programming through SR-unaware services. A system 473 implementing one of these functions may handle the SR processing on 474 behalf of an SR-unaware service and allows the service to properly 475 process the traffic that is steered through it. 477 A service may be located at any hop in an SR policy, including the 478 last segment. However, the SR proxy behaviors defined in this 479 section are dedicated to supporting SR-unaware services at 480 intermediate hops in the segment list. In case an SR-unaware service 481 is at the last segment, it is sufficient to ensure that the SR 482 information is ignored (IPv6 routing extension header with Segments 483 Left equal to 0) or removed before the packet reaches the service 484 (MPLS PHP, SRv6 End.D or PSP). 486 As illustrated on Figure 4, the generic behavior of an SR proxy has 487 two parts. The first part is in charge of passing traffic from the 488 network to the service. It intercepts the SR traffic destined for 489 the service via a locally instantiated service segment, modifies it 490 in such a way that it appears as non-SR traffic to the service, then 491 sends it out on a given interface, IFACE-OUT, connected to the 492 service. The second part receives the traffic coming back from the 493 service on IFACE-IN, restores the SR information and forwards it 494 according to the next segment in the list. IFACE-OUT and IFACE-IN 495 are respectively the proxy interface used for sending traffic to the 496 service and the proxy interface that receives the traffic coming back 497 from the service. These can be physical interfaces or sub-interfaces 498 (VLANs) and, unless otherwise stated, IFACE-OUT and IFACE-IN can 499 represent the same interface. 501 +----------------------------+ 502 | | 503 | Service | 504 | | 505 +----------------------------+ 506 ^ Non SR | 507 | traffic | 508 | v 509 +-----------+----------+ 510 +--| IFACE OUT | IFACE IN |--+ 511 SR traffic | +-----------+----------+ | SR traffic 512 ---------->| SR proxy |----------> 513 | | 514 +----------------------------+ 516 Figure 4: Generic SR proxy 518 In the next subsections, the following SR proxy mechanisms are 519 defined: 521 o Static proxy 523 o Dynamic proxy 525 o Shared-memory proxy 527 o Masquerading proxy 529 Each mechanism has its own characteristics and constraints, which are 530 summarized in the below table. It is up to the operator to select 531 the best one based on the proxy node capabilities, the service 532 behavior and the traffic type. It is also possible to use different 533 proxy mechanisms within the same service policy. 535 +-----+-----+-----+-----+ 536 | | | | M | 537 | | | S | a | 538 | | | h | s | 539 | | | a | q | 540 | | | r | u | 541 | | D | e | e | 542 | S | y | d | r | 543 | t | n | | a | 544 | a | a | m | d | 545 | t | m | e | i | 546 | i | i | m | n | 547 | c | c | . | g | 548 +---------------------------------------+-----+-----+-----+-----+ 549 | | SR-MPLS | Y | Y | Y | - | 550 | | | | | | | 551 | SR flavors | SRv6 insertion | P | P | P | Y | 552 | | | | | | | 553 | | SRv6 encapsulation | Y | Y | Y | - | 554 +----------------+----------------------+-----+-----+-----+-----+ 555 | Chain agnostic configuration | N | N | Y | Y | 556 +---------------------------------------+-----+-----+-----+-----+ 557 | Transparent to chain changes | N | Y | Y | Y | 558 +----------------+----------------------+-----+-----+-----+-----+ 559 | | DA modification | Y | Y | Y | NAT | 560 | | | | | | | 561 | | Payload modification | Y | Y | Y | Y | 562 | | | | | | | 563 |Service support | Packet generation | Y | Y |cache|cache| 564 | | | | | | | 565 | | Packet deletion | Y | Y | Y | Y | 566 | | | | | | | 567 | | Transport endpoint | Y | Y |cache|cache| 568 +----------------+----------------------+-----+-----+-----+-----+ 569 | | Ethernet | Y | Y | Y | - | 570 | Supported | | | | | | 571 | traffic | IPv4 | Y | Y | Y | - | 572 | | | | | | | 573 | | IPv6 | Y | Y | Y | Y | 574 +----------------+----------------------+-----+-----+-----+-----+ 576 Figure 5: SR proxy summary 578 Note: The use of a shared memory proxy requires both the service 579 (VNF) and the proxy to be running on the same node. 581 6.1. Static SR proxy 583 The static proxy is an SR endpoint behavior for processing SR-MPLS or 584 SRv6 encapsulated traffic on behalf of an SR-unaware service. This 585 proxy thus receives SR traffic that is formed of an MPLS label stack 586 or an IPv6 header on top of an inner packet, which can be Ethernet, 587 IPv4 or IPv6. 589 A static SR proxy segment is associated with the following mandatory 590 parameters 592 o INNER-TYPE: Inner packet type 594 o NH-ADDR: Next hop Ethernet address (only for inner type IPv4 and 595 IPv6) 597 o IFACE-OUT: Local interface for sending traffic towards the service 599 o IFACE-IN: Local interface receiving the traffic coming back from 600 the service 602 o CACHE: SR information to be attached on the traffic coming back 603 from the service, including at least 605 * CACHE.SA: IPv6 source address (SRv6 only) 607 * CACHE.LIST: Segment list expressed as MPLS labels or IPv6 608 address 610 A static SR proxy segment is thus defined for a specific service, 611 inner packet type and cached SR information. It is also bound to a 612 pair of directed interfaces on the proxy. These may be both 613 directions of a single interface, or opposite directions of two 614 different interfaces. The latter is recommended in case the service 615 is to be used as part of a bi-directional SR SC policy. If the proxy 616 and the service both support 802.1Q, IFACE-OUT and IFACE-IN can also 617 represent sub-interfaces. 619 The first part of this behavior is triggered when the proxy node 620 receives a packet whose active segment matches a segment associated 621 with the static proxy behavior. It removes the SR information from 622 the packet then sends it on a specific interface towards the 623 associated service. This SR information corresponds to the full 624 label stack for SR-MPLS or to the encapsulation IPv6 header with any 625 attached extension header in the case of SRv6. 627 The second part is an inbound policy attached to the proxy interface 628 receiving the traffic returning from the service, IFACE-IN. This 629 policy attaches to the incoming traffic the cached SR information 630 associated with the SR proxy segment. If the proxy segment uses the 631 SR-MPLS data plane, CACHE contains a stack of labels to be pushed on 632 top of the packets. With the SRv6 data plane, CACHE is defined as a 633 source address, an active segment and an optional SRH (tag, segments 634 left, segment list and metadata). The proxy encapsulates the packets 635 with an IPv6 header that has the source address, the active segment 636 as destination address and the SRH as a routing extension header. 637 After the SR information has been attached, the packets are forwarded 638 according to the active segment, which is represented by the top MPLS 639 label or the IPv6 Destination Address. An MPLS TTL or IPv6 Hop Limit 640 value may also be configured in CACHE. If it is not, the proxy 641 should set these values according to the node's default setting for 642 MPLS or IPv6 encapsulation. 644 In this scenario, there are no restrictions on the operations that 645 can be performed by the service on the stream of packets. It may 646 operate at all protocol layers, terminate transport layer 647 connections, generate new packets and initiate transport layer 648 connections. This behavior may also be used to integrate an 649 IPv4-only service into an SRv6 policy. However, a static SR proxy 650 segment can be used in only one service policy at a time. As opposed 651 to most other segment types, a static SR proxy segment is bound to a 652 unique list of segments, which represents a directed SR SC policy. 653 This is due to the cached SR information being defined in the segment 654 configuration. This limitation only prevents multiple segment lists 655 from using the same static SR proxy segment at the same time, but a 656 single segment list can be shared by any number of traffic flows. 657 Besides, since the returning traffic from the service is re- 658 classified based on the incoming interface, an interface can be used 659 as receiving interface (IFACE-IN) only for a single SR proxy segment 660 at a time. In the case of a bi-directional SR SC policy, a different 661 SR proxy segment and receiving interface are required for the return 662 direction. 664 The static proxy behavior may also be used for sending traffic 665 through "bump in the wire" services that are transparent to the IP 666 and Ethernet layers. This type of processing is assumed when the 667 inner traffic type is Ethernet, since the original destination 668 address of the Ethernet frame is preserved when the packet is steered 669 into the SR Policy and likely associated with a node downstream of 670 the policy tail-end. In case the inner type is IP (IPv4 or IPv6), 671 the NH-ADDR parameter may be set to a dummy or broadcast Ethernet 672 address, or simply to the address of the proxy receiving interface 673 (IFACE-IN). 675 6.1.1. SR-MPLS pseudocode 677 6.1.1.1. Static proxy for inner type Ethernet 679 Upon receiving an MPLS packet with top label L, where L is an MPLS L2 680 static proxy segment, a node N does: 682 1. Pop all labels 683 2. IF payload type is Ethernet THEN 684 3. Forward the exposed frame on IFACE-OUT 685 4. ELSE 686 5. Drop the packet 688 Upon receiving on IFACE-IN an Ethernet frame with a destination 689 address different than the interface address, a node N does: 691 1. Push labels in CACHE on top of the frame Ethernet header 692 2. Lookup the top label and proceed accordingly 694 The receiving interface must be configured in promiscuous mode in 695 order to accept those Ethernet frames. 697 6.1.1.2. Static proxy for inner type IPv4 699 Upon receiving an MPLS packet with top label L, where L is an MPLS 700 IPv4 static proxy segment, a node N does: 702 1. Pop all labels 703 2. IF payload type is IPv4 THEN 704 3. Forward the exposed packet on IFACE-OUT towards NH-ADDR 705 4. ELSE 706 5. Drop the packet 708 Upon receiving a non-link-local IPv4 packet on IFACE-IN, a node N 709 does: 711 1. Decrement TTL and update checksum 712 2. Push labels in CACHE on top of the packet IPv4 header 713 3. Lookup the top label and proceed accordingly 715 6.1.1.3. Static proxy for inner type IPv6 717 Upon receiving an MPLS packet with top label L, where L is an MPLS 718 IPv6 static proxy segment, a node N does: 720 1. Pop all labels 721 2. IF payload type is IPv6 THEN 722 3. Forward the exposed packet on IFACE-OUT towards NH-ADDR 723 4. ELSE 724 5. Drop the packet 726 Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N 727 does: 729 1. Decrement Hop Limit 730 2. Push labels in CACHE on top of the packet IPv6 header 731 3. Lookup the top label and proceed accordingly 733 6.1.2. SRv6 pseudocode 735 6.1.2.1. Static proxy for inner type Ethernet 737 Upon receiving an IPv6 packet destined for S, where S is an IPv6 738 static proxy segment for Ethernet traffic, a node N does: 740 1. IF ENH == 59 THEN ;; Ref1 741 2. Remove the (outer) IPv6 header and its extension headers 742 3. Forward the exposed frame on IFACE-OUT 743 4. ELSE 744 5. Drop the packet 746 Ref1: 59 refers to "no next header" as defined by IANA allocation for 747 Internet Protocol Numbers. 749 Upon receiving on IFACE-IN an Ethernet frame with a destination 750 address different than the interface address, a node N does: 752 1. Retrieve CACHE entry matching IFACE-IN and traffic type 753 2. Push SRH with CACHE.LIST on top of the Ethernet header ;; Ref2 754 3. Push IPv6 header with 755 SA = CACHE.SA 756 DA = CACHE.LIST[0] ;; Ref3 757 Next Header = 43 ;; Ref4 758 4. Set outer payload length and flow label 759 5. Lookup outer DA in appropriate table and proceed accordingly 761 Ref2: Unless otherwise specified, the segments in CACHE.LIST should 762 be encoded in reversed order, Segment Left and Last Entry values 763 should be set of the length of CACHE.LIST minus 1, and Next Header 764 should be set to 59. 766 Ref3: CACHE.LIST[0] represents the first IPv6 SID in CACHE.LIST. 768 Ref4: If CACHE.LIST contains a single entry, the SRH can be omitted 769 and the Next Header value must be set to 59. 771 The receiving interface must be configured in promiscuous mode in 772 order to accept those Ethernet frames. 774 6.1.2.2. Static proxy for inner type IPv4 776 Upon receiving an IPv6 packet destined for S, where S is an IPv6 777 static proxy segment for IPv4 traffic, a node N does: 779 1. IF ENH == 4 THEN ;; Ref1 780 2. Remove the (outer) IPv6 header and its extension headers 781 3. Forward the exposed packet on IFACE-OUT towards NH-ADDR 782 4. ELSE 783 5. Drop the packet 785 Ref1: 4 refers to IPv4 encapsulation as defined by IANA allocation 786 for Internet Protocol Numbers. 788 Upon receiving a non-link-local IPv4 packet on IFACE-IN, a node N 789 does: 791 1. Decrement TTL and update checksum 792 2. IF CACHE.SRH THEN ;; Ref2 793 3. Push CACHE.SRH on top of the existing IPv4 header 794 4. Set NH value of the pushed SRH to 4 795 5. Push outer IPv6 header with SA, DA and traffic class from CACHE 796 6. Set outer payload length and flow label 797 7. Set NH value to 43 if an SRH was added, or 4 otherwise 798 8. Lookup outer DA in appropriate table and proceed accordingly 800 Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the 801 static SR proxy segment associated with IFACE-IN. 803 6.1.2.3. Static proxy for inner type IPv6 805 Upon receiving an IPv6 packet destined for S, where S is an IPv6 806 static proxy segment for IPv6 traffic, a node N does: 808 1. IF ENH == 41 THEN ;; Ref1 809 2. Remove the (outer) IPv6 header and its extension headers 810 3. Forward the exposed packet on IFACE-OUT towards NH-ADDR 811 4. ELSE 812 5. Drop the packet 814 Ref1: 41 refers to IPv6 encapsulation as defined by IANA allocation 815 for Internet Protocol Numbers. 817 Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N 818 does: 820 1. Decrement Hop Limit 821 2. IF CACHE.SRH THEN ;; Ref2 822 3. Push CACHE.SRH on top of the existing IPv6 header 823 4. Set NH value of the pushed SRH to 41 824 5. Push outer IPv6 header with SA, DA and traffic class from CACHE 825 6. Set outer payload length and flow label 826 7. Set NH value to 43 if an SRH was added, or 41 otherwise 827 8. Lookup outer DA in appropriate table and proceed accordingly 829 Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the 830 static SR proxy segment associated with IFACE-IN. 832 6.2. Dynamic SR proxy 834 The dynamic proxy is an improvement over the static proxy that 835 dynamically learns the SR information before removing it from the 836 incoming traffic. The same information can then be re-attached to 837 the traffic returning from the service. As opposed to the static SR 838 proxy, no CACHE information needs to be configured. Instead, the 839 dynamic SR proxy relies on a local caching mechanism on the node 840 instantiating this segment. 842 Upon receiving a packet whose active segment matches a dynamic SR 843 proxy function, the proxy node pops the top MPLS label or applies the 844 SRv6 End behavior, then compares the updated SR information with the 845 cache entry for the current segment. If the cache is empty or 846 different, it is updated with the new SR information. The SR 847 information is then removed and the inner packet is sent towards the 848 service. 850 The cache entry is not mapped to any particular packet, but instead 851 to an SR SC policy identified by the receiving interface (IFACE-IN). 852 Any non-link-local IP packet or non-local Ethernet frame received on 853 that interface will be re-encapsulated with the cached headers as 854 described in Section 6.1. The service may thus drop, modify or 855 generate new packets without affecting the proxy. 857 6.2.1. SR-MPLS pseudocode 859 The dynamic proxy SR-MPLS pseudocode is obtained by inserting the 860 following instructions at the beginning of the static SR-MPLS 861 pseudocode (Section 6.1.1). 863 1. IF top label S bit is 0 THEN ;; Ref1 864 2. Pop top label 865 3. IF C(IFACE-IN) different from remaining labels THEN ;; Ref2 866 4. Copy all remaining labels into C(IFACE-IN) ;; Ref3 867 5. ELSE 868 6. Drop the packet 870 Ref1: As mentioned at the beginning of Section 6, an SR proxy is not 871 needed to include an SR-unaware service at the end of an SR policy. 873 Ref2: A TTL margin can be configured for the top label stack entry to 874 prevent constant cache updates when multiple equal-cost paths with 875 different hop counts are used towards the SR proxy node. In that 876 case, a TTL difference smaller than the configured margin should not 877 trigger a cache update (provided that the labels are the same). 879 Ref3: C(IFACE-IN) represents the cache entry associated to the 880 dynamic SR proxy segment. It is identified with IFACE-IN in order to 881 efficiently retrieve the right SR information when a packet arrives 882 on this interface. 884 In addition, the inbound policy should check that C(IFACE-IN) has 885 been defined before attempting to restore the MPLS label stack and 886 drop the packet otherwise. 888 6.2.2. SRv6 pseudocode 890 The dynamic proxy SRv6 pseudocode is obtained by inserting the 891 following instructions between lines 1 and 2 of the static proxy SRv6 892 pseudocode. 894 1. IF NH=SRH & SL > 0 THEN ;; Ref1 895 2. Decrement SL and update the IPv6 DA with SRH[SL] 896 3. IF C(IFACE-IN) different from IPv6 encaps THEN ;; Ref2 897 4. Copy the IPv6 encaps into C(IFACE-IN) ;; Ref3 898 5. ELSE 899 6. Drop the packet 901 Ref1: As mentioned at the beginning of Section 6, an SR proxy is not 902 needed to include an SR-unaware service at the end of an SR policy. 904 Ref2: "IPv6 encaps" represents the IPv6 header and any attached 905 extension header. 907 Ref3: C(IFACE-IN) represents the cache entry associated to the 908 dynamic SR proxy segment. It is identified with IFACE-IN in order to 909 efficiently retrieve the right SR information when a packet arrives 910 on this interface. 912 In addition, the inbound policy should check that C(IFACE-IN) has 913 been defined before attempting to restore the IPv6 encapsulation and 914 drop the packet otherwise. 916 6.3. Shared memory SR proxy 918 The shared memory proxy is an SR endpoint behavior for processing SR- 919 MPLS or SRv6 encapsulated traffic on behalf of an SR-unaware service. 920 This proxy behavior leverages a shared-memory interface with a 921 virtualized service (VNF) in order to hide the SR information from an 922 SR-unaware service while keeping it attached to the packet. We 923 assume in this case that the proxy and the VNF are running on the 924 same compute node. A typical scenario is an SR-capable vrouter 925 running on a container host and forwarding traffic to VNFs isolated 926 within their respective container. 928 More details will be added in a future revision of this document. 930 6.4. Masquerading SR proxy 932 The masquerading proxy is an SR endpoint behavior for processing SRv6 933 traffic on behalf of an SR-unaware service. This proxy thus receives 934 SR traffic that is formed of an IPv6 header and an SRH on top of an 935 inner payload. The masquerading behavior is independent from the 936 inner payload type. Hence, the inner payload can be of any type but 937 it is usually expected to be a transport layer packet, such as TCP or 938 UDP. 940 A masquerading SR proxy segment is associated with the following 941 mandatory parameters: 943 o S-ADDR: Ethernet or IPv6 address of the service 945 o IFACE-OUT: Local interface for sending traffic towards the service 947 o IFACE-IN: Local interface receiving the traffic coming back from 948 the service 950 A masquerading SR proxy segment is thus defined for a specific 951 service and bound to a pair of directed interfaces or sub-interfaces 952 on the proxy. As opposed to the static and dynamic SR proxies, a 953 masquerading segment can be present at the same time in any number of 954 SR SC policies and the same interfaces can be bound to multiple 955 masquerading proxy segments. The only restriction is that a 956 masquerading proxy segment cannot be the last segment in an SR SC 957 policy. 959 The first part of the masquerading behavior is triggered when the 960 proxy node receives an IPv6 packet whose Destination Address matches 961 a masquerading proxy segment. The proxy inspects the IPv6 extension 962 headers and substitutes the Destination Address with the last segment 963 in the SRH attached to the IPv6 header, which represents the final 964 destination of the IPv6 packet. The packet is then sent out towards 965 the service. 967 The service receives an IPv6 packet whose source and destination 968 addresses are respectively the original source and final destination. 969 It does not attempt to inspect the SRH, as RFC8200 specifies that 970 routing extension headers are not examined or processed by transit 971 nodes. Instead, the service simply forwards the packet based on its 972 current Destination Address. In this scenario, we assume that the 973 service can only inspect, drop or perform limited changes to the 974 packets. For example, Intrusion Detection Systems, Deep Packet 975 Inspectors and non-NAT Firewalls are among the services that can be 976 supported by a masquerading SR proxy. Variants of the masquerading 977 behavior are defined in Section 6.4.2 and Section 6.4.3 to support a 978 wider range of services. 980 The second part of the masquerading behavior, also called de- 981 masquerading, is an inbound policy attached to the proxy interface 982 receiving the traffic returning from the service, IFACE-IN. This 983 policy inspects the incoming traffic and triggers a regular SRv6 984 endpoint processing (End) on any IPv6 packet that contains an SRH. 985 This processing occurs before any lookup on the packet Destination 986 Address is performed and it is sufficient to restore the right active 987 segment as the Destination Address of the IPv6 packet. 989 6.4.1. SRv6 masquerading proxy pseudocode 991 Masquerading: Upon receiving a packet destined for S, where S is an 992 IPv6 masquerading proxy segment, a node N processes it as follows. 994 1. IF NH=SRH & SL > 0 THEN 995 2. Update the IPv6 DA with SRH[0] 996 3. Forward the packet on IFACE-OUT 997 4. ELSE 998 5. Drop the packet 1000 De-masquerading: Upon receiving a non-link-local IPv6 packet on 1001 IFACE-IN, a node N processes it as follows. 1003 1. IF NH=SRH & SL > 0 THEN 1004 2. Decrement SL 1005 3. Update the IPv6 DA with SRH[SL] ;; Ref1 1006 4. Lookup DA in appropriate table and proceed accordingly 1007 Ref1: This pseudocode can be augmented to support the Penultimate 1008 Segment Popping (PSP) endpoint flavor. The exact pseudocode 1009 modification are provided in 1010 [I-D.filsfils-spring-srv6-network-programming]. 1012 6.4.2. Variant 1: Destination NAT 1014 Services modifying the destination address in the packets they 1015 process, such as NATs, can be supported by a masquerading proxy with 1016 the following modification to the de-masquerading pseudocode. 1018 De-masquerading - NAT: Upon receiving a non-link-local IPv6 packet on 1019 IFACE-IN, a node N processes it as follows. 1021 1. IF NH=SRH & SL > 0 THEN 1022 2. Update SRH[0] with the IPv6 DA 1023 3. Decrement SL 1024 4. Update the IPv6 DA with SRH[SL] 1025 5. Lookup DA in appropriate table and proceed accordingly 1027 6.4.3. Variant 2: Caching 1029 Services generating packets or acting as endpoints for transport 1030 connections can be supported by adding a dynamic caching mechanism 1031 similar to the one described in Section 6.2. 1033 More details will be added in a future revision of this document. 1035 7. Metadata 1037 7.1. MPLS data plane 1039 Metadata can be carried for SR-MPLS traffic in a Segment Routing 1040 header inserted between the last MPLS label and the MPLS payload. 1041 When used solely as a metadata container, the SRH does not carry any 1042 segment but only the mandatory header fields, including the tag and 1043 flags, and any TLVs that is required for transporting the metadata. 1045 Since the MPLS encapsulation has no explicit protocol identifier 1046 field to indicate the protocol type of the MPLS payload, how to 1047 indicate the presence of metadata in an MPLS packet is a potential 1048 issue to be addressed. One possible solution is to add the 1049 indication about the presence of metadata in the semantic of the 1050 SIDs. Note that only the SIDs whose behavior involves looking at the 1051 metadata or the MPLS payload would need to include such semantic 1052 (e.g., service segments). Other segments, such as traffic 1053 engineering segments, are not affected by the presence of metadata. 1054 Another, more generic, solution is to introduce a protocol identifier 1055 field within the MPLS packet as described in 1056 [I-D.xu-mpls-payload-protocol-identifier]. 1058 7.2. IPv6 data plane 1060 7.2.1. SRH TLV objects 1062 The IPv6 SRH TLV objects are designed to carry all sorts of metadata. 1063 In particular, the NSH carrier TLV is defined as a container for NSH 1064 metadata. 1066 TLV objects can be imposed by the ingress edge router that steers the 1067 traffic into the SR SC policy. 1069 An SR-aware service may impose, modify or remove any TLV object 1070 attached to the first SRH, either by directly modifying the packet 1071 headers or via a control channel between the service and its 1072 forwarding plane. 1074 An SR-aware service that re-classifies the traffic and steers it into 1075 a new SR SC policy (e.g. DPI) may attach any TLV object to the new 1076 SRH. 1078 Metadata imposition and handling will be further discussed in a 1079 future version of this document. 1081 7.2.1.1. Opaque Metadata TLV 1083 This document defines an SRv6 TLV called Opaque Metadata TLV. This 1084 is a fixed-length container to carry any type of Service Metadata. 1085 No assumption is made by this document on the structure or the 1086 content of the carried metadata. The Opaque Metadata TLV has the 1087 following format: 1089 0 1 2 3 1090 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Type | Length | | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1094 | | 1095 | Service Metadata | 1096 | | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 where: 1101 o Type: to be assigned by IANA. 1103 o Length: 14. 1105 o Service Metadata: 14 octets of opaque data. 1107 7.2.1.2. NSH Carrier TLV 1109 This document defines an SRv6 TLV called NSH Carrier TLV. It is a 1110 container to carry Service Metadata in the form of Variable-Length 1111 Metadata as defined in [RFC8300] for NSH MD Type 2. The NSH Carrier 1112 TLV has the following format: 1114 0 1 2 3 1115 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Type | Length | Flags | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 // Service Metadata // 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 where: 1124 o Type: to be assigned by IANA. 1126 o Length: the total length of the TLV. 1128 o Flags: 8 bits. No flags are defined in this document. SHOULD be 1129 set to 0 on transmission and MUST be ignored on receipt. 1131 o Service Metadata: a list of Service Metadata TLV as defined in 1132 [RFC8300] for NSH MD Type 2. 1134 7.2.2. SRH tag 1136 The SRH tag identifies a packet as part of a group or class of 1137 packets [I-D.ietf-6man-segment-routing-header]. 1139 In the context of service programming, this field can be used to 1140 encode basic metadata in the SRH. An example use case would be to 1141 leverage the SRH tag to encode a policy ID which could be leveraged 1142 in an SR-aware function to determine which processing policy to apply 1143 rather than having doing local classification or leverage alternate 1144 encapsulations. 1146 8. Implementation status 1148 This section is to be removed prior to publishing as an RFC. 1150 8.1. SR-aware services 1152 Specific SRv6 support has been implemented for the below open-source 1153 services: 1155 o Iptables (1.6.2 and later) 1157 o Nftables (0.8.4 and later) 1159 o Snort 1161 In addition, any service relying on the Linux kernel, version 4.10 1162 and later, or FD.io VPP for packet forwarding can be considered as 1163 SR-aware. 1165 8.2. Proxy behaviors 1167 The static SR proxy is available for SR-MPLS and SRv6 on various 1168 Cisco hardware and software platforms. Furthermore, the following 1169 proxies are available on open-source software. 1171 +-------------+-------------+ 1172 | VPP | Linux | 1173 +---+-----------------------------------+-------------+-------------+ 1174 | M | Static proxy | Available | In progress | 1175 | P | | | | 1176 | L | Dynamic proxy | In progress | In progress | 1177 | S | | | | 1178 | | Shared memory proxy | In progress | In progress | 1179 +---+-----------------------------------+-------------+-------------+ 1180 | | Static proxy | Available | In progress | 1181 | S | | | | 1182 | R | Dynamic proxy | Available | Available | 1183 | v | | | | 1184 | 6 | Shared memory proxy | In progress | In progress | 1185 | | | | | 1186 | | Masquerading proxy | Available | Available | 1187 +---+-----------------------------------+-------------+-------------+ 1189 Figure 6: Open-source implementation status table 1191 9. Related works 1193 The Segment Routing solution addresses a wide problem that covers 1194 both topological and service policies. The topological and service 1195 instructions can be either deployed in isolation or in combination. 1196 SR has thus a wider applicability than the architecture defined in 1197 [RFC7665]. Furthermore, the inherent property of SR is a stateless 1198 network fabric. In SR, there is no state within the fabric to 1199 recognize a flow and associate it with a policy. State is only 1200 present at the ingress edge of the SR domain, where the policy is 1201 encoded into the packets. This is completely different from other 1202 proposals such as [RFC8300] and the MPLS label swapping mechanism 1203 described in [I-D.ietf-mpls-sfc], which rely on state configured at 1204 every hop of the service chain. 1206 10. IANA Considerations 1208 10.1. SRv6 Endpoint Behaviors 1210 This I-D requests the IANA to allocate, within the "SRv6 Endpoint 1211 Behaviors" sub-registry belonging to the top-level "Segment-routing 1212 with IPv6 dataplane (SRv6) Parameters" registry, the following 1213 allocations: 1215 Value Description Reference 1216 -------------------------------------------------------------- 1217 TBA1 End.AN - SR-aware function (native) [This.ID] 1218 TBA2 End.AS - Static proxy [This.ID] 1219 TBA3 End.AD - Dynamic proxy [This.ID] 1220 TBA4 End.AM - Masquerading proxy [This.ID] 1222 10.2. Segment Routing Header TLVs 1224 This I-D requests the IANA to allocate, within the "Segment Routing 1225 Header TLVs" registry, the following allocations: 1227 Value Description Reference 1228 ---------------------------------------------- 1229 TBA1 Opaque Metadata TLV [This.ID] 1230 TBA2 NSH Carrier TLV [This.ID] 1232 11. Security Considerations 1234 The security requirements and mechanisms described in [RFC8402], 1235 [I-D.ietf-6man-segment-routing-header] and 1236 [I-D.filsfils-spring-srv6-network-programming] also apply to this 1237 document. 1239 This document does not introduce any new security vulnerabilities. 1241 12. Acknowledgements 1243 The authors would like to thank Thierry Couture, Ketan Talaulikar, 1244 Loa Andersson, Andrew G. Malis, Adrian Farrel, Alexander Vainshtein 1245 and Joel M. Halpern for their valuable comments and suggestions on 1246 the document. 1248 13. Contributors 1250 P. Camarillo (Cisco), B. Peirens (Proximus), D. Steinberg 1251 (Steinberg Consulting), A. AbdelSalam (Gran Sasso Science 1252 Institute), G. Dawra (LinkedIn), S. Bryant (Huawei), H. Assarpour 1253 (Broadcom), H. Shah (Ciena), L. Contreras (Telefonica I+D), J. 1254 Tantsura (Individual), M. Vigoureux (Nokia) and J. Bhattacharya 1255 (Cisco) substantially contributed to the content of this document. 1257 14. References 1259 14.1. Normative References 1261 [I-D.filsfils-spring-srv6-network-programming] 1262 Filsfils, C., Camarillo, P., Leddy, J., 1263 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1264 Network Programming", draft-filsfils-spring-srv6-network- 1265 programming-07 (work in progress), February 2019. 1267 [I-D.ietf-6man-segment-routing-header] 1268 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1269 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1270 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 1271 progress), April 2019. 1273 [I-D.ietf-spring-segment-routing-mpls] 1274 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1275 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1276 data plane", draft-ietf-spring-segment-routing-mpls-19 1277 (work in progress), March 2019. 1279 [I-D.ietf-spring-segment-routing-policy] 1280 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1281 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1282 Policy Architecture", draft-ietf-spring-segment-routing- 1283 policy-02 (work in progress), October 2018. 1285 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1286 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1287 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1288 July 2018, . 1290 14.2. Informative References 1292 [I-D.dawra-idr-bgp-sr-service-chaining] 1293 Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d., 1294 Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F., 1295 and K. Talaulikar, "BGP Control Plane Extensions for 1296 Segment Routing based Service Chaining", draft-dawra-idr- 1297 bgp-sr-service-chaining-02 (work in progress), January 1298 2018. 1300 [I-D.filsfils-spring-sr-policy-considerations] 1301 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1302 P. Mattes, "SR Policy Implementation and Deployment 1303 Considerations", draft-filsfils-spring-sr-policy- 1304 considerations-03 (work in progress), April 2019. 1306 [I-D.ietf-mpls-sfc] 1307 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1308 Forwarding Plane for Service Function Chaining", draft- 1309 ietf-mpls-sfc-07 (work in progress), March 2019. 1311 [I-D.xu-mpls-payload-protocol-identifier] 1312 Xu, X., Assarpour, H., Ma, S., and F. Clad, "MPLS Payload 1313 Protocol Identifier", draft-xu-mpls-payload-protocol- 1314 identifier-06 (work in progress), March 2019. 1316 [IFIP18] Abdelsalam, A., Salsano, S., Clad, F., Camarillo, P., and 1317 C. Filsfils, "SEgment Routing Aware Firewall For Service 1318 Function Chaining scenarios", IFIP Networking conference , 1319 May 2018. 1321 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1322 Chaining (SFC) Architecture", RFC 7665, 1323 DOI 10.17487/RFC7665, October 2015, 1324 . 1326 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1327 "Network Service Header (NSH)", RFC 8300, 1328 DOI 10.17487/RFC8300, January 2018, 1329 . 1331 Authors' Addresses 1333 Francois Clad (editor) 1334 Cisco Systems, Inc. 1335 France 1337 Email: fclad@cisco.com 1338 Xiaohu Xu (editor) 1339 Alibaba 1341 Email: xiaohu.xxh@alibaba-inc.com 1343 Clarence Filsfils 1344 Cisco Systems, Inc. 1345 Belgium 1347 Email: cf@cisco.com 1349 Daniel Bernier 1350 Bell Canada 1351 Canada 1353 Email: daniel.bernier@bell.ca 1355 Cheng Li 1356 Huawei 1358 Email: chengli13@huawei.com 1360 Bruno Decraene 1361 Orange 1362 France 1364 Email: bruno.decraene@orange.com 1366 Shaowen Ma 1367 Juniper 1369 Email: mashaowen@gmail.com 1371 Chaitanya Yadlapalli 1372 AT&T 1373 USA 1375 Email: cy098d@att.com 1376 Wim Henderickx 1377 Nokia 1378 Belgium 1380 Email: wim.henderickx@nokia.com 1382 Stefano Salsano 1383 Universita di Roma "Tor Vergata" 1384 Italy 1386 Email: stefano.salsano@uniroma2.it