Internet DRAFT - draft-xing-nmrg-sdn-controller-aware-mptcp-mpquic

draft-xing-nmrg-sdn-controller-aware-mptcp-mpquic







nmrg                                                             Z. Xing
Internet-Draft                                                     H. Qi
Intended status: Informational                                     X. Di
Expires: 7 October 2022   Changchun University of Science and Technology
                                                            5 April 2022


  An SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model
          draft-xing-nmrg-sdn-controller-aware-mptcp-mpquic-01

Abstract

   This document aims to study and implement MPTCP (MultiPath
   Transmission Control Protocol) and MPQUIC (MultiPath Quick UDP
   Internet Connection) for software-defined networking.  In a software-
   defined network, the controller can parse MPTCP and MPQUIC data
   packets and allocate MPTCP or MPQUIC data packets to suitable
   transmission paths according to the obtained global network state,
   reducing the probability of transmission path congestion and
   improving path utilization.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 October 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components



Xing, et al.             Expires 7 October 2022                 [Page 1]

Internet-Draft   SDN-based MPTCP-aware and MPQUIC-aware       April 2022


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Default transmission control mode of MPTCP or MPQUIC in
           SDN . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  SDN-based MPTCP-aware and MPQUIC-aware multi-path transmission
           control model . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The traditional TCP protocol only uses one path between the server
   and the client to transmit data.  In order to realize the
   simultaneous transmission of data between multiple paths between the
   server and the client, the International Internet Engineering Task
   Force proposed and standardized MultiPath TCP (MPTCP) [RFC6897] in
   2013, MPTCP realizes multiple paths between hosts to transmit data at
   the same time, but it is necessary to modify the operating system
   kernel to change the protocol stack of both parties in order to
   increase the MPTCP protocol.  Therefore, MPTCP has disadvantages such
   as difficulty in deployment.  In order to solve the drawbacks in the
   transmission network and adapt to the faster development of the
   Internet, Google proposed the HTTP/3 protocol which is Quick UDP
   Internet Connection (QUIC) [RFC9000].  QUIC has many new features,
   such as: 0-RTT, forward error correction, connection migration,
   flexible congestion control, multiplexing without head-of-line
   blocking, easy deployment, and more.  MultiPath QUIC (MPQUIC)
   [MPQUIC] is a multi-path transmission protocol designed on the basis
   of QUIC.  Software Defined Network (SDN) [RFC7426] is a new network
   innovation architecture implemented by virtualization.  By separating
   control and forwarding, it breaks the closedness of traditional
   network equipment, and uses programming to make network management
   more concise and efficient. flexible.  The purpose of this research
   is to realize the coupling control of MPTCP or MPQUIC sub-flows in
   software-defined networks, so as to improve bandwidth utilization and
   resource allocation fairness, effectively alleviate network
   congestion and achieve load balancing between paths.






Xing, et al.             Expires 7 October 2022                 [Page 2]

Internet-Draft   SDN-based MPTCP-aware and MPQUIC-aware       April 2022


   At present, some scholars have studied the model of deploying MPTCP
   in software-defined network, [QUICSDN] \ [SDN_for_MPTCP] \
   [SDN_MPTCP], but their SDN controller cannot parse the headers of
   MPTCP and MPQUIC data packets at the same time, and cannot achieve
   unified management of MPTCP and MPQUIC links.

   The SDN-based MPTCP and MPQUIC transmission control system consists
   of two parts.  The first part is the control plane: that is the SDN
   controller, which includes MPTCP/MPQUIC parsing module, path
   allocation module, flow table distribution module, flow table
   generation module and link management module. composition.  The main
   function is to parse the header identifier token or CID of MPTCP and
   MPQUIC according to the data packet, allocate suitable paths and
   issue flow tables according to the global information of the entire
   network, and manage the links of the entire network at the same time.
   The second part is the data plane, the switch that supports OpenFlow.
   It mainly completes the collection of link status and reports it to
   the controller: it executes the flow table issued by the controller
   and realizes the forwarding of data packets.

   The purpose of this document is to:

   Describe the model that the controller can parse MPTCP or MPQUIC data
   packets in the software-defined network.

   According to the global topology information obtained by the switch,
   the controller allocates MPTCP or MPQUIC data packets with efficient
   transmission path methods.

   The principle of multi-path transmission control system based on SDN
   controller MPTCP or MPQUIC is shown in Figure 1.




















Xing, et al.             Expires 7 October 2022                 [Page 3]

