idnits 2.17.1 draft-du-apn6-path-infomation-detection-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 13, 2020) is 1383 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 (-07) exists of draft-li-apn-framework-00 Summary: 0 errors (**), 0 flaws (~~), 3 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 L. Geng 5 Expires: January 14, 2021 China Mobile 6 July 13, 2020 8 Path Information Detection in Application-aware IPv6 Networking 9 draft-du-apn6-path-infomation-detection-00 11 Abstract 13 This document introduces a method to detect path information in 14 Application-aware IPv6 Networking. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 14, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Current Mechanism in APN6 . . . . . . . . . . . . . . . . . . 2 58 3. Path Latency Information Detection . . . . . . . . . . . . . 3 59 4. Other Path Information Detection . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 8.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 Application-aware IPv6 Networking is a kind of self-identified 71 mechanism per packet. In the mechanism of APN6 72 [I-D.li-apn6-problem-statement-usecases], an IPv6 packet can carry 73 the APP ID information and SLA requirements of the traffic in its 74 Extension Headers. Therefore, the network equipment can analyze them 75 in each packet and handle the packet accordingly. 77 This novel mechanism can enable the negotiation between the user 78 traffic and the network. The network can supply proper treatment for 79 different kinds of user traffic. As a result of this flexible on- 80 demand SLA mechanism, the user can get a better experience, and the 81 network resource can be scheduled more efficiently. 83 However, the current mechanism in APN6 only enables a unidirectional 84 information notification, i.e., from the APP/user to the network. 85 The APP/user is not aware of the path information in the network. In 86 some cases, it is not sufficient. A bidirectional information 87 negotiation mechanism can enable a more powerful APN6 platform. 89 This document introduces the process of the path information 90 detection mechanism in APN6 by extending some IPv6 Extension Headers. 92 2. Current Mechanism in APN6 94 As shown in Figure 1, the APN framework [I-D.li-apn-framework] 95 includes App (Client and Server), App-aware Edge, App-aware-process 96 Head-End, App-aware-process Mid-Point, and App-aware-process End- 97 Point. 99 Client Server 100 +-----+ +-----+ 101 |App x|-\ /->|App x| 102 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 103 \->|App- | |App-aware|-A-|App-aware|-A-|App-aware|-/ 104 User side |aware|-|process |-B-|process |-B-|process | 105 /->|Edge | |Head-End |-C-|Mid-Point|-C-|End-Point|-\ 106 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 107 |App y|-/ \->|App y| 108 +-----+ --------- Uplink ----------> +-----+ 110 Figure 1: Framework and Key Components in APN6 112 The data-driven process of APN6 is described below. 114 The APP or the APP-aware Edge will generate an APN packet which 115 carries the application characteristic information in the 116 encapsulation. The information may include application-aware 117 identification, such as SLA level, application ID, user ID, flow ID, 118 etc., and network performance requirements, such as bandwidth, 119 latency, jitter, packet loss ratio, etc. The former is recorded in 120 the Application-aware ID Options, and the latter is recorded in the 121 Service-Para Options defined in the [I-D.li-apn-framework]. 123 App-aware-process Head-End can read that information and steer the 124 packet into a given policy which satisfies the application 125 requirements. It is supposed that a set of paths, tunnels or SR 126 policies, exist between the App-aware-process Head-End and the App- 127 aware-process End-Point. App-aware-process Head-End can find one 128 existing path or establish a new one for the traffic. 130 3. Path Latency Information Detection 132 In the APN architecture, the user/APP can give a latency requirement 133 to the network, and the network will provide a low latency path for 134 the traffic. The path may be the one with the lowest latency among 135 the set of paths between the Head-End and the End-Point, or may be 136 one of the paths with a lower latency than the value carried in the 137 latency requirement TLV. However, the users/APPs do not know how 138 well the network handle the requirements, especially when the APPs 139 give multiple requirements. 141 An APP can easily obtain a bidirectional E2E latency, i.e., the sum 142 of the bidirectional network latency and the server latency, but it 143 does not know the exact network latency. The mechanism proposed in 144 this document can provide this information to the APP, and the APP 145 can confirm the network's SLA guarantee activity if needed. 147 In details, the APP can add a new Service-Para Option named Timestamp 148 Request TLV into the packet to indicate that it needs the timestamps 149 of the headend and the endpoint in the network. The headend and the 150 endpoint can read the TLV and add two new Timestamp TLVs in the IPv6 151 extension header, which contain the time that the packet reach the 152 headend and the endpoint respectively. Then, the server can receive 153 this specific packet with the Timestamp Request TLV and the two 154 Timestamp TLVs. The server can record the timestamps, and 155 encapsulate them into a packet that is about to be sent to the APP. 156 This packet can also include a Timestamp Request TLV. On the 157 converse direction, the headend and the endpoint in the network can 158 add another two Timestamp TLVs into the packet. Hence, the APP can 159 get four timestamps in total, and know the forwarding path latency 160 and the reverse path latency of the network. 162 4. Other Path Information Detection 164 The APP can also request other information by extending more Request 165 TLVs and Information TLVs in the IPv6 extension header. For example, 166 the APP can request to obtain the SR policy BSID in the Path 167 Information TLV. In this case, only the headend on the forwarding 168 direction needs to add information into the packet. As the 169 information needs to be handled by the server, the BSID can be stored 170 in DOH (Destination Options Header) of the packet. 172 When the APP has obtained the BSID, it can add it into the SID list 173 contained in the packet or into a new Service-Para Option. The 174 headend can directly steer the traffic to a specific SR Policy 175 according to that information. Therefore, it only needs to analyze 176 the several packets in the traffic at the beginning, and does not 177 need to analyze the following packets with BSID in the traffic in 178 details. 180 5. IANA Considerations 182 TBD. 184 6. Security Considerations 186 TBD. 188 7. Acknowledgements 190 TBD. 192 8. References 194 8.1. Normative References 196 [I-D.li-apn-framework] 197 Li, Z., Peng, S., Voyer, D., Li, C., Geng, L., Cao, C., 198 Ebisawa, K., Previdi, S., and J. Guichard, "Application- 199 aware Networking (APN) Framework", draft-li-apn- 200 framework-00 (work in progress), March 2020. 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, 204 DOI 10.17487/RFC2119, March 1997, 205 . 207 8.2. Informative References 209 [I-D.li-apn6-problem-statement-usecases] 210 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 211 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 212 Statement and Use Cases of Application-aware IPv6 213 Networking (APN6)", draft-li-apn6-problem-statement- 214 usecases-01 (work in progress), November 2019. 216 Authors' Addresses 218 Zongpeng Du 219 China Mobile 220 No.32 XuanWuMen West Street 221 Beijing 100053 222 China 224 Email: duzongpeng@foxmail.com 226 Peng Liu 227 China Mobile 228 No.32 XuanWuMen West Street 229 Beijing 100053 230 China 232 Email: liupengyjy@chinamobile.com 233 Liang Geng 234 China Mobile 235 No.32 XuanWuMen West Street 236 Beijing 100053 237 China 239 Email: gengliang@chinamobile.com