idnits 2.17.1 draft-ietf-spring-sr-service-programming-03.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 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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 1378: '...e defined in this document. SHOULD be...' RFC 2119 keyword, line 1379: '...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 (September 08, 2020) is 1319 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 1261 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-18 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-05 == Outdated reference: A later version (-09) exists of draft-xu-mpls-payload-protocol-identifier-06 Summary: 2 errors (**), 0 flaws (~~), 5 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: March 12, 2021 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 Mellanox 16 C. Yadlapalli 17 AT&T 18 W. Henderickx 19 Nokia 20 S. Salsano 21 Universita di Roma "Tor Vergata" 22 September 08, 2020 24 Service Programming with Segment Routing 25 draft-ietf-spring-sr-service-programming-03 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 IPv6 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 March 12, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 23 81 6.2.1. SR-MPLS Pseudocode . . . . . . . . . . . . . . . . . 24 82 6.2.2. SRv6 Pseudocode . . . . . . . . . . . . . . . . . . . 24 83 6.3. Shared Memory SR Proxy . . . . . . . . . . . . . . . . . 25 84 6.4. Masquerading SR Proxy . . . . . . . . . . . . . . . . . . 25 85 6.4.1. SRv6 Masquerading Proxy Pseudocode . . . . . . . . . 27 86 6.4.2. Destination NAT Flavor . . . . . . . . . . . . . . . 28 87 6.4.3. Caching Flavor . . . . . . . . . . . . . . . . . . . 28 88 7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 7.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 29 90 7.2. IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 30 91 7.2.1. SRH TLV Objects . . . . . . . . . . . . . . . . . . . 30 92 7.2.2. SRH Tag . . . . . . . . . . . . . . . . . . . . . . . 31 93 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 31 94 8.1. SR-Aware Services . . . . . . . . . . . . . . . . . . . . 32 95 8.2. Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 32 96 9. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 32 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 98 10.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 33 99 10.2. Segment Routing Header TLVs . . . . . . . . . . . . . . 33 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 101 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 102 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 104 14.1. Normative References . . . . . . . . . . . . . . . . . . 35 105 14.2. Informative References . . . . . . . . . . . . . . . . . 36 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 108 1. Introduction 110 Segment Routing (SR) [RFC8402] is an architecture based on the source 111 routing 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 Virtual Network Functions (VNFs) or 117 physical service appliances 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) [I-D.ietf-spring-srv6-network-programming] 128 supports metadata transportation in the Segment Routing Header 129 [I-D.ietf-6man-segment-routing-header], either natively in the tag 130 field or with extensions such as TLVs. 132 This document describes how a service can be associated with a SID, 133 including legacy services with no SR capabilities, and how these 134 service SIDs are integrated within an SR policy. The definition of 135 an SR Policy and the traffic steering mechanisms are covered in 136 [I-D.ietf-spring-segment-routing-policy] and hence outside the scope 137 of this document. 139 The definition of control plane components, such as service segment 140 discovery, is outside the scope of this data plane document. For 141 reference, the option of using BGP extensions to support SR service 142 programming is proposed in [I-D.dawra-idr-bgp-sr-service-chaining]. 144 2. Terminology 146 This document leverages the terminology proposed in [RFC8402], 147 [RFC8660], [I-D.ietf-6man-segment-routing-header], 148 [I-D.ietf-spring-srv6-network-programming] and 149 [I-D.ietf-spring-segment-routing-policy]. It also introduces the 150 following new terms. 152 Service segment: A segment associated with a service. The service 153 may either run on a physical appliance or in a virtual environment 154 such as a virtual machine or container. 156 SR-aware service: A service that is fully capable of processing SR 157 traffic. An SR-aware service can be directly associated with a 158 service segment. 160 SR-unaware service: A service that is unable to process SR traffic or 161 may behave incorrectly due to presence of SR information in the 162 packet headers. An SR-unaware service can be associated with a 163 service segment through an SR proxy function. 165 3. Classification and Steering 167 Classification and steering mechanisms are defined in section 8 of 168 [I-D.ietf-spring-segment-routing-policy] and are independent from the 169 purpose of the SR policy. From the perspective of a headend node 170 classifying and steering traffic into an SR policy, there is no 171 difference whether this policy contains IGP, BGP, peering, VPN or 172 service segments, or any combination of these. 174 As documented in the above reference, traffic is classified when 175 entering an SR domain. The SR policy headend may, depending on its 176 capabilities, classify the packets on a per-destination basis, via 177 simple FIB entries, or apply more complex policy routing rules 178 requiring to look deeper into the packet. These rules are expected 179 to support basic policy routing such as 5-tuple matching. In 180 addition, the IPv6 SRH tag field defined in 181 [I-D.ietf-6man-segment-routing-header] can be used to identify and 182 classify packets sharing the same set of properties. Classified 183 traffic is then steered into the appropriate SR policy and forwarded 184 as per the SID-list(s) of the active candidate path. 186 SR traffic can be re-classified by an SR endpoint along the original 187 SR policy (e.g., DPI service) or a transit node intercepting the 188 traffic. This node is the head-end of a new SR policy that is 189 imposed onto the packet, either as a stack of MPLS labels or as an 190 IPv6 SRH. 192 4. Service Segments 194 In the context of this document, the term service refers to a 195 physical appliance running on dedicated hardware, a virtualized 196 service inside an isolated environment such as a Virtual Machine 197 (VM), container or namespace, or any process running on a compute 198 element. A service may also comprise multiple sub-components running 199 in different processes or containers. Unless otherwise stated, this 200 document does not make any assumption on the type or execution 201 environment of a service. 203 The execution of a service can be integrated as part of an SR policy 204 by assigning a segment identifier, or SID, to the service and 205 including this service SID in the SR policy SID-list. Such a service 206 SID may be of local or global significance. In the former case, 207 other segments, such as prefix or adjacency segments, can be used to 208 steer the traffic up to the node where the service segment is 209 instantiated. In the latter case, the service is directly reachable 210 from anywhere in the routing domain. This is realized with SR-MPLS 211 by assigning a SID from the global label block 212 ([I-D.ietf-spring-segment-routing-mpls]), or with SRv6 by advertising 213 the SID locator in the routing protocol 214 ([I-D.ietf-spring-srv6-network-programming]). It is up to the 215 network operator to define the scope and reachability of each service 216 SID. This decision can be based on various considerations such as 217 infrastructure dynamicity, available control plane or orchestration 218 system capabilities. 220 This document categorizes services in two types, depending on whether 221 they are able to behave properly in the presence of SR information or 222 not. These are respectively named SR-aware and SR-unaware services. 224 4.1. SR-Aware Services 226 An SR-aware service can process the SR information in the packets it 227 receives. This means being able to identify the active segment as a 228 local instruction and move forward in the segment list, but also that 229 the service's own behavior is not hindered due to the presence of SR 230 information. For example, an SR-aware firewall filtering SRv6 231 traffic based on its final destination must retrieve that information 232 from the last entry in the SRH rather than the Destination Address 233 field of the IPv6 header. 235 An SR-aware service is associated with a locally instantiated service 236 segment, which is used to steer traffic through it. 238 If the service is configured to intercept all the packets passing 239 through the appliance, the underlying routing system only has to 240 implement a default SR endpoint behavior (e.g., SR-MPLS node segment 241 or SRv6 End behavior), and the corresponding SID will be used to 242 steer traffic through the service. 244 If the service requires the packets to be directed to a specific 245 virtual interface, networking queue or process, a dedicated SR 246 behavior may be required to steer the packets to the appropriate 247 location. The definition of such service-specific functions is out 248 of the scope of this document. 250 SR-aware services also enable advanced network programming 251 functionalities such as conditional branching and jumping to 252 arbitrary SIDs in the segment list. In addition, SRv6 provides 253 several ways of passing and exchanging information between services 254 (e.g., SID arguments, tag field and TLVs). An example scenario 255 involving these features is described in [IFIP18], which discusses 256 the implementation of an SR-aware Intrusion Detection System. 258 Examples of SR-aware services are provided in section Section 8.1. 260 4.2. SR-Unaware Services 262 Any service that does not meet the above criteria for SR-awareness is 263 considered as SR-unaware. 265 An SR-unaware service is not able to process the SR information in 266 the traffic that it receives. It may either drop the traffic or take 267 erroneous decisions due to the unrecognized routing information. In 268 order to include such services in an SR policy, it is thus required 269 to remove the SR information as well as any other encapsulation 270 header before the service receives the packet, or to alter it in such 271 a way that the service can correctly process the packet. 273 In this document, we define the concept of an SR proxy as an entity, 274 separate from the service, that performs these modifications and 275 handle the SR processing on behalf of a service. The SR proxy can 276 run as a separate process on the service appliance, on a virtual 277 switch or router on the compute node or on a different host. 279 An SR-unaware service is associated with a service segment 280 instantiated on the SR proxy, which is used to steer traffic through 281 the service. Section 6 describes several SR proxy behaviors to 282 handle the encapsulation headers and SR information under various 283 circumstances. 285 5. SR Service Policies 287 An SR service policy is an SR policy, as defined in 288 [I-D.ietf-spring-segment-routing-policy], that includes at least one 289 service. This service is represented in the SID-list by its 290 associated service SID. In case the policy should include several 291 services, the service traversal order is indicated by the relative 292 position of each service SID in the SID-list. Using the mechanisms 293 described in [I-D.ietf-spring-segment-routing-policy], it is possible 294 to load balance the traffic over several services, or instances of 295 the same service, by associating with the SR service policy a 296 weighted set of SID-lists, each containing a possible sequence of 297 service SIDs to be traversed. Similarly, several candidate paths can 298 be specified for the SR service policy, each with its own set of SID- 299 lists, for resiliency purposes. 301 Furthermore, binding SIDs (BSIDs) can be leveraged in the context of 302 service policies to reduce the number of SIDs imposed by the headend, 303 provide opacity between domains and improve scalability, as described 304 in [I-D.filsfils-spring-sr-policy-considerations]. For example, a 305 network operator may want a policy in its core domain to include 306 services that are running in one of its datacenters. One option is 307 to define an SR policy at ingress edge of the core domain that 308 explicitly includes all the SIDs needed to steer the traffic through 309 the core and in the DC, but that may result in a long SID-list and 310 requires to update the ingress edge configuration every time the DC 311 part of the policy is modified. Alternatively, a separate policy can 312 be defined at the ingress edge of the datacenter with only the SIDs 313 that needs to be executed there and its BSID included in the core 314 domain policy. That BSID remains stable when the DC policy is 315 modified and can even be shared among several core domain policies 316 that would require the same type of processing in the DC. 318 This section describes how services can be integrated within an SR- 319 MPLS or SRv6 service policy. 321 +------------------------------------------+ 322 | SR network | 323 | | 324 +----+----+ +---------+ +----+-----+ 325 | H +----------+ S +-----------+ E | 326 |(headend)| |(service)| |(endpoint)| 327 +----+----+ +---------+ +----+-----+ 328 | =====================================> | 329 | P1(H,E,C) | 330 +------------------------------------------+ 332 Figure 1: SR service policy 334 Figure 1 illustrates a basic SR service policy instantiated on a 335 headend node H towards an endpoint E and traversing a service S. The 336 SR policy may also include additional requirements, such as traffic 337 engineering or VPN. On the head-end H, the SR policy P1 is created 338 with a color C and endpoint E and associated with an SR path that can 339 either be explicitly configured, dynamically computed on H or 340 provisioned by a network controller. 342 In its most basic form, the SR policy P1 would be resolved into the 343 SID-list < SID(S), SID(E) >. This is assuming that SID(S) and SID(E) 344 are directly reachable from H and S, respectively, and that the 345 forwarding path meets the policy requirement. However, depending on 346 the dataplane and the segments available in the network, additional 347 SIDs may be required to enforce the SR policy. 349 This model applies regardless of the SR-awareness of the service. If 350 it is SR-unaware, then S simply represents the proxy that takes care 351 of transmitting the packet to the actual service. 353 Traffic can then be steered into this policy using any of the 354 mechanisms described in [I-D.ietf-spring-segment-routing-policy]. 356 The following subsections describe the specificities of each SR 357 dataplane. 359 5.1. SR-MPLS Data Plane 360 +-----------------------------------------------+ 361 | SR-MPLS network | 362 | | 363 +----+----+ ------> +---------+ ------> +----+-----+ 364 | H +-------------+ S +-------------+ E | 365 |(headend)| |(service)| |(endpoint)| 366 +----+----+ +---------+ +----+-----+ 367 | (1) (2) (3) (4) | 368 |+---------+ +---------+ +---------+ +---------+| 369 || ... | | L(S) | | ... | | L(E) || 370 |+---------+ +---------+ +---------+ +---------+| 371 || L(S) | | ... | | L(E) | |Inner pkt|| 372 |+---------+ +---------+ +---------+ +---------+| 373 || ... | | L(E) | |Inner pkt| | 374 |+---------+ +---------+ +---------+ | 375 || L(E) | |Inner pkt| | 376 |+---------+ +---------+ | 377 ||Inner pkt| | 378 |+---------+ | 379 +-----------------------------------------------+ 381 Figure 2: Packet walk in an SR-MPLS network 383 In an SR-MPLS network, the SR policy SID-list is encoded as a stack 384 of MPLS labels[I-D.ietf-spring-segment-routing-mpls] and pushed on 385 top of the packet. 387 In the example shown on Figure 2, the SR policy should steer the 388 traffic from the head-end H to the endpoint E via a service S. This 389 translates into an MPLS label stack that includes at least a label 390 L(S) associated to service S and a label L(E) associated to the 391 endpoint E. The label stack may also include additional intermediate 392 SIDs if these are required for traffic engineering (e.g., to encode a 393 low latency path between H and S and / or between S and E) or simply 394 for reachability purposes. Indeed, the service SID L(S) may be taken 395 from the global or local SID block of node S and, in the latter case, 396 one or more SIDs might be needed before L(S) in order for the packet 397 to reach node S (e.g., a prefix-SID of S), where L(S) can be 398 interpreted. The same applies for the SID L(E) at the SR policy 399 endpoint. 401 Special consideration must be taken into account when using Local 402 SIDs for service identification due to increased label stack depth 403 and the associated impacts. 405 When the packet arrives at S, this node determines the MPLS payload 406 type and the appropriate behavior for processing the packet based on 407 the semantic locally associated to the top label L(S). If S is an 408 SR-aware service, the SID L(S) may provide additional context or 409 indication on how to process the packet (e.g., a firewall SID may 410 indicate which rule set should be applied onto the packet). If S is 411 a proxy in front of an SR-unaware service, L(S) indicates how and to 412 which service attached to this proxy the packet should be 413 transmitted. At some point in the process, L(S) is also popped from 414 the label stack in order to expose the next SID, which may be L(E) or 415 another intermediate SID. 417 5.2. SRv6 Data Plane 419 +-----------------------------------------------+ 420 | SRv6 network | 421 | | 422 +----+----+ ------> +---------+ ------> +----+-----+ 423 | H +-------------+ S +-------------+ E | 424 |(headend)| |(service)| |(endpoint)| 425 +----+----+ +---------+ +----+-----+ 426 | (1) (2) (3) (4) | 427 |+---------+ +---------+ +---------+ +---------+| 428 ||IP6(H,..)| |IP6(H, S)| |IP6(H,..)| |IP6(H, E)|| 429 |+---------+ +---------+ +---------+ +---------+| 430 ||SRH(E,..,| |SRH(E,..,| |SRH(E,..,| |SRH(E,..,|| 431 || S,..;| | S,..;| | S,..;| | S,..;|| 432 || SL=i)| | SL=j)| | SL=k)| | SL=0)|| 433 |+---------+ +---------+ +---------+ +---------+| 434 ||Inner pkt| |Inner pkt| |Inner pkt| |Inner pkt|| 435 |+---------+ +---------+ +---------+ +---------+| 436 +-----------------------------------------------+ 438 Figure 3: Packet walk in an SRv6 network 440 In an SRv6 network, the SR Policy is encoded into the packet as an 441 IPv6 header possibly followed by a Segment Routing Header (SRH) 442 [I-D.ietf-6man-segment-routing-header]. 444 In the example shown on Figure 3, the SR policy should steer the 445 traffic from the head-end H to the endpoint E via a service S. This 446 translates into Segment-List that includes at least a segment SID(S) 447 to the service, or service proxy, S and a segment SID(E) to the 448 endpoint E. The Segment-List may also include additional 449 intermediate SIDs if these are required for traffic engineering 450 (e.g., the encode a low latency path between H and S and / or between 451 S and E) or simply for reachability purposes. Indeed, the service 452 SID locator may or may not be advertised in the routing protocol and, 453 in the latter case, one or more SIDs might be needed before SID(S) in 454 order to bring the packet up to node S, where SID(S) can be 455 interpreted. The same applies for the segment SID(E) at the SR 456 policy endpoint. 458 When the packet arrives at S, this node determines how to process the 459 packet based on the semantic locally associated to the active segment 460 SID(S). If S is an SR-aware service, then SID(S) may provide 461 additional context or indication on how to process the packet (e.g., 462 a firewall SID may indicate which rule set should be applied onto the 463 packet). If S is a proxy in front of an SR-unaware service, SID(S) 464 indicates how and to which service attached to this proxy the packet 465 should be transmitted. At some point in the process, the SRv6 End 466 function is also applied in order to make the next SID, which may be 467 SID(E) or another intermediate SID, active. 469 The "Inner pkt" on Figure 3 represents the SRv6 payload, which may be 470 an encapsulated IP packet, an Ethernet frame or a transport-layer 471 payload, for example. 473 6. SR Proxy Behaviors 475 This section describes several SR proxy behaviors designed to enable 476 SR service programming through SR-unaware services. A system 477 implementing one of these behaviors may handle the SR processing on 478 behalf of an SR-unaware service and allows the service to properly 479 process the traffic that is steered through it. 481 A service may be located at any hop in an SR policy, including the 482 last segment. However, the SR proxy behaviors defined in this 483 section are dedicated to supporting SR-unaware services at 484 intermediate hops in the segment list. In case an SR-unaware service 485 is at the last segment, it is sufficient to ensure that the SR 486 information is ignored (IPv6 routing extension header with Segments 487 Left equal to 0) or removed before the packet reaches the service 488 (MPLS PHP, SRv6 decapsulation behavior or PSP flavor). 490 As illustrated on Figure 4, the generic behavior of an SR proxy has 491 two parts. The first part is in charge of passing traffic from the 492 network to the service. It intercepts the SR traffic destined for 493 the service via a locally instantiated service segment, modifies it 494 in such a way that it appears as non-SR traffic to the service, then 495 sends it out on a given interface, IFACE-OUT, connected to the 496 service. The second part receives the traffic coming back from the 497 service on IFACE-IN, restores the SR information and forwards it 498 according to the next segment in the list. IFACE-OUT and IFACE-IN 499 are respectively the proxy interface used for sending traffic to the 500 service and the proxy interface that receives the traffic coming back 501 from the service. These can be physical interfaces or sub-interfaces 502 (VLANs) and, unless otherwise stated, IFACE-OUT and IFACE-IN can 503 represent the same interface. 505 +----------------------------+ 506 | | 507 | Service | 508 | | 509 +----------------------------+ 510 ^ Non SR | 511 | traffic | 512 | v 513 +-----------+----------+ 514 +--| IFACE OUT | IFACE IN |--+ 515 SR traffic | +-----------+----------+ | SR traffic 516 ---------->| SR proxy |----------> 517 | | 518 +----------------------------+ 520 Figure 4: Generic SR proxy 522 In the next subsections, the following SR proxy mechanisms are 523 defined: 525 o Static proxy 527 o Dynamic proxy 529 o Shared-memory proxy 531 o Masquerading proxy 533 Each mechanism has its own characteristics and constraints, which are 534 summarized in the below table. It is up to the operator to select 535 the best one based on the proxy node capabilities, the service 536 behavior and the traffic type. It is also possible to use different 537 proxy mechanisms within the same service policy. 539 +-----+-----+-----+-----+ 540 | | | | M | 541 | | | S | a | 542 | | | h | s | 543 | | | a | q | 544 | | | r | u | 545 | | D | e | e | 546 | S | y | d | r | 547 | t | n | | a | 548 | a | a | m | d | 549 | t | m | e | i | 550 | i | i | m | n | 551 | c | c | . | g | 552 +---------------------------------------+-----+-----+-----+-----+ 553 | | SR-MPLS | Y | Y | Y | - | 554 | | | | | | | 555 | SR flavors | Inline SRv6 | P | P | P | Y | 556 | | | | | | | 557 | | SRv6 encapsulation | Y | Y | Y | - | 558 +----------------+----------------------+-----+-----+-----+-----+ 559 | Chain agnostic configuration | N | N | Y | Y | 560 +---------------------------------------+-----+-----+-----+-----+ 561 | Transparent to chain changes | N | Y | Y | Y | 562 +----------------+----------------------+-----+-----+-----+-----+ 563 | | DA modification | Y | Y | Y | NAT | 564 | | | | | | | 565 | | Payload modification | Y | Y | Y | Y | 566 | | | | | | | 567 |Service support | Packet generation | Y | Y |cache|cache| 568 | | | | | | | 569 | | Packet deletion | Y | Y | Y | Y | 570 | | | | | | | 571 | | Packet re-ordering | Y | Y | Y | Y | 572 | | | | | | | 573 | | Transport endpoint | Y | Y |cache|cache| 574 +----------------+----------------------+-----+-----+-----+-----+ 575 | | Ethernet | Y | Y | Y | - | 576 | Supported | | | | | | 577 | traffic | IPv4 | Y | Y | Y | - | 578 | | | | | | | 579 | | IPv6 | Y | Y | Y | Y | 580 +----------------+----------------------+-----+-----+-----+-----+ 582 Figure 5: SR proxy summary 584 Note: The use of a shared memory proxy requires both the service 585 (VNF) and the proxy to be running on the same node. 587 6.1. Static SR Proxy 589 The static proxy is an SR endpoint behavior for processing SR-MPLS or 590 SRv6 encapsulated traffic on behalf of an SR-unaware service. This 591 proxy thus receives SR traffic that is formed of an MPLS label stack 592 or an IPv6 header on top of an inner packet, which can be Ethernet, 593 IPv4 or IPv6. 595 A static SR proxy segment is associated with the following mandatory 596 parameters 598 o INNER-TYPE: Inner packet type 600 o NH-ADDR: Next hop Ethernet address (only for inner type IPv4 and 601 IPv6) 603 o IFACE-OUT: Local interface for sending traffic towards the service 605 o IFACE-IN: Local interface receiving the traffic coming back from 606 the service 608 o CACHE: SR information to be attached on the traffic coming back 609 from the service, including at least 611 * CACHE.SA: IPv6 source address (SRv6 only) 613 * CACHE.LIST: Segment list expressed as MPLS labels or IPv6 614 address 616 A static SR proxy segment is thus defined for a specific service, 617 inner packet type and cached SR information. It is also bound to a 618 pair of directed interfaces on the proxy. These may be both 619 directions of a single interface, or opposite directions of two 620 different interfaces. The latter is recommended in case the service 621 is to be used as part of a bi-directional SR service policy. If the 622 proxy and the service both support 802.1Q, IFACE-OUT and IFACE-IN can 623 also represent sub-interfaces. 625 The first part of this behavior is triggered when the proxy node 626 receives a packet whose active segment matches a segment associated 627 with the static proxy behavior. It removes the SR information from 628 the packet then sends it on a specific interface towards the 629 associated service. This SR information corresponds to the full 630 label stack for SR-MPLS or to the encapsulation IPv6 header with any 631 attached extension header in the case of SRv6. 633 The second part is an inbound policy attached to the proxy interface 634 receiving the traffic returning from the service, IFACE-IN. This 635 policy attaches to the incoming traffic the cached SR information 636 associated with the SR proxy segment. If the proxy segment uses the 637 SR-MPLS data plane, CACHE contains a stack of labels to be pushed on 638 top of the packets. With the SRv6 data plane, CACHE is defined as a 639 source address, an active segment and an optional SRH (tag, segments 640 left, segment list and metadata). The proxy encapsulates the packets 641 with an IPv6 header that has the source address, the active segment 642 as destination address and the SRH as a routing extension header. 643 After the SR information has been attached, the packets are forwarded 644 according to the active segment, which is represented by the top MPLS 645 label or the IPv6 Destination Address. An MPLS TTL or IPv6 Hop Limit 646 value may also be configured in CACHE. If it is not, the proxy 647 should set these values according to the node's default setting for 648 MPLS or IPv6 encapsulation. 650 In this scenario, there are no restrictions on the operations that 651 can be performed by the service on the stream of packets. It may 652 operate at all protocol layers, terminate transport layer 653 connections, generate new packets and initiate transport layer 654 connections. This behavior may also be used to integrate an 655 IPv4-only service into an SRv6 policy. However, a static SR proxy 656 segment can be used in only one service policy at a time. As opposed 657 to most other segment types, a static SR proxy segment is bound to a 658 unique list of segments, which represents a directed SR service 659 policy. This is due to the cached SR information being defined in 660 the segment configuration. This limitation only prevents multiple 661 segment lists from using the same static SR proxy segment at the same 662 time, but a single segment list can be shared by any number of 663 traffic flows. Besides, since the returning traffic from the service 664 is re-classified based on the incoming interface, an interface can be 665 used as receiving interface (IFACE-IN) only for a single SR proxy 666 segment at a time. In the case of a bi-directional SR service 667 policy, a different SR proxy segment and receiving interface are 668 required for the return direction. 670 The static proxy behavior may also be used for sending traffic 671 through "bump in the wire" services that are transparent to the IP 672 and Ethernet layers. This type of processing is assumed when the 673 inner traffic type is Ethernet, since the original destination 674 address of the Ethernet frame is preserved when the packet is steered 675 into the SR Policy and likely associated with a node downstream of 676 the policy tail-end. In case the inner type is IP (IPv4 or IPv6), 677 the NH-ADDR parameter may be set to a dummy or broadcast Ethernet 678 address, or simply to the address of the proxy receiving interface 679 (IFACE-IN). 681 6.1.1. SR-MPLS Pseudocode 683 6.1.1.1. Static Proxy for Inner Type Ethernet 685 When processing an MPLS packet whose top label matches a locally 686 instantiated MPLS static proxy SID for Ethernet traffic, the 687 following pseudocode is executed. 689 S01. POP all labels in the MPLS label stack. 690 S02. Submit the frame to the Ethernet module for transmission via 691 interface IFACE-OUT. 693 Figure 6: SID processing for MPLS static proxy (Ethernet) 695 When processing an Ethernet frame received on the interface IFACE-IN 696 and with a destination MAC address that is neither a broadcast 697 address nor matches the address of IFACE-IN, the following pseudocode 698 is executed. 700 S01. Retrieve the CACHE entry associated with IFACE-IN. 701 S02. If the CACHE entry is not empty { 702 S03. Remove the preamble or Frame Check Sequence (FCS). 703 S04. PUSH all labels from the retrieved CACHE entry. 704 S05. Submit the packet to the MPLS module for transmission as per 705 the top label in the MPLS label stack. 706 S06. } 708 Figure 7: Inbound policy for MPLS static proxy (Ethernet) 710 6.1.1.2. Static Proxy for Inner Type IPv4 712 When processing an MPLS packet whose top label matches a locally 713 instantiated MPLS static proxy SID for IPv4 traffic, the following 714 pseudocode is executed. 716 S01. POP all labels in the MPLS label stack. 717 S02. Submit the packet to the IPv4 module for transmission on 718 interface IFACE-OUT via NH-ADDR. 720 Figure 8: SID processing for MPLS static proxy (IPv4) 722 When processing an IPv4 packet received on the interface IFACE-IN and 723 with a destination address that does not match any address of IFACE- 724 IN, the following pseudocode is executed. 726 S01. Retrieve the CACHE entry associated with IFACE-IN. 727 S02. If the CACHE entry is not empty { 728 S03. Decrement the TTL and adjust the checksum accordingly. 729 S04. PUSH all labels from the retrieved CACHE entry. 730 S05. Submit the packet to the MPLS module for transmission as per 731 the top label in the MPLS label stack. 732 S06. } 734 Figure 9: Inbound policy for MPLS static proxy (IPv4) 736 6.1.1.3. Static Proxy for Inner Type IPv6 738 When processing an MPLS packet whose top label matches a locally 739 instantiated MPLS static proxy SID for IPv6 traffic, the following 740 pseudocode is executed. 742 S01. POP all labels in the MPLS label stack. 743 S02. Submit the packet to the IPv6 module for transmission on 744 interface IFACE-OUT via NH-ADDR. 746 Figure 10: SID processing for MPLS static proxy (IPv6) 748 When processing an IPv6 packet received on the interface IFACE-IN and 749 with a destination address that does not match any address of IFACE- 750 IN, the following pseudocode is executed. 752 S01. Retrieve the CACHE entry associated with IFACE-IN. 753 S02. If the CACHE entry is not empty { 754 S03. Decrement the Hop Limit. 755 S04. PUSH all labels from the retrieved CACHE entry. 756 S05. Submit the packet to the MPLS module for transmission as per 757 the top label in the MPLS label stack. 758 S06. } 760 Figure 11: Inbound policy for MPLS static proxy (IPv6) 762 6.1.2. SRv6 Pseudocode 764 6.1.2.1. Static Proxy for Inner Type Ethernet 766 When processing an IPv6 packet matching a FIB entry locally 767 instantiated as an SRv6 static proxy SID for Ethernet traffic, the 768 following pseudocode is executed. 770 S01. When an SRH is processed { 771 S02. If (Segments Left == 0) { 772 S03. Proceed to process the next header in the packet. 773 S04. } 774 S05. If (IPv6 Hop Limit <= 1) { 775 S06. Send an ICMP Time Exceeded message to the Source Address, 776 Code 0 (hop limit exceeded in transit), 777 Interrupt packet processing and discard the packet. 778 S07. } 779 S08. max_last_entry = (Hdr Ext Len / 2) - 1 780 S09. If ((Last Entry > max_last_entry) or 781 (Segments Left > (Last Entry + 1))) { 782 S10. Send an ICMP Parameter Problem message to the Source Address, 783 Code 0 (Erroneous header field encountered), 784 Pointer set to the Segments Left field, 785 Interrupt packet processing and discard the packet. 786 S11. } 787 S12. Decrement Hop Limit by 1. 788 S13. Decrement Segments Left by 1. 789 S14. Copy Segment List[Segments Left] from the SRH to the 790 Destination Address of the IPv6 header. 791 S15. If (Upper-layer header type != 143 (Ethernet)) { 792 S16. Resubmit the packet to the IPv6 module for transmission to 793 the new destination. 794 S17. } 795 S18. Perform IPv6 decapsulation. 796 S19. Submit the frame to the Ethernet module for transmission via 797 interface IFACE-OUT. 798 S20. } 800 Figure 12: SID processing for SRv6 static proxy (Ethernet) 802 S15: 143 (Ethernet) refers to the value assigned by IANA for 803 "Ethernet" in the "Internet Protocol Numbers" registry. 805 When processing the Upper-layer header of a packet matching a FIB 806 entry locally instantiated as an SRv6 static proxy SID for Ethernet 807 traffic, the following pseudocode is executed. 809 S01. If (Upper-layer header type != 143 (Ethernet)) { 810 S02. Process as per [I-D.ietf-spring-srv6-network-programming] Section 4.1.1 811 S03. } 812 S04. Perform IPv6 decapsulation. 813 S05. Submit the frame to the Ethernet module for transmission via 814 interface IFACE-OUT. 816 Figure 13: Upper-layer header processing for SRv6 static proxy 817 (Ethernet) 819 When processing an Ethernet frame received on the interface IFACE-IN 820 and with a destination MAC address that is neither a broadcast 821 address nor matches the address of IFACE-IN, the following pseudocode 822 is executed. 824 S01. Retrieve the CACHE entry associated with IFACE-IN. 825 S02. If the CACHE entry is not empty { 826 S03. Remove the preamble or Frame Check Sequence (FCS). 827 S04. Perform IPv6 encapsulation with an SRH 828 Source Address of the IPv6 header is set to CACHE.SA, 829 Destination Address of the IPv6 header is set to 830 CACHE.LIST[0], 831 Next Header of the SRH is set to 143 (Ethernet), 832 Segment List of the SRH is set to CACHE.LIST. 833 S05. Submit the packet to the IPv6 module for transmission to the 834 next destination. 835 S06. } 837 Figure 14: Inbound policy for SRv6 static proxy (Ethernet) 839 S04: CACHE.LIST[0] represents the first entry in CACHE.LIST. Unless 840 a local configuration indicates otherwise, the SIDs in CACHE.LIST 841 should be encoded in the Segment List field in reversed order, the 842 Segment Left and Last Entry values should be set of the length of 843 CACHE.LIST minus 1. If CACHE.LIST contains a single entry, the SRH 844 can be omitted and the Next Header field of the IPv6 header set to 845 143 (Ethernet). 847 6.1.2.2. Static Proxy for Inner Type IPv4 849 When processing an IPv6 packet matching a FIB entry locally 850 instantiated as an SRv6 static proxy SID for IPv4 traffic, the 851 following pseudocode is executed. 853 S01. When an SRH is processed { 854 S02. If (Segments Left == 0) { 855 S03. Proceed to process the next header in the packet. 856 S04. } 857 S05. If (IPv6 Hop Limit <= 1) { 858 S06. Send an ICMP Time Exceeded message to the Source Address, 859 Code 0 (hop limit exceeded in transit), 860 Interrupt packet processing and discard the packet. 861 S07. } 862 S08. max_last_entry = (Hdr Ext Len / 2) - 1 863 S09. If ((Last Entry > max_last_entry) or 864 (Segments Left > (Last Entry + 1))) { 865 S10. Send an ICMP Parameter Problem message to the Source Address, 866 Code 0 (Erroneous header field encountered), 867 Pointer set to the Segments Left field, 868 Interrupt packet processing and discard the packet. 869 S11. } 870 S12. Decrement Hop Limit by 1. 871 S13. Decrement Segments Left by 1. 872 S14. Copy Segment List[Segments Left] from the SRH to the 873 Destination Address of the IPv6 header. 874 S15. If (Upper-layer header type != 4 (IPv4)) { 875 S16. Resubmit the packet to the IPv6 module for transmission to 876 the new destination. 877 S17. } 878 S18. Perform IPv6 decapsulation. 879 S19. Submit the packet to the IPv4 module for transmission on 880 interface IFACE-OUT via NH-ADDR. 881 S20. } 883 Figure 15: SID processing for SRv6 static proxy (IPv4) 885 When processing the Upper-layer header of a packet matching a FIB 886 entry locally instantiated as an SRv6 static proxy SID for IPv4 887 traffic, the following pseudocode is executed. 889 S01. If (Upper-layer header type != 4 (IPv4)) { 890 S02. Process as per [I-D.ietf-spring-srv6-network-programming] Section 4.1.1 891 S03. } 892 S04. Perform IPv6 decapsulation. 893 S05. Submit the packet to the IPv4 module for transmission on 894 interface IFACE-OUT via NH-ADDR. 896 Figure 16: Upper-layer header processing for SRv6 static proxy (IPv4) 898 When processing an IPv4 packet received on the interface IFACE-IN and 899 with a destination address that does not match any address of IFACE- 900 IN, the following pseudocode is executed. 902 S01. Retrieve the CACHE entry associated with IFACE-IN. 903 S02. If the CACHE entry is not empty { 904 S03. Decrement the TTL and adjust the checksum accordingly. 905 S04. Perform IPv6 encapsulation with an SRH 906 Source Address of the IPv6 header is set to CACHE.SA, 907 Destination Address of the IPv6 header is set to 908 CACHE.LIST[0], 909 Next Header of the SRH is set to 4 (IPv4), 910 Segment List of the SRH is set to CACHE.LIST. 911 S05. Submit the packet to the IPv6 module for transmission to the 912 next destination. 913 S06. } 915 Figure 17: Inbound policy for SRv6 static proxy (IPv4) 917 S04: CACHE.LIST[0] represents the first entry in CACHE.LIST. Unless 918 a local configuration indicates otherwise, the SIDs in CACHE.LIST 919 should be encoded in the Segment List field in reversed order, the 920 Segment Left and Last Entry values should be set of the length of 921 CACHE.LIST minus 1. If CACHE.LIST contains a single entry, the SRH 922 can be omitted and the Next Header field of the IPv6 header set to 4 923 (IPv4). 925 6.1.2.3. Static Proxy for Inner Type IPv6 927 When processing an IPv6 packet matching a FIB entry locally 928 instantiated as an SRv6 static proxy SID for IPv6 traffic, the 929 following pseudocode is executed. 931 S01. When an SRH is processed { 932 S02. If (Segments Left == 0) { 933 S03. Proceed to process the next header in the packet. 934 S04. } 935 S05. If (IPv6 Hop Limit <= 1) { 936 S06. Send an ICMP Time Exceeded message to the Source Address, 937 Code 0 (hop limit exceeded in transit), 938 Interrupt packet processing and discard the packet. 939 S07. } 940 S08. max_last_entry = (Hdr Ext Len / 2) - 1 941 S09. If ((Last Entry > max_last_entry) or 942 (Segments Left > (Last Entry + 1))) { 943 S10. Send an ICMP Parameter Problem message to the Source Address, 944 Code 0 (Erroneous header field encountered), 945 Pointer set to the Segments Left field, 946 Interrupt packet processing and discard the packet. 947 S11. } 948 S12. Decrement Hop Limit by 1. 949 S13. Decrement Segments Left by 1. 950 S14. Copy Segment List[Segments Left] from the SRH to the 951 Destination Address of the IPv6 header. 952 S15. If (Upper-layer header type != 41 (IPv6)) { 953 S16. Resubmit the packet to the IPv6 module for transmission to 954 the new destination. 955 S17. } 956 S18. Perform IPv6 decapsulation. 957 S19. Submit the packet to the IPv6 module for transmission on 958 interface IFACE-OUT via NH-ADDR. 959 S20. } 961 Figure 18: SID processing for SRv6 static proxy (IPv6) 963 When processing the Upper-layer header of a packet matching a FIB 964 entry locally instantiated as an SRv6 static proxy SID for IPv6 965 traffic, the following pseudocode is executed. 967 S01. If (Upper-layer header type != 41 (IPv6)) { 968 S02. Process as per [I-D.ietf-spring-srv6-network-programming] Section 4.1.1 969 S03. } 970 S04. Perform IPv6 decapsulation. 971 S05. Submit the packet to the IPv6 module for transmission on 972 interface IFACE-OUT via NH-ADDR. 974 Figure 19: Upper-layer header processing for SRv6 static proxy (IPv6) 976 When processing an IPv6 packet received on the interface IFACE-IN and 977 with a destination address that does not match any address of IFACE- 978 IN, the following pseudocode is executed. 980 S01. Retrieve the CACHE entry associated with IFACE-IN. 981 S02. If the CACHE entry is not empty { 982 S03. Decrement the Hop Limit. 983 S04. Perform IPv6 encapsulation with an SRH 984 Source Address of the IPv6 header is set to CACHE.SA, 985 Destination Address of the IPv6 header is set to 986 CACHE.LIST[0], 987 Next Header of the SRH is set to 41 (IPv6), 988 Segment List of the SRH is set to CACHE.LIST. 989 S05. Submit the packet to the IPv6 module for transmission to the 990 next destination. 991 S06. } 993 Figure 20: Inbound policy for SRv6 static proxy (IPv6) 995 S04: CACHE.LIST[0] represents the first entry in CACHE.LIST. Unless 996 a local configuration indicates otherwise, the SIDs in CACHE.LIST 997 should be encoded in the Segment List field in reversed order, the 998 Segment Left and Last Entry values should be set of the length of 999 CACHE.LIST minus 1. If CACHE.LIST contains a single entry, the SRH 1000 can be omitted and the Next Header field of the (outer) IPv6 header 1001 set to 41 (IPv6). 1003 6.2. Dynamic SR Proxy 1005 The dynamic proxy is an improvement over the static proxy that 1006 dynamically learns the SR information before removing it from the 1007 incoming traffic. The same information can then be re-attached to 1008 the traffic returning from the service. As opposed to the static SR 1009 proxy, no CACHE information needs to be configured. Instead, the 1010 dynamic SR proxy relies on a local caching mechanism on the node 1011 instantiating this segment. 1013 Upon receiving a packet whose active segment matches a dynamic SR 1014 proxy function, the proxy node pops the top MPLS label or applies the 1015 SRv6 End behavior, then compares the updated SR information with the 1016 cache entry for the current segment. If the cache is empty or 1017 different, it is updated with the new SR information. The SR 1018 information is then removed and the inner packet is sent towards the 1019 service. 1021 The cache entry is not mapped to any particular packet, but instead 1022 to an SR service policy identified by the receiving interface (IFACE- 1023 IN). Any non-link-local IP packet or non-local Ethernet frame 1024 received on that interface will be re-encapsulated with the cached 1025 headers as described in Section 6.1. The service may thus drop, 1026 modify or generate new packets without affecting the proxy. 1028 6.2.1. SR-MPLS Pseudocode 1030 The dynamic proxy SR-MPLS pseudocode is obtained by inserting the 1031 following instructions at the beginning of the static SR-MPLS 1032 pseudocode (Section 6.1.1). 1034 S01. If the top label S bit is different from 0 { 1035 S02. Discard the packet. 1036 S03. } 1037 S04. POP the top label. 1038 S05. Copy the IPv6 encapsulation in a CACHE entry associated with the 1039 interface IFACE-IN. 1041 Figure 21: SID processing for MPLS dynamic proxy 1043 S01: As mentioned at the beginning of Section 6, an SR proxy is not 1044 needed to include an SR-unaware service at the end of an SR policy. 1046 S05: An implementation may optimize the caching procedure by copying 1047 information into the cache only if it is different from the current 1048 content of the cache entry. Furthermore, a TTL margin can be 1049 configured for the top label stack entry to prevent constant cache 1050 updates when multiple equal-cost paths with different hop counts are 1051 used towards the SR proxy node. In that case, a TTL difference 1052 smaller than the configured margin should not trigger a cache update 1053 (provided that the labels are the same). 1055 When processing an Ethernet frame, an IPv4 packet or an IPv6 packet 1056 received on the interface IFACE-IN and with a destination address 1057 that does not match any address of IFACE-IN, the pseudocode reported 1058 in Figure 7, Figure 9 or Figure 11, respectively, is executed. 1060 6.2.2. SRv6 Pseudocode 1062 When processing an IPv6 packet matching a FIB entry locally 1063 instantiated as an SRv6 dynamic proxy SID, the same pseudocode as 1064 described in Figure 12, Figure 15 and Figure 18, respectively for 1065 Ethernet, IPv4 and IPv6 traffic, is executed with the following 1066 addition between lines S17 and S18. 1068 (... S17. }) 1069 S17.1. Copy the IPv6 encapsulation in a CACHE entry associated with 1070 the interface IFACE-IN. 1071 (S18. Perform IPv6 decapsulation...) 1073 Figure 22: SID processing for SRv6 dynamic proxy 1075 An implementation may optimize the caching procedure by copying 1076 information into the cache only if it is different from the current 1077 content of the cache entry. A Hop Limit margin can be configured to 1078 prevent constant cache updates when multiple equal-cost paths with 1079 different hop counts are used towards the SR proxy node. In that 1080 case, a Hop Limit difference smaller than the configured margin 1081 should not trigger a cache update. Similarly, the Flow Label value 1082 can be ignored when comparing the current packet IPv6 header with the 1083 cache entry. In this case, the Flow Label should be re-computed by 1084 the proxy node when it restores the IPv6 encapsulation from the cache 1085 entry. 1087 When processing the Upper-layer header of a packet matching a FIB 1088 entry locally instantiated as an SRv6 dynamic proxy SID, process the 1089 packet as per [I-D.ietf-spring-srv6-network-programming] 1090 Section 4.1.1. 1092 When processing an Ethernet frame, an IPv4 packet or an IPv6 packet 1093 received on the interface IFACE-IN and with a destination address 1094 that does not match any address of IFACE-IN, the same pseudocode as 1095 in Figure 14, Figure 17 or Figure 20, respectively, is executed. 1097 6.3. Shared Memory SR Proxy 1099 The shared memory proxy is an SR endpoint behavior for processing SR- 1100 MPLS or SRv6 encapsulated traffic on behalf of an SR-unaware service. 1101 This proxy behavior leverages a shared-memory interface with a 1102 virtualized service (VNF) in order to hide the SR information from an 1103 SR-unaware service while keeping it attached to the packet. We 1104 assume in this case that the proxy and the VNF are running on the 1105 same compute node. A typical scenario is an SR-capable vrouter 1106 running on a container host and forwarding traffic to VNFs isolated 1107 within their respective container. 1109 6.4. Masquerading SR Proxy 1111 The masquerading proxy is an SR endpoint behavior for processing SRv6 1112 traffic on behalf of an SR-unaware service. This proxy thus receives 1113 SR traffic that is formed of an IPv6 header and an SRH on top of an 1114 inner payload. The masquerading behavior is independent from the 1115 inner payload type. Hence, the inner payload can be of any type but 1116 it is usually expected to be a transport layer packet, such as TCP or 1117 UDP. 1119 A masquerading SR proxy segment is associated with the following 1120 mandatory parameters: 1122 o NH-ADDR: Next hop Ethernet address 1123 o IFACE-OUT: Local interface for sending traffic towards the service 1125 o IFACE-IN: Local interface receiving the traffic coming back from 1126 the service 1128 A masquerading SR proxy segment is thus defined for a specific 1129 service and bound to a pair of directed interfaces or sub-interfaces 1130 on the proxy. As opposed to the static and dynamic SR proxies, a 1131 masquerading segment can be present at the same time in any number of 1132 SR service policies and the same interfaces can be bound to multiple 1133 masquerading proxy segments. The only restriction is that a 1134 masquerading proxy segment cannot be the last segment in an SR 1135 service policy. 1137 The first part of the masquerading behavior is triggered when the 1138 proxy node receives an IPv6 packet whose Destination Address matches 1139 a masquerading proxy SID. The proxy inspects the IPv6 extension 1140 headers and substitutes the Destination Address with the last SID in 1141 the SRH attached to the IPv6 header, which represents the final 1142 destination of the IPv6 packet. The packet is then sent out towards 1143 the service. 1145 The service receives an IPv6 packet whose source and destination 1146 addresses are respectively the original source and final destination. 1147 It does not attempt to inspect the SRH, as RFC8200 specifies that 1148 routing extension headers are not examined or processed by transit 1149 nodes. Instead, the service simply forwards the packet based on its 1150 current Destination Address. In this scenario, we assume that the 1151 service can only inspect, drop or perform limited changes to the 1152 packets. For example, Intrusion Detection Systems, Deep Packet 1153 Inspectors and non-NAT Firewalls are among the services that can be 1154 supported by a masquerading SR proxy. Flavors of the masquerading 1155 behavior are defined in Section 6.4.2 and Section 6.4.3 to support a 1156 wider range of services. 1158 The second part of the masquerading behavior, also called de- 1159 masquerading, is an inbound policy attached to the proxy interface 1160 receiving the traffic returning from the service, IFACE-IN. This 1161 policy inspects the incoming traffic and triggers a regular SRv6 1162 endpoint processing (End) on any IPv6 packet that contains an SRH. 1163 This processing occurs before any lookup on the packet Destination 1164 Address is performed and it is sufficient to restore the right active 1165 SID as the Destination Address of the IPv6 packet. 1167 6.4.1. SRv6 Masquerading Proxy Pseudocode 1169 Masquerading: When processing an IPv6 packet matching a FIB entry 1170 locally instantiated as an SRv6 masquerading proxy SID, the following 1171 pseudocode is executed. 1173 S01. When an SRH is processed { 1174 S02. If (Segments Left == 0) { 1175 S03. Proceed to process the next header in the packet. 1176 S04. } 1177 S05. If (IPv6 Hop Limit <= 1) { 1178 S06. Send an ICMP Time Exceeded message to the Source Address, 1179 Code 0 (hop limit exceeded in transit), 1180 Interrupt packet processing and discard the packet. 1181 S07. } 1182 S08. max_last_entry = (Hdr Ext Len / 2) - 1 1183 S09. If ((Last Entry > max_last_entry) or 1184 (Segments Left > (Last Entry + 1))) { 1185 S10. Send an ICMP Parameter Problem message to the Source Address, 1186 Code 0 (Erroneous header field encountered), 1187 Pointer set to the Segments Left field, 1188 Interrupt packet processing and discard the packet. 1189 S11. } 1190 S12. Decrement Hop Limit by 1. 1191 S13. Decrement Segments Left by 1. 1192 S14. Copy Segment List[0] from the SRH to the Destination Address 1193 of the IPv6 header. 1194 S15. Submit the packet to the IPv6 module for transmission on 1195 interface IFACE-OUT via NH-ADDR. 1196 S16. } 1198 Figure 23: SID processing for SRv6 masquerading proxy 1200 When processing the Upper-layer header of a packet matching a FIB 1201 entry locally instantiated as an SRv6 masquerading proxy SID, process 1202 the packet as per [I-D.ietf-spring-srv6-network-programming] 1203 Section 4.1.1. 1205 De-masquerading: When processing an IPv6 packet received on the 1206 interface IFACE-IN and with a destination address that does not match 1207 any address of IFACE-IN, the following pseudocode is executed. 1209 S01. When an SRH is processed { 1210 S02. If (IPv6 Hop Limit <= 1) { 1211 S03. Send an ICMP Time Exceeded message to the Source Address, 1212 Code 0 (hop limit exceeded in transit), 1213 Interrupt packet processing and discard the packet. 1214 S04. } 1215 S05. If (Segments Left != 0) { 1216 S06. max_last_entry = (Hdr Ext Len / 2) - 1 1217 S07. If ((Last Entry > max_last_entry) or 1218 (Segments Left > Last Entry)) { 1219 S08. Send an ICMP Parameter Problem message to the Source Address, 1220 Code 0 (Erroneous header field encountered), 1221 Pointer set to the Segments Left field, 1222 Interrupt packet processing and discard the packet. 1223 S09. } 1224 S10. Copy Segment List[Segments Left] from the SRH to the 1225 Destination Address of the IPv6 header. 1226 S11. } 1227 S12. Decrement Hop Limit by 1. 1228 S13. Submit the packet to the IPv6 module for transmission to the 1229 next destination. 1230 S14. } 1232 Figure 24: Inbound policy for SRv6 masquerading proxy 1234 6.4.2. Destination NAT Flavor 1236 Services modifying the destination address in the packets they 1237 process, such as NATs, can be supported by reporting the updated 1238 Destination Address back into the Segment List field of the SRH. 1240 The Destination NAT flavor of the SRv6 masquerading proxy is enabled 1241 by adding the following instruction between lines S09 and S10 of the 1242 de-masquerading pseudocode in Figure 24. 1244 (... S09. }) 1245 S09.1. Copy the Destination Address of the IPv6 header to the 1246 Segment List[0] entry of the SRH. 1247 (S10. Copy Segment List[Segments Left] from the SRH to the 1248 Destination Address of the IPv6 header...) 1250 6.4.3. Caching Flavor 1252 Services generating packets or acting as endpoints for transport 1253 connections can be supported by adding a dynamic caching mechanism 1254 similar to the one described in Section 6.2. 1256 The caching flavor of the SRv6 masquerading proxy is enabled by: 1258 o Adding the following instruction between lines S14 and S15 of the 1259 masquerading pseudocode in Figure 23. 1261 (... S14. Copy Segment List[0] from the SRH to the Destination 1262 Address of the IPv6 header. 1263 S14.1. Copy the IPv6 encapsulation in a CACHE entry associated with 1264 the interface IFACE-IN. 1265 (S15. Submit the packet to the IPv6 module for transmission on 1266 interface IFACE-OUT via NH-ADDR.) 1268 o Updating the de-masquerading pseudocode such that, in addition to 1269 the SRH processing in Figure 24, the following pseudocode is 1270 executed when processing an IPv6 packet (received on the interface 1271 IFACE-IN and with a destination address that does not match any 1272 address of IFACE-IN) that does not contain an SRH. 1274 S01. Retrieve the CACHE entry associated with IFACE-IN. 1275 S02. If the CACHE entry is not empty { 1276 S03. If (IPv6 Hop Limit <= 1) { 1277 S04. Send an ICMP Time Exceeded message to the Source Address, 1278 Code 0 (hop limit exceeded in transit), 1279 Interrupt packet processing and discard the packet. 1280 S05. } 1281 S06. Decrement Hop Limit by 1. 1282 S07. Update the IPv6 encapsulation according to the retrieved CACHE 1283 entry. 1284 S08. Submit the packet to the IPv6 module for transmission to the 1285 next destination. 1286 S09. } 1288 7. Metadata 1290 7.1. MPLS Data Plane 1292 Metadata can be carried for SR-MPLS traffic in a Segment Routing 1293 Header inserted between the last MPLS label and the MPLS payload. 1294 When used solely as a metadata container, the SRH does not carry any 1295 segment but only the mandatory header fields, including the tag and 1296 flags, and any TLVs that is required for transporting the metadata. 1298 Since the MPLS encapsulation has no explicit protocol identifier 1299 field to indicate the protocol type of the MPLS payload, how to 1300 indicate the presence of metadata in an MPLS packet is a potential 1301 issue to be addressed. One possible solution is to add the 1302 indication about the presence of metadata in the semantic of the 1303 SIDs. Note that only the SIDs whose behavior involves looking at the 1304 metadata or the MPLS payload would need to include such semantic 1305 (e.g., service segments). Other segments, such as topological 1306 segments, are not affected by the presence of metadata. Another, 1307 more generic, solution is to introduce a protocol identifier field 1308 within the MPLS packet as described in 1309 [I-D.xu-mpls-payload-protocol-identifier]. 1311 7.2. IPv6 Data Plane 1313 7.2.1. SRH TLV Objects 1315 The IPv6 SRH TLV objects are designed to carry all sorts of metadata. 1316 TLV objects can be imposed by the ingress edge router that steers the 1317 traffic into the SR service policy. 1319 An SR-aware service may impose, modify or remove any TLV object 1320 attached to the first SRH, either by directly modifying the packet 1321 headers or via a control channel between the service and its 1322 forwarding plane. 1324 An SR-aware service that re-classifies the traffic and steers it into 1325 a new SR service policy (e.g. DPI) may attach any TLV object to the 1326 new SRH. 1328 Metadata imposition and handling will be further discussed in a 1329 future version of this document. 1331 7.2.1.1. Opaque Metadata TLV 1333 This document defines an SRv6 TLV called Opaque Metadata TLV. This 1334 is a fixed-length container to carry any type of Service Metadata. 1335 No assumption is made by this document on the structure or the 1336 content of the carried metadata. The Opaque Metadata TLV has the 1337 following format: 1339 0 1 2 3 1340 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 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Type | Length | | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1344 | | 1345 | Service Metadata | 1346 | | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 where: 1351 o Type: to be assigned by IANA. 1353 o Length: 14. 1355 o Service Metadata: 14 octets of opaque data. 1357 7.2.1.2. NSH Carrier TLV 1359 This document defines an SRv6 TLV called NSH Carrier TLV. It is a 1360 container to carry Service Metadata in the form of Variable-Length 1361 Metadata as defined in [RFC8300] for NSH MD Type 2. The NSH Carrier 1362 TLV has the following format: 1364 0 1 2 3 1365 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 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Type | Length | Flags | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 // Service Metadata // 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 where: 1374 o Type: to be assigned by IANA. 1376 o Length: the total length of the TLV. 1378 o Flags: 8 bits. No flags are defined in this document. SHOULD be 1379 set to 0 on transmission and MUST be ignored on receipt. 1381 o Service Metadata: a list of Service Metadata TLV as defined in 1382 [RFC8300] for NSH MD Type 2. 1384 7.2.2. SRH Tag 1386 The SRH tag identifies a packet as part of a group or class of 1387 packets [I-D.ietf-6man-segment-routing-header]. 1389 In the context of service programming, this field can be used to 1390 encode basic metadata in the SRH. An example use-case is to leverage 1391 the SRH tag to encode a policy ID. This policy ID can then be used 1392 by an SR-aware function to identify a particular processing policy to 1393 be applied on that packet. 1395 8. Implementation Status 1397 This section is to be removed prior to publishing as an RFC. 1399 8.1. SR-Aware Services 1401 Specific SRv6 support has been implemented for the below open-source 1402 services: 1404 o Iptables (1.6.2 and later) [IPTABLES] 1406 o Nftables (0.8.4 and later) [NFTABLES] 1408 o Snort [SNORT] 1410 In addition, any service relying on the Linux kernel, version 4.10 1411 and later, or FD.io VPP for packet forwarding can be considered as 1412 SR-aware. 1414 8.2. Proxy Behaviors 1416 The static SR proxy is available for SR-MPLS and SRv6 on various 1417 Cisco hardware and software platforms. Furthermore, the following 1418 proxies are available on open-source software. 1420 +-------------+-------------+ 1421 | VPP | Linux | 1422 +---+-----------------------------------+-------------+-------------+ 1423 | M | Static proxy | Available | In progress | 1424 | P | | | | 1425 | L | Dynamic proxy | In progress | In progress | 1426 | S | | | | 1427 | | Shared memory proxy | In progress | In progress | 1428 +---+-----------------------------------+-------------+-------------+ 1429 | | Static proxy | Available | In progress | 1430 | S | | | | 1431 | R | Dynamic proxy | Available | Available | 1432 | v | | | | 1433 | 6 | Shared memory proxy | In progress | In progress | 1434 | | | | | 1435 | | Masquerading proxy | Available | Available | 1436 +---+-----------------------------------+-------------+-------------+ 1438 Figure 25: Open-source implementation status table 1440 9. Related Works 1442 The Segment Routing solution addresses a wide problem that covers 1443 both topological and service policies. The topological and service 1444 instructions can be either deployed in isolation or in combination. 1445 SR has thus a wider applicability than the architecture defined in 1446 [RFC7665]. Furthermore, the inherent property of SR is a stateless 1447 network fabric. In SR, there is no state within the fabric to 1448 recognize a flow and associate it with a policy. State is only 1449 present at the ingress edge of the SR domain, where the policy is 1450 encoded into the packets. This is completely different from other 1451 proposals such as [RFC8300] and the MPLS label swapping mechanism 1452 described in [I-D.ietf-mpls-sfc], which rely on state configured at 1453 every hop of the service chain. 1455 10. IANA Considerations 1457 10.1. SRv6 Endpoint Behaviors 1459 This I-D requests the IANA to allocate, within the "SRv6 Endpoint 1460 Behaviors" sub-registry belonging to the top-level "Segment-routing 1461 with IPv6 dataplane (SRv6) Parameters" registry, the following 1462 allocations: 1464 Value Description Reference 1465 -------------------------------------------------------------- 1466 TBA1-1 End.AN - SR-aware function (native) [This.ID] 1467 TBA1-2 End.AS - Static proxy [This.ID] 1468 TBA1-3 End.AD - Dynamic proxy [This.ID] 1469 TBA1-4 End.AM - Masquerading proxy [This.ID] 1470 TBA1-5 End.AM - Masquerading proxy with NAT [This.ID] 1471 TBA1-6 End.AM - Masquerading proxy with Caching [This.ID] 1472 TBA1-7 End.AM - Masquerading proxy with NAT & [This.ID] 1473 Caching 1475 10.2. Segment Routing Header TLVs 1477 This I-D requests the IANA to allocate, within the "Segment Routing 1478 Header TLVs" registry, the following allocations: 1480 Value Description Reference 1481 ---------------------------------------------- 1482 TBA2-1 Opaque Metadata TLV [This.ID] 1483 TBA2-2 NSH Carrier TLV [This.ID] 1485 11. Security Considerations 1487 The security requirements and mechanisms described in [RFC8402], 1488 [I-D.ietf-6man-segment-routing-header] and 1489 [I-D.ietf-spring-srv6-network-programming] also apply to this 1490 document. 1492 This document does not introduce any new security vulnerabilities. 1494 12. Acknowledgements 1496 The authors would like to thank Thierry Couture, Ketan Talaulikar, 1497 Loa Andersson, Andrew G. Malis, Adrian Farrel, Alexander Vainshtein 1498 and Joel M. Halpern for their valuable comments and suggestions on 1499 the document. 1501 13. Contributors 1503 The following people have contributed to this document: 1505 Pablo Camarillo 1506 Cisco Systems, Inc. 1507 Spain 1509 Email: pcamaril@cisco.com 1511 Bart Peirens 1512 Proximus 1513 Belgium 1515 Email: bart.peirens@proximus.com 1517 Dirk Steinberg 1518 Lapishills Consulting Limited 1519 Cyprus 1521 Email: dirk@lapishills.com 1523 Ahmed AbdelSalam 1524 Cisco Systems, Inc. 1525 Italy 1527 Email: ahabdels@cisco.com 1529 Gaurav Dawra 1530 LinkedIn 1531 United States of America 1533 Email: gdawra@linkedin.com 1535 Stewart Bryant 1536 Futurewei Technologies Inc 1537 Email: stewart.bryant@gmail.com 1539 Hamid Assarpour 1540 Broadcom 1542 Email: hamid.assarpour@broadcom.com 1544 Himanshu Shah 1545 Ciena 1547 Email: hshah@ciena.com 1549 Luis M. Contreras 1550 Telefonica I+D 1551 Spain 1553 Email: luismiguel.contrerasmurillo@telefonica.com 1555 Jeff Tantsura 1556 Individual 1558 Email: jefftant@gmail.com 1560 Martin Vigoureux 1561 Nokia 1563 Email: martin.vigoureux@nokia.com 1565 Jisu Bhattacharya 1566 Cisco Systems, Inc. 1567 United States of America 1569 Email: jisu@cisco.com 1571 14. References 1573 14.1. Normative References 1575 [I-D.ietf-6man-segment-routing-header] 1576 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1577 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1578 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 1579 progress), October 2019. 1581 [I-D.ietf-spring-segment-routing-mpls] 1582 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1583 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1584 data plane", draft-ietf-spring-segment-routing-mpls-22 1585 (work in progress), May 2019. 1587 [I-D.ietf-spring-segment-routing-policy] 1588 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1589 P. Mattes, "Segment Routing Policy Architecture", draft- 1590 ietf-spring-segment-routing-policy-08 (work in progress), 1591 July 2020. 1593 [I-D.ietf-spring-srv6-network-programming] 1594 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1595 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1596 draft-ietf-spring-srv6-network-programming-18 (work in 1597 progress), August 2020. 1599 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1600 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1601 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1602 July 2018, . 1604 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1605 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1606 Routing with the MPLS Data Plane", RFC 8660, 1607 DOI 10.17487/RFC8660, December 2019, 1608 . 1610 14.2. Informative References 1612 [I-D.dawra-idr-bgp-sr-service-chaining] 1613 Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d., 1614 Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F., 1615 and K. Talaulikar, "BGP Control Plane Extensions for 1616 Segment Routing based Service Chaining", draft-dawra-idr- 1617 bgp-sr-service-chaining-02 (work in progress), January 1618 2018. 1620 [I-D.filsfils-spring-sr-policy-considerations] 1621 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1622 P. Mattes, "SR Policy Implementation and Deployment 1623 Considerations", draft-filsfils-spring-sr-policy- 1624 considerations-05 (work in progress), April 2020. 1626 [I-D.ietf-mpls-sfc] 1627 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1628 Forwarding Plane for Service Function Chaining", draft- 1629 ietf-mpls-sfc-07 (work in progress), March 2019. 1631 [I-D.xu-mpls-payload-protocol-identifier] 1632 Xu, X., Assarpour, H., Ma, S., and F. Clad, "MPLS Payload 1633 Protocol Identifier", draft-xu-mpls-payload-protocol- 1634 identifier-06 (work in progress), March 2019. 1636 [IFIP18] Abdelsalam, A., Salsano, S., Clad, F., Camarillo, P., and 1637 C. Filsfils, "SEgment Routing Aware Firewall For Service 1638 Function Chaining scenarios", IFIP Networking conference , 1639 May 2018. 1641 [IPTABLES] 1642 "iptables-1.6.2 changes", February 2018, 1643 . 1646 [NFTABLES] 1647 "nftables-0.8.4 changes", May 2018, 1648 . 1651 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1652 Chaining (SFC) Architecture", RFC 7665, 1653 DOI 10.17487/RFC7665, October 2015, 1654 . 1656 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1657 "Network Service Header (NSH)", RFC 8300, 1658 DOI 10.17487/RFC8300, January 2018, 1659 . 1661 [SNORT] "SR-Snort", March 2018, 1662 . 1664 Authors' Addresses 1666 Francois Clad (editor) 1667 Cisco Systems, Inc. 1668 France 1670 Email: fclad@cisco.com 1672 Xiaohu Xu (editor) 1673 Alibaba 1675 Email: xiaohu.xxh@alibaba-inc.com 1677 Clarence Filsfils 1678 Cisco Systems, Inc. 1679 Belgium 1681 Email: cf@cisco.com 1683 Daniel Bernier 1684 Bell Canada 1685 Canada 1687 Email: daniel.bernier@bell.ca 1689 Cheng Li 1690 Huawei 1692 Email: chengli13@huawei.com 1694 Bruno Decraene 1695 Orange 1696 France 1698 Email: bruno.decraene@orange.com 1700 Shaowen Ma 1701 Mellanox 1703 Email: mashaowen@gmail.com 1704 Chaitanya Yadlapalli 1705 AT&T 1706 USA 1708 Email: cy098d@att.com 1710 Wim Henderickx 1711 Nokia 1712 Belgium 1714 Email: wim.henderickx@nokia.com 1716 Stefano Salsano 1717 Universita di Roma "Tor Vergata" 1718 Italy 1720 Email: stefano.salsano@uniroma2.it