idnits 2.17.1 draft-du-apn6-data-driven-accounting-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 (November 2, 2020) is 1271 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-01 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: May 6, 2021 China Mobile 6 November 2, 2020 8 Data-driven Accounting in Application-aware IPv6 Networking 9 draft-du-apn6-data-driven-accounting-00 11 Abstract 13 This document introduces a new usecase of Application-aware IPv6 14 Networking to enable data-driven accounting. 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 May 6, 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. Data-driven Accounting Usecase . . . . . . . . . . . . . . . 3 59 4. General Process of the Data-driven Accounting . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 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 In this mechanism, different user traffic can get different 78 treatments so that the network resource can be used more efficiently. 79 As the emergence of various new services with various requirements, 80 the same treatment for all traffic cannot continue to be sustainable 81 in future. 83 Current usecases in APN6 only mention different treatments of the 84 traffic, but do not mention the way to account, which is essential 85 for the operator. If the operators can charge for APN services 86 properly, the APN technologies will be adopted more quickly. 88 This document introduces the usecase and the general process about 89 the data-driven accounting in APN6. 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. Data-driven Accounting Usecase 131 In the APN architecture, a client can send both normal IPv6 packets 132 and APN encapsulated packets simultaneously, which may trigger 133 complicated accounting/charging mechanisms. 135 As the treatment of the APN packets may be various according to 136 multiple factors, such as the time of accessing the network, the 137 network conditions, etc., a flexible accounting mechanism is needed. 138 In addition, it is better that the accounting mechanism can support 139 negotiations between the client and the accounting point. 141 For example, a user occasionally needs to transfer an import file or 142 attend an important meeting, they can use this APN-based data-driven 143 mechanism to trigger a better network service and pay a reasonable 144 amount of money. 146 4. General Process of the Data-driven Accounting 148 The general process of data-driven accounting is described as below. 150 Firstly, the client inform the the accounting point, which is 151 normally also the gateway of the client, about the requirement of the 152 traffic, and optionally including the cost the user can offer. 154 Secondly, the network provide the service accordingly. 156 Thirdly, the client can do the accounting itself, and occasionally 157 send a specific APN packet to the accounting point to align the 158 accounting information. 160 Fourthly, the network confirm the accounting information received 161 from the client, and make a decision about further treatment of the 162 traffic. 164 Finally, the client may terminate the service and the accounting. 166 As the client and the accounting point can negotiate by using this 167 APN mechanism, a more flexible accounting mechanism is enabled. In 168 this mechanism, the client can participate the accounting, and the 169 accounting point needs to confirm the legality of the APN accounting 170 packets. Therefore, the APN accounting packet should include 171 accounting information of the flow and the signature of the client 172 for the packet. 174 The accounting point can notify the client about an SRv6 Accounting 175 Function before the service accessing. In this case, the accounting 176 information and the signature can be carried in the SRv6 SID list or 177 some other places of the SRH. 179 5. IANA Considerations 181 TBD. 183 6. Security Considerations 185 TBD. 187 7. Acknowledgements 189 TBD. 191 8. References 193 8.1. Normative References 195 [I-D.li-apn-framework] 196 Li, Z., Peng, S., Voyer, D., Li, C., Geng, L., Cao, C., 197 Ebisawa, K., Previdi, S., and J. Guichard, "Application- 198 aware Networking (APN) Framework", draft-li-apn- 199 framework-01 (work in progress), September 2020. 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, 203 DOI 10.17487/RFC2119, March 1997, 204 . 206 8.2. Informative References 208 [I-D.li-apn6-problem-statement-usecases] 209 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 210 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 211 Statement and Use Cases of Application-aware IPv6 212 Networking (APN6)", draft-li-apn6-problem-statement- 213 usecases-01 (work in progress), November 2019. 215 Authors' Addresses 217 Zongpeng Du 218 China Mobile 219 No.32 XuanWuMen West Street 220 Beijing 100053 221 China 223 Email: duzongpeng@foxmail.com 225 Peng Liu 226 China Mobile 227 No.32 XuanWuMen West Street 228 Beijing 100053 229 China 231 Email: liupengyjy@chinamobile.com 232 Liang Geng 233 China Mobile 234 No.32 XuanWuMen West Street 235 Beijing 100053 236 China 238 Email: gengliang@chinamobile.com