idnits 2.17.1 draft-du-apn6-auto-encapsulation-adjustment-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 date (March 9, 2020) is 1510 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 (~~), 2 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: September 10, 2020 China Mobile 6 March 9, 2020 8 Auto-adjustment of Encapsulation Information in APN6 9 draft-du-apn6-auto-encapsulation-adjustment-00 11 Abstract 13 This document introduces a method to adjust the encapsulation 14 information in 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 September 10, 2020. 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. Auto-adjustment of Encapsulation Information . . . . . . . . 3 58 2.1. Current Mechanism in APN6 . . . . . . . . . . . . . . . . 3 59 2.2. Comparisons of Data Plane and Control Plane Programming . 3 60 2.3. Potential Solutions for Auto-adjustment . . . . . . . . . 4 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 6.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 As the development of 5G and new emerging Internet services, such as 72 live video streaming, the network are facing a larger and larger SLA 73 difference between two different kinds of traffic. For better 74 bearing of the user's traffic, the network needs to be intelligent 75 and be aware of the user traffic's demand. An innovation method 76 called APN6 is introduced in [I-D.li-apn6-problem-statement-usecases] 77 and [I-D.li-apn-framework]. 79 In the mechanism of APN6, the packet can carry the ID information and 80 SLA requirements of the traffic, and the network equipment can get 81 them in each packet and handle the packet accordingly. It is one 82 kind of network programming mechanisms in the data plane. 84 As encapsulation information increases in an APN packet, some 85 bandwidth is kindly wasted in APN6 which uses a larger overhead in 86 every packet. On one aspect, it is believed that it is necessary for 87 the evolution to the intelligent network; on the other aspect, it is 88 recommended that after the network has known the requirements of the 89 traffic and associated it with a proper policy, the traffic needs not 90 to resend the same information in every packet again and again. This 91 document mainly talks about the process of the later. 93 2. Auto-adjustment of Encapsulation Information 95 2.1. Current Mechanism in APN6 97 As shown in Figure 1, the APN framework [I-D.li-apn-framework] 98 includes Service-aware App, App-aware Edge Device, App-aware-process 99 Head-End, App-aware-process Mid-Point, and App-aware-process End- 100 Point. 102 Client Server 103 +-----+ +-----+ 104 |App x|-\ /->|App x| 105 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 106 \->|App- | |App-aware|-A-|App-aware|-A-|App-aware|-/ 107 User side |aware|-|process |-B-|process |-B-|process | 108 /->|Edge | |Head-End |-C-|Mid-Point|-C-|End-Point|-\ 109 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 110 |App y|-/ \->|App y| 111 +-----+ --------- Uplink ----------> +-----+ 113 Figure 1: Framework and Key Components in APN6 115 The data-driven process of APN6 is described below. 117 The APP or the APP-aware Edge will generate an APN packet which 118 carries the application characteristic information in the 119 encapsulation. 121 App-aware-process Head-End can read that information and steer the 122 packet into a given policy which satisfies the application 123 requirements. It is supposed that a set of paths, tunnels or SR 124 policy, exist between the App-aware-process Head-End and the App- 125 aware-process End-Point. App-aware-process Head-End can find one 126 existing path or establish a new one for the traffic. 128 2.2. Comparisons of Data Plane and Control Plane Programming 130 We can realize the same traffic steering in the control plane. The 131 control-plane based process, which is described below, includes three 132 key components: the identity of the traffic, policies in Head-End, 133 and the interface to notify the user requirements. 135 The APP or the Edge knowing the application characteristic 136 information, needs to report that information to the controller of 137 the Head-End by some means. 139 The controller needs to know the traffic requirements and the status 140 of the network, and generate a policy for the Head-End. The policy 141 SHOULD include the identity of the traffic and the path that the 142 traffic should follow. 144 The Head-End needs to implement the policy, and steer the traffic to 145 the proper path. 147 In this mechanism, we do not need to carry extra information in each 148 packet, but need to generate control messages between the Edge and 149 the controller, and between the Head-End and the controller. 151 If the traffic is not that large, and simple to handle, a control- 152 layer decision-loop is not that necessary. By comparison, a date- 153 driven method is more flexible. Of course, the Head-End after 154 steering the traffic needs to report the (summarized) change to the 155 controller. 157 2.3. Potential Solutions for Auto-adjustment 159 We can find that after the Head-End has enabled the policy, the extra 160 information carried in the following APN6 packets has little use. 161 Therefore, an auto-adjustment of encapsulation information mechanism 162 may be helpful for the simplification of the following APN6 packets. 164 According to [I-D.li-apn-framework], the information may include 165 application-aware identification, such as SLA level, application ID, 166 user ID, flow ID, etc., and network performance requirements, such as 167 bandwidth, latency, jitter, packet loss ratio, etc. Hence, at least, 168 we can send only the application-aware identification information in 169 the following APN6 packets without network performance requirements 170 information. 172 Two methods are talked about below. 174 One straightforward method is that we firstly send full information 175 in APN6 packets, and after 3 seconds, we send APN6 packets that only 176 contains the necessary information, such as the application-aware 177 identification information. In this method, we believe that the 178 Head-End can handle the policy mapping in 3 seconds. Of courses, the 179 "3 seconds" is just an example here, which can be adjusted according 180 to the situation of each network. 182 Another method is that after enabling the policy, the Head-End needs 183 to notify the encapsulation point by some means. However, we do not 184 have a notification mechanism between different nodes in the data- 185 plane network programming now. We need to notify by using the 186 control plane again. The control plane sends a message to the 187 encapsulation point to adjust the encapsulation degree. 189 This document suggests to enable a simple notification method for the 190 data-plane network programming if the information is not that 191 complicated. For example, we can send a "ping" message with a 192 specific flag to the encapsulation point. The advantage is easy to 193 inter operate. 195 In future, with the technical development of network equipments, the 196 bandwidth may not be the bottle neck anymore, so that a full APN6 197 encapsulation packet may be used widely to enable the data plane 198 intelligence. However, the auto-adjustment of encapsulation 199 information method can help the adoption of the APN6 mechanism by 200 providing a transit solution. Meanwhile, this document also provides 201 a feedback mechanism for the data plane programming to enable the 202 coordination between different nodes. 204 . 206 3. IANA Considerations 208 TBD. 210 4. Security Considerations 212 TBD. 214 5. Acknowledgements 216 TBD. 218 6. References 220 6.1. Normative References 222 [I-D.li-apn-framework] 223 Li, Z., Peng, S., Voyer, D., Li, C., Geng, L., Cao, C., 224 Ebisawa, K., Previdi, S., and J. Guichard, "Application- 225 aware Networking (APN) Framework", draft-li-apn- 226 framework-00 (work in progress), March 2020. 228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 229 Requirement Levels", BCP 14, RFC 2119, 230 DOI 10.17487/RFC2119, March 1997, 231 . 233 6.2. Informative References 235 [I-D.li-apn6-problem-statement-usecases] 236 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 237 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 238 Statement and Use Cases of Application-aware IPv6 239 Networking (APN6)", draft-li-apn6-problem-statement- 240 usecases-01 (work in progress), November 2019. 242 Authors' Addresses 244 Zongpeng Du 245 China Mobile 246 No.32 XuanWuMen West Street 247 Beijing 100053 248 China 250 Email: duzongpeng@foxmail.com 252 Peng Liu 253 China Mobile 254 No.32 XuanWuMen West Street 255 Beijing 100053 256 China 258 Email: liupengyjy@chinamobile.com 260 Liang Geng 261 China Mobile 262 No.32 XuanWuMen West Street 263 Beijing 100053 264 China 266 Email: gengliang@chinamobile.com