idnits 2.17.00 (12 Aug 2021) /tmp/idnits15826/draft-du-apn6-auto-encapsulation-adjustment-02.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 document date (March 2, 2022) is 73 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-04 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: September 3, 2022 March 2, 2022 7 Auto-adjustment of Encapsulation Information in APN6 8 draft-du-apn6-auto-encapsulation-adjustment-02 10 Abstract 12 This document introduces a method to adjust the encapsulation 13 information in 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 September 3, 2022. 38 Copyright Notice 40 Copyright (c) 2022 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. Auto-adjustment of Encapsulation Information . . . . . . . . 2 57 2.1. Current Mechanism in APN6 . . . . . . . . . . . . . . . . 3 58 2.2. Comparisons of Data Plane and Control Plane Programming . 3 59 2.3. Potential Solutions for Auto-adjustment . . . . . . . . . 4 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 6.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 As the development of 5G and the new emerging Internet services, such 71 as live video streaming, the networks are facing a larger and larger 72 SLA requirement difference. For better bearing of the user's 73 traffic, the networks need to be intelligent and be aware of the user 74 traffic's demand. An innovative method called APN6 is introduced in 75 [I-D.li-apn6-problem-statement-usecases] and [I-D.li-apn-framework]. 77 In the mechanism of APN6, the packet can carry the ID information and 78 SLA requirements of the traffic, and a network equipment can get them 79 in each packet and handle the packet accordingly. It is one kind of 80 network programming mechanisms in the data plane. 82 As the encapsulation information increases in an APN packet, some 83 bandwidth is kindly wasted in APN6 which contains a larger overhead 84 in every packet. On one aspect, it is believed that it is necessary 85 for the evolution to an intelligent network; on the other aspect, it 86 is recommended that after the network has known the requirements of 87 the traffic and associated it with a proper policy, the traffic does 88 not need to resend the same information in every packet again and 89 again. This document describes the process of the later. 91 2. Auto-adjustment of Encapsulation Information 92 2.1. Current Mechanism in APN6 94 As shown in Figure 1, the APN framework [I-D.li-apn-framework] 95 includes Service-aware App, App-aware Edge Device, 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 APN packets each carries 115 the application characteristic information in the encapsulation. 117 App-aware-process Head-End can read that information and steer the 118 packets into a given policy which satisfies the application's SLA 119 requirements. It is supposed that a set of paths, tunnels or SR 120 policies, exist between the App-aware-process Head-End and the App- 121 aware-process End-Point. App-aware-process Head-End can find one 122 existing path or establish a new one for the traffic. 124 2.2. Comparisons of Data Plane and Control Plane Programming 126 We can realize the same traffic steering in the control plane. The 127 control-plane based process, as described below, includes three key 128 components: the identity of the traffic, policies in Head-End, and 129 the interface to notify the user requirements. 131 The APP or the Edge knowing the application characteristic 132 information, needs to report that information to the controller of 133 the Head-End by some means. 135 The controller needs to know the traffic requirements and the status 136 of the network, and generate a policy for the Head-End. The policy 137 SHOULD include the identity of the traffic and the path that the 138 traffic should follow. 140 The Head-End needs to implement the policy, and steer the traffic to 141 the proper path. 143 In this mechanism, we do not need to carry extra information in each 144 packet, but need to generate control messages between the Edge and 145 the controller, and between the Head-End and the controller. 147 In the situation that the traffic is small, and simple to handle, a 148 control-layer decision-loop is not that necessary. By comparison, a 149 date-driven method is more flexible. In this situation, the Head-End 150 after steering the traffic needs to report the (summarized) change to 151 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 described below. 171 One straightforward method is that we firstly send full information 172 in APN6 packets, and after several seconds, we send APN6 packets that 173 only 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 the several 176 seconds. For example, it can be three seconds. The number should be 177 a parameter that can be adjusted according to the situation of each 178 network. 180 Another method is that after enabling the policy, the Head-End can 181 notify the encapsulation point by some means. However, we do not 182 have a notification mechanism between different nodes in the data- 183 plane network programming now. We need to notify by using the 184 control plane again. The control plane sends a message to the 185 encapsulation point to adjust the encapsulation degree. 187 This document suggests to enable a simple notification method for the 188 data-plane network programming if the information is not that 189 complicated. For example, we can send a "ping" message with a 190 specific flag to the encapsulation point. The advantage is easy to 191 inter-operate. 193 In future, with the technical development of network equipments, the 194 bandwidth may not be the bottleneck anymore, so that a full APN6 195 encapsulation packet may be used widely to enable the data plane 196 intelligence. However, the auto-adjustment of encapsulation 197 information method can help the adoption of the APN6 mechanism by 198 providing a transit solution. Meanwhile, this document also provides 199 a feedback mechanism for the data plane programming to enable the 200 coordination between two nodes. 202 3. IANA Considerations 204 TBD. 206 4. Security Considerations 208 TBD. 210 5. Acknowledgements 212 TBD. 214 6. References 216 6.1. Normative References 218 [I-D.li-apn-framework] 219 Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., 220 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 221 "Application-aware Networking (APN) Framework", draft-li- 222 apn-framework-04 (work in progress), October 2021. 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, 226 DOI 10.17487/RFC2119, March 1997, 227 . 229 6.2. Informative References 231 [I-D.li-apn6-problem-statement-usecases] 232 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 233 Ebisawa, K., Previdi, S., and J. N. Guichard, "Problem 234 Statement and Use Cases of Application-aware IPv6 235 Networking (APN6)", draft-li-apn6-problem-statement- 236 usecases-01 (work in progress), November 2019. 238 Authors' Addresses 240 Zongpeng Du 241 China Mobile 242 No.32 XuanWuMen West Street 243 Beijing 100053 244 China 246 Email: duzongpeng@foxmail.com 248 Peng Liu 249 China Mobile 250 No.32 XuanWuMen West Street 251 Beijing 100053 252 China 254 Email: liupengyjy@chinamobile.com