CN107396396A - 支持多源多径的数据传输管理方法 - Google Patents

支持多源多径的数据传输管理方法 Download PDF

Info

Publication number
CN107396396A
CN107396396A CN201710399525.0A CN201710399525A CN107396396A CN 107396396 A CN107396396 A CN 107396396A CN 201710399525 A CN201710399525 A CN 201710399525A CN 107396396 A CN107396396 A CN 107396396A
Authority
CN
China
Prior art keywords
terminal
source
component equipment
packet
component
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201710399525.0A
Other languages
English (en)
Other versions
CN107396396B (zh
Inventor
权伟
张宏科
崔恩放
刘亚娜
吕肖肖
曾金捷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Jiaotong University
Original Assignee
Beijing Jiaotong University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Jiaotong University filed Critical Beijing Jiaotong University
Priority to CN201710399525.0A priority Critical patent/CN107396396B/zh
Publication of CN107396396A publication Critical patent/CN107396396A/zh
Application granted granted Critical
Publication of CN107396396B publication Critical patent/CN107396396B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0289Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14Multichannel or multilink protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了一种支持多源多径的数据传输管理方法。该方法主要包括:在源设备和终端之间建立MS‑MPTCP连接,在所述MS‑MPTCP连接中添加子源设备,所述子源设备利用MS‑MPTCP连接通过多条路径与所述源或所述终端进行数据通信;所述子源接收来自所述源或所述终端的数据,所述子源设备根据所述数据包的大小和每条路径的传输延时给所述数据包分配传输路径,根据所述终端的接收窗口和每条路径的带宽给所述终端分配传输带宽。本发明可以满足多源、多径协同对于路径拥塞感知和路径分配调度的需求,可灵活分配路径给终端,并可以获取并控制终端拥塞窗口减少拥塞,可以提高网络利用率、增大用户带宽、提供稳定数据流。

Description

支持多源多径的数据传输管理方法
技术领域
本发明涉及无线网络通信技术领域,尤其涉及一种支持多源多径的数据传输管理方法。
背景技术
当前智能终端普遍有多个网络接口,当前网络也普遍有多条路径可以达到同一目的地,例如数据中心内在的冗余多路径,然而这些路径没有被很好的利用。MPTCP(Multipath TCP,多径TCP)协议是一种利用多条路径并发传输的传输层协议,可以提高端到端的吞吐率,增加网络利用率。并且由于MPTCP仅仅对TCP报文的选项字段进行扩展,所以可以通过传统网络设备而不用更改网络中间设备,容易被广泛应用。
MPTCP尽管可以通过多路径传输数据,降低网络时延,提高网络利用率,但是在实际应用中,当前用户终端(例如智能手机)可拥有的IP接口数目并没有很多,大部分为2个(wifi和数据网络),这限制了网络利用率的进一步提高。另外,路径过多容易造成buffer过大和乱序问题,消耗CPU计算资源、增加等待时间。
因为现有的交换路由设备不能满足多路径管理的需求,其路径的分配主要工作在网络层,对于传输层的拥塞等情况缺乏感知。
现有技术中的第一种多路径管理中的拥塞管理方法为:基于H3C S5820V2系列数据中心交换机的拥塞管理方法,该H3C S5820V2系列数据中心交换机可以支持显示拥塞通知。该方法的基本原理是交换机在出现拥塞时通知TCP,即当TCP段传递时,交换机使用IP首部中的2位来记录拥塞,当TCP段到达后,接收方知道报文段是否在某个位置经历过拥塞。然后,接收方使用下一个ACK通知发送方有拥塞发生,发送方做出响应,缩小自己的拥塞窗口。此机制可以减少交换机队列长度,避免因队列过长而交换机内存不够造成的硬件丢包现象。
上述现有技术中的第一种多路径管理中的拥塞管理方法的缺点为:该方法在使用上并不能很好地进行网络路径拥塞感知,不能够精确地通知具体拥塞情况,仅设置了2位来记录拥塞是否发生,不能获取所有流的拥塞窗口,进行区分管理,无法满足多源、多径协同传输的缓存和路径管理需求。
现有技术中的第二种多路径管理中的拥塞管理方法为:基于S6700系列万兆交换机的拥塞管理方法,该S6700系列万兆交换机支持ECMP(Equal-CostMultipathRouting,等价多路由协议)等多路径协议。存在多条不同链路到达同一目的地址的网络环境中,如果在上述网络环境中使用ECMP协议,发往该目的地址的数据包只能利用其中的一条链路,其它链路处于备份状态或无效状态,并且在动态路由环境下相互的切换需要一定时间,而等值多路径路由协议可以在该网络环境下同时使用多条链路,不仅增加了传输带宽,并且可以无时延无丢包地备份失效链路的数据传输。
现有技术中的第二种多路径管理中的拥塞管理方法的缺点为:实际情况是,各路径的带宽、时延和可靠性等不一样,该方法将各路径的带宽、时延和可靠性认可成一样,不能很好地利用带宽,尤其在路径间差异大时,效果会非常不理想。例如,路由器两个出口,两路径,一个带宽是100M,一个是2M,如果部署是ECMP,则网络总带宽只能达到4M的利用率。
发明内容
本发明的实施例提供了一种支持多源多径的数据传输管理方法,以满足多源、多径协同对于路径拥塞感知和路径分配调度的需求。
为了实现上述目的,本发明采取了如下技术方案。
一种支持多源多径的数据传输管理方法,包括:
在源设备和终端之间建立MS-MPTCP连接,在所述MS-MPTCP连接中添加子源设备,所述子源设备利用MS-MPTCP连接通过多条路径与所述源进行数据通信;
所述子源接收来自所述源或所述终端的数据,所述子源设备根据所述数据包的大小和每条路径的传输延时给所述数据包分配传输路径,根据所述终端的接收窗口和每条路径的带宽给所述终端分配传输带宽。
进一步地,所述的在源设备和终端之间建立MS-MPTCP连接,在所述MS-MPTCP连接中添加子源设备,包括:
源设备和终端建立MPTCP连接的过程:一端的源通过无线通信网络或者有线通信网络向另一端的终端发起MPTCP握手,经过三次握手过程建立两端之间的MPTCP连接,并且两端交换版本号,确认是否支持MS-MPTCP;
子源设备与源设备之间建立MS-MPTCP连接的处理过程:在终端侧设置一个或者多个子源设备,所述子源设备拥有多个IP地址,通过多条网络路径与所述源连接,所述子源设备向所述源发送子源请求加入连接信令MS_SHARE信令,所述源响应所述MS_SHARE信令,所述子源设备与所述源之间通过握手过程,确定源设备和子源设备双方版本均支持MS-MPTCP协议,所述子源设备获取所述源设备和终端之间MPTCP连接的密钥key,所述子源设备与所述源设备之间建立MS-MPTCP连接;
子源设备与终端之间建立MS-MPTCP连接的处理过程:所述子源设备向所述终端发送携带所述密钥key的子源加入连接信令MS_JOIN信令,请求在MPTCP连接中添加子源设备,所述终端响应所述MS_JOIN信令,子源设备和终端之间MS-MPTCP连接建立。
进一步地,所述的所述终端将需要传输给所述源的数据包发送给所述子源设备,所述子源设备根据所述数据包的大小和每条路径的传输延时给所述数据包分配传输路径,包括:
所述子源接收来自所述源或所述终端的数据,所述子源设备根据所述数据包的大小和每条路径的传输延时使用向前预测的算法给所述数据包分配传输路径,所述向前预测算法的处理过程包括:
所述子源设备在传输数据包之前,将记录的当前实时获取的各路径往返时延、当前实时获取的各路径丢包率和当前各路径上传输的数据包的数量进行动态参数的平滑处理,并根据所述平滑处理结果预测各路径的实际传输能力,预测在各路径上发送所述数据包的传输时间,按照传输时间从大到小的顺序依次选取一条或者多条路径作为所述数据包的传输路径。
进一步地,所述的根据所述终端的接收窗口和每条路径的带宽给所述终端分配传输带宽,包括:
对于所述子源设备与所述源之间的每条路径r,用τr表示其RTT,ωr表示其拥塞窗口大小,xr=ωrr为路径r的发送速率,所述子源设备与终端T连接侧的终端接收窗口为ωT,则所述子源设备的实时带宽为∑rxr=∑rωrr,和所述子源设备连接的各个终端从所述子源设备获取均等带宽,所述子源设备给所述终端T分配的带宽为其中,T为所述子源设备所连接终端的总个数,所述终端T的发送速率为xT=ωTT
进一步地,所述的方法还包括:
当子源设备加入源和终端的通信后,源首先通过发送窗口将发送缓存中的数据包通过多条可用路径发往子源设备,子源设备将接收到的来自源的数据包进行存储;当终端向所述子源设备发出获取数据请求后,子源设备通过发送窗口将先存储的数据包发往终端;
所述源和子源设备的发送窗口变化规律如下:在没有收到数据确认的情况下,发送端把发送窗口内的数据都连续发送出去,凡是已经发送但未接收到确认的数据包暂时保留在发送窗口,以便在超时重传时使用;发送窗口的后沿的后面部分表示已发送且已收到确认的数据包,其前沿的前面部分表示不允许发送的数据包;当收到数据包确认后,发送窗口的后沿会前移;当发送窗口中已发送但未收到确定的数据包占满发送窗口时,就不允许再继续发送数据包,直到收到确认。
进一步地,所述源和子源设备的发送窗口的前沿必须在其接收窗口后沿之后,不能超过其接收窗口前沿。
由上述本发明的实施例提供的技术方案可以看出,本发明实施例提出了一种用于网络路径管理的多源、多径协同传输子源设备,可以满足多源、多径协同对于路径拥塞感知和路径分配调度的需求,可灵活分配路径给终端,并可以获取并控制终端拥塞窗口减少拥塞,可以提高网络利用率、增大用户带宽、提供稳定数据流。
本发明附加的方面和优点将在下面的描述中部分给出,这些将从下面的描述中变得明显,或通过本发明的实践了解到。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种子源设备的抽象模型示意图;
图2为本发明实施例提供的一种子源设备的物理模型示意图;
图3为本发明实施例提供的一种子源设备的拓扑模型示意图;
图4为本发明实施例提供的一种在源设备和终端之间添加子源设备建立MS-MPTCP连接的处理流程图;
图5为本发明实施例提出的一种多源协作机制的数学模型示意图;
图6为本发明实施例提出的一种多源协作机制的窗口模型示意图;
图7为本发明实施例给出了一个三条路径的拓扑示意图;
图8为本发明实施例给出的两台终端同时通过子源设备传输数据的拓扑图。
具体实施方式
下面详细描述本发明的实施方式,所述实施方式的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的,仅用于解释本发明,而不能解释为对本发明的限制。
本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是,本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件,但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解,当我们称元件被“连接”或“耦接”到另一元件时,它可以直接连接或耦接到其他元件,或者也可以存在中间元件。此外,这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。
本技术领域技术人员可以理解,除非另外定义,这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是,诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义,并且除非像这里一样定义,不会用理想化或过于正式的含义来解释。
为便于对本发明实施例的理解,下面将结合附图以几个具体实施例为例做进一步的解释说明,且各个实施例并不构成对本发明实施例的限定。
本发明实施例针对当前的交换设备无法满足多源、多径协同对于路径拥塞感知和路径分配调度需求的问题,在多源、多径协同传输策略的基础上,提出了一种子源设备,提出了一种多源协作MPTCP传输策略。
上述多源协作MPTCP传输策略是对MPTCP的一种扩展,支持将发送源的数据缓存区(buffer)分割传输到多个不同的源,接收者可以从这几个不同的源获取数据,达到多源、多径协同传输的目的,实现资源与位置的分离。多源、多径协同传输策略可以在设备IP接口数目有限的情况下,进一步增加网络利用率,并通过灵活管理网络路径减少碰撞拥塞。提出了一种子源设备,以满足实际需求,加快策略部署实现。
本发明实施例针对子源设备,在传统路由交换设备的基础上增加了传输层的功能,将根据传输层获得的路径拥塞情况和窗口情况进行路径规划、分配路径。子源设备所拥有的抽象模型如图1所示,物理模型如图2所示,拓扑模型如图3所示
本发明实施例提出了一种多源协作MPTCP传输策略,多源协作MPTCP传输策略是对MPTCP的一种扩展,支持将发送源的数据缓存区(buffer)分割传输到多个不同的源,接收者可以从这几个不同的源获取数据,达到多源、多径协同传输的目的,实现资源与位置的分离,多源可以先对数据缓存和排序再发给终端,减少终端CPU负荷。多源、多径协同传输策略可以在设备IP接口数目有限的情况下,进一步增加网络利用率,并通过灵活管理网络路径减少碰撞拥塞。
图4为本发明实施例提供的一种在源设备和终端之间添加子源设备,建立MS-MPTCP连接的处理流程图。具体的处理过程包括三个阶段:源设备和终端建立MPTCP连接;子源设备与源之间建立MS-MPTCP连接;子源设备和终端建立MS-MPTCP连接。
源设备和终端建立MPTCP连接的过程:MS-MPTCP连接建立在MPTCP的基础上,可先在源和终端之间建立MPTCP连接、增加地址。一端的源通过无线通信网络或者有线通信网络向另一端的终端发起MPTCP握手,经过三次握手过程建立两端之间的MPTCP连接,并且两端交换版本号,确认是否支持MS-MPTCP。
子源设备与源设备之间建立MS-MPTCP连接的处理过程:在终端侧设置一个或者多个子源设备,所述子源设备拥有多个IP地址,通过多条网络路径与所述源连接,所述子源设备向所述源发送子源请求加入连接信令MS_SHARE信令,所述源响应所述MS_SHARE信令,所述子源设备与所述源之间通过握手过程,确定源设备和子源设备双方版本均支持MS-MPTCP协议,所述子源设备获取上述源设备和终端之间MPTCP连接的密钥key,所述子源设备与所述源设备之间建立MS-MPTCP连接。
子源设备与终端之间建立MS-MPTCP连接的处理过程:所述子源设备向所述终端发送携带所述密钥key的子源加入连接信令MS_JOIN信令,请求在MPTCP连接中添加子源设备,所述终端响应所述MS_JOIN信令,子源设备和终端之间MS-MPTCP连接建立。
需要注意的是,子源可以向源设备和终端的任何一方发起子源加入连接请求(MS_SHARE信令),图4描述的是子源首先向源设备发送请求的情况。同样的,子源可以首先向终端发送上述请求,确定通信双方(源和终端)是否支持MS-MPTCP,如果支持则继续获取所述通信双方MPTCP连接的密钥key。当源和终端均不支持MS-MPTCP时,则无论子源向任何一方请求加入子源连接时均不会被响应;当一方支持、另一方不支持时,支持方可由第一次握手的版本号得知对方版本不支持,当子源向支持方请求加入连接时,该支持方也不会响应。即两端有任何一端不支持时子源均不会被响应,是否支持由源和终端的版本号判断。源利用MS-MPTCP连接通过多条路径与所述子源设备进行数据通信,所述子源设备根据所述终端的接收窗口、每条路径的传输延时和子源设备的带宽给所述终端分配数据传输路径和传输带宽。
在路径调度上,由于终端先将数据交给子源,再由子源发送,对内子源相当于已经获知了所有终端的拥塞窗口,对外子源可以知道所拥有路径的往返时延(RTT)等参数,在路径调度上可以使用向前预测的算法进行多条路径的调度,并且可以协调每个终端的窗口,尽量满足所有接入TCP流的公平性,并减小TCP流的拥塞碰撞。
上述向前预测算法的处理过程包括:
在准备传输数据包之前,将子源设备记录的当前实时获取的各路径往返时延(RTT)、当前实时获取的各路径丢包率(Packet Loss Rate)、以及当前各路径上传输的数据包的数量,进行动态参数的平滑处理,并根据上述平滑处理结果预测各路径的实际传输能力,即在当前路径上发送该数据包需要的传输时间的多少。最后根据各路径的传输能力从大到小进行依次排序进行数据包的传输,预测在各路径上发送所述数据包的传输时间,按照传输时间从大到小的顺序依次选取一条或者多条路径作为所述数据包的传输路径。从而以恰当的路径调度顺序进行数据包的正确传输,尽最大努力保证数据包按序到达接收端,改善整体传输能力、稳定吞吐量。
图5为本发明实施例提出的一种多源协作机制的数学模型示意图,本发明实施例将网络节点之间的连接用集合L={1,…,|L|}表示。在多源协作机制中,网络由终端和源共享,终端用集合T={1,…,|T|}表示,源用集合S={1,…,|S|}表示,子源用集合SS={1,…,|SS|}表示。源与子源之间有多条路径r,路径r包含特定的连接。如图5所示,S1与SS1之间有多条路径,连接(L1,L6,L11,L13)组成一条路径,(L3,L10,L13)组成另外一条路径。子源可以将路径临时分配给某个终端使用,如图5子源SS1将路径(L1,L6,L11,L13)和路径(L3,L10,L13)分配给终端T1使用。
图6为本发明实施例提出的一种多源协作机制的窗口模型示意图,此功能由窗口调度模块完成。对于每条路径r,用τr表示其RTT,ωr表示其拥塞窗口大小,对应的子源跟终端连接侧的终端接收窗口为ωT,另xr=ωrr为路径r的发送速率,则子源SS1的实时带宽为Σr xr=Σrωrr,此带宽由终端共享,并且终端从子源设备获取均等带宽,即其中,T为子源所连接终端的总个数。同样的,终端T的发送速率为xT=ωTT
当子源加入源和终端的通信后,源首先将发送缓存中的数据通过多条可用路径发往子源,子源接收到这些数据包,并保存下来。当终端向源发出请求后,子源会将先前接收到的数据包发往终端。具体的窗口变化如下,源或子源发送窗口变化规律如下:在没有收到数据确认的情况下,发送端可以连续把窗口内的数据都发送出去,凡是已经发送但未接收到确认的数据包必须暂时保留在发送窗口,以便在超时重传时使用。发送窗口的后沿的后面部分表示已发送且已收到确认的数据包,其前沿的前面部分表示不允许发送的数据包。当收到数据包确认后,发送窗口的后沿会前移。如图6所示,在源发送窗口中,序号为36~39的数据为已发送并收到确认的数据包,序号40~53为以发送但未收到确认的数据包,序号54~56为不允许发送的数据包。其中,源与子源之间的可用路径包括路径1、路径2、……、路径n等,源会根据上述前向预测算法,合理分配数据包在各个路径上进行传输。在子源接收窗口中,序号26~35为子源已接收的数据包,序号36~53为子源可以接收的数据包,序号54~56为子源不允许接收的数据包。在子源发送窗口中,序号26~33为子源已发送但未收到确认的数据包。在终端的接收窗口中,序号18~25为终端已向子源发送确认并向主机交付的数据包,序号26~33为允许接收的数据包,序号34~48为不允许接收的数据包。当数据包序号出现在接收窗口允许接收的范围内时,表示可以接收相应的数据包。当源或子源的发送窗口中已发送但未收到确定的数据包占满发送窗口时,也就是说发送窗口的可用窗口为零时,就不允许再继续发送数据包,直到收到确认。
在这里需要说明的是,子源处理数据包的过程是这样的:首先子源接收源发送的数据包并将其缓存在本地;然后当子源接收到终端的请求后,会将先前接收的源的数据包发送给终端。因此,子源的发送窗口的前沿必须在其接收窗口后沿之后,不能超过其接收窗口前沿。
数据缓存功能由存储模块完成,本发明设传输数据量为Q,用T表示传递完Q的总时延,总时延又分为发送时延、传播时延、处理时延和排队时延,根据之前的数学模型,一般MPTCP传输时,总时延为:
等号右边为实时带宽,是在不断变化的。
在增加子源后,子源可代替缓存,并且其带宽可超过连接它的单一终端,终端再次接收数据时可从附近子源设备接收,理想情况下网络时延几乎为0,终端以设备最大带宽M获取数据,则总传输时间为:
T=Q/M
这样得到带宽弥补时延等式:Q/∑r xr=Q/M
达到此平衡时,终端逼近自己设备最大带宽接收数据,相当于以高于设备的带宽弥补路径拥塞等造成的时延,这在没有中间缓存的传统网络中是很难做到的。
在实际情况中,我们发现多路径TCP在路径增加以后,对于终端的CPU内存消耗也增加较快,这是由于到达的数据包发生了乱序,而且其乱序比单一路径TCP要更加严重,随着路径的增加,对于MPTCP速率进一步扩大的瓶颈则在于处理时延。
多源协作机制中,子源与终端距离较近,而且连接路径要少于子源与源之间的路径,子源会先排好序再发送给终端,这相当于将终端CPU内存消耗转移到了子源上。
同时,为了保证充裕的子源缓存空间,适应快速变化的动态网络传输模式,子源设备还具备缓存清理功能。每个发送到子源的数据包都具有一个缓存定时器,当该数据包的定时器为零时,该数据包就会被子源清理,从而确保子源具有充裕的缓存空间。
子源设备可以是专用设备也可以是x86服务器,也可以是一台普通计算机。在实际组网中,无需将所有的路由交换设备都换成子源设备,只需在几个关键节点部署即可达到效果,实现花费和效益的均衡。
实施例一
使用本发明进行文件上传时,终端无需等待数据经过漫长路由网络传输,只需将数据传给最近的子源设备,由子源设备完成这一耗时的任务,从而尽快解放终端。图7为该实施例给出了一个三条路径的拓扑示意图。
首先升级终端和服务器使其支持多源、多径传输策略。
在终端侧和服务器侧分别部署一个子源设备,并为子源设备提供相应路径,图7中给出了三条相互隔离的路径,当然也可以是有交叉的路径。
终端上传文件时,由于其直连子源,将会把数据以直连线速传输给子源,子源会缓存数据,并协调多个路径传输,这时终端无需等待数据包经过网络并返回确认,只需获取子源的确认即可,当终端传输完成时即可断开连接,数据已经完全交给了网络,将数据传输给对端的任务将由子源完成。
实施例二
当多终端同时上网时,子源可以控制终端拥塞窗口,从而平均的分配带宽,而不是使其竞争造成拥塞。图8为该实施例给出的两台终端同时通过子源设备传输数据的拓扑图。
同样的终端需要支持该策略,并布置该拓扑,多个终端连接不同接口;
当两个终端同时上网时,终端均先同子源设备建立连接,这时子源发现自己拥有三条10Mb/s的路径,则每个终端分配15Mb/s。
子源会同源设备建立连接并请求数据,当终端窗口增加到15Mb/s时,则停止其继续增加。
此带宽限制是通过拥塞窗口实现的,可以动态调整,并不是传统接入网关限速。
综上所述,本发明实施例提出了一种用于网络路径管理的多源、多径协同传输子源设备,可以满足多源、多径协同对于路径拥塞感知和路径分配调度的需求,可灵活分配路径给终端,并可以获取并控制终端拥塞窗口减少拥塞,可以提高网络利用率、增大用户带宽、提供稳定数据流。
本发明实施例提出了一种支持多源、多径协同传输的子源设备能够有效管理网络路径。该设备通过对多子源的协同、对多路径的感知,实现合理的路径调度和资源分配,提高网络资源利用率、增大用户使用带宽、提升用户体验质量。
本领域普通技术人员可以理解:附图只是一个实施例的示意图,附图中的模块或流程并不一定是实施本发明所必须的。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置或系统实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置及系统实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。

Claims (6)

1.一种支持多源多径的数据传输管理方法,其特征在于,包括:
在源设备和终端之间建立MS-MPTCP连接,在所述MS-MPTCP连接中添加子源设备,所述子源设备利用MS-MPTCP连接通过多条路径与所述源或所述终端进行数据通信;
所述子源接收来自所述源或所述终端的数据,所述子源设备根据所述数据包的大小和每条路径的传输延时给所述数据包分配传输路径,根据所述终端的接收窗口和每条路径的带宽给所述终端分配传输带宽。
2.根据权利要求1所述的方法,其特征在于,所述的在源设备和终端之间建立MS-MPTCP连接,在所述MS-MPTCP连接中添加子源设备,包括:
源设备和终端建立MPTCP连接的过程:一端的源通过无线通信网络或者有线通信网络向另一端的终端发起MPTCP握手,经过三次握手过程建立两端之间的MPTCP连接,并且两端交换版本号,确认是否支持MS-MPTCP;
子源设备与源设备之间建立MS-MPTCP连接的处理过程:在终端侧设置一个或者多个子源设备,所述子源设备拥有多个IP地址,通过多条网络路径与所述源连接,所述子源设备向所述源发送子源请求加入连接信令MS_SHARE信令,所述源响应所述MS_SHARE信令,所述子源设备与所述源之间通过握手过程,确定源设备和子源设备双方版本均支持MS-MPTCP协议,所述子源设备获取所述源设备和终端之间MPTCP连接的密钥key,所述子源设备与所述源设备之间建立MS-MPTCP连接;
子源设备与终端之间建立MS-MPTCP连接的处理过程:所述子源设备向所述终端发送携带所述密钥key的子源加入连接信令MS_JOIN信令,请求在MPTCP连接中添加子源设备,所述终端响应所述MS_JOIN信令,子源设备和终端之间MS-MPTCP连接建立。
3.根据权利要求1所述的方法,其特征在于,所述子源接收来自所述源或所述终端的数据,所述子源设备根据所述数据包的大小和每条路径的传输延时给所述数据包分配传输路径,包括:
所述源通过MS-MPTCP连接将需要传输给所述终端的数据包发送给所述子源设备或者所述终端通过MS-MPTCP连接将需要传输给所述源的数据包发送给所述子源设备,所述子源设备根据所述数据包的大小和每条路径的传输延时使用向前预测的算法给所述数据包分配传输路径,所述向前预测算法的处理过程包括:
所述子源设备在传输数据包之前,将记录的当前实时获取的各路径往返时延、当前实时获取的各路径丢包率和当前各路径上传输的数据包的数量进行动态参数的平滑处理,并根据所述平滑处理结果预测各路径的实际传输能力,预测在各路径上发送所述数据包的传输时间,按照传输时间从大到小的顺序依次选取一条或者多条路径作为所述数据包的传输路径。
4.根据权利要求3所述的方法,其特征在于,所述的根据所述终端的接收窗口和每条路径的带宽给所述终端分配传输带宽,包括:
对于所述子源设备与所述源之间的每条路径r,用τr表示其RTT,ωr表示其拥塞窗口大小,xr=ωrr为路径r的发送速率,所述子源设备与终端T连接侧的终端接收窗口为ωT,则所述子源设备的实时带宽为∑rxr=∑rωrr,和所述子源设备连接的各个终端从所述子源设备获取均等带宽,所述子源设备给所述终端T分配的带宽为BandTi=∑rxr/T,其中,T为所述子源设备所连接终端的总个数,所述终端T的发送速率为xT=ωTT
5.根据权利要求4所述的方法,其特征在于,所述的方法还包括:
当子源设备加入源和终端的通信后,源首先通过发送窗口将发送缓存中的数据包通过多条可用路径发往子源设备,子源设备将接收到的来自源的数据包进行存储;当终端向所述子源设备发出获取数据请求后,子源设备通过发送窗口将先存储的数据包发往终端;
所述源和子源设备的发送窗口变化规律如下:在没有收到数据确认的情况下,发送端把发送窗口内的数据都连续发送出去,凡是已经发送但未接收到确认的数据包暂时保留在发送窗口,以便在超时重传时使用;发送窗口的后沿的后面部分表示已发送且已收到确认的数据包,其前沿的前面部分表示不允许发送的数据包;当收到数据包确认后,发送窗口的后沿会前移;当发送窗口中已发送但未收到确定的数据包占满发送窗口时,就不允许再继续发送数据包,直到收到确认。
6.根据权利要求5所述的方法,其特征在于,所述源和子源设备的发送窗口的前沿必须在其接收窗口后沿之后,不能超过其接收窗口前沿。
CN201710399525.0A 2017-05-31 2017-05-31 支持多源多径的数据传输管理方法 Active CN107396396B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710399525.0A CN107396396B (zh) 2017-05-31 2017-05-31 支持多源多径的数据传输管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710399525.0A CN107396396B (zh) 2017-05-31 2017-05-31 支持多源多径的数据传输管理方法

Publications (2)

Publication Number Publication Date
CN107396396A true CN107396396A (zh) 2017-11-24
CN107396396B CN107396396B (zh) 2020-03-24

Family

ID=60331758

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710399525.0A Active CN107396396B (zh) 2017-05-31 2017-05-31 支持多源多径的数据传输管理方法

Country Status (1)

Country Link
CN (1) CN107396396B (zh)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110460641A (zh) * 2019-07-16 2019-11-15 华为技术有限公司 数据传输方法、装置及系统
CN110505712A (zh) * 2018-05-17 2019-11-26 华为技术有限公司 一种传输文件的方法及终端
CN110581896A (zh) * 2019-09-30 2019-12-17 恒信东方文化股份有限公司 一种存储方法及其系统
CN110730248A (zh) * 2019-10-24 2020-01-24 北京大学 一种多路径传输中继设备
WO2020063269A1 (zh) * 2018-09-27 2020-04-02 中兴通讯股份有限公司 业务传输方法及装置
CN111245496A (zh) * 2019-12-30 2020-06-05 南京奥汀科技发展有限公司 一种用于电子标签网络信号的节能通讯系统及算法
CN112019443A (zh) * 2020-09-02 2020-12-01 首都师范大学 多路径数据传输方法及装置
WO2021078231A1 (zh) * 2019-10-24 2021-04-29 北京大学 基于位置感知的网络中间设备
CN113037624A (zh) * 2019-12-25 2021-06-25 华为技术有限公司 一种数据流控制的方法和装置
CN115134292A (zh) * 2022-06-28 2022-09-30 王蕊 基于拥塞窗口的多路径传输实时流媒体的路径管理方法
CN115486043A (zh) * 2020-04-23 2022-12-16 网络编码代码有限责任公司 用于译码的多路径网络通信的方法和装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101656653A (zh) * 2008-08-21 2010-02-24 中国移动通信集团公司 一种应用于多路径传输的接收缓存配置方法及装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101656653A (zh) * 2008-08-21 2010-02-24 中国移动通信集团公司 一种应用于多路径传输的接收缓存配置方法及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
PINGPING DONG等: "Performance Enhancement of Multipath TCP for Wireless Communications With Multiple Radio Interfaces", 《IEEE TRANSACTIONS ON COMMUNICATIONS》 *
SUNEET KUMAR SINGH等: "Compare the Performance of MPTCP and TCP and Proposed an Algorithm for Seamless Randover in Ret-Net", 《2015 INTERNATIONAL CONFERENCE ON COMMUNICATION, CONTROL AND INTELLIGENT SYSTEMS (CCIS)》 *

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110505712A (zh) * 2018-05-17 2019-11-26 华为技术有限公司 一种传输文件的方法及终端
WO2020063269A1 (zh) * 2018-09-27 2020-04-02 中兴通讯股份有限公司 业务传输方法及装置
US11825435B2 (en) 2018-09-27 2023-11-21 Zte Corporation Service transmission method and device
CN110460641A (zh) * 2019-07-16 2019-11-15 华为技术有限公司 数据传输方法、装置及系统
CN110581896A (zh) * 2019-09-30 2019-12-17 恒信东方文化股份有限公司 一种存储方法及其系统
WO2021078231A1 (zh) * 2019-10-24 2021-04-29 北京大学 基于位置感知的网络中间设备
CN110730248A (zh) * 2019-10-24 2020-01-24 北京大学 一种多路径传输中继设备
CN113037624A (zh) * 2019-12-25 2021-06-25 华为技术有限公司 一种数据流控制的方法和装置
WO2021129861A1 (zh) * 2019-12-25 2021-07-01 华为技术有限公司 一种数据流控制的方法和装置
CN111245496A (zh) * 2019-12-30 2020-06-05 南京奥汀科技发展有限公司 一种用于电子标签网络信号的节能通讯系统及算法
CN115486043A (zh) * 2020-04-23 2022-12-16 网络编码代码有限责任公司 用于译码的多路径网络通信的方法和装置
CN115486043B (zh) * 2020-04-23 2024-04-09 网络编码代码有限责任公司 用于译码的多路径网络通信的方法和装置
CN112019443A (zh) * 2020-09-02 2020-12-01 首都师范大学 多路径数据传输方法及装置
CN112019443B (zh) * 2020-09-02 2023-09-12 首都师范大学 多路径数据传输方法及装置
CN115134292A (zh) * 2022-06-28 2022-09-30 王蕊 基于拥塞窗口的多路径传输实时流媒体的路径管理方法
CN115134292B (zh) * 2022-06-28 2023-11-28 王蕊 基于接收窗口的多路径传输实时流媒体的路径管理方法

Also Published As

Publication number Publication date
CN107396396B (zh) 2020-03-24

Similar Documents

Publication Publication Date Title
CN107396396A (zh) 支持多源多径的数据传输管理方法
CA2939402C (en) Method to route packets in a distributed direct interconnect network
CN106789648B (zh) 基于内容存储与网络状况的软件定义网络路由决策方法
CN102185771B (zh) Mptcp中发送方数据包调度方法及系统
CN107819695A (zh) 一种基于sdn的分布式控制负载均衡系统与方法
CN103618678A (zh) 自适应多链路聚合的方法、装置及系统
CN105915467A (zh) 一种面向软件定义的数据中心网络流量均衡方法及装置
CN103067977B (zh) 无线异构网络系统中基于跨层优化的数据并发传输方法
CN108833293A (zh) 一种基于软件定义网络sdn的数据中心拥塞控制方法及装置
CN112350949B (zh) 软件定义网络中基于流调度的重路由拥塞控制方法及系统
CN103975319A (zh) Tcp连接重定位
CN107154897B (zh) Dcn中基于包散射的异构流隔离方法
CN109905280A (zh) 一种面向移动卫星网络的仿真方法及系统
Wang et al. Aggressive congestion control mechanism for space systems
CN104717144B (zh) 一种基于网内缓存和逐跳确认的可靠组播方法
Han et al. Future data center networking: From low latency to deterministic latency
CN109428842A (zh) 一种QoS信息传送方法和装置
CN110536187A (zh) 转发数据的方法和接入层交换设备
Oljira et al. Mdtcp: Towards a practical multipath transport protocol for telco cloud datacenters
Xu et al. AI-SPACE: A cloud-edge aggregated artificial intelligent architecture for Tiansuan constellation-assisted space-terrestrial integrated networks
CN102845042A (zh) 一种应用层多个活动物理接口的带宽聚集系统及方法
CN113014512B (zh) 基于n:m连接动态映射的网络连接加速转发方法
CN117376144A (zh) 一种数据传输方法及网关设备
CN210899219U (zh) 基于多路径传输的网络中间设备及多路径传输网络架构
Dong et al. Multi-layer and heterogeneous resource management in sdn-based space-terrestrial integrated networks

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant