idnits 2.17.1 draft-li-6man-app-aware-ipv6-network-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 : ---------------------------------------------------------------------------- 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 (February 22, 2021) is 1159 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: 'RFC8200' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC3272' is defined on line 692, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-li-6man-hbh-fwd-hdr-00 == Outdated reference: A later version (-07) exists of draft-li-apn-framework-01 == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-01 == Outdated reference: A later version (-04) exists of draft-liu-apn-edge-usecase-02 == Outdated reference: A later version (-02) exists of draft-peng-apn-security-privacy-consideration-00 == Outdated reference: A later version (-03) exists of draft-zhang-apn-acceleration-usecase-01 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 0 errors (**), 0 flaws (~~), 9 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: August 26, 2021 C. Li 6 C. Xie 7 China Telecom 8 D. Voyer 9 Bell Canada 10 X. Li 11 Tsinghua University 12 P. Liu 13 China Mobile 14 C. Cao 15 China Unicom 16 K. Ebisawa 17 Toyota Motor Corporation 18 February 22, 2021 20 Application-aware IPv6 Networking (APN6) Encapsulation 21 draft-li-6man-app-aware-ipv6-network-03 23 Abstract 25 Application-aware IPv6 Networking (APN6) framework makes use of IPv6 26 encapsulation in order to convey the application-aware information 27 along with the data packet to the network so to facilitate the 28 service deployment and SLA guarantee. 30 This document defines the encodings of the application characteristic 31 information, for the APN6 framework, that can be exchanged between an 32 application or a network edge device such as CPE (Customer-Premises 33 Equipment) and the network infrastructure through the use of IPv6 34 extension headers. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 26, 2021. 59 Copyright Notice 61 Copyright (c) 2021 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. Demanding Applications . . . . . . . . . . . . . . . . . . . 3 79 3.1. Online Gaming . . . . . . . . . . . . . . . . . . . . . . 4 80 3.2. Video streaming . . . . . . . . . . . . . . . . . . . . . 4 81 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 82 5. APN6 Framework and Key Components . . . . . . . . . . . . . . 5 83 6. Application-aware Options . . . . . . . . . . . . . . . . . . 7 84 6.1. Application-aware ID Option . . . . . . . . . . . . . . . 8 85 6.2. Service-Para Option . . . . . . . . . . . . . . . . . . . 9 86 7. Locations for placing the Application-aware Options . . . . . 13 87 7.1. Hop-by-Hop Options Header (HBH) . . . . . . . . . . . . . 13 88 7.2. Destination Options Header (DOH) . . . . . . . . . . . . 13 89 7.3. Segment Routing Header (SRH) . . . . . . . . . . . . . . 13 90 7.3.1. SRH TLV . . . . . . . . . . . . . . . . . . . . . . . 13 91 7.3.2. SID Arguments Field . . . . . . . . . . . . . . . . . 13 92 7.3.3. SRH TAG field . . . . . . . . . . . . . . . . . . . . 13 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 97 10.2. Informative References . . . . . . . . . . . . . . . . . 14 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 100 1. Introduction 102 A multitude of applications are carried over the network, which have 103 varying needs for network bandwidth, latency, jitter, and packet 104 loss, etc. Some applications such as online gaming and live video 105 streaming have very demanding network requirements thereof require 106 special treatments in the network. However, in current networks, the 107 network and applications are decoupled, that is, the network is not 108 aware of the applications' requirements in a finer granularity. 109 Therefore, it is difficult to provide truly fine-granular traffic 110 operations for the applications and guarantee their SLA requirements. 111 Such guarantee would also be provided by adopting the hierarchical 112 orchestration and the interactions between the orchestrator and 113 multiple controllers, but it would take a very long time by going 114 through the control and management elements. Moreover, the 115 interfaces between those elements require standardizations. 117 This document proposes encapsulations for the Application-aware IPv6 118 Networking (APN6) framework, which makes use of IPv6 encapsulations 119 (i.e. Hop-by-Hop Options Header (HBH), Destination Options Header 120 (DOH), Segment Routing Header(SRH)) to convey the application-aware 121 information including the application-aware identifications and 122 network performance requirements along with the packet to the network 123 to facilitate the service deployment and SLA guarantee. The 124 application-aware options (i.e. Application-aware ID Option and 125 Service-Para Option) are defined, which can be used in the IPv6 126 encapsulations, including the above listed different IPv6 extension 127 headers, for this purpose. 129 2. Terminologies 131 APN: Application-aware Networking 133 APN6: Application-aware IPv6 Networking, i.e. the data plane of APN 134 is IPv6 136 DPI: Deep Packet Inspection 138 3. Demanding Applications 140 This section shows the various demanding requirements of some 141 applications. The traffic of these applications needs to be 142 differentiated from other types of traffic and applied with special 143 treatments in the network, that is, the network needs to be able to 144 provide fine-granular traffic operations and acceleration to these 145 demanding applications. 147 3.1. Online Gaming 149 Good network performance is normally a prerequisite for satisfactory 150 game play, especially for the online gaming. Shooting or racing 151 online gaming is normally based on quick action and needs to update 152 the game status in real time by continuously sending and receiving 153 updates to/from the game server and/or other players. The online 154 gaming is very sensitive to the network latency. 156 [I-D.zhang-apn-acceleration-usecase] describes the game acceleration 157 scenarios using APN. In these scenarios, APN can identify the 158 specific requirements of particular gaming applications, steer the 159 flows to the game processors close to the users, and provide SLA 160 guaranteed network services such as low latency and high reliability. 162 3.2. Video streaming 164 The network latency, jitter, bandwidth, and packet loss are the key 165 factors for the video streaming. Live video streaming has even more 166 strict requirements. High quality video source require more 167 bandwidth in order to stream properly. Real time streaming services 168 also require real time content delivery from the web server to the 169 end user ideally via carefully planned explicit TE paths. The online 170 gaming often involves live video streaming. 172 [I-D.liu-apn-edge-usecase] describes the various application 173 scenarios in edge computing to which the APN can be beneficial, 174 including augmented reality, cloud gaming and remote control, which 175 empowers the video business, users interaction business and user- 176 device interaction business. In those scenarios, APN can identify 177 the specific requirements of edge computing applications on the 178 network, process close to the users, provide SLA guaranteed network 179 services such as low latency and high reliability. 181 4. Problem Statement 183 A number of IETF activities that have been or are being conducted, 184 e.g. DiffServ, primarily intend to evolve the IP architecture to 185 support new service definitions which allow preferential or 186 differentiated treatment to be applied to certain types of traffic. 187 The challenge when using traditional ways to guarantee SLA is that 188 the packets are not able to carry enough information to express 189 differentiated service requirements of various applications. The 190 network devices mainly rely on the 5-tuple of the packets which 191 cannot accurately identify applications and provide fine-grained 192 service treatments accordingly. If more information is needed, it 193 has to refer to DPI which will introduce more cost in the network and 194 impose security challenges. 196 In the era of SDN the orchestrator is introduced for the 197 orchestration of applications and the network. The SDN controller 198 can be aware of the service requirements of the applications on the 199 network through the interface interworking with the orchestrator. 200 The service requirements is used by the controller for traffic 201 management. However, the method raises the following problems: 1) 202 The whole loop is long and time-consuming which is not suitable for 203 the real-time adjustment for applications; 2) Too many interfaces are 204 involved in the loop which proposes more challenges of 205 standardization and inter-operability, and it is difficult to be 206 standardized for easy interworking. 208 5. APN6 Framework and Key Components 210 Application-aware Networking (APN) Framework is introduced in 211 [I-D.li-apn-framework] in more details. When the data plane of APN 212 is IPv6, it is APN6. Both frameworks share the same diagram, as 213 shown in Figure 1. 215 Client Server 216 +-----+ +-----+ 217 |App x|-\ /->|App x| 218 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 219 \->|App- | |App-aware|-A-|App-aware|-A-|App-aware|-/ 220 User side |aware|--|process |-B-|process |-B-|process | 221 /->|Edge | |Head-End |-C-|Mid-Point|-C-|End-Point|-\ 222 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 223 |App y|-/ \->|App y| 224 +-----+ ---------- Uplink ----------> +-----+ 226 Figure 1 APN6 Framework and Key Components 228 The key components of the APN6 framework include Service-aware App, 229 App-aware Edge Device, App-aware-process Head-End, App-aware-process 230 Mid-Point, and App-aware-process End-Point, which are introduced as 231 follows. 233 1. Service-aware App: The IPv6 enabled application that runs in the 234 host obtains application characteristic information and encapsulate 235 the packet with an IPv6 header that can, optionally, include an 236 extension header with the application characteristic information. 237 The application characteristic information (i.e. application-aware 238 information) includes the following information: 240 o Application-aware identification information: identifies the 241 application (group), the user (group), and their SLA requirements, 242 indicating that all packets belonging to the same flow will be 243 given the same treatment by the network. 245 o Service requirements information: specifying at least one of the 246 following parameters: bandwidth, delay, delay variation, packet 247 loss ratio, security, etc. 249 If the application characteristic information is carried in the IPv6 250 packet, this information is used by the App-aware-process Head-End to 251 determine the path between the App-aware-process Head-End and the 252 App-aware-process End-Point for forwarding the packet to its 253 destination, that is, to steer the packet into a given policy which 254 satisfies the application's requirements. If it is an SRv6 network 255 and the SRv6 head-end receives the IPv6 packets carrying the 256 application characteristic information, the SRv6 head-end will steer 257 the traffic into an SRv6 policy/path that can satisfy its SLA 258 requirements [I-D.ietf-spring-srv6-network-programming]. If the path 259 cannot be found, the setup of a new path will be triggered. 261 In APN6, if the application characteristic information is directly 262 added by the application and carried in the IPv6 packet sent by the 263 host, it is called "Application-side Solution". 265 2. App-aware Edge Device: This network device receives packets from 266 IPv6 enabled applications and obtains the application characteristic 267 information. If the application is not Service-aware App, the 268 application characteristic information can be obtained by packet 269 inspection, derived from service information such as double VLAN 270 tagging QinQ (C-VLAN and S-VLAN), or added according to the local 271 policies, which is out of the scope of this document. The App-aware 272 Edge Device adds the application characteristic information into the 273 packet on behalf of the application. The packets carrying the 274 application characteristic information will be sent to the App-aware- 275 process Head-End, and the application characteristic information will 276 be used to determine the path between the App-aware-process Head-End 277 and the App-aware-process End-Point for forwarding the packets. 279 In APN6, if the application characteristic information is not 280 directly added by the IPv6 enabled application but inferred at the 281 App-aware Edge Device, it is called "Network-side Solution". 283 3. App-aware-process Head-End: This network device receives packets 284 and obtains the application characteristic information. A set of 285 paths, tunnels or SR/SRv6 policy, exist between the App-aware-process 286 Head-End and the App-aware-process End-Point. The App-aware-process 287 Head-End maintains a mapping between the application characteristic 288 information and the paths between the App-aware-process Head-End and 289 the App-aware-process End-Point. The App-aware-process Head-End 290 determines the path between the App-aware-process Head-End and the 291 App-aware-process End-Point according to the application 292 characteristic information carried in the packet and the 293 corresponding mapping, which satisfies the service requirements of 294 the application. If there is no such mapping path found, the App- 295 aware-process Head-End can set up a path towards the App-aware- 296 process End-Point, and the mapping will be stored. The App-aware- 297 process Head-End forwards the packets along the path. The 298 application information conveyed by the IPv6 packet can also be 299 copied into the outer IPv6 packet for further application-aware 300 process. 302 4. App-aware-process Mid-Point: The Mid-Point provides the 303 application-aware path service according to the path set up by the 304 App-aware-process Head-End which satisfies the service requirements 305 conveyed by the IPv6 packet. The Mid-Point may also adjust the 306 resource locally in order to guarantee the service requirements 307 depending on a specific policy and the application-aware information 308 conveyed by the IPv6/SRv6 packet. Policy definitions and mechanisms 309 are out of the scope of this document. 311 5. App-aware-process End-Point: The process of the specific service 312 path will end at the End-Point. The service requirements information 313 can be removed at the End-Point together with the outer IPv6 314 encapsulation or go on to be conveyed with the IPv6 packets if the 315 Application-side Solution is used. 317 In this way, the network is aware of the applications and their 318 requirements. According to the application characteristic 319 information carried in the IPv6 packets the network is able to adjust 320 its resources fast in order to satisfy the service requirement of 321 applications. The flow-driven method also reduces the challenges of 322 inter-operability and long control loop. 324 6. Application-aware Options 326 In order to support the Application-aware IPv6 networking, two 327 application-aware options are defined: 329 o Application-aware ID Option 331 o Service-Para Option 333 6.1. Application-aware ID Option 335 The Application-aware ID option indicates the information of 336 application (group), the user (group), and their SLA and service 337 requirements, as illustrated in the following figure: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Opt Type | Opt Data Len | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 + Application-aware ID + 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 3. Application-aware ID Option 351 Opt Type: Type value is TBD1. 8-bit unsigned integer. Identifier of 352 the type of this Application-aware ID Option. 354 Opt Data Len: 8-bit unsigned integer. Length of the Option Data 355 field of this option, that is, length of the Application-aware ID, 356 recommended to be 16 octets. 358 Option Data: Option-Type-specific data. It carries Application-aware 359 ID. 361 The Application-aware ID has one of the following suggested 362 structures: 364 -- Structure I: Any combination of SLA level (e.g. Gold, Silver, 365 Bronze), APP ID, and/or user ID, and/or flow ID. The length of each 366 field is variable, as shown in the following diagram: 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | SLA Level | APP ID | User ID | Flow ID | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 4. Application-aware ID Structure I 374 SLA Level: The level of SLA requirement such as Gold, Silver, Bronze. 375 In some cases, color (e.g. red, green) can be used to indicate the 376 SLA level. 378 APP ID: The identifier of the application (group) of the traffic. 380 User ID: The user of the application (group) of the traffic. 382 Flow ID: The particular flow of the application traffic. 384 -- Structure II: Any combination of SLA level (e.g. Gold, Silver, 385 Bronze), APP ID, and/or user ID, and/or flow ID plus the arguments 386 which indicating the service requirements (e.g. upper boundary of the 387 latency: 10ms), as shown in the following diagram: 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | SLA Level| APP ID | User ID | Flow ID | Arguments | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 5. Application-aware ID Structure II 395 -- Structure III: An SRv6 SID, with its arguments as the information 396 specified in Structure I or II, as shown in the following diagram: 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Locator Address | Function ID | Arguments | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 6. Application-aware ID Structure III 404 Section 7 introduces several locations that the Application-aware ID 405 option can be encapsulated in the IPv6 packet, e.g., Hop-by-Hop 406 Options Header and Destination Options Header, depending upon the 407 scenarios and implementation requirements. 409 6.2. Service-Para Option 411 The Service-Para Option is a variable-length option carrying multiple 412 service requirement parameters. Each service requirement parameter 413 is put into the corresponding Service-Para Sub-TLV, as shown in 414 Figure 7. This Option can be put into the IPv6 Hop-by-Hop Options 415 Header, Destination Options Header, and SRH TLV. 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 | Opt Type | Opt Data Len | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 . . 424 . Service-Para Sub-TLVs (Variable) . 425 . . 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 7. Service-Para Option 431 Opt Type: Type value is TBD2. 8-bit unsigned integer. Identifier of 432 the type of this Service-Para Option. 434 Opt Data Len: 8-bit unsigned integer. Length of the Option Data 435 field of this option, that is, length of the Service-Para Sub-TLVs. 437 Option Data: Option-Type-specific data. It carries Service-Para Sub- 438 TLVs. Variable-length field. 440 The corresponding Service-Para Sub-TLVs are shown in the following 441 figures, respectively. 443 1. Bandwidth Sub-TLV 445 This Bandwidth sub-TLV indicates the bandwidth requirement of 446 applications. The format of this sub-TLV is shown in the following 447 diagram: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length | Class Type | RESERVED | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Bandwidth | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 8. Bandwidth Sub-TLV 459 where: 461 Type: TBD3, the type of the Bandwidth Sub-TLV. 463 Length: 6 octets, the length of the data field of the Bandwidth Sub- 464 TLV. 466 Class Type: The Bandwidth Type. 468 RESERVED: This field is reserved for future use. It MUST be set to 0 469 when sent and MUST be ignored when received. 471 Bandwidth: This field carries the bandwidth requirement in Mbps along 472 the path. 474 2. Delay Sub-TLV 476 This Delay Sub-TLV indicates the delay requirement. The format of 477 this sub-TLV is shown in the following diagram: 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type | Length | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | RESERVED | Delay | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Figure 9. Delay Sub-TLV 489 where: 491 Type: TBD4, the type of the Delay Sub-TLV. 493 Length: 4 octets, the length of the data field of the Delay Sub-TLV. 495 RESERVED: This field is reserved for future use. It MUST be set to 0 496 when sent and MUST be ignored when received. 498 Delay: This 24-bit field carries the delay requirements in 499 microseconds, encoded as an integer value. When set to the maximum 500 value 16,777,215 (16.777215 sec), then the delay is at least that 501 value and may be larger. This value is the highest delay that can be 502 tolerated. 504 3. Delay Variation Sub-TLV 506 This Delay Variation Sub-TLV indicates the delay variation 507 requirement. The format of this sub-TLV is shown in the following 508 diagram: 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type | Length | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | RESERVED | Delay Variation | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Figure 10. Delay Variation Sub-TLV 520 where: 522 Type: TBD5, the type of the Delay Variation Sub-TLV. 524 Length: 4 octets, the length of the data field of the Delay Variation 525 Sub-TLV. 527 RESERVED: This field is reserved for future use. It MUST be set to 0 528 when sent and MUST be ignored when received. 530 Delay Variation: This 24-bit field carries the delay variation 531 requirements in microseconds, encoded as an integer value. 533 4. Packet Loss Ratio Sub-TLV 535 This Packet Loss Ratio Sub-TLV indicates the packet loss ratio 536 requirement. The format of this sub-TLV is shown in the following 537 diagram: 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Type | Length | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | RESERVED | Packet Loss Ratio | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 11. Packet Loss Ratio Sub-TLV 549 where: 551 Type: TBD6, the type of the Packet Loss Ratio Sub-TLV. 553 Length: 4 octets, the length of the data field of the Packet Loss 554 Ratio Sub-TLV. 556 RESERVED: This field is reserved for future use. It MUST be set to 0 557 when sent and MUST be ignored when received. 559 Packet Loss Ratio: This 24-bit field carries packet loss ratio 560 requirement in packets per second. This value is the highest packet- 561 loss ratio that can be tolerated. 563 7. Locations for placing the Application-aware Options 565 The Application-aware options can be placed in several locations in 566 the IPv6 packet header depend upon the scenarios and implementation 567 requirements. 569 7.1. Hop-by-Hop Options Header (HBH) 571 The application-aware options can be carried in the Hop-by-Hop 572 Options Header as new options. By using the HBH Options Header, the 573 information carried can be read by every node along the path. 574 However, the current processing of the HBH Options Header goes to the 575 slow path, which will decrease the forwarding performance. A new 576 enhanced HBH Options Header is proposed in [I-D.li-6man-hbh-fwd-hdr] 577 in order to address the current limitations. 579 7.2. Destination Options Header (DOH) 581 The application-aware options can be carried in the Destination 582 Options Header as new options. 584 7.3. Segment Routing Header (SRH) 586 The Application-aware options can be placed in the segment routing 587 header (SRH), e.g., in the SRH TLV, the SID Arguments field, or the 588 TAG field. 590 7.3.1. SRH TLV 592 The Application-aware options can be placed in the SRH TLV. 594 7.3.2. SID Arguments Field 596 The Application-aware ID option can be put in the SID Arguments 597 field, which can be read by each node indicated by the SID in the SID 598 list. 600 7.3.3. SRH TAG field 602 The Application-aware ID option can be put in the TAG field, which 603 can be read by each node that processes the SRH. 605 8. IANA Considerations 607 IANA maintains the registry for the Options and Sub-TLVs. 609 Service-Para Option will require one new type code per sub-TLV 610 defined in this document: 612 Type | Description 614 ------------------------------------------------------------- 616 TBD1 | Application-aware ID Option 618 TBD2 | Service-Para Option 620 TBD3 | Bandwidth Sub-TLV 622 TBD4 | Delay Sub-TLV 624 TBD5 | Delay Variation Sub-TLV 626 TBD6 | Packet Loss Ratio Sub-TLV 628 9. Security Considerations 630 The Security Considerations described in 631 [I-D.li-apn-problem-statement-usecases] and 632 [I-D.peng-apn-security-privacy-consideration] can be referred to. 634 10. References 636 10.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 644 (IPv6) Specification", STD 86, RFC 8200, 645 DOI 10.17487/RFC8200, July 2017, 646 . 648 10.2. Informative References 650 [I-D.ietf-spring-srv6-network-programming] 651 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 652 Matsushima, S., and Z. Li, "SRv6 Network Programming", 653 draft-ietf-spring-srv6-network-programming-28 (work in 654 progress), December 2020. 656 [I-D.li-6man-hbh-fwd-hdr] 657 Li, Z. and S. Peng, "Hop-by-Hop Forwarding Options 658 Header", draft-li-6man-hbh-fwd-hdr-00 (work in progress), 659 July 2020. 661 [I-D.li-apn-framework] 662 Li, Z., Peng, S., Voyer, D., Li, C., Geng, L., Cao, C., 663 Ebisawa, K., Previdi, S., and J. Guichard, "Application- 664 aware Networking (APN) Framework", draft-li-apn- 665 framework-01 (work in progress), September 2020. 667 [I-D.li-apn-problem-statement-usecases] 668 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 669 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 670 Statement and Use Cases of Application-aware Networking 671 (APN)", draft-li-apn-problem-statement-usecases-01 (work 672 in progress), September 2020. 674 [I-D.liu-apn-edge-usecase] 675 Liu, P., Du, Z., Peng, S., and Z. Li, "Use cases of 676 Application-aware Networking (APN) in Edge Computing", 677 draft-liu-apn-edge-usecase-02 (work in progress), January 678 2021. 680 [I-D.peng-apn-security-privacy-consideration] 681 Peng, S., Li, Z., Voyer, D., Li, C., Liu, P., and C. Cao, 682 "APN Security and Privacy Considerations", draft-peng-apn- 683 security-privacy-consideration-00 (work in progress), 684 September 2020. 686 [I-D.zhang-apn-acceleration-usecase] 687 Zhang, S., Cao, C., Peng, S., and Z. Li, "Use cases of 688 Application-aware Networking (APN) in Game Acceleration", 689 draft-zhang-apn-acceleration-usecase-01 (work in 690 progress), December 2020. 692 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 693 Xiao, "Overview and Principles of Internet Traffic 694 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 695 . 697 Authors' Addresses 699 Zhenbin Li 700 Huawei Technologies 701 Beijing 100095 702 China 704 Email: lizhenbin@huawei.com 706 Shuping Peng 707 Huawei Technologies 708 Beijing 100095 709 China 711 Email: pengshuping@huawei.com 713 Cong Li 714 China Telecom 715 Beijing 102209 716 China 718 Phone: +86-10-50902556 719 Email: licong@chinatelecom.cn 721 Chongfeng Xie 722 China Telecom 723 Beijing 102209 724 China 726 Phone: +86-10-50902116 727 Email: xiechf@chinatelecom.cn 729 Daniel Voyer 730 Bell Canada 731 Canada 733 Email: daniel.voyer@bell.ca 735 Xing Li 736 Tsinghua University 737 China 739 Email: xing@cernet.edu.cn 740 Peng Liu 741 China Mobile 742 China 744 Email: liupengyjy@chinamobile.com 746 Chang Cao 747 China Unicom 748 China 750 Email: liuc131@chinaunicom.cn 752 Kentaro Ebisawa 753 Toyota Motor Corporation 754 Japan 756 Email: ebisawa@toyota-tokyo.tech