idnits 2.17.1 draft-song-sfc-legacy-sf-mapping-00.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 10, 2014) is 3670 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) == Unused Reference: 'I-D.jiang-sfc-arch' is defined on line 402, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-mahalingam-dutt-dcops-vxlan-08 Summary: 1 error (**), 0 flaws (~~), 4 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 L. Yong 4 Intended status: Standards Track Y. Jiang 5 Expires: October 12, 2014 Huawei 6 April 10, 2014 8 SFC Header Mapping for Legacy SF 9 draft-song-sfc-legacy-sf-mapping-00 11 Abstract 13 SFC (Service Function Chaining) is used to manipulate service 14 functions with easy creation, updating and deletion. A service 15 function chain goes through a list of ordered service function 16 instances. One assumption of this document is that legacy service 17 function instances can participate in the service chain. They are 18 not aware of the SFC header, nor interpret it. This document 19 provides a mechanism between a Service Forwarding Entity (SFE) and a 20 Service Function Instance (SFI), to identify the SFC header 21 associated with a packet that is returned from an SFI, without SFC 22 header being explicitly carried in the wired protocol between SFE and 23 SFI. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 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 12, 2014. 48 Copyright Notice 50 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. For Transparent Service Functions . . . . . . . . . . . . 4 69 3.1.1. Layer 2 MAC Address . . . . . . . . . . . . . . . . . 4 70 3.1.2. VLAN . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1.3. QinQ . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1.4. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2. For Non-transparent Service Functions . . . . . . . . . . 9 74 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 75 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Informative References . . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 SFC is used to manipulate service functions with easy creation, 82 updating and deletion. A service function chain goes through a list 83 of ordered service functions. One assumption of this document is 84 that certain service functions can be kept as legacy. They do not 85 have to be aware of the SFC header, nor interprets it. This document 86 provides a mechanism between a Service Forwarding Entity and a 87 Service Function Instance, to identify the SFC header associated with 88 a packet that is returned from an SFI, without anything in the SFC 89 header being explicitly carried in the wired protocol between a SFE 90 and SFI. 92 +----------------+ 93 |Service Function| 94 |Instance | 95 +----+----+------+ 96 ^ | 97 | | 98 | | 99 (2)| |(3) 100 | | 101 | | 102 +----+----V--------+ 103 (1) |Service Forwarding| (4) 104 -------->|Entity +-------> 105 +------------------+ 106 Figure 1: Procedure of a packet processed by a legacy service function 108 The legacy service function (i.e. SFI in the Figure 1) only handles 109 packets without SFC header, because it does not understand the SFC 110 header. One advantage is that the existing service functions don't 111 need to be upgraded to support SFC. Otherwise it may be a hindrance 112 for the widely adoption of SFC. 114 We assume that for most SFIs, the packet header is transparent to a 115 legacy SFI. SFI will not modify the layer 2 or layer 3 packet 116 headers. If the payload in the SFC encapsulation is layer 3 traffic, 117 it will be kept as it is, and a new layer 2 header will be added 118 before sending to the SFI. However if the payload in the SFC 119 encapsulation is layer 2 traffic, we may modify the original source 120 MAC address and use it for mapping to the stored SFC header, but it 121 will not impact the SFI processing. The SFI will send the traffic 122 back after processing. For the current stage, we leave the legacy 123 SFIs which modify the original packet headers as an open issue for 124 further study. 126 As shown in Figure 1, there are four steps. The SFE receives a 127 packet, and removes its SFC header, which may optionally contain 128 metadata, and stores the SFC header locally, and then sends the 129 original packet to the SFI. After SFI processing the packet, the 130 traffic will be sent back to the SFE. The SFE retrieves the pre- 131 stored SFC header accordingly, and encapsulates the packet with the 132 SFC header, and then sends the packet to next-hop service function. 133 The key problem here is how to map the packet to its original SFC 134 header. 136 If the SFC header is not changed per flow at a certain point, e.g., a 137 specific SFE, (i.e. each flow has a specific SFC header in a SFE, but 138 in another SFE, the SFC header is different), then the SFE needs to 139 find the original SFC header per flow. If the SFC header is changed 140 per packet for a specific flow at a certain point, then the SFE needs 141 to find the original SFC header per packet. The second case may be 142 happened if different packets in a flow carry different metadata 143 (e.g. the metadata can be injected to the packet by a DPI appliance). 144 It's also the reason why we cannot use five-tuple for the mapping to 145 retrieve the original SFC header. 147 We use an expiration time for each mapping entry in the SFE. If the 148 SFC header in that entry has not been retrieved after the expiration 149 time, the entry will be deleted from the entry table. 151 2. Terminology 153 The terminology used in this document is defined below: 155 Legacy SF: A conventional service function that does not support 156 SFC header. 158 Transparent SF: A service function that does not change any bit of 159 the original service packet header (Layer 2, layer 3, and layer 4) 160 sent to it. 162 Non-transparent SF: A service function that changes some part of 163 the original service packet header sent to it. 165 Original Service Packet: The payload in a SFC encapsulation packet 166 or a packet constructed based on the original payload. 168 3. Mechanisms 170 The mechanisms used in this document require that each forwarding 171 entity and its connected service functions in a same layer 2 network. 172 The following are considerations mainly for transparent SFIs. If the 173 original payload packet is a layer 2 packet, and the mapping method 174 used is layer 2 MAC address, then the assumption is that the SFI does 175 not need to look into the layer 2 header. If it does, other 176 mechanisms should be used. 178 3.1. For Transparent Service Functions 180 If the service function is transparent to packet headers, we can use 181 the following methods for SFC header mapping. 183 3.1.1. Layer 2 MAC Address 185 We can use layer 2 MAC address to associate a SFC header between SFE 186 and SFI, i.e. each SFC header will be assigned a source MAC address 187 on the SFE. If SFC header can be changed per packet, then SFE 188 assigns a new source MAC address for each packet it received, 189 otherwise, it assigns a new MAC address for each flow it received. 191 When SFE received the returned packet from the SFI, it retrieves the 192 packet's original SFC header by using the MAC address as a key. And 193 then it encapsulates the packet with that SFC header and sends to the 194 next hop. 196 0 1 2 3 197 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 199 Outer Ethernet Header: 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | SFI Destination MAC Address | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |SFI Destination MAC Address | SFE Source MAC Address | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | SFE Source MAC Address | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Ethertype = 0x0800 | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Original IP Payload: 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Original Payload | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 3.1.2. VLAN 219 If the network between the SFE and SFI is a layer 2 network, and in 220 the case that a SFI need to look into the MAC address of the packet, 221 then VLAN can be used for the mapping between them. The SFE removes 222 the SFC header and sends the packet to the SFI, with encapsulating a 223 certain VLAN ID. It locally maintains the mapping between VLAN ID 224 and the SFC header. When it gets the returned packet from the SFI, 225 it removes the VLAN part from the packet and retrieves the 226 corresponding SFC header according to the VLAN ID, and then 227 encapsulates SFC header into that packet before sending to the next 228 service function. 230 The VLAN ID can be used for mapping per flow, i.e. each flow will be 231 assigned a new VLAN ID. If SFC header could be changed per packet, 232 the length of VLAN ID is not enough for mapping. 234 0 1 2 3 235 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 237 Outer Ethernet Header: 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | SFI Destination MAC Address | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |SFI Destination MAC Address | SFE Source MAC Address | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | SFE Source MAC Address | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |OptnlEthtype = C-Tag 802.1Q |Outer.VLAN Tag Information | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Ethertype = 0x0800 | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Original IP Payload: 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Original Payload | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 3.1.3. QinQ 259 If the network between the SFE and SFI is already a VLAN network, and 260 the SFI needs to look into the MAC address, then QinQ is used for the 261 communication between SFE and SFI. The SFE remove the SFC header and 262 send the original traffic to SFI with a certain outer VLAN ID. It 263 locally maintains the mapping between outer VLAN ID and the SFC 264 header. 266 If the network between SFE and SFI is not a VLAN network, then QinQ 267 can be used for either per flow mapping or per packet mapping, using 268 two layer VLAN fields. If the network between SFE and SFI is a VLAN 269 network, then QinQ can only be used for per flow mapping, using one 270 VLAN field. 272 0 1 2 3 273 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 275 Outer Ethernet Header: 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | SFI Destination MAC Address | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |SFI Destination MAC Address | SFE Source MAC Address | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | SFE Source MAC Address | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |OptnlEthtype = S-Tag 802.1Q |Outer.VLAN Tag Information | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |Ethertype = C-Tag 802.1Q |Inner.VLAN Tag Information | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Ethertype = 0x0800 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Original IP Payload: 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Original Payload | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 3.1.4. VXLAN 299 If the SFE and SFI are already deployed in a QinQ network, then we 300 can use VXLAN [I-D.mahalingam-dutt-dcops-vxlan] for the mapping. 301 This tunneling technology is only used when the original packet type 302 is at layer 2 and the SFI has to look into the layer 2 MAC header. 304 The drawback of this mechanism is that it requires both SFE and SFI 305 to support VXLAN. 307 0 1 2 3 308 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 310 Outer Ethernet Header: 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | SFI Destination MAC Address | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |SFI Destination MAC Address | SFE Source MAC Address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | SFE Source MAC Address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |OptnlEthtype = C-Tag 802.1Q |Outer.VLAN Tag Information | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Ethertype = 0x0800 | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Outer IP Header: 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |Version| IHL |Type of Service| Total Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Identification |Flags| Fragment Offset | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |Time to Live |Protocol=17(UDP) | Header Checksum | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Outer Source IPv4 Address | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Outer Destination IPv4 Address | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Outer UDP Header: 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Source Port = xxxx | Dest Port = VXLAN Port | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | UDP Length | UDP Checksum | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 VXLAN Header: 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |R|R|R|R|I|R|R|R| Reserved | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | VXLAN Network Identifier (VNI) | Reserved | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 3.2. For Non-transparent Service Functions 356 Non transparent service functions including NAT (Network Address 357 Translation), WOC (WAN Optimization Controller) and etc, are more 358 complicated, as they may change any part of the original packet sent 359 to them. It is better to analyze case by case, to utilize a specific 360 filed that the SFI does not change for the mapping and retrieving the 361 SFC header. We would like to leave it for open discussion. 363 The use case below is just one example that SFE can learn the 364 behavior of the SFI changing the packet. In this example, we can use 365 the following method for SFC header mapping. The SFI needs to report 366 its mapping rules (e.g. 5-tuple mapping rules) to the control plane 367 (step 1), and then the control plane can notify the SFE the mapping 368 information (step 2). According to the mapping information, the SFE 369 can establish a mapping table for the SFC header, the original 370 header, and the processed header of the packet. After receiving the 371 packet from the SFI (step 5), the SFE retrieves the SFC header from 372 the mapping table by using the processed header as a key. 374 +-------------+ 375 |Control Plane| 376 +--+-----+----+ 377 ^ ^ 378 | | 379 | |(1) +----------------+ 380 | +------->Service Function| 381 (2)| |Instance | 382 | +-----+---+------+ 383 | (4)^ |(5) 384 +---------------+ | | 385 | | | 386 +--V---+---V-------+ 387 (3) |Service Forwarding| (6) 388 --------->+Entity +-------> 389 +------------------+ 391 4. Security considerations 393 When we modify the layer 2 header of the original packet and send it 394 to SFI, if the SFI needs to look into the layer 2 header, it may 395 cause security threats.). It also provides diagrams of the main 396 entities that the information model is comprised of. 398 5. Acknowledgement 400 6. Informative References 402 [I-D.jiang-sfc-arch] 403 Jiang, Y. and L. Hongyu, "An Architecture of Service 404 Function Chaining", draft-jiang-sfc-arch-01 (work in 405 progress), February 2014. 407 [I-D.mahalingam-dutt-dcops-vxlan] 408 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 409 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 410 Framework for Overlaying Virtualized Layer 2 Networks over 411 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-08 412 (work in progress), February 2014. 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 Authors' Addresses 419 Haibin Song 420 Huawei 421 101 Software Avenue, Yuhua District 422 Nanjing, Jiangsu 210012 423 China 425 Email: haibin.song@huawei.com 427 Lucy Yong 428 Huawei 429 5340 Legacy Drive 430 Plano, TX 75025 431 U.S.A. 433 Email: lucy.yong@huawei.com 435 Yuanlong Jiang 436 Huawei 437 Bantian, Longgang district 438 Shenzhen 518129 439 China 441 Email: jiangyuanlong@huawei.com