idnits 2.17.1 draft-du-apn6-auto-encapsulation-adjustment-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 date (July 13, 2020) is 1375 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: January 14, 2021 China Mobile 6 July 13, 2020 8 Auto-adjustment of Encapsulation Information in APN6 9 draft-du-apn6-auto-encapsulation-adjustment-01 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 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. Auto-adjustment of Encapsulation Information . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . 5 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. For better bearing of the user's traffic, the network 74 needs to be intelligent and be aware of the user traffic's demand. 75 An innovative method called APN6 is introduced in 76 [I-D.li-apn6-problem-statement-usecases] and [I-D.li-apn-framework]. 78 In the mechanism of APN6, the packet can carry the ID information and 79 SLA requirements of the traffic, and the network equipment can get 80 them in each packet and handle the packet accordingly. It is one 81 kind of network programming mechanisms in the data plane. 83 As the encapsulation information increases in an APN packet, some 84 bandwidth is kindly wasted in APN6 which contains a larger overhead 85 in every packet. On one aspect, it is believed that it is necessary 86 for the evolution to an intelligent network; on the other aspect, it 87 is recommended that after the network has known the requirements of 88 the traffic and associated it with a proper policy, the traffic needs 89 not to resend the same information in every packet again and again. 90 This document mainly describes the process of the later. 92 2. Auto-adjustment of Encapsulation Information 93 2.1. Current Mechanism in APN6 95 As shown in Figure 1, the APN framework [I-D.li-apn-framework] 96 includes Service-aware App, App-aware Edge Device, App-aware-process 97 Head-End, App-aware-process Mid-Point, and App-aware-process End- 98 Point. 100 Client Server 101 +-----+ +-----+ 102 |App x|-\ /->|App x| 103 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 104 \->|App- | |App-aware|-A-|App-aware|-A-|App-aware|-/ 105 User side |aware|-|process |-B-|process |-B-|process | 106 /->|Edge | |Head-End |-C-|Mid-Point|-C-|End-Point|-\ 107 +-----+ | +-----+ +---------+ +---------+ +---------+ | +-----+ 108 |App y|-/ \->|App y| 109 +-----+ --------- Uplink ----------> +-----+ 111 Figure 1: Framework and Key Components in APN6 113 The data-driven process of APN6 is described below. 115 The APP or the APP-aware Edge will generate APN packets each carries 116 the application characteristic information in the encapsulation. 118 App-aware-process Head-End can read that information and steer the 119 packets into a given policy which satisfies the application's 120 requirements. It is supposed that a set of paths, tunnels or SR 121 policies, exist between the App-aware-process Head-End and the App- 122 aware-process End-Point. App-aware-process Head-End can find one 123 existing path or establish a new one for the traffic. 125 2.2. Comparisons of Data Plane and Control Plane Programming 127 We can realize the same traffic steering in the control plane. The 128 control-plane based process, which is described below, includes three 129 key components: the identity of the traffic, policies in Head-End, 130 and the interface to notify the user requirements. 132 The APP or the Edge knowing the application characteristic 133 information, needs to report that information to the controller of 134 the Head-End by some means. 136 The controller needs to know the traffic requirements and the status 137 of the network, and generate a policy for the Head-End. The policy 138 SHOULD include the identity of the traffic and the path that the 139 traffic should follow. 141 The Head-End needs to implement the policy, and steer the traffic to 142 the proper path. 144 In this mechanism, we do not need to carry extra information in each 145 packet, but need to generate control messages between the Edge and 146 the controller, and between the Head-End and the controller. 148 If the traffic is small, and simple to handle, a control-layer 149 decision-loop is not that necessary. By comparison, a date-driven 150 method is more flexible. Of course, the Head-End after steering the 151 traffic needs to report the (summarized) change to the controller. 153 2.3. Potential Solutions for Auto-adjustment 155 We can find that after the Head-End has selected the policy, the 156 extra information carried in the following APN6 packets has little 157 use. Therefore, an auto-adjustment of encapsulation information 158 mechanism may be helpful for the simplification of the following IPv6 159 packets. 161 According to [I-D.li-apn-framework], the information may include 162 application-aware identification, such as SLA level, application ID, 163 user ID, flow ID, etc., and network performance requirements, such as 164 bandwidth, latency, jitter, packet loss ratio, etc. Hence, at least, 165 we can send only the application-aware identification information in 166 the following APN6 packets without network performance requirements 167 information. 169 Two methods are talked about below. 171 One straightforward method is that we firstly send full information 172 in APN6 packets, and after 3 seconds, we send APN6 packets that only 173 contain the necessary information, such as the application-aware 174 identification information. In this method, we believe that the 175 Head-End can handle the policy mapping process in 3 seconds. Of 176 courses, the "3 seconds" is just an example here, which can be 177 adjusted according to the situation of each network. 179 Another method is that after enabling the policy, the Head-End needs 180 to notify the encapsulation point by some means. However, we do not 181 have a notification mechanism between different nodes in the data- 182 plane network programming now. We need to notify by using the 183 control plane again. The control plane sends a message to the 184 encapsulation point to adjust the encapsulation degree. 186 This document suggests to enable a simple notification method for the 187 data-plane network programming if the information is not that 188 complicated. For example, we can send a "ping" message with a 189 specific flag to the encapsulation point. The advantage is easy to 190 inter-operate. 192 In future, with the technical development of network equipments, the 193 bandwidth may not be the bottleneck anymore, so that a full APN6 194 encapsulation packet may be used widely to enable the data plane 195 intelligence. However, the auto-adjustment of encapsulation 196 information method can help the adoption of the APN6 mechanism by 197 providing a transit solution. Meanwhile, this document also provides 198 a feedback mechanism for the data plane programming to enable the 199 coordination between two nodes. 201 3. IANA Considerations 203 TBD. 205 4. Security Considerations 207 TBD. 209 5. Acknowledgements 211 TBD. 213 6. References 215 6.1. Normative References 217 [I-D.li-apn-framework] 218 Li, Z., Peng, S., Voyer, D., Li, C., Geng, L., Cao, C., 219 Ebisawa, K., Previdi, S., and J. Guichard, "Application- 220 aware Networking (APN) Framework", draft-li-apn- 221 framework-00 (work in progress), March 2020. 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, 225 DOI 10.17487/RFC2119, March 1997, 226 . 228 6.2. Informative References 230 [I-D.li-apn6-problem-statement-usecases] 231 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 232 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 233 Statement and Use Cases of Application-aware IPv6 234 Networking (APN6)", draft-li-apn6-problem-statement- 235 usecases-01 (work in progress), November 2019. 237 Authors' Addresses 239 Zongpeng Du 240 China Mobile 241 No.32 XuanWuMen West Street 242 Beijing 100053 243 China 245 Email: duzongpeng@foxmail.com 247 Peng Liu 248 China Mobile 249 No.32 XuanWuMen West Street 250 Beijing 100053 251 China 253 Email: liupengyjy@chinamobile.com 255 Liang Geng 256 China Mobile 257 No.32 XuanWuMen West Street 258 Beijing 100053 259 China 261 Email: gengliang@chinamobile.com