idnits 2.17.1 draft-li-6man-app-aware-ipv6-network-01.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 (April 20, 2020) is 1467 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 (-28) exists of draft-ietf-spring-srv6-network-programming-15 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 0 errors (**), 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: October 22, 2020 C. Li 6 C. Xie 7 China Telecom 8 April 20, 2020 10 Application-aware IPv6 Networking 11 draft-li-6man-app-aware-ipv6-network-01 13 Abstract 15 A multitude of applications are carried over the network, which have 16 varying needs for network bandwidth, latency, jitter, and packet 17 loss, etc. Some applications such as online gaming and live video 18 streaming have very demanding network requirements thereof require 19 special treatments in the network. However, in current networks, the 20 network and applications are decoupled, that is, the network is not 21 aware of the applications' requirements in a finer granularity. 22 Therefore, it is difficult to provide truly fine-granular traffic 23 operations for the applications and guarantee their SLA requirements. 25 This document proposes a new framework, named Application-aware IPv6 26 Networking, and also the solution to guarantee SLA for applications, 27 which makes use of IPv6 extensions header in order to convey the 28 application related information including its requirements along with 29 the packet to the network so to facilitate the service deployment and 30 network resources adjustment. Then, it defines the application-aware 31 options which can be used in the different IPv6 extension headers for 32 the purpose. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on October 22, 2020. 57 Copyright Notice 59 Copyright (c) 2020 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 76 3. Demanding Applications . . . . . . . . . . . . . . . . . . . 4 77 3.1. Online Gaming . . . . . . . . . . . . . . . . . . . . . . 4 78 3.2. Video streaming . . . . . . . . . . . . . . . . . . . . . 4 79 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 80 5. App-aware IPv6 Networking Framework . . . . . . . . . . . . . 5 81 6. Application-aware Options . . . . . . . . . . . . . . . . . . 6 82 6.1. Application-aware ID Option . . . . . . . . . . . . . . . 7 83 6.2. Service-Para Option . . . . . . . . . . . . . . . . . . . 8 84 7. Locations for placing the Application-aware Options . . . . . 11 85 7.1. Hop-by-Hop Options Header (HBH) . . . . . . . . . . . . . 11 86 7.2. Destination Options Header (DOH) . . . . . . . . . . . . 11 87 7.3. Segment Routing Header (SRH) . . . . . . . . . . . . . . 12 88 7.3.1. SRH TLV . . . . . . . . . . . . . . . . . . . . . . . 12 89 7.3.2. SID Arguments Field . . . . . . . . . . . . . . . . . 12 90 7.3.3. SRH TAG field . . . . . . . . . . . . . . . . . . . . 12 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 95 10.2. Informative References . . . . . . . . . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 98 1. Introduction 100 A multitude of applications are carried over the network, which have 101 varying needs for network bandwidth, latency, jitter, and packet 102 loss, etc. Some applications such as online gaming and live video 103 streaming have very demanding network requirements thereof require 104 special treatments in the network. However, in current networks, the 105 network and applications are decoupled, that is, the network is not 106 aware of the applications' requirements in a finer granularity. 107 Therefore, it is difficult to provide truly fine-granular traffic 108 operations for the applications and guarantee their SLA requirements. 109 Such guarantee would also be provided by adopting the hierarchical 110 orchestration and the interactions between the orchestrator and 111 multiple controllers, but it would take a very long time by going 112 through the control and management elements. Moreover, the 113 interfaces between those elements require standardizations. 115 This document proposes a new framework, named Application-aware IPv6 116 Networking, and also the solution to guarantee SLA for applications, 117 which makes use of IPv6 extensions header (i.e. Hop-by-Hop Options 118 Header (HBH), Destination Options Header (DOH), Segment Routing 119 Header(SRH)) to convey the applications related information including 120 their identifiers and requirements along with the packet to the 121 network to facilitate the service deployment and network resource 122 adjustment. Then it defines the application-aware options (i.e. 123 application-aware ID option and service-aware para option), which can 124 be used in the above listed different IPv6 extension headers for the 125 purpose. 127 2. Terminologies 129 ASBR: Autonomous System Boundary Router 131 ASG: Aggregation Service Gateway 133 CPE: Customer-Premises Equipment 135 CSG: Cell Site Gateway 137 FBB: Fixed Broadband 139 MBB: Mobile Broadband 141 RG: Residential Gateway 143 RSG: Radio Service Gateway 145 3. Demanding Applications 147 This section shows the various demanding requirements of some 148 applications. The traffic of these applications needs to be 149 differentiated from other types of traffic and applied with special 150 treatments in the network, that is, the network needs to be able to 151 provide fine-granular traffic operations and acceleration to these 152 demanding applications. In return, the operators will get their 153 networks' revenue increased. 155 3.1. Online Gaming 157 Good network performance is normally a prerequisite for satisfactory 158 game play, especially for the online gaming. Shooting or racing 159 online gaming is normally based on quick action and needs to update 160 the game status in real time by continuously sending and receiving 161 updates to/from the game server and/or other players. The online 162 gaming is very sensitive to the network latency. 164 3.2. Video streaming 166 The network latency, jitter, bandwidth, and packet loss are the key 167 factors for the video streaming. Live video streaming has even more 168 strict requirements. High quality video source require more 169 bandwidth in order to stream properly. Real time streaming services 170 also require real time content delivery from the web server to the 171 end user ideally via carefully planned explicit TE paths. The online 172 gaming often involves live video streaming. 174 4. Problem Statement 176 [RFC3272] reviews a number of IETF activities which are primarily 177 intended to evolve the IP architecture to support new service 178 definitions which allow preferential or differentiated treatment to 179 be accorded to certain types of traffic. The challenge when using 180 traditional ways to guarantee SLA is that the packets are not able to 181 carry enough information of service requirements of applications. 182 The network devices mainly rely on the 5-tuple of the packets which 183 cannot provide fine-grained service process. If more information is 184 needed, it has to refer to DPI which will introduce more cost in the 185 network and impose security challenges. 187 In the era of SDN the orchestrator is introduced for the 188 orchestration of applications and the network. The SDN controller 189 can be aware of the service requirements of the applications on the 190 network through the interface interworking with the orchestrator. 191 The service requirements is used by the controller for traffic 192 management. The method raises the following problems: 1) The whole 193 loop is long and time-consuming which is not suitable for the real- 194 time adjustment for applications; 2) Too many interfaces are involved 195 in the loop which proposes more challenges of standardization and 196 inter-operability, and it is difficult to be standardized for easy 197 interworking. 199 5. App-aware IPv6 Networking Framework 201 Client Server 202 +-----+ +-----+ 203 |App x|-\ /->|App x| 204 +-----+ | +-----+ +--------+ +---------+ +---------+ | +-----+ 205 \->|App- | |App- |-A-|App- |-A-|App- |-/ 206 User side |aware|--|aware |-B-|aware |-B-|aware | 207 /->|Edge | |Head-End|-C-|Mid-Point|-C-|End-Point|-\ 208 +-----+ | +-----+ +--------+ +---------+ +---------+ | +-----+ 209 |App y|-/ \->|App y| 210 +-----+ ---------- Uplink ----------> +-----+ 212 Figure 1 App-aware IPv6 Network 214 In the application-aware IPv6 network shown in Figure 1, there are 215 following components: 217 1. Application-aware Apps: The IPv6 enabled applications runs in the 218 host which can optionally add the service requirements of the 219 applications in an IPv6 extension header ([RFC8200]) or remove it 220 from the IPv6 extension header. The service requirement information 221 includes: 223 o An IPv6 application-aware ID which identifies the IPv6 packets as 224 part of the traffic flow belonging to a specific SLA 225 level/Application/User; 227 o A set of parameters for the specific service such as bandwidth, 228 delay, delay variation, packet loss ratio, etc. 230 The service requirements will be processed by the IPv6 enabled nodes 231 along the path or the SRv6 232 ([I-D.ietf-spring-srv6-network-programming]) nodes along the SRv6 233 path. 235 2. App-aware Edge Device: The Edge Device can add the service 236 requirements of the applications on network through the IPv6 237 extension header on behalf of the IPv6 enabled applications or change 238 the service requirements conveyed by the packets of the application- 239 aware applications according to local policies which is out of the 240 scope of this document. The service requirements will be processed 241 by the IPv6 enabled nodes along the path or the SRv6 enabled node 242 along the SRv6 path which be programmed by the Edge Device. The 243 application information can also be encapsulated through L2 244 encapsulation or some tunnel encapsulations appended to the packet 245 depending on different application scenarios and device capability. 247 3. App-aware-process Head-End: The service requirements may be 248 processed as a service path such as a SRv6 Policy path of SFC at the 249 App-aware-process Head-End. The service requirements conveyed in the 250 IPv6 packets can be mapped to an existing service path or an existing 251 Policy which satisfies the specific requirement, trigger to set up 252 the new service path by the Head-End, or trigger the global traffic 253 adjustment by the controller according to the information provided by 254 the network devices. The process depends on the local policy which 255 is out of the scope this document. The application information 256 conveyed by the packet received from the App-aware Edge Device can 257 also be copied or be mapped to the out IPv6 extension header for 258 further application-aware process. 260 4. App-aware-process Mid-Point: The Mid-Point provides the path 261 service according to the service path set up by the Head-End which 262 satisfies the service requirement conveyed by the IPv6 packets. The 263 Mid-Point may also adjust the resource locally to guarantee the 264 service requirements depending on a specific policy and the 265 applicaton-aware information conveyed by the packet. Policy 266 definitions and mechanisms are out of the scope of this document. 268 5. App-aware-process End-Point: The process of the specific service 269 path will end at the End-Point. The service requirements information 270 can be removed at the End-Point together with the SRH or go on to be 271 conveyed with the IPv6 packets. 273 In this way the network is able to be aware of the service 274 requirements expressed by the applications explicitly. According to 275 the service requirement information carried in the IPv6 packets the 276 network is able to adjust its resources fast in order to satisfy the 277 service requirement of applications. The flow-driven method also 278 reduces the challenges of inter-operability and long control loop. 280 6. Application-aware Options 282 In order to support the Application-aware IPv6 networking, two 283 application-aware options are defined: 285 o Application-aware ID option 287 o Service-Para Option 289 6.1. Application-aware ID Option 291 The Application-aware ID option indicates the information of the 292 applications, users, and application requirements, as illustrated in 293 the following figure: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Option Type | Opt Data Len | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 + IPv6 Application-aware ID + 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3. IPv6 Application-aware ID Option 307 Option Type: TBD_1 309 Opt Data Len: 16 octets. 311 The IPv6 Application-aware ID is 128bits long which has one of the 312 following structures: 314 -- Structure I: Any combination of SLA level (e.g. Gold, Silver, 315 Bronze), APP ID, and/or user ID. The length of each field is 316 variable, as shown in the following diagram: 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | SLA Level | APP ID | User ID | Flow ID | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 4. IPv6 Application-aware ID Structure I 324 -- Structure II: Any combination of SLA level (e.g. Gold, Silver, 325 Bronze), APP ID, and/or user ID plus the arguments which indicating 326 the service requirements of the identified application, as shown in 327 the following diagram: 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | SLA Level| APP ID | User ID | Flow ID | Arguments | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 5. IPv6 Application-aware ID Structure II 335 -- Structure III: An SRv6 SID, with its arguments as the information 336 specified in Structure II, as shown in the following diagram: 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Locator Address | Function ID | Arguments | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 6. IPv6 Application-aware ID Structure III 344 6.2. Service-Para Option 346 The Service-Para Option is a variable-length option carrying multiple 347 service requirement parameters for specific application. Each 348 service requirement parameter is put into the corresponding Service- 349 Para Sub-TLV, as shown in Figure 6. This Option can be put into the 350 IPv6 Hop-by-Hop Options, Destination Options, and SRH TLV. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Option Type | Opt Data Len | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 . . 359 . Service-Para Sub-TLVs(Variable) . 360 . . 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 7. IPv6 Service-Para Option 366 Option Type TBD 368 Opt Data Len 8-bit unsigned integer. Length of the 369 Service-Para Sub-TLVs. 371 Service-Para Sub-TLVs Variable-length field with Service- 372 Para Sub-TLVs. 374 The corresponding Service-Para Sub-TLVs are shown in the following 375 figures respectively. 377 1. BW Sub-TLV 379 This BW sub-TLV indicates the bandwidth requirement of applications. 380 The format of this sub-TLV is shown in the following diagram: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type | Length | Class Type | RESERVED | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Bandwidth | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 8. BW Sub-TLV 392 where: 394 Type: TBD 396 Length: 4 398 Class Type: The Bandwidth Type. 400 RESERVED: This field is reserved for future use. It MUST be set to 0 401 when sent and MUST be ignored when received. 403 Bandwidth: This field carries the bandwidth requirement along the 404 path. 406 2. Delay Sub-TLV 408 This Delay Sub-TLV indicates the delay requirement of applications. 409 The format of this sub-TLV is shown in the following diagram: 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type | Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | RESERVED | Delay | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 9. Delay Sub-TLV 421 where: 423 Type: TBD 425 Length: 4 427 RESERVED: This field is reserved for future use. It MUST be set to 0 428 when sent and MUST be ignored when received. 430 Delay: This 24-bit field carries the delay requirements in 431 microseconds, encoded as an integer value. When set to the maximum 432 value 16,777,215 (16.777215 sec), then the delay is at least that 433 value and may be larger. This value is the highest delay that can be 434 tolerated. 436 3. Delay Variation Sub-TLV 438 This Delay Variation Sub-TLV indicates the delay variation 439 requirement of applications. The format of this sub-TLV is shown in 440 the following diagram: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type | Length | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | RESERVED | Delay Variation | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 10. Delay Variation Sub-TLV 452 where: 454 Type: TBD 456 Length: 4 458 RESERVED: This field is reserved for future use. It MUST be set to 0 459 when sent and MUST be ignored when received. 461 Delay Variation: This 24-bit field carries the delay variation 462 requirements in microseconds, encoded as an integer value. 464 4. Packet Loss Ratio Sub-TLV 466 This Packet Loss Ratio Sub-TLV indicates the packet loss ratio 467 requirement of applications. The format of this sub-TLV is shown in 468 the following diagram: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Type | Length | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | RESERVED | Packet Loss Ratio | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 11. Packet Loss Ratio Sub-TLV 480 where: 482 Type: TBD 484 Length: 4 486 RESERVED: This field is reserved for future use. It MUST be set to 0 487 when sent and MUST be ignored when received. 489 Link Loss: This 24-bit field carries link packet loss ratio 490 requirement. This value is the highest packet-loss ratio that can be 491 tolerated. 493 7. Locations for placing the Application-aware Options 495 The Application-aware options can be placed in several locations in 496 the IPv6 packet header depend upon the scenarios and implementation 497 requirements. 499 7.1. Hop-by-Hop Options Header (HBH) 501 The application-aware options can be carried in the Hop-by-Hop 502 Options Header as new options. By using the HBH Options Header, the 503 information carried can be read by every node along the path. 504 However, the current processing of the HBH Options Header goes to the 505 slow path, which will decrease the forwarding performance. 506 Therefore, we propose a new enhanced HBH Options Header in [I-D.li- 507 6man-enhanced-extension-header]. 509 7.2. Destination Options Header (DOH) 511 The application-aware options can be carried in the Destination 512 Options Header as new options. 514 7.3. Segment Routing Header (SRH) 516 The Application-aware options can be placed in the segment routing 517 header (SRH), e.g., in the SRH TLV, the SID Arguments field, or the 518 TAG field. 520 7.3.1. SRH TLV 522 The Application-aware options can be placed in the SRH TLV. 524 7.3.2. SID Arguments Field 526 The Application-aware ID option can be put in the SID Arguments 527 field, which can be read by each node indicated by the SID in the SID 528 list. 530 7.3.3. SRH TAG field 532 The Application-aware ID option can be put in the TAG field, which 533 can be read by each node that processes the SRH. 535 8. IANA Considerations 537 IANA maintains the registry for the Options and Sub-TLVs. 539 Application-Para Option will require one new type code per sub-TLV 540 defined in this document: 542 Type Value 544 ---------------------------------------------------- 546 TBD Application-aware ID Option 548 TBD Application-Para Option 550 TBD BW Sub-TLV 552 TBD Delay Sub-TLV 554 TBD Delay Variation Sub-TLV 556 TBD Packet Loss Sub-TLV 558 9. Security Considerations 560 TBD 562 10. References 564 10.1. Normative References 566 [I-D.ietf-spring-srv6-network-programming] 567 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 568 Matsushima, S., and Z. Li, "SRv6 Network Programming", 569 draft-ietf-spring-srv6-network-programming-15 (work in 570 progress), March 2020. 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, 574 DOI 10.17487/RFC2119, March 1997, 575 . 577 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 578 (IPv6) Specification", STD 86, RFC 8200, 579 DOI 10.17487/RFC8200, July 2017, 580 . 582 10.2. Informative References 584 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 585 Xiao, "Overview and Principles of Internet Traffic 586 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 587 . 589 Authors' Addresses 591 Zhenbin Li 592 Huawei Technologies 593 Huawei Bld., No.156 Beiqing Rd. 594 Beijing 100095 595 China 597 Email: lizhenbin@huawei.com 598 Shuping Peng 599 Huawei Technologies 600 Huawei Bld., No.156 Beiqing Rd. 601 Beijing 100095 602 China 604 Email: pengshuping@huawei.com 606 Cong Li 607 China Telecom 608 China Telecom Information Science&Technology Innovation 609 park, Beiqijia Town,Changping District 610 Beijing 102209 611 China 613 Phone: +86-10-50902556 614 Email: licong@chinatelecom.cn 616 Chongfeng Xie 617 China Telecom 618 China Telecom Information Science&Technology Innovation 619 park, Beiqijia Town,Changping District 620 Beijing 102209 621 China 623 Phone: +86-10-50902116 624 Email: xiechf@chinatelecom.cn