Internet-Draft   SDN-based MPTCP-aware and MPQUIC-aware       April 2022


   +--------------------Control plane-----------------------+
   |    +-------------------------------------------+       |
   |    |       MPTCP / MPQUIC parsing module       |       |
   |    |           (Parse packet header)           |       |
   |    +---------------------+---------------------+       |
   |                          |                             |
   |                     token or CID                       |
   |                          |                             |
   |    +---------------------v---------------------+       |
   |    |           Path allocation module          |       |
   | +-->    (Select the appropriate path from      <--+    |
   | |  |    the candidate path - assigned path)    |  |    |
   | |  +---------------------+---------------------+  |    |
   | |                        |                   Allocated |
   | |            +-----Allocate path------+         path   |
   | |            |                        |           |    |
   | |  +---------v----------+ +-----------v--------+  |    |
   | |  |     Flow table     | |  Link management   |  |    |
   | |  | generation module  | |      module        |  |    |
   | |  |   (All switch      | |(Manage the mapping +--+    |
   | |  |  assignment flow   | |table flows and save|       |
   | |  |  tables for the    | |   the connection   |       |
   | |  |  selected path)    | |    information)    |       |
   | |  +---------+----------| +--------------------+       |
   +-|------------|-----------------------------------------+
    Network       |
    status        +----Flow table-----+
     |                                |
     |  +---------------Data plane----v-------------+
     |  | +------------------+ +------------------+ |
     |  | |    SDN switch    | |    SDN switch    | |
     +--+ | (Forwarding flow | | (Forwarding flow | |
        | | table and obtain | | table and obtain | |
        | |  network status) | |  network status) | |
        | +------------------+ +------------------+ |
        +-------------------------------------------+

   Figure 1 Schematic diagram of SDN-based MPTCP-aware and MPQUIC-aware
   transmission control model

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].






Xing, et al.             Expires 7 October 2022                 [Page 4]

Internet-Draft   SDN-based MPTCP-aware and MPQUIC-aware       April 2022


3.  Default transmission control mode of MPTCP or MPQUIC in SDN

   In a software-defined network, the default controller cannot parse
   MPTCP or MPQUIC data packets.  If MPTCP or MPQUIC are deployed and
   there are multiple transmission links, the controller only selects
   one of the paths to transmit data, and the other paths are idle.  The
   utilization rate is low, and it is impossible to transmit data on
   multiple paths at the same time, resulting in low transmission
   efficiency.

4.  SDN-based MPTCP-aware and MPQUIC-aware multi-path transmission
    control model

        +---------------------+        +----------------------------+
        | Create a flow table |        |The packet P arrives at s1, |
        +----------+----------+        | and s1 performs flow table |<-+
                   |                   |   item matching on p       |  |
                   v                   +--------------+-------------+  |
        +----------+----------+                       |                |
        | Parse packet header |<-----+                |                |
        +----------+----------+      |                v                |
                   |                 |                /\               |
       +-----------+------------+    |               /  \              |
       |           |            |    +---NO-----Match successful?      |
       v           v            v                    \  /              |
      /\          /\           /\                     \/               |
     /  \        /  \         /  \                    YES              |
  MP_CAPABLE     CID         MP_JOIN                   |               |
     \  /        \  /         \  /                     v               |
      \/          \/           \/         +------------+-------------+ |
      |            |            |         |Forward paket according to|-+
      |            |            v         |the flow tabl instruction |
      |            |     +------+------+  +------------+-------------+
      |            |     |Extract token|               ^
      |            |     +------+------+               |
      |            |            |                      |
      |            v            v                      |
      |     +------+----+ +-----+-------+              |
      |     | key=Q+CID | | key=T+token |              |
      |     +-----+-----+ +------+------+              |
      |           |              |                     |
      |           +------+-------+                     |
      |                  |                             |
      |                  v                             |
      |                 /\                             |
      |                /  \                            |
      |           Is there a key                       |
      |        +--in the flow table?--+                |



Xing, et al.             Expires 7 October 2022                 [Page 5]

