idnits 2.17.1 draft-xing-alto-sdn-controller-aware-mptcp-mpquic-05.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 (12 May 2022) is 715 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 356 == Missing Reference: 'T' is mentioned on line 356, but not defined == Missing Reference: 'J' is mentioned on line 482, but not defined ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 alto Z. Xing 3 Internet-Draft X. Di 4 Intended status: Informational H. Qi 5 Expires: 13 November 2022 Changchun University of Science and Technology 6 12 May 2022 8 The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model 9 using ALTO 10 draft-xing-alto-sdn-controller-aware-mptcp-mpquic-05 12 Abstract 14 This document aims to study and implement MultiPath Transmission 15 Control Protocol (MPTCP) and MultiPath Quick UDP Internet Connection 16 (MPQUIC) using application layer traffic optimization (ALTO) in 17 software defined network (SDN). In a software-defined network, ALTO 18 server collects network cost indicators (including link delay, number 19 of paths, availability, network traffic, bandwidth and packet loss 20 rate etc.), and the controller extracts MPTCP or MPQUIC packet header 21 to allocate MPTCP or MPQUIC packet to suitable transmission path 22 according to the network cost indicators by ALTO, which can reduce 23 the probability of transmission path congestion and improving path 24 utilization. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 13 November 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Default transmission control mode of MPTCP or MPQUIC in 62 SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Delivering functions by ALTO . . . . . . . . . . . . . . . . 4 64 5. Architectural Framework . . . . . . . . . . . . . . . . . . . 4 65 6. Implementation and Deployment . . . . . . . . . . . . . . . . 6 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 9. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 11.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 The traditional TCP protocol only uses one path between the server 78 and the client to transmit data. In order to realize the 79 simultaneous transmission of data between multiple paths between the 80 server and the client, the International Internet Engineering Task 81 Force proposed and standardized MPTCP [RFC6897] . MPTCP realizes 82 multiple paths between hosts to transmit data at the same time, but 83 it is necessary to modify the operating system kernel to change the 84 protocol stack of both parties in order to increase the MPTCP 85 protocol. Therefore, MPTCP has disadvantages such as difficulty in 86 deployment. In order to solve the drawbacks in the transmission 87 network and adapt to the faster development of the Internet, Google 88 proposed the HTTP/3 protocol which is Quick UDP Internet Connection 89 (QUIC) [RFC9000]. QUIC has many new features, such as: 0-RTT, 90 forward error correction, connection migration, flexible congestion 91 control, multiplexing without head-of-line blocking, easy deployment, 92 and more. MPQUIC [MPQUIC] is a multi-path transmission protocol 93 designed on the basis of QUIC. SDN [RFC7426] is a new network 94 innovation architecture implemented by virtualization. By separating 95 control and forwarding, it breaks the closedness of traditional 96 network equipment, and uses programming to make network management 97 more concise and efficient. flexible. ALTO [RFC7285] can obtain and 98 provide global network information to the controller, such as network 99 traffic, link delay, etc. The main multipath transmission protocols 100 MPTCP and MPQUIC have their own characteristics [MultipathTester]. 101 The application of multipath transmission in SDN can greatly improve 102 the transmission throughput. 104 Realize the coupling control of MPTCP and mpquic subflows in the 105 software defined network, obtain the network state information and 106 allocate the optimal path according to Alto, so as to improve the 107 bandwidth utilization and resource allocation fairness, effectively 108 alleviate the network congestion and realize the load balance between 109 paths. 111 At present, some scholars have studied the model of deploying MPTCP 112 or MPQUIC in software-defined network, [QUICSDN] \ [SDN_for_MPTCP] \ 113 [SDN_MPTCP], but their SDN controller cannot manage the headers of 114 MPTCP and MPQUIC data packets at the same time, and cannot achieve 115 unified management of MPTCP and MPQUIC links.The ALTO protocol can 116 easily obtain various network states (including multiple SDNs, 117 dynamic networks) from SDN without the internal details of the 118 network provider, and deliver controller decisions [SDN_ALTO_proof] \ 119 [SDN_ALTO], which is already a mature solution. 121 The purpose of this document is to: 123 Describe the model that the controller can extract MPTCP or MPQUIC 124 data packets in the software-defined network. 126 According to the global information obtained by the AlTO, the 127 controller allocates MPTCP or MPQUIC data packets with efficient 128 transmission path. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Default transmission control mode of MPTCP or MPQUIC in SDN 138 In a software-defined network, the default controller cannot extract 139 MPTCP or MPQUIC data packets. If MPTCP or MPQUIC are deployed and 140 there are multiple transmission paths, the controller only selects 141 one of the paths to transmit data, and the other paths are idle 142 (there is only one path to transmit data). The utilization rate is 143 low, and it is impossible to transmit data on multiple paths at the 144 same time, resulting in low transmission efficiency. 146 4. Delivering functions by ALTO 148 Alto server is used to obtain network status information, and the 149 controller in SDN is the client of Alto. Alto server will collect 150 network cost indicators (including link delay, number of paths, 151 availability, network traffic, bandwidth and packet loss rate). 153 5. Architectural Framework 155 The architectural framework of multi-path transmission model based on 156 SDN controller MPTCP and MPQUIC using ALTO is shown in Figure 1. 158 +--------------Network Status Acquisition----------------+ 159 | ALTO Server | 160 | (Network topology, traffic distribution, | 161 | link delay/bandwidth) | 162 +---------------^----------------------------------------+ 163 | 164 +------ALTO Protocol----+ 165 | 166 +-----------Control Plane-(ALTO Client)-v----------------+ 167 | +-------------------------------------------+ | 168 | | Extract MPTCP / MPQUIC header module | | 169 | | (Extract packet header) | | 170 | +---------------------+---------------------+ | 171 | | | 172 | token or CID | 173 | | | 174 | +---------------------v---------------------+ | 175 | | Path selection module | | 176 | +--> (Select the appropriate path from <--+ | 177 | | | the candidate path - assigned path) | | | 178 | | +---------------------+---------------------+ | | 179 | | | Allocated | 180 | | +-----Allocate path------+ path | 181 | | | | | | 182 | | +---------v----------+ +-----------v--------+ | | 183 | | | Flow rules | | Link management | | | 184 | | | generation module | | module | | | 185 | | | (All switch | |(Manage the mapping +--+ | 186 | | | assignment flow | |table flows and save| | 187 | | | tables for the | | the connection | | 188 | | | selected path) | | information) | | 189 | | +---------+----------| +--------------------+ | 190 +-|------------|-----------------------------------------+ 191 Network | 192 status +----Flow rules-----+ 193 | | 194 | +---------------Data Plane----v-------------+ 195 | | +------------------+ +------------------+ | 196 | | | SDN switch | | SDN switch | | 197 +--+ | (Forwarding flow | | (Forwarding flow | | 198 | | rules and obtain | | rules and obtain | | 199 | | network status) | | network status) | | 200 | +------------------+ +------------------+ | 201 +-------------------------------------------+ 203 Figure 1 Schematic diagram of SDN-based MPTCP-aware and MPQUIC-aware 204 transmission control model using ALTO 205 The SDN-based MPTCP and MPQUIC transmission control using ALTO model 206 consists of three parts. 208 * The first part is the network status acquisition module, which 209 acquires basic network status information from ALTO. 211 * The second part is the control plane, that is the SDN controller, 212 also the client of ALTO, which includes extracting MPTCP / MPQUIC 213 header module, path selection module, flow rules generation module 214 and link management module. The main function is to extract the 215 header identifier token or CID of MPTCP and MPQUIC according to 216 the data packet (For details, see Section 4), obtain the global 217 information of the whole network according to AlTO and allocate 218 suitable paths and put flow rules to switches according to the 219 global information of the entire network, and manage the links of 220 the entire network at the same time. 222 * The third part is the data plane which is some OpenFlow switches. 223 It executes the flow rules issued by the controller and realizes 224 the forwarding of data packets. 226 6. Implementation and Deployment 228 +---------------------+ +----------------------------+ 229 | Create a flow table | |The packet p arrives at s1, | 230 +----------+----------+ | and s1 performs flow rules <--+ 231 | | item matching on p | | 232 | +--------------+-------------+ | 233 +----------v----------+ | | 234 |Obtain Network Status| | | 235 |Extract packet header|<-----+ | | 236 +----------+----------+ | v | 237 | | /\ | 238 +-----------+------------+ | / \ | 239 | | | +---NO-----Match successful? | 240 v v v \ / | 241 /\ /\ /\ \/ | 242 / \ / \ / \ YES | 243 MP_CAPABLE CID MP_JOIN | | 244 \ / \ / \ / | | 245 \/ \/ \/ +------------v-------------+ | 246 | | | |Forward paket according to|-+ 247 | | v |the flow rules instruction| 248 | | +------+------+ +------------^-------------+ 249 | | |Extract token| | 250 | | +------+------+ | 251 | | | | 252 | | | | 253 | +------v----+ +-----v-------+ | 254 | | key=Q+CID | | key=T+token | | 255 | +-----+-----+ +------+------+ | 256 | | | | 257 | +------+-------+ | 258 | | | 259 | v | 260 | /\ | 261 | / \ | 262 | Is there a key | 263 | +--in the flow table?--+ | 264 | | \ / | | 265 | NO \/ YES | 266 | | | | 267 | +------v----------+ +-------v------+ | 268 | |Extract source IP| | | | 269 | |destination IP | | Path of all | | 270 | |source port | | subflows in | | 271 | |destination port | | value,RL | | 272 | |and subflow | | | | 273 | |identifier | | | | 274 | +-------+---------+ +-------+------+ | 275 | | | | 276 | | | | 277 | +-------v---------+ +-------v-------+ | 278 | |Add the subflow | |Extract the | | 279 | |meta information | |subflow meta | | 280 | |to value and then| |information | | 281 | |save | |and add it to | | 282 | |to the flow rules| |value | | 283 | +-------+---------+ +-------+-------+ | 284 +-------->| | | 285 | | | 286 +-------v---------+ +-------v------+ | 287 | | |Allocate a new| | 288 |Allocate the | |path to p, and| | 289 |first path to p | |route does not| | 290 |route | |belong to RL | | 291 +-------+---------+ +-------+------+ | 292 | | | 293 +----------+----------+ | 294 | | 295 | | 296 +---------------------v----------------------+ | 297 |Put forward and reverse flow rules to switch|----+ 298 +--------------------------------------------+ 299 Figure 2 The flow chart of the SDN-based MPTCP-aware and MPQUIC-aware 300 multi-path transmission control model using ALTO 301 The flow chart of the SDN-based MPTCP-aware and MPQUIC-aware multi- 302 path transmission control model using ALTO is shown in Figure 2. The 303 transmission control model is realized by the following steps: 305 * Step 1.ALTO server collects network cost indicators (including 306 link delay, number of paths, availability, network traffic, 307 bandwidth and packet loss rate), which are recorded as: G (V, e), 308 network topology g, V is the vertex and E is the edge. 310 * Step 2. The SDN controller creates a mapping table flows for 311 storing MPTCP or MPQUIC connection information, and each entry 312 structure of the mapping table flows is ; wherein key 313 is the unique identifier of MPTCP or MPQUIC connection, When the 314 packet comes from MPTCP, key=T+token; and when the packet comes 315 from MPQUIC, key=Q+CID (The letters T and Q are used to 316 distinguish MPTCP and MPQUIC). value is a set of sub-stream meta- 317 information, each item in the set is a sub-stream meta- 318 information; each sub-stream meta-information consists of source 319 IP, destination IP, source port, destination port, MPTCP (or 320 MPQUIC) sub-stream identifier and the path route composition. 322 * Step 3. When the data packet p of a certain MPTCP or MPQUIC 323 subflow reaches the first switch s1, the first switch s1 extracts 324 the header field of the data packet p, extracts the source IP, 325 source port, destination IP and the destination port matches the 326 source IP, source port, destination IP and destination port of the 327 flow table in the first switch s1 respectively, and judges whether 328 the matching is successful. If so, go to step 13; if not, then 329 the first switch s1 encapsulates the data packet p and forwards it 330 to the SDN controller, and at the same time adds the data packet p 331 to the waiting queue. 333 * Step 4. After receiving the data packet p, the SDN controller 334 extracts the header field of the data packet p, extracts the 335 connection identifier of the data packet, and generates a key 336 value, where when the data packet comes from MPTCP, key=T+token; 337 When the packet comes from MPQUIC, key=Q+CID. Then query whether 338 there is a key in the mapping table flows, if so, go to step 8, if 339 not, go to step 5. 341 * Step 5. Extract the source IP, destination IP, source port, and 342 destination port of the data packet p and generate a key value, 343 where when the data packet comes from MPTCP, key=T+token; and when 344 the data packet comes from MPQUIC, key=Q+CID . 346 * Step 6. ALTO to get basic network information. The controller 347 calculates the threshold T according to the global network state 348 information (network topology, number of switches, etc.). Using 349 the depth-first traversal algorithm, find the available path set 350 R={r_1,...,r_i,...,r_m } from all source nodes whose length does 351 not exceed a certain threshold T to the destination node, r_i is 352 the i available path, in the available path set Select a shortest 353 path r_i in R as the path route of the sub-flow, where 354 r_i=, s_(i,j) represents the i available 355 path The switch numbered j, where i belong to [1,m],j belong to 356 [1,T]. 358 * Step 7. Use the MPTCP and MPQUIC connection identifiers as the 359 unique identifier key of the MPTCP and MPQUIC connections, where 360 the key is the unique identifier of the MPTCP and MPQUIC 361 connections. When the data packet comes from MPTCP, key=T+token; 362 and the data packet comes from In MPQUIC, key=Q+CID. The source 363 IP, source port, destination IP, destination port, MPTCP, MPQUIC 364 sub-flow identifier and path route of the data packet p are added 365 to the set value of sub-flow meta information as sub-flow meta- 366 information, and then the The form is saved to the 367 mapping table flows, and go to step 11. 369 * Step 8. The SDN controller updates the flows table according to 370 the global information of the network, and takes out the value 371 from the connection identifier, and then composes all paths in the 372 value into a set RL={r_1,r_2,...}. 374 * Step 9. The SDN controller searches for a suitable disjoint path 375 for the data packet p according to the method in Step 5, and sets 376 the found path as route=r_i, where r_i not belong to RL. 378 * Step 10. Extract the source IP, destination IP, source port, 379 destination port, and MPTCP, MPQUIC sub-flow identifiers of the 380 data packet p, and convert the source IP, source port, destination 381 IP, destination port, MPTCP (or MPQUIC) sub-flow identifiers and 382 the path route is added to the value as sub-flow meta information. 384 * Step 11. The SDN controller uses the source IP, source port, 385 destination IP and destination port to issue the flow table to all 386 switches in the route route, and set the route 387 route=r_i=, for the 388 switch s_(i,j), the flow entry sent is the source IP, source port 389 to the destination, the data packets of IP and destination port 390 are forwarded to s_(i,j+1). 392 * Step 12. The controller sends the reverse flow table to all 393 switches on the route route and sets the route 394 route=r_i=, for the 395 switch s_(i,j) ,the flow table entry sent is to forward the data 396 packets from the destination IP, destination port to source IP, 397 and source port to s_(i,j-1). 399 * Step 13. The switch already contains a flow entry for processing 400 the data packet p, and forwards the data packet according to the 401 rules defined by the flow entry, and completes the processing of 402 the data packet p. Step 3 is executed when the forwarding fails 403 or the processing of other subsequent data packets returns. 405 7. Security Considerations 407 The transmission control model uses the default security mechanism of 408 SDN\ALTO\MPTCP\QUIC in the network, and does not modify the default 409 security mechanisms such as encryption and authentication models 410 [RFC7426], [RFC7285], [RFC6824] and [RFC9000]. 412 8. IANA Considerations 414 TBD. 416 9. Discussion 418 The SDN transmission control model proposed in this document can 419 simultaneously identify MPTCP and MPQUIC data packets and allocate 420 optimal paths according to the network status obtained by ALTO, which 421 expands the application scope of MPTCP and MPQUIC. In order to 422 verify its comprehensive transmission performance, a fat-tree data 423 center network is designed. The transmission control method proposed 424 in this document improves the throughput by about 3 times compared to 425 the default transmission control method. This model also supports 426 data transmission in multiple software-defined networks, and can also 427 be applied to satellite networks, marine networks, etc. to transmit 428 data. 430 10. Acknowledgments 432 The authors thank all reviewers for their comments. 434 11. References 436 11.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, 440 DOI 10.17487/RFC2119, March 1997, 441 . 443 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 444 "TCP Extensions for Multipath Operation with Multiple 445 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 446 . 448 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 449 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 450 March 2013, . 452 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 453 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 454 "Application-Layer Traffic Optimization (ALTO) Protocol", 455 RFC 7285, DOI 10.17487/RFC7285, September 2014, 456 . 458 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 459 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 460 Defined Networking (SDN): Layers and Architecture 461 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 462 2015, . 464 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 465 Multiplexed and Secure Transport", RFC 9000, 466 DOI 10.17487/RFC9000, May 2021, 467 . 469 11.2. Informative References 471 [MPQUIC] "Multipath Extension for QUIC", 472 . 475 [MultipathTester] 476 "Coninck Q D , Bonaventure O . MultipathTester: Comparing 477 MPTCP and MPQUIC in Mobile Environments[C]// 2019 Network 478 Traffic Measurement and Analysis Conference (TMA). 2019.", 479 . 481 [QUICSDN] "Kumar P , Chen J , Dezfouli B . QuicSDN: Transitioning 482 from TCP to QUIC for Southbound Communication in SDNs[J]. 483 2021.", 484 . 486 [SDN_ALTO] "V. K. Gurbani, M. Scharf, T. V. Lakshman, V. Hilt and E. 487 Marocco, "Abstracting network state in Software Defined 488 Networks (SDN) for rendezvous services," 2012 IEEE 489 International Conference on Communications (ICC), 2012, 490 pp. 6627-6632.", 491 . 493 [SDN_ALTO_proof] 494 "Faigl, Z. , Z. Szabo , and R. Schulcz . "Application- 495 layer traffic optimization in software-defined mobile 496 networks: A proof-of-concept implementation." 497 IEEE(2014):1-6.", 498 . 500 [SDN_for_MPTCP] 501 "Hussein A , Elhajj I H , Chehab A , et al. SDN for MPTCP: 502 An enhanced architecture for large data transfers in 503 datacenters[C]// IEEE International Conference on 504 Communications. IEEE, 2017.", 505 . 507 [SDN_MPTCP] 508 "7. K. Gao, C. Xu, J. Qin, S. Yang, L. Zhong and G. 509 Muntean, "QoS-driven Path Selection for MPTCP: A Scalable 510 SDN-assisted Approach," 2019 IEEE Wireless Communications 511 and Networking Conference (WCNC), 2019, pp. 1-6,", 512 . 514 Authors' Addresses 516 Ziyang Xing 517 Changchun University of Science and Technology 518 Changchun 519 Email: more60@163.com 521 Xiaoqiang Di 522 Changchun University of Science and Technology 523 Changchun 524 Email: dixiaoqiang@cust.edu.cn 526 Hui Qi 527 Changchun University of Science and Technology 528 Changchun 529 Email: qihui@cust.edu.cn