idnits 2.17.1 draft-li-6man-service-aware-ipv6-network-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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 22 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 (March 11, 2019) is 1866 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) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 12, 2019 March 11, 2019 7 Service-aware IPv6 Network 8 draft-li-6man-service-aware-ipv6-network-00 10 Abstract 12 A multitude of applications are carried over the network, which have 13 varying needs for network bandwidth, latency, jitter, and packet 14 loss, etc. Some applications such as online gaming and live video 15 streaming have very demanding network requirements thereof require 16 special treatments in the network. However, since the current 17 network is lack of enough information of service requirements of such 18 applications it is difficult to guarantee the SLA or it may take long 19 time to provide such guarantee. This document proposes the solution 20 to make use of IPv6 extensions header to convey the service 21 requirement information along with the packet to the network to 22 facilitate the service deployment and network resource adjustment to 23 guarantee SLA for applications. Then it defines the service-aware 24 options which can be used in the different IPv6 extension headers for 25 the purpose. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 12, 2019. 50 Copyright Notice 52 Copyright (c) 2019 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 (https://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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Online Gaming . . . . . . . . . . . . . . . . . . . . . . 3 70 2.2. Video streaming . . . . . . . . . . . . . . . . . . . . . 3 71 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 72 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 5. Service-aware Options . . . . . . . . . . . . . . . . . . . . 5 74 5.1. Service-aware ID Option . . . . . . . . . . . . . . . . . 5 75 5.2. Service-Para Option . . . . . . . . . . . . . . . . . . . 7 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 A multitude of applications are carried over the network, which have 86 varying needs for network bandwidth, latency, jitter, and packet 87 loss, etc. Some applications such as online gaming and live video 88 streaming have very demanding network requirements thereof require 89 special treatments in the network. However, since the current 90 network is lack of enough information of service requirements of such 91 applications it is difficult to guarantee the SLA or it may take long 92 time to provide such guarantee. This document proposes the solution 93 to take use of IPv6 extensions header to convey the service 94 requirement information along with the packet to the network to 95 facilitate the service deployment and network resource adjustment to 96 guarantee SLA for applications. Then it defines the service-aware 97 options which can be used in the different IPv6 extension headers for 98 the purpose. 100 2. Use Cases 102 This section shows the various demanding requirements of some 103 applications in the following use cases. The traffic of these 104 applications needs to be differentiated from other traffic and 105 applied with special treatments in the network. 107 2.1. Online Gaming 109 Good network performance is normally a prerequisite for satisfactory 110 game play, especially for the online gaming. The maximum allowable 111 ping rate (network latency) and the required minimum download/upload 112 speed (network bandwidth) are the key factors to make the online 113 gaming playable. Shooting or racing online gaming is normally based 114 on quick action and needs to update the game status in real time by 115 continuously sending and receiving updates to/from the game server 116 and/or other players. The network paths with low latency and low 117 packet loss need to be explicitly selected from the game players to 118 the game server. 120 2.2. Video streaming 122 The network latency, jitter, bandwidth, and packet loss are the key 123 factors for the video streaming. Live video streaming has even more 124 strict requirements. High quality video source (e.g. from Netflix) 125 require more bandwidth in order to stream properly. Real time 126 streaming services also requires real time content delivery from the 127 web server to the end user ideally via carefully planned explicit TE 128 paths. The online gaming often involves live video streaming. 130 3. Problem Statement 132 [RFC3272] reviews a number of IETF activities which are primarily 133 intended to evolve the IP architecture to support new service 134 definitions which allow preferential or differentiated treatment to 135 be accorded to certain types of traffic. The challenge when using 136 traditional ways to guarantee SLA is that the packets are not able to 137 carry enough information of service requirements of applications. 138 The network devices mainly relies on the 5-tuple of the packets which 139 cannot provide fine-grained service process. If more information is 140 needed, it has to refer to DPI which will introduce more cost in the 141 network and impose security challenges. 143 In the era of SDN the orchestrator is introduced for the 144 orchestration of applications and the network. The SDN controller 145 can be aware of the service requirements of the applications on the 146 network through the interface interworking with the orchestrator. 147 The service requirements is used by the controller for traffic 148 management. The method raises the following problems: 1) The whole 149 loop is long and time-consuming which is not suitable for the real- 150 time adjustment for applications; 2) Too many interfaces are involved 151 in the loop which proposes more challenges of standardization and 152 inter-operability, and it is difficult to be standardized for easy 153 interworking. 155 4. Framework 157 +-----+ +-----+ 158 |App x|----\ /---->|App x| 159 +-----+ | +-----------+ +--------+ +---------+ +---------+ | +-----+ 160 \--->| | | |---A---| |---A---| |---/ 161 |Edge Device|----|Head-End|---B---|Mid-Point|---B---|End-Point| 162 /--->| | | |---C---| |---C---| |---\ 163 +-----+ | +-----------+ +--------+ +---------+ +---------+ | +-----+ 164 |App y|----/ \---->|App y| 165 +-----+ +-----+ 167 Figure 1 Service-aware IPv6 Network 169 In the service-aware IPv6 network shown in Figure 1, there are 170 following components: 172 1. Service-aware Apps: The IPv6 enabled applications runs in the 173 host which can add the service requirements of the applications on 174 network through the IPv6 extension header ([RFC8200]) or remove it 175 from the IPv6 extension header. The service requirement information 176 includes the IPv6 service-aware ID which identifies the IPv6 packets 177 of the traffic belongs to the specific SLA level/Applications/User 178 and the parameters for the specific service such as bandwidth, delay, 179 delay variation, packet loss ratio, etc. The service requirements 180 will be processed by the IPv6 enabled nodes along the path or the 181 SRv6 ([I-D.filsfils-spring-srv6-network-programming]) enabled node 182 along the SRv6 path which be programmed in the host. The Apps can 183 also need not to add any service requirement information in the IPv6 184 extension header. 186 2. Service-aware Edge Device: The Edge Device can add the service 187 requirements of the applications on network through the IPv6 188 extension header on behalf of the IPv6 enabled applications or change 189 the service requirements conveyed by the packets of the service-aware 190 applications according to local policies which is out of the scope of 191 this document. The service requirements will be processed by the 192 IPv6 enabled nodes along the path or the SRv6 enabled node along the 193 SRv6 path which be programmed by the Edge Device. 195 3. Service-process Head-End: The service requirements may be 196 processed as a service path such as SRv6 TE path of SFC at the 197 Service-process Head-End. The service requirements conveyed in the 198 IPv6 packets can be mapped to a service path which satisfies the 199 specific requirement, trigger to set up the new service path by the 200 Head-End, or trigger the global traffic adjustment by the controller 201 according to the information provided by the network devices. The 202 process depends on the local policy which is out of the scope this 203 document. 205 4. Service-process Mid-Point: The Mid-Point provides the path 206 service according to the service path set up by the Head-End which 207 satisfies the service requirement conveyed by the IPv6 packets. The 208 Mid-Point may also adjust the resource locally to guarantee the 209 service requirements depending on specific policies which is out of 210 the scope of this document. 212 5. Service-process End-Point: The process of the specific service 213 path will end at the End-Point. The service requirements information 214 can be removed at the End-Point or go on to be conveyed with the IPv6 215 packets. 217 In this way the network is able to be aware of the service 218 requirements of the applications explicitly. According to these 219 service requirement information carried in the IPv6 packets the 220 network is able to adjust its resource fast to satisfy the service 221 requirement of applications. The flow-driven method also reduces the 222 challenges of inter-operability and loop control loop. 224 5. Service-aware Options 226 Two service-aware options are defined, i.e. Service-aware ID option 227 and Service-Para Option to support the Service-aware IPv6 network. 229 5.1. Service-aware ID Option 231 The Service-aware ID option indicates the information of the 232 applications, users, and service requirements, which is defined in 233 the following figure: 235 0 1 2 3 236 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Option Type | Opt Data Len | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 + + 242 | | 243 + IPv6 Service-aware ID + 244 | | 245 + + 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 2. IPv6 Service-aware ID Option 251 Option Type: TBD 253 Opt Data Len: 16 octets. 255 The IPv6 Service-aware ID is 128bits long which can have the 256 following structures: 258 -- Structure I: Any combination of SLA level (e.g. Gold, Silver, 259 Bronze), APP ID, and/or user ID. The length of each field is 260 variable, which is shown in the following diagram: 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | SLA Level | APP ID | User ID | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 3. IPv6 Service-aware ID Structure I 268 -- Structure II: Any combination of SLA level (e.g. Gold, Silver, 269 Bronze), APP ID, and/or user ID plus the arguments which indicates 270 the service requirements of the identified application, which is 271 shown in the following diagram: 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | SLA Level | APP ID | User ID | Arguments | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 4. IPv6 Service-aware ID Structure II 279 -- Structure III: An SRv6 SID, with its arguments as the information 280 specified in Structure 2, which is shown in the following diagram: 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Locator Address | Function ID | Arguments | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 5. IPv6 Service-aware ID Structure III 288 This Option can be put into the IPv6 Hop-by-Hop Options, Destination 289 Options, and SRH TLV ([I-D.ietf-6man-segment-routing-header]). 291 5.2. Service-Para Option 293 The Service-Para Option is a variable-length option carrying multiple 294 service requirement parameters. Each service requirement parameter 295 is put into the corresponding Service Para Sub-TLV, as shown in 296 Figure 6. This Option can be put into the IPv6 Hop-by-Hop Options, 297 Destination Options, and SRH TLV. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Option Type | Opt Data Len | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 . . 306 . Service Para Sub-TLVs(Variable) . 307 . . 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 6. IPv6 Service-Para Option 313 Option Type TBD 315 Opt Data Len 8-bit unsigned integer. Length of the 316 Service Para Sub-TLVs. 318 Service Para Sub-TLVs Variable-length field with Service 319 Para Sub-TLVs. 321 The corresponding Service Para Sub-TLVs are shown in the following 322 figures respectively. 324 1. BW Sub-TLV 326 This BW sub-TLV indicates the bandwidth requirement of applications. 327 The format of this sub-TLV is shown in the following diagram: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type | Length | Class Type | RESERVED | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Bandwidth | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 7. BW Sub-TLV 339 where: 341 Type: TBD 343 Length: 4 345 Class Type: The Bandwidth Type. 347 RESERVED: This field is reserved for future use. It MUST be set to 0 348 when sent and MUST be ignored when received. 350 Bandwidth: This field carries the bandwidth requirement along the 351 path. 353 2. Delay Sub-TLV 355 This Delay Sub-TLV indicates the delay requirement of applications. 356 The format of this sub-TLV is shown in the following diagram: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type | Length | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | RESERVED | Delay | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 8. Delay Sub-TLV 368 where: 370 Type: TBD 372 Length: 4 374 RESERVED: This field is reserved for future use. It MUST be set to 0 375 when sent and MUST be ignored when received. 377 Delay: This 24-bit field carries the delay requirements in 378 microseconds, encoded as an integer value. When set to the maximum 379 value 16,777,215 (16.777215 sec), then the delay is at least that 380 value and may be larger. This value is the highest delay that can be 381 tolerated. 383 3. Delay Variation Sub-TLV 385 This Delay Variation Sub-TLV indicates the delay variation 386 requirement of applications. The format of this sub-TLV is shown in 387 the following diagram: 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type | Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | RESERVED | Delay Variation | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 9. Delay Variation Sub-TLV 399 where: 401 Type: TBD 403 Length: 4 405 RESERVED: This field is reserved for future use. It MUST be set to 0 406 when sent and MUST be ignored when received. 408 Delay Variation: This 24-bit field carries the delay variation 409 requirements in microseconds, encoded as an integer value. 411 4. Packet Loss Ratio Sub-TLV 413 This Packet Loss Ratio Sub-TLV indicates the packet loss ratio 414 requirement of applications. The format of this sub-TLV is shown in 415 the following diagram: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type | Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | RESERVED | Packet Loss Ratio | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Figure 10. Packet Loss Ratio Sub-TLV 427 where: 429 Type: TBD 431 Length: 4 433 RESERVED: This field is reserved for future use. It MUST be set to 0 434 when sent and MUST be ignored when received. 436 Link Loss: This 24-bit field carries link packet loss ratio 437 requirement. This value is the highest packet-loss ratio that can be 438 tolerated. 440 6. IANA Considerations 442 IANA maintains the registry for the Options and Sub-TLVs. 444 Service-Para Option will require one new type code per sub-TLV 445 defined in this document: 447 Type Value 449 ---------------------------------------------------- 451 TBD Service-aware ID Option 453 TBD Service-Para Option 455 TBD BW Sub-TLV 457 TBD Delay Sub-TLV 459 TBD Delay Variation Sub-TLV 461 TBD Packet Loss Sub-TLV 463 7. Security Considerations 465 TBD 467 8. References 469 8.1. Normative References 471 [I-D.filsfils-spring-srv6-network-programming] 472 Filsfils, C., Camarillo, P., Leddy, J., 473 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 474 Network Programming", draft-filsfils-spring-srv6-network- 475 programming-07 (work in progress), February 2019. 477 [I-D.ietf-6man-segment-routing-header] 478 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 479 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 480 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 481 progress), February 2019. 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, 485 DOI 10.17487/RFC2119, March 1997, 486 . 488 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 489 (IPv6) Specification", STD 86, RFC 8200, 490 DOI 10.17487/RFC8200, July 2017, 491 . 493 8.2. Informative References 495 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 496 Xiao, "Overview and Principles of Internet Traffic 497 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 498 . 500 Authors' Addresses 502 Zhenbin Li 503 Huawei Technologies 504 Huawei Bld., No.156 Beiqing Rd. 505 Beijing 100095 506 China 508 Email: lizhenbin@huawei.com 509 Shuping Peng 510 Huawei Technologies 511 Huawei Bld., No.156 Beiqing Rd. 512 Beijing 100095 513 China 515 Email: pengshuping@huawei.com