idnits 2.17.1 draft-xia-nvo3-vxlan-qosmarking-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2015) is 3333 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC0826' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 398, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-nvo3-arch-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Intended status: Experimental Huawei Technologies Co., Ltd. 5 Expires: September 6, 2015 S. Fan 6 China Telecom 7 March 5, 2015 9 Quality of Service Marking and Framework in Overlay Networks 10 draft-xia-nvo3-vxlan-qosmarking-04.txt 12 Abstract 14 Overlay networks such as The Virtual eXtensible Local Area Network 15 enable multiple tenants to operate in a data center. Each tenant 16 needs to be assigned a priority group to prioritize their traffic 17 using tenant based quality of service marking. Also, cloud carriers 18 wish to use quality of service to differentiate different 19 applications, i.e. legacy, traffic based marking. For these 20 purposes, Quality of Service bits are assigned in the Virtual 21 eXtensible Local Area Network outer Ethernet header. How these bits 22 are assigned and are processed in the network are explained in 23 detail. Also the document presents a quality of service framework 24 for overlay networks such as Virtual eXtensible Local Area Network. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 6, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 63 4. QoS Marking Schemes in VXLAN . . . . . . . . . . . . . . . . 4 64 4.1. Tenant Based Marking . . . . . . . . . . . . . . . . . . 5 65 4.2. Application Based Marking . . . . . . . . . . . . . . . . 6 66 4.3. QoS Bits in Outer IP Header . . . . . . . . . . . . . . . 6 67 5. Quality of Service Operation at VXLAN Decapsulation Point . . 7 68 6. Quality of Service Operation at VXLAN Encapsulation Point . . 7 69 7. QoS processing for VXLAN outer IP header . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 11.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Data center networks are being increasingly used by telecom operators 81 as well as by enterprises. An important requirement in data center 82 networks is multitenancy, i.e. multiple tenants each with their own 83 isolated network domain. Virtual eXtensible Local Area Network 84 (VXLAN) is a solution that is gaining popularity in industry 85 [RFC7348]. VXLAN overlays a Layer 2 network over a Layer 3 network. 86 Each overlay is identified by the VXLAN Network Identifier (VNI). 87 VXLAN tunnel end point (VTEP) can be hosted at the the hypervisor on 88 the server or higher above in the network. VXLAN encapsulation with 89 a UDP header is only known to the VTEP, the Virtual Machines (VM) 90 never sees it. 92 It should be noted that in this document, VTEP plays the role of the 93 Network Virtualization Edge (NVE) according to NVO3 architecture for 94 overlay networks like VXLAN or NVGRE defined in [I-D.ietf-nvo3-arch]. 96 NVE interfaces the tenant system underneath with the L3 network 97 called the Virtual Network (VN). 99 Since VXLAN allows multiple tenants to operate, data center operators 100 are facing the problem of treating their traffic. There is interest 101 to provide different quality of service to the tenants based on their 102 service level agreements, i.e. tenant-based QoS. 104 Cloud carriers have interest in different quality of service to 105 different applications such as voice, video, network control 106 applications, etc. In this case, quality of service marking can be 107 done using deep packet inspection (DPI) in order to detect the type 108 of application in each packet, i.e. application based QoS. 110 In this document, we develop Quality of Service marking solution for 111 VXLAN as part of the Quality of Service framework for overlay multi- 112 tenant networks as such it complements VXLAN architecture defined in 113 [RFC7348]. The solution is compatible with IP level Differentiated 114 Services model or diffserv described in [RFC2474] and [RFC2475]. 115 Configuration guidelines are described in [RFC4594]. Diffserv 116 interconnection classes and interconnection practice are described in 117 [I-D.geib-tsvwg-diffserv-intercon]. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. The 124 terminology in this document is based on the definitions in 125 [RFC7348]. 127 3. Problem Statement 129 In an overlay network such as VXLAN network multiple tenants are 130 supported. There is interest in assigning different priority to each 131 tenant's traffic based on the premium that tenant pays, etc. In 132 another words, cloud carriers would like to categorize tenants into 133 different traffic classes such as diamond, gold, silver and bronze 134 classes. 136 Cloud carriers wish to categorize the traffic based on the 137 application such as voice, video, etc. Based on the type of the 138 application different traffic classes may be identified and different 139 priority levels can be assigned to each. 141 In order to do these, quality of service marking is needed in the 142 overlay network. 144 The solution developed in this document is based on the Network 145 Virtualization Edge (NVE) to do the marking at the encapsulation 146 layer. The marking, especially the tenant based QoS marking has to 147 be done when the frames are introduced by the virtual machines (VM) 148 because it is the encapsulation layer that adds the tenant 149 identification, e.g. VXLAN Network Identifier (VNI) to each frame 150 coming from the VMs. Because of this tenant based Quality of Service 151 marking SHOULD be done at the encapsulation layer. 153 4. QoS Marking Schemes in VXLAN 155 Three bits are reserved in VXLAN Outer Ethernet Header's C-Tag 802.1Q 156 field/VLAN Tag Information field's priority code point (PCP) field 157 shown as QoS-flag in Figure 1. 159 Three bits called QoS-flag are reserved to indicate the quality of 160 service class that this packet belongs. These bits will be assigned 161 according to the type of traffic carried in this flow, e.g. video, 162 voice, critical application, etc. These assignments in relation to 163 IP level Differentiated Services model, diffserv bits or DS field, 164 are discussed in Section 7. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | |Q o S| | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1: QoS Flag 174 Priority code point bits are assigned as follows in IEEE 802.1p 175 [IEEE802.1D]: 177 001 - BK or background traffic 179 000 - BE or best effort traffic 181 010 - EE or Excellent Effort 183 011 - CA or Critical Applications 185 100 - VI or Video 187 101 - VO or Voice 189 110 - IC or Internetwork Control 190 111 - NC or Network Control 192 '111' has the highest priority while '001' has the lowest, for 193 example, video traffic has higher priority than web surfing which is 194 best effort traffic. 196 IEEE 802.1p [IEEE802.1D] based PCP marking is supported by most 197 switches currently deployed that have the QoS capabilities. 199 We propose two different mappings to make use of the QoS field, 200 tenant based marking or application based marking. Both of these 201 markings are compatible with IEEE 802.1p PCP marking as well as the 202 class selector codepoints defined by diffserv. 204 4.1. Tenant Based Marking 206 Tenant based marking is based on tenancy priorities. The cloud 207 carrier categorizes its tenants into different groups such as 208 diamond, gold, silver, bronze, standard and so on. All traffic for a 209 diamond tenant has a high priority to be forwarded regardless of 210 application types. The below is the mapping proposed in this 211 document. 213 001 - Reserved 215 000 - Standard 217 010 - Bronze 219 011 - Silver 221 100 - Gold 223 101 - Diamond 225 110 - Emergency 227 111 - Reserved 229 The sender SHOULD assign bits 16-18 with bits assigned values as 230 above if the quality of service treatment is needed on this packet. 231 The sender SHOULD assign the same bit pattern to all the packets of 232 the same tenant, i.e. the same VNI value. 234 4.2. Application Based Marking 236 This marking is based on application priorities. NVE uses some 237 mechanism such as Deep Packet Inspection (DPI) to identify 238 application types, and fills in the QoS field based on the identified 239 application types. The below is a possible mapping. 241 001 - Reserved 243 000 - ftp/email 245 010 - Facebook, Twitter, Social Media 247 011 - Instant Message 249 100 - video 251 101 - voice 253 110 - High Performance computation 255 111 - Reserved 257 The sender SHOULD assign bits 16-18 with bits assigned values as 258 above if the quality of service treatment is needed on this packet. 259 The sender SHOULD assign the same bit pattern to all the packets of 260 the same flow. 262 4.3. QoS Bits in Outer IP Header 264 Outer IPv4 header in VXLAN has type of service (TOS) field of 8 bits. 265 Outer IPv6 header is VXLAN has traffic class field of 8 bits. 267 In case virtual machines are differentiated services capable, inner 268 IP header contains per hop behavior (PHB) settings inline with 269 diffserv RFCs. VXLAN NVE SHOULD copy inner IP header QoS bits into 270 outer IP header bits. 272 In case virtual machines are not differentiated services capable, 273 outer IP header QoS bits MUST be assigned by VXLAN NVE. VXLAN NVE 274 SHOULD assign one of the class selector (CS) codepoints with value 275 'xxx000' corresponding to the marking explained above if the packet 276 is a unicast packet. For more details, see Section 7. 278 5. Quality of Service Operation at VXLAN Decapsulation Point 280 There are two types of VXLAN packets receivers, that is, a VXLAN 281 enabled NVE or a VXLAN gateway [I-D.sarikaya-nvo3-proxy-vxlan]. 283 When the VXLAN enabled NVE receives the packet, it decapsulates the 284 packet and delivers it downstream to a corresponding VM. If there 285 are multiple packets to be processed, packets with high priority 286 (that is higher QoS value) should be processed first. 288 The QoS operation is different for the VXLAN gateway processing. The 289 gateway which provides VXLAN tunnel termination functions could be 290 ToR/access switches or switches higher up in the data center network 291 topology. For incoming frames on the VXLAN connected interface, the 292 gateway strips out the VXLAN header and forwards to a physical port 293 based on the destination MAC address of the inner Ethernet frame. If 294 inner VLAN is included in the VXLAN frame or a VLAN is supposed to be 295 added based on configuration, the VXLAN gateway decapsulates the 296 VXLAN packet and remarks the QoS field of the outgoing Ethernet frame 297 based on VXLAN Outer Ethernet Header QoS bits. The switch SHOULD 298 copy the Q-Flags of VXLAN Outer Ethernet Header into IEEE 802.1p 299 Priory Code Point (PCP) field in VLAN tag. 301 6. Quality of Service Operation at VXLAN Encapsulation Point 303 There are two types of VXLAN packet senders, that is, a VXLAN enabled 304 NVE or a VXLAN gateway. 306 For a VXLAN enabled NVE, the upstream procedure is: 308 Reception of Frames 310 The VXLAN enabled NVE receives an Ethernet packet from a hosting 311 VM. 313 Lookup 315 Making use of the destination of the Ethernet packet, the VXLAN 316 enabled NVE looks up MAC-NVE mapping table, and retrieves IP 317 address of destination NVE. 319 Acquisition of QoS parameters 321 There are two different ways to acquire QoS parameters for VXLAN 322 encapsulation. The first is a dynamic one which requires a VXLAN 323 enabled NVE has Deep Packet Inspection (DPI) capability and can 324 identify different application types. The second is a static one 325 which requires a VM manager to assign QoS parameters to different 326 VNIs based on premium that different tenancies pay. 328 Encapsulation of frames 330 The NVE then encapsulates the packet using VXLAN format with 331 acquired QoS parameters and VNI. The specific format is given in 332 Section 4. After the frame is encapsulated it is sent out 333 upstream to the network. 335 For a VXLAN gateway, packets are encapsulated using VXLAN format with 336 QoS field in a similar way. Once the VXLAN gateway receives a packet 337 from a non-VXLAN domain, it encapsulates the packet with QoS 338 parameters which are acquired through DPI or priorities of tenancies. 340 7. QoS processing for VXLAN outer IP header 342 QoS is user experience of end-to-end network operation. A packet 343 from VM A to VM B normally traverses such network entities 344 sequentially as virtual switch A which is co-located with VM A, TOR 345 switch A, aggregation switch A, a core switch, aggregation switch B, 346 TOR switch B, virtual switch B. VXLAN processing only takes place in 347 virtual switches, and all other network entities only execute IP 348 forwarding. VXLAN QoS mapping to outer IP header at virtual switch A 349 is needed to achieve end-to-end QoS. 351 Six bits of the Differentiated Services Field (DS field) are used as 352 a codepoint (DSCP) to select the per hop behaviour (PHB) a packet 353 experiences at each node in a Differentiated Services Domain 354 [RFC2474]. DS field is 8 bits long, 6 bits of it are used as DSCP 355 and two bits are unused. DS field is carried in both IPv4 and IPv6 356 packet headers. 358 Using 6 bits of DS field, it is possible to define 64 codepoints. A 359 pool of 32 RECOMMENDED codepoints called Pool 1 is standardized by 360 IANA. 8 of these 32 codepoints are called class selector (CS) 361 codepoints, from CS0 corresponding to '000000' to CS7 corresponding 362 to '111000' codepoints. There are also 12 assured forwarding (AF) 363 codepoints [RFC2597], an expedited forwarding (EF) per hop behavior 364 [RFC3246] and VOICE-ADMIT codepoint for capacity-admitted traffic 365 [RFC5865]. In this document we use class selector codepoints. Other 366 codepoints are out of scope. 368 When a packet forwarded from non-VXLAN domain to VXLAN domain through 369 a VXLAN gateway, DSCP field of outer IP header for unicast packets 370 should be marked based on VXLAN QoS using the class selector 371 codepoints, i.e. 'xxx000' that corresponds to VXLAN QoS marking, i.e. 373 with xxx assigned based on static or dynamic QoS markings defined 374 above in Section 4. 376 8. Security Considerations 378 Special security considerations in [RFC7348] are applicable. 380 9. IANA considerations 382 None. 384 10. Acknowledgements 386 The authors are grateful to Brian Carpenter, David Black, Erik 387 Nordmark for their constructive comments on our work. 389 11. References 391 11.1. Normative References 393 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 394 converting network protocol addresses to 48.bit Ethernet 395 address for transmission on Ethernet hardware", STD 37, 396 RFC 826, November 1982. 398 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 399 1981. 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 405 "Definition of the Differentiated Services Field (DS 406 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 407 1998. 409 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 410 and W. Weiss, "An Architecture for Differentiated 411 Services", RFC 2475, December 1998. 413 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 414 "Assured Forwarding PHB Group", RFC 2597, June 1999. 416 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 417 J., Courtney, W., Davari, S., Firoiu, V., and D. 418 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 419 Behavior)", RFC 3246, March 2002. 421 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 422 Guidelines for DiffServ Service Classes", RFC 4594, August 423 2006. 425 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 426 Services Code Point (DSCP) for Capacity-Admitted Traffic", 427 RFC 5865, May 2010. 429 [I-D.ietf-nvo3-arch] 430 Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 431 Narten, "An Architecture for Overlay Networks (NVO3)", 432 draft-ietf-nvo3-arch-02 (work in progress), October 2014. 434 [IEEE802.1D] 435 IEEE, "Virtual Bridged Local Area Networks", IEEE Std 436 802.1D-2005, May 2006. 438 11.2. Informative References 440 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 441 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 442 eXtensible Local Area Network (VXLAN): A Framework for 443 Overlaying Virtualized Layer 2 Networks over Layer 3 444 Networks", RFC 7348, August 2014. 446 [I-D.geib-tsvwg-diffserv-intercon] 447 Geib, R. and D. Black, "DiffServ interconnection classes 448 and practice", draft-geib-tsvwg-diffserv-intercon-08 (work 449 in progress), November 2014. 451 [I-D.sarikaya-nvo3-proxy-vxlan] 452 Sarikaya, B. and F. Xia, "Virtual eXtensible Local Area 453 Network over IEEE 802.1Qbg", draft-sarikaya-nvo3-proxy- 454 vxlan-00 (work in progress), October 2014. 456 Authors' Addresses 458 Frank Xia 459 Huawei Technologies Co., Ltd. 460 101 Software Avenue, Yuhua District 461 Nanjing, Jiangsu 210012, China 463 Phone: ++86-25-56625443 464 Email: xiayangsong@huawei.com 465 Behcet Sarikaya 466 Huawei Technologies Co., Ltd. 467 5340 Legacy Dr. Building 3 468 Plano, TX 75024 470 Phone: +1 972-509-5599 471 Email: sarikaya@ieee.org 473 Shi Fan 474 China Telecom 475 Room 708, No.118, Xizhimennei Street 476 Beijing , P.R. China 100035 478 Phone: +86-10-58552140 479 Email: shifan@ctbri.com.cn