idnits 2.17.1 draft-song-sfc-legacy-sf-mapping-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 : ---------------------------------------------------------------------------- ** 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 41 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 29, 2014) is 3497 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-02 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: April 2, 2015 Y. Jiang 6 L. Dunbar 7 Huawei 8 N. Bouthors 9 Qosmos 10 September 29, 2014 12 SFC Header Mapping for Legacy SF 13 draft-song-sfc-legacy-sf-mapping-03 15 Abstract 17 A Service Function Chain (SFC) defines a set of abstract service 18 functions and ordering constraints that must be applied to packets 19 and/or frames selected as a result of classification. One assumption 20 of this document is that legacy service function can participate in 21 the service function chain, but they are not aware of the SFC header, 22 nor interpret it. This document provides a mechanism between an SFC 23 proxy and an SFC-unaware Service Function (i.e. legacy SF), to 24 identify the SFC header associated with a packet that is returned 25 from a legacy SF, without SFC header being explicitly carried in the 26 wired protocol between SFC Proxy and legacy SF. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 2, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. For Transparent Service Functions . . . . . . . . . . . . 5 71 3.1.1. Layer 2 MAC Address . . . . . . . . . . . . . . . . . 5 72 3.1.2. VLAN . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.3. QinQ . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1.4. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.1.5. 5-tuple . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.2. For Non-transparent Service Functions . . . . . . . . . . 10 77 4. Operation Consideration . . . . . . . . . . . . . . . . . . . 11 78 5. Security considerations . . . . . . . . . . . . . . . . . . . 13 79 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 7.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 A Service Function Chain (SFC) [I-D.ietf-sfc-architecture] defines a 88 set of abstract service functions and ordering constraints that must 89 be applied to packets and/or frames selected as a result of 90 classification. One assumption of this document is that some service 91 functions are kept as legacy, and they do not have to be aware of the 92 SFC header, nor interpret it. This document provides a mechanism 93 between an SFC proxy and a legacy SF, to identify the SFC header 94 associated with a packet that is returned from a legacy SF, without 95 anything in the SFC header being explicitly carried in the wired 96 protocol between an SFC proxy and a legacy SF. 98 +----------------+ 99 |SFC-unaware | 100 |Service Function| 101 +----+----+------+ 102 ^ | 103 | | 104 | | 105 (2)| |(3) 106 | | 107 | | 108 +----+----V--------+ 109 (1) | SFC | (4) 110 -------->| Proxy +-------> 111 +------------------+ 112 Figure 1: Procedure of a packet processed by a legacy SF 114 The legacy service function (i.e. SFC-unaware service function in 115 the Figure 1) only handles packets without SFC header, because it 116 does not understand the SFC header. One advantage is that the 117 existing service functions don't need to be upgraded to support SFC. 118 Otherwise it may be a hindrance for the widely adoption of SFC. 120 Assuming that for some legacy SFs, the packet header is transparent 121 to them, i.e., this kind of SFs will not modify the layer 2 or layer 122 3 packet headers. If the payload in the SFC encapsulation is layer 3 123 traffic, it will be kept as it is, and a new layer 2 header will be 124 added before sending to the SF. However if the payload in the SFC 125 encapsulation is layer 2 traffic, the SFC proxy may modify the 126 original source MAC address and use the new source MAC address for 127 mapping to the stored SFC header. This will not impact the SF 128 processing. The SF will send the traffic back after processing. For 129 the current stage, we leave the legacy SFs which modify the original 130 packet headers as an open issue for further study. 132 As shown in Figure 1, there are four steps. The SFC proxy receives a 133 packet, and removes its SFC header, which may optionally contain 134 metadata, and store the SFC header locally, and then sends the 135 original packet to the SF. After SF processing the packet, the 136 traffic will be sent back to the SFC proxy. The SFC proxy retrieves 137 the pre- stored SFC header accordingly, and encapsulates the packet 138 with the SFC header, and then sends the packet to next-hop service 139 function. The key problem here is how to map the packet to its 140 original SFC header. 142 If the SFC header is not changed per flow at a certain point, e.g., a 143 specific SFC proxy (i.e. each flow has a specific SFC header in a SFC 144 proxy, but in another SFC proxy, the SFC header is different), then 145 the SFC proxy needs to find the original SFC header per flow. If the 146 SFC header is changed per packet for a specific flow at a certain 147 point, then the SFC proxy needs to find the original SFC header per 148 packet. The second case may happen if different packets in a flow 149 carry different metadata (e.g. the metadata can be injected to the 150 packet by a DPI appliance). It's also the reason why five-tuple 151 cannot be used for the mapping to retrieve the original SFC header. 153 When metadata is sent without any associated payload (congruent 154 metadata) and the associated service function is a legacy one, then 155 SFF MUST relay the metadata to the next hop SFF, without sending the 156 metadata to SFC proxy. 158 [Open Issue: Should the authors of 'SFC header' consider the issue of 159 having a flag on metadata specifying if it is per flow, per packet? 160 Only the sender of the metadata knows. ] 162 An expiration time can be used for each mapping entry in the SFC 163 proxy. If the SFC header in that entry has not been retrieved after 164 the expiration time, the entry will be deleted from the entry table. 166 2. Terminology 168 The terminology used in this document is defined below: 170 Legacy SF: A conventional service function that does not support 171 SFC header, i.e. SFC-unaware SF. 173 Transparent SF: A service function that does not change any bit of 174 the original service packet header (Layer 2, layer 3, and layer 4) 175 sent to it, but it may drop packets. 177 Non-transparent SF: A service function that changes some part of 178 the original service packet header sent to it. 180 Original Service Packet: The payload in a SFC encapsulation packet 181 or a packet constructed based on the original payload. 183 3. Mechanisms 185 The mechanisms used in this document require that each forwarding 186 entity and its connected service functions in a same layer 2 network. 187 The following are considerations mainly for transparent SFs. If the 188 original payload packet is a layer 2 packet, and the mapping method 189 used is layer 2 MAC address, then the assumption is that the SF does 190 not need to look into the layer 2 header. If it does, other 191 mechanisms should be used. 193 3.1. For Transparent Service Functions 195 If the service function is transparent to packet headers, the 196 following methods can be used for SFC header mapping. 198 3.1.1. Layer 2 MAC Address 200 The layer 2 MAC address is used to associate a SFC header between SFC 201 proxy and SF, i.e. each SFC header will be assigned a source MAC 202 address on the SFC proxy. If SFC header can be changed per packet, 203 then SFC proxy assigns a new source MAC address for each packet it 204 received, otherwise, it assigns a new MAC address for each flow it 205 received. 207 When SFC proxy received the returned packet from the SF, it retrieves 208 the packet's original SFC header by using the MAC address as a key. 209 And then it encapsulates the packet with that SFC header and sends to 210 the next hop. 212 Open issue: usually the MAC address table size in a switch is no more 213 than 16K. When there is a requirement that per packet metadata needs 214 to be restored to each packet after the packet returns from the SF 215 instance, it may require more MAC addresses than the MAC table size 216 in the switch. This may overflow the MAC table, thus the packet 217 cannot route back to the SFC proxy correctly. 219 0 1 2 3 220 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 222 Outer Ethernet Header: 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | SF Destination MAC Address | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | SF Destination MAC Address | SFC Proxy Source MAC Address | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | SFC Proxy Source MAC Address | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Ethertype = 0x0800 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Original IP Payload: 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Original Payload | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 3.1.2. VLAN 242 If the network between the SFC proxy and SF is a layer 2 network, and 243 in the case that an SF needs to look into the MAC address of the 244 packet, then VLAN can be used for the mapping between them. The SFC 245 proxy removes the SFC header and sends the packet to the SF, with 246 encapsulating a certain VLAN ID. It is a new encapsulation, this 247 supposes that the legacy App can be configured to accept encapsulated 248 packets and to send them back on the same VLAN. It is assumed that 249 the receiving service function host/VM can support multiple VLANs. 250 It locally maintains the mapping between VLAN ID and the SFC header. 251 When it gets the returned packet from the SF, it removes the VLAN 252 part from the packet and retrieves the corresponding SFC header 253 according to the VLAN ID, and then encapsulates SFC header into that 254 packet before sending to the next service function. 256 The VLAN ID may be used for mapping per flow, i.e. each flow will be 257 assigned a new VLAN ID. If SFC header could be changed per packet, 258 the length of VLAN ID is not enough for mapping. 260 [Open issue: [I-D.dolson-sfc-vlan] describes an approach for service 261 function chaining by using the input interface and VLAN number to 262 select the next output interface and new VLAN number. However the 263 mechanism discussed in this section is not necessary to use a pair of 264 VLAN IDs to identify the uplink and downlink streams respectively. 265 Only in the condition that the path IDs for the symmetric flows are 266 same, then it is necessary to assign different VLAN IDs for the 267 uplink and downlink streams respectively in order to associate the 268 VLAN ID with a specific service chain header.] 270 0 1 2 3 271 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 273 Outer Ethernet Header: 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | SFI Destination MAC Address | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | SF Destination MAC Address | SFC Proxy Source MAC Address | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | SFC Proxy Source MAC Address | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |OptnlEthtype = C-Tag 802.1Q |Outer.VLAN Tag Information | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Ethertype = 0x0800 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Original IP Payload: 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Original Payload | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 3.1.3. QinQ 295 If the network between the SFC proxy and SF is already a VLAN 296 network, and the SF needs to look into the MAC address, then QinQ is 297 used for the communication between SFC proxy and SF. The SFC proxy 298 remove the SFC header and send the original traffic to SF with a 299 certain outer VLAN ID. It locally maintains the mapping between 300 outer VLAN ID and the SFC header. 302 If the network between SFC proxy and SF is not a VLAN network, then 303 QinQ can be used for either per flow mapping or per packet mapping, 304 using two layer VLAN fields. Because of the increase in address 305 space, QinQ can be used in two-layer VLAN: outer VLAN-id per flow, 306 and inner VLAN-id per packet. If the network between SFC proxy and 307 SF is a VLAN network, then QinQ can only be used for per flow 308 mapping, using one VLAN field. 310 0 1 2 3 311 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 313 Outer Ethernet Header: 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | SF Destination MAC Address | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | SF Destination MAC Address | SFC Proxy Source MAC Address | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | SFC Proxy Source MAC Address | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 |OptnlEthtype = S-Tag 802.1Q |Outer.VLAN Tag Information | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 |Ethertype = C-Tag 802.1Q |Inner.VLAN Tag Information | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Ethertype = 0x0800 | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Original IP Payload: 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Original Payload | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 3.1.4. VXLAN 337 If the SFC proxy and SF are already deployed in a QinQ network, then 338 VXLAN [I-D.mahalingam-dutt-dcops-vxlan] can be used for the mapping, 339 i.e. VNI can be used for the mapping between them. This tunneling 340 technology is only used when the original packet type is at layer 2 341 and the SF has to look into the layer 2 MAC header. 343 The drawback of this mechanism is that it requires both SFC proxy and 344 SF to support VXLAN. 346 0 1 2 3 347 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 349 Outer Ethernet Header: 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | SF Destination MAC Address | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 |SFI Destination MAC Address | SFC Proxy Source MAC Address | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | SFC Proxy Source MAC Address | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 |OptnlEthtype = C-Tag 802.1Q |Outer.VLAN Tag Information | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Ethertype = 0x0800 | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Outer IP Header: 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |Version| IHL |Type of Service| Total Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Identification |Flags| Fragment Offset | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |Time to Live |Protocol=17(UDP) | Header Checksum | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Outer Source IPv4 Address | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Outer Destination IPv4 Address | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Outer UDP Header: 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Source Port = xxxx | Dest Port = VXLAN Port | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | UDP Length | UDP Checksum | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 VXLAN Header: 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |R|R|R|R|I|R|R|R| Reserved | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | VXLAN Network Identifier (VNI) | Reserved | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 3.1.5. 5-tuple 395 The 5-tuple of an SFC packet can be used as a key to associate an SFC 396 header in the SFC proxy when the 5-tuple is not modified by the 397 legacy SF. The SFC proxy maintains a mapping table for the 5-tuple 398 and the SFC header. When the packet returns from the SF instance, 399 the original SFC header for this packet can be retrieved by inquiring 400 the mapping table using 5-tuple as the key. However, this method may 401 not work in multi-tenant organizations, as such unicity could be 402 Valid only within the scope of a single tenant. So if the SFC is 403 provided as a multi-tenant service, this method would fail. 405 3.2. For Non-transparent Service Functions 407 Non transparent service functions including NAT (Network Address 408 Translation), WOC (WAN Optimization Controller) and etc, are more 409 complicated, as they may change any part of the original packet sent 410 to them. It is better to analyze case by case, to utilize a specific 411 field that the SF does not change for the mapping and retrieving the 412 SFC header. We would like to leave it for open discussion. 414 The use case below is just one example that SFC proxy can learn the 415 behavior of the SF changing the packet. In this example, the 416 following method is used for SFC header mapping. The SF needs to 417 report its mapping rules (e.g. 5-tuple mapping rules) to the control 418 plane (step 1), and then the control plane can notify the SFC proxy 419 the mapping information (step 2). According to the mapping 420 information, the SFC proxy can establish a mapping table for the SFC 421 header, the original header, and the processed header of the packet. 422 After receiving the packet from the SF (step 5), the SFC proxy 423 retrieves the SFC header from the mapping table by using the 424 processed header as a key. 426 +-------------+ 427 |Control Plane| 428 +--+-----+----+ 429 ^ ^ 430 | | 431 | |(1) +----------------+ 432 | +------->SFC-unaware | 433 (2)| |Service Function| 434 | +-----+---+------+ 435 | (4)^ |(5) 436 +---------------+ | | 437 | | | 438 +--V---+---V-------+ 439 (3) | SFC | (6) 440 --------->+ Proxy +-------> 441 +------------------+ 443 4. Operation Consideration 445 The following table shows all the methods and the conditions to use. 447 Table 1: Operation Consideration 449 +-----------+--------+-------------------------------+-------------------+ 450 | |Methods | Stored Key-Value |Application | 451 | | | |Scenario | 452 +-----------+--------+-------------------------------+-------------------+ 453 | |MAC | (Source MAC Address, SFC |L2 header won't | 454 |For Trans- |Address | header) |be modified by the | 455 |parent SF | | |SF. | 456 | | |e.g. assign a source MAC | | 457 | | |address per path ID | | 458 | +--------+-------------------------------+-------------------+ 459 | |VLAN | (VLAN ID, SFC header) |L2 header won't | 460 | | | |be modified by the | 461 | | |e.g. assign a VLAN ID per path |SF. | 462 | | |ID | | 463 | +--------+-------------------------------+-------------------+ 464 | |QinQ |(Outer VLAN ID, SFC header) |The SF is required | 465 | | | |to support QinQ. | 466 | | |e.g. assign an outer VLAN ID |L2 header won't | 467 | | |per path ID |be modified by | 468 | | | |the SF. | 469 | +--------+-------------------------------+-------------------+ 470 | |VXLAN |(VNI, SFC header) |The SF is required | 471 | | | |to support VXLAN. | 472 | | |e.g. assign a VNI per path ID | | 473 | +--------+-------------------------------+-------------------+ 474 | |5-tuple |(5-tuple, SFC header) |5-tuple is not | 475 | | | |modified by the | 476 | | |The SFC proxy maintains the |SF. | 477 | | |mapping table for 5-tuple and | | 478 | | |the SFC header. | | 479 +-----------+--------+----------------- -------------+-------------------+ 480 | |TBD |Mapping rules: |The SFC proxy is | 481 |For | |e.g. 5-tuple -> 5-tuple' |configured or is | 482 |Non-trans- | | |able to obtain the | 483 |parent SF | |SFC Proxy: |mapping rules of | 484 | | |5-tuple -> 5-tuple' |the SF. The SF | 485 | | |5-tuple'-> SFC header |modifies the | 486 | | | |5-tuple based on | 487 | | | |the mapping | 488 | | | |rules. | 489 +-----------+--------+---------------------------------------------------+ 490 5. Security considerations 492 When the layer 2 header of the original packet is modified and sent 493 to the SF, if the SF needs to look into the layer 2 header, it may 494 cause security threats. It also provides diagrams of the main 495 entities that the information model is comprised of. 497 6. Acknowledgement 499 The authors would like to thank Ron Parker for his comments. 501 7. References 503 7.1. Normative References 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, March 1997. 508 7.2. Informative References 510 [I-D.dolson-sfc-vlan] 511 Dolson, D., "VLAN Service Function Chaining", draft- 512 dolson-sfc-vlan-00 (work in progress), February 2014. 514 [I-D.ietf-sfc-architecture] 515 Halpern, J. and C. Pignataro, "Service Function Chaining 516 (SFC) Architecture", draft-ietf-sfc-architecture-02 (work 517 in progress), September 2014. 519 [I-D.mahalingam-dutt-dcops-vxlan] 520 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 521 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 522 Framework for Overlaying Virtualized Layer 2 Networks over 523 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-09 524 (work in progress), April 2014. 526 Authors' Addresses 528 Haibin Song 529 Huawei 530 101 Software Avenue, Yuhuatai District 531 Nanjing, Jiangsu 210012 532 China 534 Email: haibin.song@huawei.com 535 Jianjie You 536 Huawei 537 101 Software Avenue, Yuhuatai District 538 Nanjing, 210012 539 China 541 Email: youjianjie@huawei.com 543 Lucy Yong 544 Huawei 545 5340 Legacy Drive 546 Plano, TX 75025 547 U.S.A. 549 Email: lucy.yong@huawei.com 551 Yuanlong Jiang 552 Huawei 553 Bantian, Longgang district 554 Shenzhen 518129 555 China 557 Email: jiangyuanlong@huawei.com 559 Linda Dunbar 560 Huawei 561 1700 Alma Drive, Suite 500 562 Plano, TX 75075 563 U.S.A. 565 Email: ldunbar@huawei.com 567 Nicolas Bouthors 568 Qosmos 570 Email: nicolas.bouthors@qosmos.com