idnits 2.17.00 (12 Aug 2021) /tmp/idnits16191/draft-du-apn6-path-infomation-detection-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 24, 2021) is 324 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 (-05) exists of draft-li-apn-framework-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Du 3 Internet-Draft P. Liu 4 Intended status: Standards Track China Mobile 5 Expires: December 26, 2021 June 24, 2021 7 Path Information Detection in Application-aware IPv6 Networking 8 draft-du-apn6-path-infomation-detection-01 10 Abstract 12 This document introduces a method to detect path information in 13 Application-aware IPv6 Networking. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 26, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Current Mechanism in APN6 . . . . . . . . . . . . . . . . . . 2 57 3. Path Latency Information Detection . . . . . . . . . . . . . 3 58 4. Other Path Information Detection . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 8.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 Application-aware IPv6 Networking is a kind of self-identified 70 mechanism per packet. In the mechanism of APN6 71 [I-D.li-apn6-problem-statement-usecases], an IPv6 packet can carry 72 the APP ID information and SLA requirements of the traffic in its 73 Extension Headers. Therefore, the network equipment can analyze them 74 in each packet and handle the packet accordingly. 76 This novel mechanism can enable the negotiation between the user 77 traffic and the network. The network can supply proper treatment for 78 different kinds of user traffic. As a result of this flexible on- 79 demand SLA mechanism, the user can get a better experience, and the 80 network resource can be scheduled more efficiently. 82 However, the current mechanism in APN6 only enables a unidirectional 83 information notification, i.e., from the APP/user to the network. 84 The APP/user is not aware of the path information in the network. In 85 some cases, it is not sufficient. A bidirectional information 86 negotiation mechanism can enable a more powerful APN6 platform. 88 This document introduces the process of the path information 89 detection mechanism in APN6 by extending some IPv6 Extension Headers. 91 2. Current Mechanism in APN6 93 As shown in Figure 1, the APN framework [I-D.li-apn-framework] 94 includes App (Client and Server), App-aware Edge, App-aware-process 95 Head-End, App-aware-process Mid-Point, and App-aware-process End- 96 Point. 98 Client Server 99 +-----+ +-----+ 100 |App x|-\ /->|App x| 101 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 102 \->|App- | |App-aware|-A-|App-aware|-A-|App-aware|-/ 103 User side |aware|-|process |-B-|process |-B-|process | 104 /->|Edge | |Head-End |-C-|Mid-Point|-C-|End-Point|-\ 105 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 106 |App y|-/ \->|App y| 107 +-----+ --------- Uplink ----------> +-----+ 109 Figure 1: Framework and Key Components in APN6 111 The data-driven process of APN6 is described below. 113 The APP or the APP-aware Edge will generate an APN packet which 114 carries the application characteristic information in the 115 encapsulation. The information may include application-aware 116 identification, such as SLA level, application ID, user ID, flow ID, 117 etc., and network performance requirements, such as bandwidth, 118 latency, jitter, packet loss ratio, etc. The former is recorded in 119 the Application-aware ID Options, and the latter is recorded in the 120 Service-Para Options defined in the [I-D.li-apn-framework]. 122 App-aware-process Head-End can read that information and steer the 123 packet into a given policy which satisfies the application 124 requirements. It is supposed that a set of paths, tunnels or SR 125 policies, exist between the App-aware-process Head-End and the App- 126 aware-process End-Point. App-aware-process Head-End can find one 127 existing path or establish a new one for the traffic. 129 3. Path Latency Information Detection 131 In the APN architecture, the user/APP can give a latency requirement 132 to the network, and the network will provide a low latency path for 133 the traffic. The path may be the one with the lowest latency among 134 the set of paths between the Head-End and the End-Point, or may be 135 one of the paths with a lower latency than the value carried in the 136 latency requirement TLV. However, the users/APPs do not know how 137 well the network handle the requirements, especially when the APPs 138 give multiple requirements. 140 An APP can easily obtain a bidirectional E2E latency, i.e., the sum 141 of the bidirectional network latency and the server latency, but it 142 does not know the exact network latency. The mechanism proposed in 143 this document can provide this information to the APP, and the APP 144 can confirm the network's SLA guarantee activity if needed. 146 In details, the APP can add a new Service-Para Option named Timestamp 147 Request TLV into the packet to indicate that it needs the timestamps 148 of the headend and the endpoint in the network. The headend and the 149 endpoint can read the TLV and add two new Timestamp TLVs in the IPv6 150 extension header, which contain the time that the packet reach the 151 headend and the endpoint respectively. Then, the server can receive 152 this specific packet with the Timestamp Request TLV and the two 153 Timestamp TLVs. The server can record the timestamps, and 154 encapsulate them into a packet that is about to be sent to the APP. 155 This packet can also include a Timestamp Request TLV. On the 156 converse direction, the headend and the endpoint in the network can 157 add another two Timestamp TLVs into the packet. Hence, the APP can 158 get four timestamps in total, and know the forwarding path latency 159 and the reverse path latency of the network. 161 4. Other Path Information Detection 163 The APP can also request other information by extending more Request 164 TLVs and Information TLVs in the IPv6 extension header. For example, 165 the APP can request to obtain the SR policy BSID in the Path 166 Information TLV. In this case, only the headend on the forwarding 167 direction needs to add information into the packet. As the 168 information needs to be handled by the server, the BSID can be stored 169 in DOH (Destination Options Header) of the packet. 171 When the APP has obtained the BSID, it can add it into the SID list 172 contained in the packet or into a new Service-Para Option. The 173 headend can directly steer the traffic to a specific SR Policy 174 according to that information. Therefore, it only needs to analyze 175 the several packets in the traffic at the beginning, and does not 176 need to analyze the following packets with BSID in the traffic in 177 details. 179 Another example is about dynamic load balance. Nowadays, the load 180 balance in the network, such as the ECMP or weighted-ECMP, is based 181 on pre-configured weight. As an example, in an SR policy, different 182 candidate paths may have different 183 weights[I-D.ietf-spring-segment-routing-policy]. We assume two SID 184 lists, List1 and List2, have weight 1 and weight 5 respectively. In 185 this static load balance, more traffic will be steered to List2 186 because it has a large weight. However, even if the candidate path 187 following List2 is congested, and the candidate path following List1 188 is light-loaded, no mechanism can enable new-coming traffic to use 189 List1 more than before. In other words, we can not adjust the weight 190 ratio from 1:5 to 1:3. It is because that if we change it, some 191 traffic used to follow List2 will be moved to the path following 192 List1, and misorder may take place. 194 With the help of the path information detection methods in this 195 document, a flow can be aware of the candidate path it follows, and 196 carry an ID of the candidate path in the IPv6 header. The load 197 balance point in the network can use it to steer the flow traffic 198 directly, bypassing the load balance process. In this situation, for 199 the dynamic path-attached traffic, the load balance point can use a 200 dynamic weight, which may be influenced by the traffic load in the 201 candidate paths. When a new flow comes, it can be load-balanced by 202 using the dynamic weight. 204 5. IANA Considerations 206 TBD. 208 6. Security Considerations 210 TBD. 212 7. Acknowledgements 214 TBD. 216 8. References 218 8.1. Normative References 220 [I-D.li-apn-framework] 221 Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., 222 Ebisawa, K., Previdi, S., and J. N. Guichard, 223 "Application-aware Networking (APN) Framework", draft-li- 224 apn-framework-02 (work in progress), February 2021. 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, 228 DOI 10.17487/RFC2119, March 1997, 229 . 231 8.2. Informative References 233 [I-D.ietf-spring-segment-routing-policy] 234 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 235 P. Mattes, "Segment Routing Policy Architecture", draft- 236 ietf-spring-segment-routing-policy-11 (work in progress), 237 April 2021. 239 [I-D.li-apn6-problem-statement-usecases] 240 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 241 Ebisawa, K., Previdi, S., and J. N. Guichard, "Problem 242 Statement and Use Cases of Application-aware IPv6 243 Networking (APN6)", draft-li-apn6-problem-statement- 244 usecases-01 (work in progress), November 2019. 246 Authors' Addresses 248 Zongpeng Du 249 China Mobile 250 No.32 XuanWuMen West Street 251 Beijing 100053 252 China 254 Email: duzongpeng@foxmail.com 256 Peng Liu 257 China Mobile 258 No.32 XuanWuMen West Street 259 Beijing 100053 260 China 262 Email: liupengyjy@chinamobile.com