Internet-Draft   SDN-based MPTCP-aware and MPQUIC-aware       April 2022


      |        |       \  /           |                |
      |       NO        \/           YES               |
      |        |                      |                |
      |        v                      v                |
      | +-------+---------+   +-------+------+         |
      | |Extract source IP|   |              |         |
      | |destination IP   |   | Path of all  |         |
      | |source port      |   | subflows in  |         |
      | |destination port |   | value,RL     |         |
      | |and subflow      |   |              |         |
      | |identifier       |   |              |         |
      | +-------+---------+   +-------+------+         |
      |         |                     |                |
      |         v                     v                |
      | +-------+---------+   +-------+-------+        |
      | |Add the subflow  |   |Extract the    |        |
      | |meta information |   |subflow meta   |        |
      | |to value and then|   |information    |        |
      | |save <key:value> |   |and add it to  |        |
      | |to the flow table|   |value          |        |
      | +-------+---------+   +--------+------+        |
      +-------->|                     |                |
                v                     v                |
        +-------+---------+   +-------+------+         |
        |                 |   |Allocate a new|         |
        |Allocate the     |   |path to p, and|         |
        |first path to p  |   |route does not|         |
        |route            |   |belong to RL  |         |
        +-------+---------+   +-------+------+         |
                |                     |                |
                +----------+----------+                |
                           |                           |
                           v                           |
     +---------------------+----------------------+    |
     |Put forward and reverse flow table to switch|----+
     +--------------------------------------------+
  Figure 2 The flow chart of the SDN-based MPTCP-aware and MPQUIC-aware
   multi-path transmission control model

   The flow chart of the SDN-based MPTCP-aware and MPQUIC-aware multi-
   path transmission control model is shown in Figure 2.  The
   transmission control model is realized by the following steps:

   Step 1.  The SDN controller creates a mapping table flows for storing
   MPTCP or MPQUIC connection information, and each entry structure of
   the mapping table flows is <key:value>; wherein key is the unique
   identifier of MPTCP or MPQUIC connection, When the packet comes from
   MPTCP, key=T+token; and when the packet comes from MPQUIC, key=Q+CID.



Xing, et al.             Expires 7 October 2022                 [Page 6]

Internet-Draft   SDN-based MPTCP-aware and MPQUIC-aware       April 2022


   value is a set of sub-stream meta-information, each item in the set
   is a sub-stream meta-information; each sub-stream meta-information
   consists of source IP, destination IP, source port, destination port,
   MPTCP (or MPQUIC) sub-stream identifier and the path route
   composition.

   Step 2.  When the data packet p of a certain MPTCP or MPQUIC subflow
   reaches the first switch s1, the first switch s1 parses the header
   field of the data packet p, extracts the source IP, source port,
   destination IP and the destination port matches the source IP, source
   port, destination IP and destination port of the flow table in the
   first switch s1 respectively, and judges whether the matching is
   successful.  If so, go to step 12; if not, then the first switch s1
   encapsulates the data packet p and forwards it to the SDN controller,
   and at the same time adds the data packet p to the waiting queue.

   Step 3.  After receiving the data packet p, the SDN controller parses
   the header field of the data packet p, extracts the connection
   identifier of the data packet, and generates a key value, where when
   the data packet comes from MPTCP, key=T+token; When the packet comes
   from MPQUIC, key=Q+CID.  Then query whether there is a key in the
   mapping table flows, if so, go to step 7, if not, go to step 4.

   Step 4.  Extract the source IP, destination IP, source port, and
   destination port of the data packet p and generate a key value, where
   when the data packet comes from MPTCP, key=T+token; and when the data
   packet comes from MPQUIC, key=Q+CID .

   Step 5.  The controller calculates the threshold T according to the
   global network state information (network topology, number of
   switches, etc.).  Using the depth-first traversal algorithm, find the
   available path set R={r_1,...,r_i,...,r_m } from all source nodes
   whose length does not exceed a certain threshold T to the destination
   node, r_i is the i available path, in the available path set Select a
   shortest path r_i in R as the path route of the sub-flow, where
   r_i=<s_(i,1),...,s_(i,j),...>, s_(i,j) represents the i available
   path The switch numbered j, where i belong to [1,m],j belong to
   [1,T].













Xing, et al.             Expires 7 October 2022                 [Page 7]

