| Internet-Draft | SDN-based MPTCP-aware and MPQUIC-aware | March 2022 |
| Xing, et al. | Expires 30 September 2022 | [Page] |
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.¶
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 30 September 2022.¶
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 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.¶
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) 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, in 2016, Google proposed the HTTP/3 protocol based on the [Quick_UDP_Internet_Connection__QUIC__protocol]. 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_] is a multi-path transmission protocol designed on the basis of QUIC. [Software_Defined_Network__SDN_] 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.¶
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.¶
+--------------------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¶
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].¶
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.¶
+---------------------+ +----------------------------+
| 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?--+ |
| | \ / | |
| 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. 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].¶
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.¶
The transmission control model proposed in this document uses software to define 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].¶
This document defines some new values as following.¶
| Value | Name | Reference |
|---|---|---|
| key | When packet from MPTCP:key=T+token, and when packet from MPQUIC:key=Q+CID | Section 3 |
| flows table | To save key and value | Section 3 |
| RL | Transmission path composed of all sub streams | Section 3 |
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.¶
This document introduces and implements the software-defined network in which the controller parses the headers of MPTCP or MPQUIC data packets and generates a unique connection identifier based on the token or CID. According to the global network status information obtained by the switch, the controller selects the appropriate transmission path to generate the distribution flow table, to ensure efficient forwarding of data packets.¶