idnits 2.17.00 (12 Aug 2021) /tmp/idnits16005/draft-fu-panrg-path-selection-req-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2021) is 306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-idr-performance-routing' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-panrg-path-properties' is defined on line 259, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-panrg-questions' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-dyncast-ps-usecases' is defined on line 269, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-irtf-panrg-path-properties-02 == Outdated reference: draft-irtf-panrg-questions has been published as RFC 9217 == Outdated reference: A later version (-03) exists of draft-liu-dyncast-ps-usecases-01 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANRG Y. Fu 3 Internet-Draft P. Liu 4 Intended status: Informational China Mobile 5 Expires: January 13, 2022 July 12, 2021 7 Requirements of applying path-aware networking for dynamic path 8 selection 9 draft-fu-panrg-path-selection-req-00 11 Abstract 13 Emerging new services have new business characteristics, different 14 from traditional C/S business model, whose most traffic is downstream 15 traffic, more and more new business with gradually increasing 16 upstream traffic have appeared, such as short videos, live sales etc, 17 . Due to the new traffic characteristics of these services, more 18 requirements have been put forward for the choice of network paths. 19 In addition, emerging services also put forward new requirements for 20 computing. Only selecting the network path or the service node 21 cannot meet the stringent requirements. The perception of network 22 paths and path selection also need to consider the characteristics of 23 the service, and further need to coordinate the state of the network 24 side and the service node side. The application of path-aware 25 networking can assist the terminal to better perceive the network 26 status, and also combine the status of the service node to achieve 27 on-demand, more fine-grained path selection. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 13, 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. On-demand awareness on paths and path properties . . . . . . 3 70 3. Definition and application of path property weight . . . . . 4 71 4. Service endpoint consideration in path-aware networking . . . 5 72 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 76 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 79 1. Introduction 81 In path-aware networking architecture, endpoints have the ability to 82 select or influence the path through the network used by any given 83 packet or flow. The network and transport layers explicitly expose 84 information about the path or paths available from one endpoint to 85 another, and to those endpoints and the applications running on them, 86 so that they can make this selection [draft-irtf-panrg-questions-09]. 87 This draft targets at the third question in [draft-irtf-panrg- 88 questions-09]: how can endpoints select paths to use for traffic in a 89 way that can be trusted by the network, the endpoints, and the 90 applications using them? 92 And this draft targets at the path selection use case of path-aware 93 networking, and we both consider the scenario that a set of paths to 94 the same destination and also the scenario that several destinations 95 with several paths. According to [draft-irtf-panrg-path-properties- 96 02], entities may select their paths to fulfill a specific goal, 97 e.g., related to security or performance, as an example of 98 performance related path selection, an entity may prefer paths with 99 performance properties that best match its traffic requirements. In 100 this draft, we target at the services with various traffic 101 requirements for upstream and downstream traffic and also with 102 requirements to service endpoint Different types of services have 103 different requirements to network: 105 1. For transmission-intensive services, the amount of data 106 transmitted is large, so the choice of network path affects the 107 entire service larger. 109 2. For computing-intensive services, the computing tasks of service 110 endpoint are complex and the choice of endpoint affect the entire 111 service is large 113 3. And traditional transmission-intensive services tend to have a 114 lot of downstream traffic, so they usually specify the downstream 115 path. 117 4. For transmission-intensive services with large upstream traffic, 118 such as short video and live broadcast, the upstream path matters a 119 lot so the perception and specification of upstream path is necessary 120 to meet service requirements. 122 So the terminal needs to be aware of both the status of the uplink 123 path and the downlink path, and specify the uplink path and the 124 downlink path based on service characteristics. What's more, for 125 computing-intensive services, the terminal still needs to be aware of 126 the status of service endpoint, and the path-aware networking also 127 need to consider the status of endpoint when select network path. 129 2. On-demand awareness on paths and path properties 131 For services with different requirements, when path-aware networking 132 is applied to realize path perception, it is necessary to dynamically 133 determine the perceived target paths and target path attributes, such 134 as perceiving the given upstream path or the given downstream path, 135 and perceiving path latency or path bandwidth [draft-irtf-panrg-path- 136 properties-02]. When user initiates a service request, path-aware 137 networking needs to analyses service requirements related to path- 138 awareness, including time sensitivity, traffic amount, and traffic 139 characteristics etc, and decide to be aware of which set of paths and 140 which path properties of them. So path-aware networking needs to 141 specify the following information: 143 1. Service requirements towards path-awareness 144 2. Target paths to be perceived 146 3. Target path properties to be perceived 148 For example, when a service with large amount of uplink traffic and 149 strict requirements on service latency is requested, path-aware 150 networking assign a set of uplink paths which are to be perceived, 151 and determine the target path property is path latency, and then 152 specify the above mentioned upstream paths to user, and then user 153 initiate uplink path detection packet towards given paths carrying 154 target path properties , and then the network nodes along the path 155 writes the required path properties information. With path-aware 156 networking, the given paths and corresponding properties are 157 obtained, and user can select optimal uplink path which meet service 158 requirements. 160 3. Definition and application of path property weight 162 In path-aware network, instead of using single MED value, other 163 properties such as Link Capacity or Link Usage could additionally be 164 used to improve load balancing or performance [I-D.ietf-idr- 165 performance-routing]. And more properties are required to be 166 considered for new emerging services [draft-irtf-panrg-path- 167 properties-02]. 169 The transmission of upstream traffic and downstream traffic, and also 170 data processing by the service endpoint form a complete service 171 process (face recognition, CLOUD A/VR, etc.). So the completion of 172 the service needs to consider multi-dimensional factors. 174 For path-aware networking, facing diverse service requirements and 175 multi-dimensional path properties, to solve the problem of how to 176 comprehensive select path considering service requirements, a new 177 parameter needs to be introduced: path property weight values, which 178 represent the weight of each path properties and are used to 179 comprehensively define the perceived multi-dimensional path 180 properties. And then the path-aware networking needs to specify the 181 following information: 183 1. Service requirements towards path-awareness 185 2. Target paths to be perceived 187 3. Target path properties to be perceived 189 4. Path property weight values of target path properties 190 For example, for requested services that require large uplink 191 bandwidth, path-aware networking need to define larger uplink path 192 bandwidth weight, and calculates the target "uplink path + downlink 193 path" pair based on the given weight value. 195 4. Service endpoint consideration in path-aware networking 197 Many emerging services not only put forward new requirements for the 198 network, but also put forward requirements for computing. For 199 services such as AR/VR, the budgets for computing delay and network 200 delay are almost equivalent [draft-liu-dyncast-ps-usecases-01] , 201 therefore, when path-aware network perceives paths, designates path 202 and selects paths, it also needs to consider the status of the 203 service endpoint. And then the path-aware networking needs to 204 specify the following information: 206 1. Service requirements towards path-awareness, including service 207 endpoint 209 2. Target service endpoints and properties 211 3. Target paths to be perceived corresponding to target service 212 endpoints 214 4. Target path properties to be perceived 216 5. Path property weight values of target path properties including 217 service endpoint 219 And when the requested service is a computationally intensive 220 service, the status of the service endpoint will have a greater 221 impact in the entire process. Therefore, it is also necessary to 222 select an optimal service endpoint to provide services. Path-aware 223 networking needs to generate multiple target paths for multiple 224 candidate service endpoints, and specify new path parameter weight 225 values towards target path properties and target service endpoint 226 status. 228 5. Summary 230 The dynamic path selection considering service requirements and 231 service characteristics has become one of the current technical 232 development directions. This draft analyzes the application of path- 233 aware networking to achieve the on-demand path awareness and service 234 endpoint awareness, and provides optimal path selection. 236 6. IANA Considerations 238 This document makes no request of IANA. 240 Note to RFC Editor: this section may be removed on publication as an 241 RFC. 243 7. Security Considerations 245 TBD 247 8. Acknowledgements 249 TBD 251 9. Normative References 253 [I-D.ietf-idr-performance-routing] 254 Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. 255 Jacquenet, "Performance-based BGP Routing Mechanism", 256 draft-ietf-idr-performance-routing-03 (work in progress), 257 December 2020. 259 [I-D.irtf-panrg-path-properties] 260 Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path 261 Properties", draft-irtf-panrg-path-properties-02 (work in 262 progress), February 2021. 264 [I-D.irtf-panrg-questions] 265 Trammell, B., "Current Open Questions in Path Aware 266 Networking", draft-irtf-panrg-questions-09 (work in 267 progress), April 2021. 269 [I-D.liu-dyncast-ps-usecases] 270 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 271 (Dyncast) Use Cases & Problem Statement", draft-liu- 272 dyncast-ps-usecases-01 (work in progress), February 2021. 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 Authors' Addresses 280 Yuexia Fu 281 China Mobile 282 Beijing 283 100053 284 China 286 Email: fuyuexia@chinamobile.com 288 Peng Liu 289 China Mobile 290 Beijing 291 100053 292 China 294 Email: liupengyjy@chinamobile.com