Internet-Draft   SDN-based MPTCP-aware and MPQUIC-aware       April 2022


   Step 6.  Use the MPTCP and MPQUIC connection identifiers as the
   unique identifier key of the MPTCP and MPQUIC connections, where the
   key is the unique identifier of the MPTCP and MPQUIC connections.
   When the data packet comes from MPTCP, key=T+token; and the data
   packet comes from In MPQUIC, key=Q+CID.  The source IP, source port,
   destination IP, destination port, MPTCP, MPQUIC sub-flow identifier
   and path route of the data packet p are added to the set value of
   sub-flow meta information as sub-flow meta-information, and then the
   <key:value> The form is saved to the mapping table flows, and go to
   step 10.

   Step 7.  The SDN controller updates the flows table according to the
   global information of the network, and takes out the value from the
   connection identifier, and then composes all paths in the value into
   a set RL={r_1,r_2,...}.

   Step 8.  The SDN controller searches for a suitable disjoint path for
   the data packet p according to the method in Step 5, and sets the
   found path as route=r_i, where r_i not belong to RL.

   Step 9.  Extract the source IP, destination IP, source port,
   destination port, and MPTCP, MPQUIC sub-flow identifiers of the data
   packet p, and convert the source IP, source port, destination IP,
   destination port, MPTCP (or MPQUIC) sub-flow identifiers and the path
   route is added to the value as sub-flow meta information.

   Step 10.  The SDN controller uses the source IP, source port,
   destination IP and destination port to issue the flow table to all
   switches in the route route, and set the route
   route=r_i=<s_(i,1),...,s_(i,j-1),s_(i.j),s_(i,j+1),...>, for the
   switch s_(i,j), the flow entry sent is the source IP, source port to
   the destination, the data packets of IP and destination port are
   forwarded to s_(i,j+1).

   Step 11.  The controller sends the reverse flow table to all switches
   on the route route and sets the route
   route=r_i=<s_(i,1),...,s_(i,j-1),s_(i,j),s_(i,j+1),...>, for the
   switch s_(i,j) ,the flow table entry sent is to forward the data
   packets from the destination IP, destination port to source IP, and
   source port to s_(i,j-1).

   Step 12.  The switch already contains a flow entry for processing the
   data packet p, and forwards the data packet according to the rules
   defined by the flow entry, and completes the processing of the data
   packet p.  Step 2 is executed when the forwarding fails or the
   processing of other subsequent data packets returns.





Xing, et al.             Expires 7 October 2022                 [Page 8]

Internet-Draft   SDN-based MPTCP-aware and MPQUIC-aware       April 2022


5.  Security Considerations

   The transmission control model uses the default security mechanism of
   MPTCP or mpquic in the network, and does not modify the default
   security mechanisms such as encryption and authentication models
   [RFC7426], [RFC6824] and [RFC9000].

6.  Discussion

   The transmission control model introduced in this document can
   identify MPTCP and MPQUIC packets at the same time, expanding the
   application scope of MPTCP and MPQUIC.  In order to verify its
   comprehensive performance, a fat-tree data center network is
   designed.  The transmission control model proposed in this document
   increases the throughput by 3.2 times compared to the default
   transmission control model.

7.  Informative References

   [MPQUIC]   "Multipath Extension for QUIC",
              <https://www.ietf.org/archive/id/draft-lmbdhk-quic-
              multipath-00.html>.

   [QUICSDN]  "Kumar P , Chen J , Dezfouli B . QuicSDN: Transitioning
              from TCP to QUIC for Southbound Communication in SDNs[J].
              2021.",
              <https://ui.adsabs.harvard.edu/abs/2021arXiv210708336K>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

   [RFC6897]  Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
              Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,
              March 2013, <https://www.rfc-editor.org/info/rfc6897>.

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
              Defined Networking (SDN): Layers and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/info/rfc7426>.




Xing, et al.             Expires 7 October 2022                 [Page 9]

Internet-Draft   SDN-based MPTCP-aware and MPQUIC-aware       April 2022


   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [SDN_for_MPTCP]
              "Hussein A , Elhajj I H , Chehab A , et al. SDN for MPTCP:
              An enhanced architecture for large data transfers in
              datacenters[C]// IEEE International Conference on
              Communications. IEEE, 2017.",
              <https://doi.org/10.1109/ICC.2017.7996653>.

   [SDN_MPTCP]
              "7. K. Gao, C. Xu, J. Qin, S. Yang, L. Zhong and G.
              Muntean, "QoS-driven Path Selection for MPTCP: A Scalable
              SDN-assisted Approach," 2019 IEEE Wireless Communications
              and Networking Conference (WCNC), 2019, pp. 1-6,",
              <https://doi.org/10.1109/WCNC.2019.8885585>.

Authors' Addresses

   Ziyang Xing
   Changchun University of Science and Technology
   Changchun
   Email: more60@163.com


   Hui Qi
   Changchun University of Science and Technology
   Changchun
   Email: qihui@cust.edu.cn


   Xiaoqiang Di
   Changchun University of Science and Technology
   Changchun
   Email: dixiaoqiang@cust.edu.cn














Xing, et al.             Expires 7 October 2022                [Page 10]