idnits 2.17.1 draft-song-sfc-legacy-sf-mapping-08.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 32 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 6, 2016) is 2786 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-07 Summary: 2 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: March 10, 2017 Y. Jiang 6 L. Dunbar 7 Huawei 8 N. Bouthors 9 Qosmos 10 D. Dolson 11 Sandvine 12 September 6, 2016 14 SFC Header Mapping for Legacy SF 15 draft-song-sfc-legacy-sf-mapping-08 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 supporting the SFC 24 header, or even being aware of it. This document provides some of 25 the mechanisms between an SFC proxy and an SFC-unaware service 26 function (herein termed "legacy SF"), to identify the SFC header 27 associated with a packet that is returned from a legacy SF, without 28 an SFC header being explicitly carried in the wired protocol between 29 SFC 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 March 10, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. For Transparent Service Functions . . . . . . . . . . . . 5 69 3.1.1. VLAN . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1.2. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.3. Ethernet MAC Address . . . . . . . . . . . . . . . . 6 72 3.1.4. 5-tuple . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2. For Non-transparent Service Functions . . . . . . . . . . 7 74 4. Operation Considerations . . . . . . . . . . . . . . . . . . 8 75 4.1. Examplar Mechanisms . . . . . . . . . . . . . . . . . . . 8 76 4.2. Challenges to Support Legacy SF . . . . . . . . . . . . . 8 77 4.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 7.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 A Service Function Chain (SFC) [RFC7665] defines a set of abstract 88 service functions and ordering constraints that must be applied to 89 packets and/or frames selected as a result of classification. One 90 assumption of this document is that some service functions may remain 91 as legacy implementations, i.e. SFC-unaware SFs. The SFC proxy is 92 proposed to act as a gateway between the SFC encapsulation and SFC- 93 unaware SFs. The SFC proxy removes the SFC header and then sends the 94 packet to a legacy SF for processing, but how to associate the 95 original SFC header with the packet returned from the legacy SF needs 96 to be considered. 98 This document describes some of the mechanisms between an SFC proxy 99 and a legacy SF, to identify the SFC header associated with a packet 100 that is returned from a legacy SF. The benefit for supporting legacy 101 SF is that SFC-unaware SFs can exist in the SFC-enabled domain. An 102 SFC proxy allows a legacy SF to function in the SFC-enabled domain 103 without modification of the legacy SF. 105 +----------------+ 106 |SFC-unaware | 107 |Service Function| 108 | (Legacy SF) | 109 +----+----+------+ 110 ^ | 111 | | 112 +----+----+------+ 113 |Switch(optional)| 114 +----+----+------+ 115 | | 116 (2)| |(3) 117 | | 118 +----+----V--------+ 119 (1) | SFC | (4) 120 -------->| Proxy +-------> 121 +------------------+ 123 Figure 1: Procedure of a packet processed by a legacy SF 125 Different classes of legacy SF may have variable support for 126 different types of packets with respect to parsing and semantics 127 (e.g., some classes of legacy SF may accept VLAN-tagged traffic; 128 others may not), usually depending on device configuration. For 129 example, by creation of VLANs, traffic is steered through a firewall. 131 This document focuses heavily on legacy SFs that are transparent at 132 layer 2. In particular we assume the following conditions apply in 133 the class of legacy SF we are considering proxying: 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 followed 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 (1) from an SFF, and removes its SFC header, which may 179 optionally contain metadata, and store the SFC header locally, and 180 then (2) sends the de-encapsulated packet to the SF. After the SF 181 processes the packet, the packet will be sent back (3) to the SFC 182 proxy. The SFC proxy retrieves the pre-stored SFC header 183 accordingly, determines the SFC header for the next stage of the path 184 and encapsulates the packet with the next SFC header, returning the 185 packet to an SFF (4). 187 2. Terminology 189 The terminology used in this document is defined below: 191 Legacy SF: A conventional service function that does not support 192 SFC header, i.e., SFC-unaware SF. 194 Transparent SF: A service function that does not change any bit of 195 the layer 2/3/4 packet header sent to it, but it may drop the 196 packet. 198 Non-transparent SF: A service function that changes some bits of 199 the layer 2/3/4 packet header sent to it. 201 SFC Proxy: Removes and inserts SFC encapsulation on behalf of an 202 SFC-unaware service function. SFC proxies are logical elements. 204 3. Mechanisms 206 The mapping mechanisms between the SFC proxy and the transparent or 207 non-transparent legacy SFs are discussed in this section. The 208 mechanisms used in this document require that each forwarding entity 209 (i.e., SFC proxy) and its connected service functions are in the same 210 layer 2 network. The detailed definitions of SFC proxy and SFC- 211 unaware SFs is discussed in [RFC7665]. 213 3.1. For Transparent Service Functions 215 3.1.1. VLAN 217 If the service function is transparent to packet headers, for 218 example, layer-2-transparent SF, then VLAN can be used for mapping 219 between the SFC proxy and SF. It is assumed that the switch between 220 the SFC proxy and SF delivers traffic for all VLANs, or the SFC proxy 221 and SF may be directly connected. 223 The SFC proxy removes the SFC header and sends the packet to the SF, 224 with encapsulating a certain VLAN ID that can represent the SFC 225 header. The legacy SF is supposed to accept VLAN-tagged packets and 226 send them back on the same VLAN. It is assumed that the SF is able 227 to process Ethernet packets with VLAN tags and also accept a wide 228 range of VLAN tags. The SFC proxy locally maintains the mapping 229 between VLAN ID/direction and the SFC header. 231 When receiving the returned packet from the SF, the SFC proxy removes 232 the VLAN part from the packet and retrieves the corresponding SFC 233 header according to the VLAN ID and the direction of packet travel, 234 and then encapsulates SFC header into that packet before sending to 235 the next service function. Packet direction is required because the 236 SFC header for left-to-right packets is different than the SFC header 237 for right-to-left packets. 239 3.1.2. VXLAN 241 If the SFC proxy and SF are already deployed in a nested VLAN 242 network, the VLAN mapping method is not applicable. Then VXLAN 243 [RFC7348] can be used for the mapping, i.e. VNI can be used for the 244 mapping between them. VXLAN is a Layer 2 overlay scheme over a Layer 245 3 network. It uses MAC Address-in-User Datagram Protocol (MAC-in- 246 UDP) encapsulation. The drawback of this mechanism is that it 247 requires both SFC proxy and SF to support VXLAN. 249 This approach has similar features and drawbacks of the VLAN scheme, 250 but the number of possible VNIs is larger. 252 3.1.3. Ethernet MAC Address 254 The MAC address also can be used to associate an SFC header between 255 the SFC proxy and SF; i.e., each SFC header will be assigned a source 256 MAC address on the SFC proxy. When the SFC proxy receives the 257 returned packet from the SF, it retrieves the packet's original SFC 258 header by using the source MAC address as a key. And then it 259 encapsulates the packet with that SFC header and sends to the next 260 hop. 262 An issue with the source-MAC address approach is that there is not 263 symmetry between packets going left-to-right with packets going 264 right-to-left. Such symmetry might be assumed by some legacy SFs. 265 For example, if a layer-2-transparent SF responds to a TCP SYN with a 266 TCP RST, it might do so by reversing the source and destination of 267 the layer 2 header. Such a packet received by the SFC proxy would 268 not result in finding of the correct SFC header. It is assumed that 269 the SF passes the MAC header through without even reversal. A 270 variation that is symmetric assigns a unique source/destination pair 271 for each unique SFC header. 273 3.1.4. 5-tuple 275 The 5-tuple of a packet carried within SFC encapsulation can be used 276 by the SFC proxy as a key to associate an SFC header when the 5-tuple 277 is not modified by the legacy SF. The SFC proxy maintains a mapping 278 table for the 5-tuple and the SFC header. When the packet returns 279 from the SF instance, the original SFC header for this packet can be 280 retrieved by inquiring the mapping table using 5-tuple as the key. 281 However, this method may not work in multi-tenant scenario, as such 282 uniqueness could be valid only within the scope of a single tenant. 284 So if the SFC is provided as a multi-tenant service, this method 285 would fail. 287 3.2. For Non-transparent Service Functions 289 Non transparent service functions including NAT (Network Address 290 Translation), WOC (WAN Optimization Controller) and etc, are more 291 complicated, as they may change any part of the original packet sent 292 to them. It is better to analyze case by case, to utilize a specific 293 field that the SF does not change for the mapping and retrieving the 294 SFC header. We would like to leave it for open discussion. 296 The Figure below shows an example procedure that SFC proxy can learn 297 the behavior of the SF changing the packet. In this example, the 298 following method is used for SFC header mapping. The SF needs to 299 report its mapping rules (e.g., 5-tuple mapping rules) to the control 300 plane (e.g., by static configuration), and then the control plane can 301 notify the SFC proxy the mapping information (step 1) via interface 302 C4 [I-D.ietf-sfc-control-plane]. According to the mapping 303 information, the SFC proxy can establish a mapping table for the SFC 304 header, the original header, and the processed header of the packet. 305 After receiving the packet from the SF (step 4), the SFC proxy 306 retrieves the SFC header from the mapping table by using the 307 processed header as a key. 309 +------------------------+ 310 | | 311 | SFC Control Plane | 312 | | 313 +---^------------^-------+ 314 | | 315 |C2 | (1) 316 | | 317 +---V----+ |C4 318 -----+ SFF +------ | 319 | | | 320 +----+---+ | 321 | +---V----+ 322 +-------+ SFC | 323 (2) | Proxy | 324 +---^----+ 325 | 326 (3)|(4) 327 +------V---------+ 328 |SFC-unaware | 329 |Service Function| 330 +----------------+ 332 4. Operation Considerations 334 4.1. Examplar Mechanisms 336 The following table gives some examplar methods and the conditions to 337 use. 339 Table 1: Mapping Examples 341 +-----------+--------+-------------------------------+-------------------+ 342 | |Methods | Stored Key-Value |Application | 343 | | | |Scenario | 344 +-----------+--------+-------------------------------+-------------------+ 345 | |VLAN | (Direction, VLAN ID, |L2 header won't | 346 | For Trans-| | SFC header) |be modified by the | 347 | parent SF | |e.g., assign a VLAN ID per |SF. | 348 | | |bidirectional path-pair | | 349 | +--------+-------------------------------+-------------------+ 350 | |VXLAN | (Direction, VNI, SFC header) |The SF is required | 351 | | |e.g., assign a VNI per |to support VXLAN. | 352 | | |bidirectional path-pair |VNI is not modified| 353 | | | |by the SF. | 354 | +--------+-------------------------------+-------------------+ 355 | |5-tuple |(5-tuple, SFC header) |5-tuple is not | 356 | | | |modified by the | 357 | | |The SFC proxy maintains the |SF. | 358 | | |mapping table for 5-tuple and | | 359 | | |the SFC header. | | 360 | | |Note: an SFC header for each | | 361 | | |direction of a TCP flow. | | 362 +-----------+--------+----------------- -------------+-------------------+ 363 | |Case-by-|Mapping rules: |The SFC proxy is | 364 |For |case |e.g. 5-tuple -> 5-tuple' |configured or is | 365 |Non-trans- | | |able to obtain the | 366 |parent SF | |SFC Proxy: |mapping rules of | 367 | | |5-tuple -> 5-tuple' |the SF. The SF | 368 | | |5-tuple'-> SFC header |modifies the | 369 | | | |5-tuple based on | 370 | | | |the mapping | 371 | | | |rules. | 372 +-----------+--------+---------------------------------------------------+ 374 4.2. Challenges to Support Legacy SF 376 The key problem contemplated in this document is: what packet header 377 should be put on the packets sent to a legacy SF such that packets 378 returned from the legacy SF can be mapped to the original SFC header. 379 We need to consider the relationship between an SFC path and flows 380 within the path. Should the path act as a qualifier to the flow, or 381 should a flow be allowed to change paths? We assume flows can change 382 path; this means that a given legacy SF cannot handle traffic from 383 more than one routing domain. (Private IP addresses cannot be 384 qualified by the SFC header; different VPNs must use different legacy 385 SFs.) 387 Because we've assumed that a flow can be on multiple paths, or change 388 paths, or if metadata can vary during the life of a flow, we need to 389 ask to what extent packet accuracy matters. If the SFC header used 390 with a flow is changed from one path to another by the classifier, 391 does it matter if packets retain exactly the original SFC header? If 392 the change is to handle routing updates or fail-over then it would be 393 acceptable to put all packets returning from the legacy SF onto the 394 most recently updated header. If metadata is changed, can that 395 update be applied to all packets of a flow, or does it apply to a 396 specific packet? 398 In the case that changes to paths and metadata are considered updates 399 to the flow vs. packet properties, the SFC proxy can find the SFC 400 header based on flow (e.g., the 5-tuple of the returning IP packet). 401 If, in contrast, packet accuracy of SFC headers does matter, (e.g., 402 the metadata says something about the specific packet associated with 403 it), then some form of per-packet bookkeeping must be done by the SFC 404 proxy and the 5-tuple cannot be used for the mapping to retrieve the 405 original SFC header. 407 When packet accuracy does matter, packets injected by the legacy SF 408 pose a fundamental problem. Is there any correct SFC header that can 409 be added? Observation: the same problem exists for a normal (not 410 legacy) SF that wishes to modify or inject a packet. 412 Because the SFC proxy needs to keep dynamic state by storing packet 413 headers, an expiration time should be used for each mapping entry in 414 the SFC proxy. If the SFC header in that entry has not been 415 witnessed or retrieved after the expiration time, the entry will be 416 deleted from the entry table. 418 Observation: if metadata is not used, the number distinct SFC headers 419 is known at configuration time, equivalent to the number of paths 420 configured to pass through the SF. The mappings between SFC headers 421 and layer 2 encodings could be configured at this time vs. at run 422 time. However, if metadata is used, a combinatorial explosion of 423 distinct SFC headers may result, which is a problem for any device 424 attempting to store them for later retrieval. 426 4.3. Metadata 428 Some classes of SF may need to inject new packets, for example a 429 transparent cache sending content from its disk. The legacy SF 430 usually encapsulates the new packets with the same encapsulation with 431 the related received packets, e.g. with the same 5-tuple, or V-LAN 432 ID. The SFC proxy would associate the new packet with the 433 corresponding SFC header based on the mechanisms discussed in 434 Section 3. However, per-packet metadata should be prohibited for 435 this case. 437 Some classes of SF may need to inject a packet in the opposite 438 direction of a received packet, for example a firewall responding to 439 a TCP SYN with a RST. If the RST generator is VLAN-type legacy, it 440 may know what VLAN to use; then the SFC proxy would translate VLAN 441 into a reverse SFP and attach a corresponding SFC header insetad of 442 the original SFC header. In this case, the SFC proxy should be 443 configured with the bidirectional SFP, i.e. SFC proxy needs to be 444 designed according to the properties of the SF. Similarly, packet- 445 specific metadata is not recommended to be used. 447 We leave the metadata model as an open issue that will be documented 448 in other documents. In some cases this information will also assist 449 normal (non-legacy) SFs that wish to modify or inject packets. 451 5. Security Considerations 453 When the layer 2 header of the original packet is modified and sent 454 to the SF, if the SF needs to make use of the layer 2 header, it may 455 cause security threats. There may be security issues with state 456 exhaustion on the SFC proxy, e.g., exhausting VLAN IDs, or exhausting 457 5-tuple state memory. 459 6. Acknowledgement 461 The authors would like to thank Ron Parker and Joel Halpern for their 462 valuable comments. 464 7. References 466 7.1. Normative References 468 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 469 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 470 eXtensible Local Area Network (VXLAN): A Framework for 471 Overlaying Virtualized Layer 2 Networks over Layer 3 472 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 473 . 475 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 476 Chaining (SFC) Architecture", RFC 7665, 477 DOI 10.17487/RFC7665, October 2015, 478 . 480 7.2. Informative References 482 [I-D.ietf-sfc-control-plane] 483 Boucadair, M., "Service Function Chaining (SFC) Control 484 Plane Components & Requirements", draft-ietf-sfc-control- 485 plane-07 (work in progress), August 2016. 487 Authors' Addresses 489 Haibin Song 490 Huawei 491 101 Software Avenue, Yuhuatai District 492 Nanjing, Jiangsu 210012 493 China 495 Email: haibin.song@huawei.com 497 Jianjie You 498 Huawei 499 101 Software Avenue, Yuhuatai District 500 Nanjing, 210012 501 China 503 Email: youjianjie@huawei.com 505 Lucy Yong 506 Huawei 507 5340 Legacy Drive 508 Plano, TX 75025 509 U.S.A. 511 Email: lucy.yong@huawei.com 513 Yuanlong Jiang 514 Huawei 515 Bantian, Longgang district 516 Shenzhen 518129 517 China 519 Email: jiangyuanlong@huawei.com 520 Linda Dunbar 521 Huawei 522 1700 Alma Drive, Suite 500 523 Plano, TX 75075 524 U.S.A. 526 Email: ldunbar@huawei.com 528 Nicolas Bouthors 529 Qosmos 531 Email: nicolas.bouthors@qosmos.com 533 David Dolson 534 Sandvine 535 408 Albert Street 536 Waterloo, ON N2L 3V3 537 Canada 539 Email: ddolson@sandvine.com