idnits 2.17.1 draft-song-sfc-legacy-sf-mapping-07.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 44 instances of too long lines in the document, the longest one being 2 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 225: '... SFF MUST relay the metadata to the ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 5, 2016) is 2942 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-sfc-control-plane-03 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC working group H. Song 3 Internet-Draft J. You 4 Intended status: Informational L. Yong 5 Expires: October 7, 2016 Y. Jiang 6 L. Dunbar 7 Huawei 8 N. Bouthors 9 Qosmos 10 D. Dolson 11 Sandvine 12 April 5, 2016 14 SFC Header Mapping for Legacy SF 15 draft-song-sfc-legacy-sf-mapping-07 17 Abstract 19 A Service Function Chain (SFC) defines a set of abstract Service 20 Functions (SF) and ordering constraints that must be applied to 21 packets and/or frames selected as a result of classification. One 22 assumption of this document is that legacy service functions can 23 participate in service function chains without having support for the 24 SFC header, or even being aware of it. This document provides a 25 mechanism between an SFC proxy and an SFC-unaware service function 26 (herein termed "legacy SF"), to identify the SFC header associated 27 with a packet that is returned from a legacy SF, without an SFC 28 header being explicitly carried in the wired protocol between SFC 29 proxy and legacy SF. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 7, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. For Transparent Service Functions . . . . . . . . . . . . 6 69 3.1.1. Layer 2 MAC Address . . . . . . . . . . . . . . . . . 6 70 3.1.2. VLAN . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1.3. QinQ . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.4. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.1.5. 5-tuple . . . . . . . . . . . . . . . . . . . . . . . 12 74 3.2. For Non-transparent Service Functions . . . . . . . . . . 12 75 4. Operation Considerations . . . . . . . . . . . . . . . . . . 13 76 4.1. Metadata Consideration . . . . . . . . . . . . . . . . . 15 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 7.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 A Service Function Chain (SFC) [RFC7665] defines a set of abstract 87 service functions and ordering constraints that must be applied to 88 packets and/or frames selected as a result of classification. One 89 assumption of this document is that some service functions may remain 90 as legacy implementations, and they neither have to be aware of the 91 SFC header, nor interpret it. It is a straightforward function for 92 an SFC proxy to remove an SFC header to send a packet to a legacy SF, 93 but it is not obvious what SFC header should be added to packets 94 arriving at the SFC proxy from the legacy SF. 96 This document provides a mechanism between an SFC proxy and a legacy 97 SF, to identify the SFC header associated with a packet that is 98 returned from a legacy SF, without anything in the SFC header being 99 explicitly carried in the wired protocol between SFC proxy and legacy 100 SF. The motivation for supporting legacy SF is that existing service 101 functions don't need to be upgraded to support SFC, removing one 102 barrier to wide adoption of SFC. 104 +----------------+ 105 |SFC-unaware | 106 |Service Function| 107 | (Legacy SF) | 108 +----+----+------+ 109 ^ | 110 | | 111 +----+----+------+ 112 | Switch | 113 +----+----+------+ 114 | | 115 (2)| |(3) 116 | | 117 +----+----V--------+ 118 (1) | SFC | (4) 119 -------->| Proxy +-------> 120 +------------------+ 122 Figure 1: Procedure of a packet processed by a legacy SF 124 The legacy service function (i.e., "SFC-unaware Service Function" in 125 the Figure 1) only handles packets without SFC header, because it 126 does not understand the SFC header. Note that different classes of 127 legacy SF may have varying support for different types of packets 128 with respect to parsing and semantics (e.g., some classes of legacy 129 SF may accept VLAN-tagged traffic; others may not.). 131 This document focuses heavily on legacy SFs that are transparent at 132 layer 2. In particular, we assume the following about layer- 133 2-transparent legacy SFs: 135 1. Traffic is forwarded between pairs of interfaces, such that 136 packets received on the "left" are forwarded on the "right" and 137 vice versa. 139 2. A packet is forwarded between interfaces without modifying the 140 layer 2 header; i.e., neither source MAC nor destination MAC is 141 modified. 143 3. When supported, VLAN-tagged or Q-in-Q packets are forwarded 144 with the original VLAN tag(s) intact (S-tags and C-tags). 146 4. Traffic may be discarded by some functions (e.g., by a 147 firewall). 149 5. Traffic may be injected in either direction by some functions 150 (e.g., extra data coming from a cache, or simply TCP 151 retransmissions). We assume injected traffic relates to a layer 3 152 or layer 4 flow, and the SF clones layer 2 headers from exemplar 153 packets of the same flow. 155 6. Traffic may be modified by some functions at layer 3 (e.g., 156 DSCP marking) or higher layers (e.g., HTTP header enrichment or 157 anonymization). Note that modification can be considered a 158 special case of discarding following by injection. 160 7. Traffic may be reordered by some functions (e.g., due to 161 queuing/scheduling). 163 We leave the legacy SFs which modify the original layer 2 packet 164 headers as an open issue for further study. 166 To support this class of legacy SF, if the payload in the SFC 167 encapsulation is layer 3 traffic, the SFC proxy will extract the 168 layer 3 payload from SFC encapsulation and prepend a new layer 2 169 header before sending the packet to the SF. However if the payload 170 in the SFC encapsulation is layer 2 traffic, the SFC proxy may 171 extract the layer 2 packet from SFC encapsulation, modify the 172 original source MAC address and use the new source MAC address for 173 mapping to the stored SFC and layer 2 headers when the packets are 174 returned to the SFC proxy. This will not impact the SF processing. 175 The SF will send the traffic back after processing. 177 As shown in Figure 1, there are four steps. The SFC proxy receives a 178 packet, and removes its SFC header, which may optionally contain 179 metadata, and store the SFC header locally, and then sends the de- 180 encapsulated packet to the SF. After the SF processes the packet, 181 the packet will be sent back to the SFC proxy. The SFC proxy 182 retrieves the pre-stored SFC header accordingly, determines the SFC 183 header for the next stage of the path and encapsulates the packet 184 with the next SFC header. 186 The key problem contemplated in this document is: what layer 2 header 187 should be put on the packets sent to a legacy SF such that packets 188 returned from the legacy SF can be mapped to the original SFC header? 189 We need to consider the relationship between an SFC path and flows 190 within the path. Should the path act as a qualifier to the flow, or 191 should a flow be allowed to change paths? Below, we assume flows can 192 change path; this means that a given legacy SF cannot handle traffic 193 from more than one routing domain. (Private IP addresses cannot be 194 qualified by the SFC header; different VPNs must use different legacy 195 SFs.) 197 Because we've assumed that a flow can be on multiple paths, or change 198 paths, or if metadata can vary during the life of a flow, we need to 199 ask to what extent packet accuracy matters. If the SFC header used 200 with a flow is changed from one path to another by the classifier, 201 does it matter if packets retain exactly the original SFC header? If 202 the change is to handle routing updates or fail-over then it would be 203 acceptable to put all packets returning from the legacy SF onto the 204 most recently updated header. If metadata is changed, can that 205 update be applied to all packets of a flow, or does it apply to a 206 specific packet? 208 In the case that changes to paths and metadata are considered updates 209 to the flow vs. packet properties, the SFC proxy can find the SFC 210 header based on flow (e.g., the 5-tuple of the returning IP packet). 212 If, in contrast, packet accuracy of SFC headers does matter, (e.g., 213 the metadata says something about the specific packet associated with 214 it), then some form of per-packet bookkeeping must be done by the SFC 215 proxy and the 5-tuple cannot be used for the mapping to retrieve the 216 original SFC header. 218 When packet accuracy does matter, packets injected by the legacy SF 219 pose a fundamental problem. Is there any correct SFC header that can 220 be added? Observation: the same problem exists for a normal (not 221 legacy) SF that wishes to modify or inject a packet. 223 When metadata is sent without any associated payload (congruent 224 metadata) and the associated service function is a legacy one, then 225 SFF MUST relay the metadata to the next hop SFF, without sending the 226 metadata to SFC proxy. For some types of metadata, the metadata 227 should be saved in case it needs to be added to packets injected by 228 the legacy SF. 230 Because the SFC proxy needs to keep dynamic state by storing packet 231 headers, an expiration time should be used for each mapping entry in 232 the SFC proxy. If the SFC header in that entry has not been 233 witnessed or retrieved after the expiration time, the entry will be 234 deleted from the entry table. 236 Observation: if metadata is not used, the number distinct SFC headers 237 is known at configuration time, equivalent to the number of paths 238 configured to pass through the SF. The mappings between SFC headers 239 and layer 2 encodings could be configured at this time vs. at run 240 time. However, if metadata is used, a combinatorial explosion of 241 distinct SFC headers may result, which is a problem for any device 242 attempting to store them for later retrieval. 244 2. Terminology 246 The terminology used in this document is defined below: 248 Legacy SF: A conventional service function that does not support 249 SFC header, i.e. SFC-unaware SF. 251 Transparent SF: A service function that does not change any bit of 252 the original service packet header (Layer 2, layer 3, and layer 4) 253 sent to it, but it may drop packets. 255 Non-transparent SF: A service function that changes some part of 256 the original service packet header sent to it. 258 Original Service Packet: The payload in an SFC encapsulation 259 packet or a packet constructed based on the original payload. 261 SFC Proxy: A network function that operates as an SF node within 262 the SFC architecture while delegating application functions to one 263 or more attached Legacy SFs by acting as an adapter or bridge 264 between the SFC protocol and SF wire protocols understood by the 265 legacy SF. 267 3. Mechanisms 269 The mechanisms used in this document require that each forwarding 270 entity and its connected service functions in the same layer 2 271 network. The following are considerations mainly for transparent 272 SFs. If the original payload packet is a layer 2 packet, and the 273 mapping method used is layer 2 MAC address, then the assumption is 274 that the SF does not need to look into the layer 2 header. If it 275 does, other mechanisms should be used. 277 3.1. For Transparent Service Functions 279 If the service function is transparent to packet headers, the 280 following methods can be used for SFC header mapping. 282 3.1.1. Layer 2 MAC Address 284 The layer 2 MAC address is used to associate a SFC header between SFC 285 proxy and SF; i.e., each SFC header will be assigned a source MAC 286 address on the SFC proxy. If SFC header can be changed per packet, 287 then SFC proxy assigns a new source MAC address for each packet it 288 received, otherwise, it assigns a new MAC address for each unique SFC 289 header that must be applied to returning packets. (It is not 290 necessary to have a unique MAC address for each flow received.) 292 When SFC proxy received the returned packet from the SF, it retrieves 293 the packet's original SFC header by using the source MAC address as a 294 key. And then it encapsulates the packet with that SFC header and 295 sends to the next hop. 297 Open issue: usually the MAC address table size in a switch is no more 298 than 16K. When there is a requirement that per packet metadata needs 299 to be restored to each packet after the packet returns from the SF 300 instance, it may require more MAC addresses than the MAC table size 301 in the switch. This may overflow the MAC table, thus the packet 302 cannot route back to the SFC proxy correctly. 304 An issue with the source-MAC address approach is that there is not 305 symmetry between packets going left-to-right with packets going 306 right-to-left. Such symmetry might be assumed by some legacy SFs. 307 For example, if a layer-2-transparent SF responds to a TCP SYN with a 308 TCP RST, it might do so by reversing the source and destination of 309 the layer 2 header. Such a packet received by the SFC proxy would 310 not result in finding of the correct SFC header. A variation that is 311 symmetric assigns a unique source/destination pair for each unique 312 SFC header. 314 0 1 2 3 315 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 317 Outer Ethernet Header: 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | SF Destination MAC Address | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | SF Destination MAC Address | SFC Proxy Source MAC Address | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | SFC Proxy Source MAC Address | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Ethertype = 0x0800 | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Original IP Payload: 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Original Payload | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 3.1.2. VLAN 337 If the network between the SFC proxy and SF is a layer 2 network, and 338 in the case that an SF needs to look into the MAC address of the 339 packet, then VLAN can be used for the mapping between them. The SFC 340 proxy removes the SFC header and sends the packet to the SF, with 341 encapsulating a certain VLAN ID. It is a new encapsulation, 342 supposing that the legacy App can be configured to accept VLAN-tagged 343 packets and to send them back on the same VLAN. It is assumed that 344 the receiving service function host/VM can support multiple VLANs. 345 The SFC proxy locally maintains the mapping between VLAN ID/direction 346 and the SFC header. 348 When it gets the returned packet from the SF, the SFC proxy removes 349 the VLAN part from the packet and retrieves the corresponding SFC 350 header according to the VLAN ID and the direction of packet travel, 351 and then encapsulates SFC header into that packet before sending to 352 the next service function. Packet direction is required because the 353 SFC header for left-to-right packets is different than the SFC header 354 for right-to-left packets. 356 If metadata is not used, the number of VLAN tags required is exactly 357 the number of SFC paths that pass through the SF, and it can be known 358 at configuration time how many are required. 360 [I-D.dolson-sfc-vlan] describes an approach for service function 361 chaining by using the input interface and VLAN number to select the 362 next output interface and new VLAN number. SF devices that work with 363 the dolson-sfc-vlan scheme will work with the VLAN scheme described 364 here. 366 One open issue with VLAN tag is that if the use case requires per 367 packet metadata, then the address space of VLAN digits cannot be 368 enough. 370 0 1 2 3 371 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 373 Outer Ethernet Header: 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | SFI Destination MAC Address | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | SF Destination MAC Address | SFC Proxy Source MAC Address | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | SFC Proxy Source MAC Address | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 |OptnlEthtype = C-Tag 802.1Q |Outer.VLAN Tag Information | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Ethertype = 0x0800 | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Original IP Payload: 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Original Payload | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 3.1.3. QinQ 395 If the network between the SFC proxy and SF is already a VLAN 396 network, and the SF needs to look into the MAC address, then QinQ is 397 used for the communication between SFC proxy and SF. The SFC proxy 398 removes the SFC header and sends the original traffic to legacy SF 399 with a certain outer VLAN ID. It locally maintains the mapping 400 between outer VLAN ID and the SFC header. 402 If the network between SFC proxy and SF is not a VLAN network, then 403 QinQ can be used for either per flow mapping or per packet mapping, 404 using two layer VLAN fields. Because of the increase in address 405 space, QinQ can be used in two-layer VLAN: outer VLAN-id per flow, 406 and inner VLAN-id per packet. If the network between SFC proxy and 407 SF is a VLAN network, then QinQ can only be used for per flow 408 mapping, using one VLAN field. 410 It is assumed that the receiving service function host/VM can support 411 multiple service VLAN IDs with multiple inner VLAN IDs. 413 0 1 2 3 414 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 416 Outer Ethernet Header: 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | SF Destination MAC Address | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | SF Destination MAC Address | SFC Proxy Source MAC Address | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | SFC Proxy Source MAC Address | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 |OptnlEthtype = S-Tag 802.1Q |Outer.VLAN Tag Information | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 |Ethertype = C-Tag 802.1Q |Inner.VLAN Tag Information | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Ethertype = 0x0800 | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Original IP Payload: 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Original Payload | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 3.1.4. VXLAN 440 If the SFC proxy and SF are already deployed in a QinQ network, then 441 VXLAN [RFC7348] can be used for the mapping, i.e. VNI can be used for 442 the mapping between them. This tunneling technology is only used 443 when the original packet type is at layer 2 and the SF has to look 444 into the layer 2 MAC header. 446 The drawback of this mechanism is that it requires both SFC proxy and 447 SF to support VXLAN. 449 This approach has similar features and drawbacks of the VLAN scheme, 450 but the number of possible VLANs is larger. 452 0 1 2 3 453 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 455 Outer Ethernet Header: 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | SF Destination MAC Address | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |SFI Destination MAC Address | SFC Proxy Source MAC Address | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | SFC Proxy Source MAC Address | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |OptnlEthtype = C-Tag 802.1Q |Outer.VLAN Tag Information | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Ethertype = 0x0800 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Outer IP Header: 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 |Version| IHL |Type of Service| Total Length | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Identification |Flags| Fragment Offset | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |Time to Live |Protocol=17(UDP) | Header Checksum | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Outer Source IPv4 Address | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Outer Destination IPv4 Address | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Outer UDP Header: 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Source Port = xxxx | Dest Port = VXLAN Port | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | UDP Length | UDP Checksum | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 VXLAN Header: 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 |R|R|R|R|I|R|R|R| Reserved | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | VXLAN Network Identifier (VNI) | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 3.1.5. 5-tuple 501 The 5-tuple of an SFC packet can be used as a key to associate an SFC 502 header in the SFC proxy when the 5-tuple is not modified by the 503 legacy SF. The SFC proxy maintains a mapping table for the 5-tuple 504 and the SFC header. When the packet returns from the SF instance, 505 the original SFC header for this packet can be retrieved by inquiring 506 the mapping table using 5-tuple as the key. However, this method may 507 not work in multi-tenant organizations, as such unicity could be 508 Valid only within the scope of a single tenant. So if the SFC is 509 provided as a multi-tenant service, this method would fail. 511 Another similar use case could be that a client and a server use http 512 80 port for transporting different types of data, and if each type 513 has its specific SFC header with metadata, then 5-tuple does not work 514 either. 516 This method cannot support per-packet metadata. 518 3.2. For Non-transparent Service Functions 520 Non transparent service functions including NAT (Network Address 521 Translation), WOC (WAN Optimization Controller) and etc, are more 522 complicated, as they may change any part of the original packet sent 523 to them. It is better to analyze case by case, to utilize a specific 524 field that the SF does not change for the mapping and retrieving the 525 SFC header. We would like to leave it for open discussion. 527 The Figure below shows an example that SFC proxy can learn the 528 behavior of the SF changing the packet. In this example, the 529 following method is used for SFC header mapping. The SF needs to 530 report its mapping rules (e.g. 5-tuple mapping rules) to the control 531 plane (e.g. by static configuration), and then the control plane can 532 notify the SFC proxy the mapping information (step 1) via interface 533 C4 [I-D.ietf-sfc-control-plane]. According to the mapping 534 information, the SFC proxy can establish a mapping table for the SFC 535 header, the original header, and the processed header of the packet. 536 After receiving the packet from the SF (step 4), the SFC proxy 537 retrieves the SFC header from the mapping table by using the 538 processed header as a key. 540 +------------------------+ 541 | | 542 | SFC Control Plane | 543 | | 544 +---^------------^-------+ 545 | | 546 |C2 | (1) 547 | | 548 +---V----+ |C4 549 -----+ SFF +------ | 550 | | | 551 +----+---+ | 552 | +---V----+ 553 +-------+ SFC | 554 (2) | Proxy | 555 +---^----+ 556 | 557 (3)|(4) 558 +------V---------+ 559 |SFC-unaware | 560 |Service Function| 561 +----------------+ 563 4. Operation Considerations 565 The following table shows all the methods and the conditions to use. 567 Table 1: Operation Consideration 569 +-----------+--------+-------------------------------+-------------------+ 570 | |Methods | Stored Key-Value |Application | 571 | | | |Scenario | 572 +-----------+--------+-------------------------------+-------------------+ 573 | |MAC | (Source MAC Address, SFC |L2 header won't | 574 |For Trans- |Address | header) |be modified by the | 575 |parent SF | | |SF. | 576 | | |e.g. assign a source MAC | | 577 | | |address per packet or path ID | | 578 | +--------+-------------------------------+-------------------+ 579 | |VLAN | (Direction, VLAN ID, |L2 header won't | 580 | | | SFC header) |be modified by the | 581 | | |e.g. assign a VLAN ID per |SF. | 582 | | |bidirectional path-pair | | 583 | +--------+-------------------------------+-------------------+ 584 | |QinQ | (Direction, Outer VLAN ID, |The SF is required | 585 | | | SFC header) |to support QinQ. | 586 | | |e.g. assign an outer VLAN ID |L2 header won't | 587 | | |per bidirectional path-pair |be modified by | 588 | | | |the SF. | 589 | +--------+-------------------------------+-------------------+ 590 | |VXLAN | (Direction, VNI, SFC header) |The SF is required | 591 | | |e.g. assign a VNI per |to support VXLAN. | 592 | | |bidirectional path-pair |VNI is not modified| 593 | | | |by the SF. | 594 | +--------+-------------------------------+-------------------+ 595 | |5-tuple |(5-tuple, SFC header) |5-tuple is not | 596 | | | |modified by the | 597 | | |The SFC proxy maintains the |SF. | 598 | | |mapping table for 5-tuple and | | 599 | | |the SFC header. | | 600 | | |Note: an SFC header for each | | 601 | | |direction of a TCP flow. | | 602 +-----------+--------+----------------- -------------+-------------------+ 603 | |TBD |Mapping rules: |The SFC proxy is | 604 |For | |e.g. 5-tuple -> 5-tuple' |configured or is | 605 |Non-trans- | | |able to obtain the | 606 |parent SF | |SFC Proxy: |mapping rules of | 607 | | |5-tuple -> 5-tuple' |the SF. The SF | 608 | | |5-tuple'-> SFC header |modifies the | 609 | | | |5-tuple based on | 610 | | | |the mapping | 611 | | | |rules. | 612 +-----------+--------+---------------------------------------------------+ 613 4.1. Metadata Consideration 615 Some classes of SF may need to inject new packets, for example a 616 transparent cache sending content from its disk. The legacy SF 617 usually encapsulates the new packets with the same encapsulation with 618 the related received packets, e.g. with the same 5-tuple, or V-LAN 619 ID. The SFC proxy would associate the new packet with the 620 corresponding SFC header based on the mechanisms discussed in 621 Section 3. However, per-packet metadata should be prohibited for 622 this case. 624 Some classes of SF may need to inject a packet in the opposite 625 direction of a received packet, for example a firewall responding to 626 a TCP SYN with a RST. If the RST generator is VLAN-type legacy, it 627 may know what VLAN to use; then the SFC proxy would translate VLAN 628 into a reverse SFP and attach a corresponding SFC header insetad of 629 the original SFC header. In this case, the SFC proxy should be 630 configured with the bidirectional SFP, i.e. SFC proxy needs to be 631 designed according to the properties of the SF. Similarly, packet- 632 specific metadata is not recommended to be used. 634 We leave the metadata model as an open issue that will be documented 635 in other documents. In some cases this information will also assist 636 normal (non-legacy) SFs that wish to modify or inject packets. 638 5. Security Considerations 640 When the layer 2 header of the original packet is modified and sent 641 to the SF, if the SF needs to look into the layer 2 header, it may 642 cause security threats. It also provides diagrams of the main 643 entities that the information model is comprised of. 645 6. Acknowledgement 647 The authors would like to thank Ron Parker and Joel Halpern for their 648 comments. 650 7. References 652 7.1. Normative References 654 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 655 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 656 eXtensible Local Area Network (VXLAN): A Framework for 657 Overlaying Virtualized Layer 2 Networks over Layer 3 658 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 659 . 661 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 662 Chaining (SFC) Architecture", RFC 7665, 663 DOI 10.17487/RFC7665, October 2015, 664 . 666 7.2. Informative References 668 [I-D.dolson-sfc-vlan] 669 Dolson, D., "VLAN Service Function Chaining", draft- 670 dolson-sfc-vlan-00 (work in progress), February 2014. 672 [I-D.ietf-sfc-control-plane] 673 Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C., 674 Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A., 675 Halpern, J., Reddy, T., and P. Patil, "Service Function 676 Chaining (SFC) Control Plane Components & Requirements", 677 draft-ietf-sfc-control-plane-03 (work in progress), 678 January 2016. 680 Authors' Addresses 682 Haibin Song 683 Huawei 684 101 Software Avenue, Yuhuatai District 685 Nanjing, Jiangsu 210012 686 China 688 Email: haibin.song@huawei.com 690 Jianjie You 691 Huawei 692 101 Software Avenue, Yuhuatai District 693 Nanjing, 210012 694 China 696 Email: youjianjie@huawei.com 698 Lucy Yong 699 Huawei 700 5340 Legacy Drive 701 Plano, TX 75025 702 U.S.A. 704 Email: lucy.yong@huawei.com 705 Yuanlong Jiang 706 Huawei 707 Bantian, Longgang district 708 Shenzhen 518129 709 China 711 Email: jiangyuanlong@huawei.com 713 Linda Dunbar 714 Huawei 715 1700 Alma Drive, Suite 500 716 Plano, TX 75075 717 U.S.A. 719 Email: ldunbar@huawei.com 721 Nicolas Bouthors 722 Qosmos 724 Email: nicolas.bouthors@qosmos.com 726 David Dolson 727 Sandvine 728 408 Albert Street 729 Waterloo, ON N2L 3V3 730 Canada 732 Email: ddolson@sandvine.com