CN113746751A - 一种通信方法及装置 - Google Patents

一种通信方法及装置 Download PDF

Info

Publication number
CN113746751A
CN113746751A CN202110598905.3A CN202110598905A CN113746751A CN 113746751 A CN113746751 A CN 113746751A CN 202110598905 A CN202110598905 A CN 202110598905A CN 113746751 A CN113746751 A CN 113746751A
Authority
CN
China
Prior art keywords
data packet
probe
packet
transmission
node
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.)
Pending
Application number
CN202110598905.3A
Other languages
English (en)
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN113746751A publication Critical patent/CN113746751A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1628List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
    • 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
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • 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
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/122Avoiding congestion; Recovering from congestion by diverting traffic away from congested entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • H04L45/745Address table lookup; Address filtering
    • H04L45/7453Address table lookup; Address filtering using hashing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/34Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers

Landscapes

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

Abstract

本申请涉及通信技术领域,公开了一种通信方法及装置,用以在多路径传输时,合理分布各传输路径所传输的数据量,充分利用各传输路径的带宽资源,并避免传输的数据乱序,实现最优负载分担。该方法包括:源节点为探测数据流中的探测数据包按发送顺序赋予第一编号,所述第一编号用于所述探测数据包的传输路径选择;所述源节点以第一发送速率向目的节点发送所述探测数据流中的探测数据包;当所述源节点每接收到一个所述目的节点回传的探测数据包时,所述源节点发送业务数据流中一个待传输的业务数据包,其中所述待传输的业务数据包被赋予与所述探测数据包对应的第二编号,所述第二编号用于所述业务数据包的传输路径选择。

Description

一种通信方法及装置
技术领域
本申请涉及通信技术领域,尤其涉及一种通信方法及装置。
背景技术
随着云计算的不断发展,数据中心流量从传统的“南北流量”为主逐渐演变为“东西流量”为主,对网络带宽和性能提出了更高的挑战。为了适应云计算的新型流量分布特征,数据中心网络(data center network,DCN)的拓扑架构经历了图1所示的演进,从图1中可以看出,数据中心网络架构已从传输的树型网络架构方案(A),向“胖树(Fat-Tree)”型网络架构方案(B)演进。与树型网络架构方案不同的是,在Fat-Tree型网络架构中,任意两个边缘交换机之间存在着多条端到端的传输路径,从而实现端到端的高带宽、低时延通信。
此外,除了数据中心场景外,如图2所示,在广域网、城域网等场景中对多路径传输的需求也逐渐增加,因此当源节点与目的节点间有多条传输路径传输数据时,如何合理的分布各传输路径所传输的数据量,从而充分利用各传输路径的带宽资源,并避免传输的数据乱序成为在多路径传输时实现最优负载分担的一个重要问题。
发明内容
本申请实施例提供一种通信方法及装置,用以在多路径传输时,合理分布各传输路径所传输的数据量,充分利用各传输路径的带宽资源,并避免传输的数据乱序,实现最优负载分担。
第一方面,本申请提供了一种通信方法,该方法包括:源节点为探测数据流中的探测数据包按发送顺序赋予第一编号,所述第一编号用于所述探测数据包的传输路径选择;所述源节点以第一发送速率向目的节点发送所述探测数据流中的探测数据包;当所述源节点每接收到一个所述目的节点回传的探测数据包时,所述源节点发送业务数据流中一个待传输的业务数据包,其中所述待传输的业务数据包被赋予与所述探测数据包对应的第二编号,所述第二编号用于所述业务数据包的传输路径选择;其中,当第一编号和第二编号相同时,被赋予所述第一编号的探测数据包和被赋予所述第二编号的业务数据包对应的传输路径相同。可选的,所述源节点在一个或多个传输周期内以所述第一发送速率向所述目的节点发送所述探测数据流中的探测数据包。
采用上述方法,通过引入新的输入变量(编号),使得同一数据流中的不同业务数据包可以被哈希到不同的传输路径当中,实现了多路径的逐包(数据包)负载分担;同时基于回传探测数据包到达顺序的业务数据发送路径调整策略,利用探测数据包预传输的情况,对下一时刻多路径的链路负载进行预判,从而可以保证业务数据包可以按序到达目的节点,解决了逐包(数据包)负载分担中最致命的数据乱序问题,实现了最优负载分担。
在一个可能的设计中,所述目的节点回传的探测数据包中携带有编号接收顺序表,所述编号接收顺序表用于所述目的节点在接收到所述探测数据包时,按照接收顺序记录当前周期内已接收到的探测数据包的第一编号;所述方法还包括:当所述源节点每接收到一个所述目的节点回传的探测数据包时,所述源节点根据所述目的节点回传的探测数据包中携带的编号接收顺序表更新探测数据包到达顺序表,所述探测数据包到达顺序表中按照到达所述目的节点的顺序,记录当前周期内已到达所述目的节点的探测数据包的第一编号。可选的,所述第二编号为所述源节点根据当前周期内接收所述目的节点回传的探测数据包的次序,在所述探测数据包到达顺序表中确定的与所述次序相符的第一编号。
上述设计中,通过在回程探测数据包中引入去程探测数据包的到达顺序信息,有效解决了回程探测数据包传输乱序对业务数据报文路径规划带来的负面影响;即便回程探测数据包传输过程出现了乱序,源节点依然可以从乱序的回程探测数据包中准确还原出去程探测数据包的到达顺序,并对业务数据包的传输进行正确的路径规划,保证业务数据包按序到达目的节点。
在一个可能的设计中,所述方法还包括:所述源节点根据所述探测数据包的丢包率,调整所述第一发送速率。
上述设计中,源节点根据探测数据包的丢包率,调整探测数据包发送速率,可以有效保证探测数据包发送速率与传输带宽相匹配,避免额外的流量和处理资源的开销。
在一个可能的设计中,所述探测数据包不包含数据域。
上述设计中,探测数据包中不包含数据域,可以有效减小发送探测数据包带来的流量开销。
第二方面,本申请提供了一种通信方法,该方法包括:当目的节点每接收到一个来自于源节点的探测数据包时,所述目的节点更新编号接收顺序表,所述编号接收顺序表用于按照接收顺序,记录当前周期内已接收到的探测数据包的第一编号;所述目的节点向所述源节点回传所述探测数据包,其中回传的所述探测数据包中携带所述编号接收顺序表。
采用上述方法,通过在回程探测数据包中引入去程探测数据包的到达顺序信息,有效解决了回程探测数据包传输乱序对业务数据报文路径规划带来的负面影响;即便回程探测数据包传输过程出现了乱序,源节点依然可以从乱序的回程探测数据包中准确还原出去程探测数据包的到达顺序,并对业务数据包的传输进行正确的路径规划,保证业务数据包按序到达目的节点。
在一个可能的设计中,所述目的节点向所述源节点回传的所述探测数据包携带最高传输优先级的信息,其中所述最高传输优先级对应的丢包优先级最低。
上述设计中,回程探测数据包(即目的节点向源节点回传的探测数据包)携带最高传输优先级的信息,可以有效避免传输节点丢弃回程探测数据包,保证源节点能够根据去程探测数据包的到达目的节点顺序信息,进行业务数据包的发送。
在一个可能的设计中,所述探测数据包不包含数据域。
上述设计中,探测数据包中不包含数据域,可以有效减小发送探测数据包带来的流量开销。
第三方面,本申请提供了一种通信方法,该方法包括:传输节点接收数据包,其中所述数据包携带有编号,所述编号用于所述数据包的传输路径选择;所述传输节点基于所述数据包对应的源IP地址、目的IP地址、源端口、目的端口、传输协议以及所述编号计算哈希值;所述传输节点根据所述哈希值,选择与所述哈希值对应的出端口转发所述数据包。
采用上述方法,通过引入新的输入变量(编号),使得同一数据流中的不同业务数据包或探测数据包可以被哈希到不同的传输路径当中,实现了多路径的逐包(数据包)负载分担。
在一个可能的设计中,所述数据包为探测数据包或业务数据包。
在一个可能的设计中,所述方法还包括:所述传输节点为业务数据包传输分配第一带宽、为探测数据包传输分配第二带宽,其中所述第一带宽大于所述第二带宽。可选的,所述第二宽带与所述第一带宽的比值为所述探测数据包的平均大小与所述业务数据包平均大小的比值。
上述设计中,根据探测数据包的平均大小与业务数据包平均大小的比值为探测数据包和业务数据包分配传输带宽,有利于传输节点合理分配用于传输探测数据包和业务数据包的带宽资源。
在一个可能的设计中,所述方法还包括:当所述传输节点接收的探测数据包为去程探测数据包时,所述传输节点通过所述第二带宽传输所述去程探测数据包;当所述传输节点接收的探测数据包为回传探测数据包时,所述传输节点通过所述第一带宽传输所述回程探测数据包,其中,所述去程探测数据包为源节点向目的节点发送的探测数据包,所述回程探测数据包为所述目的节点向所述源节点回传的探测数据包。
上述设计中,可以有效避免传输节点丢弃回程探测数据包,保证源节点能够根据去程探测数据包的到达目的节点顺序信息,进行业务数据包的发送。
在一个可能的设计中,所述方法还包括:当所述传输节点接收所述去程探测数据包的速率大于所述第二带宽时,所述传输节点丢弃所述去程探测数据包,如所述传输节点丢弃超出传输能力(第二带宽)的去程探测数据包。
上述设计中,传输节点丢弃超出传输能力的去程探测数据包,可以促使源节点根据探测数据包的丢包率,调整探测数据包发送速率,从而有效保证探测数据包发送速率与传输带宽相匹配,避免额外的流量和处理资源的开销。
在一个可能的设计中,所述回程探测数据包携带最高传输优先级的信息,其中所述最高传输优先级对应的丢包优先级最低。
上述设计中,回程探测数据包携带最高传输优先级的信息,可以有效避免传输节点丢弃回程探测数据包,保证源节点能够根据去程探测数据包的到达目的节点顺序信息,进行业务数据包的发送。
在一个可能的设计中,所述探测数据包不包含数据域。
上述设计中,探测数据包中不包含数据域,可以有效减小发送探测数据包带来的流量开销。
第四方面,本申请实施例提供一种通信装置,该装置具有实现上述第一方面或者第一方面的任一种可能的设计中方法的功能,所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元(模块),比如包括通信单元和处理单元。
在一个可能的设计中,该装置可以是芯片或者集成电路。
在一个可能的设计中,该装置包括处理器和通信接口,所述处理器与所述通信接口耦合,用于实现上述第一方面或者第一方面的任一种可能的设计中所述的方法。可以理解的是,通信接口可以为收发器或输入输出接口。该装置还可以包括存储器,所述存储器存储有可被处理器执行的用于实现上述第一方面或者第一方面的任一种可能的设计中所述的方法的程序。
在一个可能的设计中,该装置可以为源节点。
第五方面,本申请实施例提供一种通信装置,该装置具有实现上述第二方面或者第二方面的任一种可能的设计中方法的功能,所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元(模块),比如包括通信单元和处理单元。
在一个可能的设计中,该装置可以是芯片或者集成电路。
在一个可能的设计中,该装置包括处理器和通信接口,所述处理器与所述通信接口耦合,用于实现上述第二方面或者第二方面的任一种可能的设计中所述的方法。可以理解的是,通信接口可以为收发器或输入输出接口。该装置还可以包括存储器,所述存储器存储有可被处理器执行的用于实现上述第二方面或者第二方面的任一种可能的设计中所述的方法的程序。
在一个可能的设计中,该装置可以为目的节点。
第六方面,本申请实施例提供一种通信装置,该装置具有实现上述第三方面或者第三方面的任一种可能的设计中方法的功能,所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元(模块),比如包括通信单元和处理单元。
在一个可能的设计中,该装置可以是芯片或者集成电路。
在一个可能的设计中,该装置包括处理器和通信接口,所述处理器与所述通信接口耦合,用于实现上述第三方面或者第三方面的任一种可能的设计中所述的方法。可以理解的是,通信接口可以为收发器或输入输出接口。该装置还可以包括存储器,所述存储器存储有可被处理器执行的用于实现上述第三方面或者第三方面的任一种可能的设计中所述的方法的程序。
在一个可能的设计中,该装置可以为传输节点。
第七方面,本申请提供一种计算机可读存储介质,所述存储介质存储有计算机指令,当所述计算机指令被执行时,可以实现上述第一方面或者第一方面的任一种可能的设计中所述的方法,或者实现上述第二方面或者第二方面的任一种可能的设计中所述的方法,或者实现上述第三方面或者第三方面的任一种可能的设计中所述的方法。
第八方面,本申请还提供一种计算机程序产品,包括计算机程序或指令,当计算机程序或指令被执行时,可以实现上述第一方面或者第一方面的任一种可能的设计中所述的方法,或者实现上述第二方面或者第二方面的任一种可能的设计中所述的方法,或者实现上述第三方面或者第三方面的任一种可能的设计中所述的方法。
第九方面,本申请还提供一种芯片,所述芯片用于实现上述第一方面或者第一方面的任一种可能的设计中所述的方法,或者实现上述第二方面或者第二方面的任一种可能的设计中所述的方法,或者实现上述第三方面或者第三方面的任一种可能的设计中所述的方法。
上述第四方面至第九方面所能达到的技术效果请参照上述第一方面至第三方面所能达到的技术效果,这里不再重复赘述。
附图说明
图1为数据中心网络的拓扑架构演变示意图;
图2为广域网、城域网中的多路径传输示意图;
图3为本申请实施例提供的通信系统架构示意图;
图4为本申请实施例提供的拥塞状态不感知的逐流负载分担方案ECMP原理示意图;
图5为本申请实施例提供的拥塞状态不感知的细粒度负载均衡方案Presto原理示意;
图6为本申请实施例提供的基于端到端拥塞信息的调度策略原理示意图;
图7为本申请实施例提供的基于局部状态信息的调度策略原理示意图;
图8为本申请实施例提供的通信过程示意图之一;
图9为本申请实施例提供的中间传输节点拥塞控制机制示意图;
图10为本申请实施例提供的负载分担策略的工作流程示意图;
图11为本申请实施例提供的不同逐包负载分担策略下乱序数据百分比示意图;
图12为本申请实施例提供的不同负载分担方案下传输完成时间的示意图;
图13为本申请实施例提供的来回程路径不对称的广域网场景示意图;
图14为本申请实施例提供的广域网中回程探测数据包传输乱序的场景示意图;
图15为本申请实施例提供的通信过程示意图之二;
图16为本申请实施例提供的去程探测数据包顺序到达示意图;
图17为本申请实施例提供的回程探测数据包乱序示意图;
图18为本申请实施例提供基于端到端传输路径状态的调度策略;
图19为本申请实施例提供的不同负载分担策略下网络的数据传输完成时间及数据包乱序比例比较示意图;
图20为本申请实施例提供的WAN网络故障场景中,不同负载分担方案作用下网络传输完成率及传输完成时间示意图;
图21为本申请实施例提供的通信装置的结构示意图之一;
图22为本申请实施例提供的通信装置的结构示意图之二。
具体实施方式
图3为本申请实施例提供的一种可能的通信系统架构示意图,包括多个主机和多个传输节点。其中,接入层和汇聚层的传输节点可以被划分为不同的集群,在每个集群中每个接入层的传输节点与每个汇聚层的传输节点连接;同时每个汇聚层的传输节点与一个或多个核心层的传输节点连接,使得每个集群可以与任何一个核心层的传输节点连接。在图3所示的通信系统架构中,任意两个接入层的传输节点间存在多条传输路径,用以实现两个传输节点间高带宽、低时延通信。
另外,在进行数据传输时,图3中的任一主机可以作为数据传输的源节点,即数据发送端,也可以作为数据传输的目的节点,即数据接收端,通过多个传输节点构建的多条传输路径进行数据传输。以主机A作为数据传输的源节点,主机B作为数据传输的目的节点为例,源节点与目的节点间存在的传输路径包括传输路径1:传输节点11-传输节点21-传输节点31-传输节点24-传输节点16;传输路径2:传输节点11-传输节点22-传输节点31-传输节点24-传输节点16;传输路径3:传输节点11-传输节点23-传输节点31-传输节点24-传输节点16;传输路径4:传输节点11-传输节点23-传输节点32-传输节点24-传输节点16;传输路径5:传输节点11-传输节点23-传输节点32-传输节点25-传输节点16等多条传输路径。本申请旨在解决源节点与目的节点间存在多条传输路径进行数据传输时,如何分布各传输路径所传输的数据量,从而充分利用各传输路径的带宽资源,并避免传输的数据乱序,实现最优负载分担的问题。
在介绍本申请实施例之前,首先对本申请中的部分用语进行解释说明,以便于本领域技术人员理解。
1)、主机,一种具有收发功能的设备,例如,可以为具有无线/有线连接功能的手持式设备、车载设备、可穿戴设备、计算设备、业务服务器、移动台(mobile station,MS)或连接到无线调制解调器的其他处理设备等,以及经接入网与一个或多个核心网进行通信的移动终端等,本申请实施例对此不限定。
2)、传输节点,一种具备数据交换(转发)功能的设备,可以是交换机,也可以是路由器、网关等设备,还可以是其他具有数据交换功能的装置或设备,本申请实施例对此不限定。
3)、五元组,通常是指源IP地址,源端口,目的IP地址,目的端口和传输层协议。例如:192.168.1.1 10000TCP 121.14.88.76 80就构成了一个五元组。其意义是,一个IP地址为192.168.1.1的节点通过端口10000,利用TCP协议,和IP地址为121.14.88.76,端口为80的节点进行连接。在本申请实施例中,传输节点可以根据接收到的数据包的五元组进行哈希计算,根据计算得到的哈希值选择出端口。例如:对五元组哈希计算后得到的哈希值为80,选择传输节点的出端口80转发数据包;对五元组哈希计算后得到的哈希值为100,选择传输节点的出端口100转发数据包。
4)、等价多路径(equal cost multipath,ECMP)方案,是一种拥塞状况不感知的逐流负载均衡方案。如图4所示,ECMP调度方案,使用哈希方法基于五元组计算不同数据流转发的出端口,完成每个数据流和端到端传输路径的一一映射,将不同的数据流均匀散列到各个端到端传输路径当中。由于每条流的五元组是确定的,因此每次ECMP哈希的出端口也是唯一确定的,该流的端到端传输路径也最终被唯一确定。然而,ECMP负载分担方案最大的问题是,当网络中流量大小分布不均时(大象流和老鼠流混合),将大流和小流等价看待并分配到不同传输路径上会导致各传输路径之间的负载严重不均衡。
5)、Presto方案,是一种拥塞状况不感知的细粒度负载均衡方案。如图5所示,Presto方案在整个调度过程中不会随数据中心状况的实时变化而调整,调度策略是固定的。该方案使用轮询法(Round Robin),将端侧到达的多个数据流,以小流(flow cell)(固定64KB大小的数据流)为粒度依次轮流调度到不同的端到端传输路径当中。由于该类技术方案不需要探测和记录实时状态信息,因此该方案的执行效率非常高,不会引入额外的存储和计算开销。Presto方案主要原理是假设网络中的多条端到端传输路径是等价的,因此采用简单的散列方法,实现每个数据流与每条端到端传输路径之间的一一映射,将数据流均匀的打散调度到各个端到端传输路径当中。然而,在非对称架构的数据中心网络或广域网(wide area network,WAN)网络中,多条端到端传输路径中的传输节点往往所连接的链路数目是不同的;同时由于设备的异构,每条链路的物理传输速率也可能是不同的;另外,在调度过程中的由于数据流的到达存在着突发情况,端到端传输路径上各传输节点的负载状况是动态变化的。因此,非对称网络中的每条端到端传输路径的性能很可能差别很大。此时简单的将数据流均匀调度到各个端到端传输路径当中,会造成各传输路径负载的严重失衡,部分传输路径拥塞情况严重而其它传输路径负载较轻,并且在非对称的网络架构下,还会出现数据乱序问题。
6)、CONGA方案,是一种基于端到端拥塞信息的调度策略方案。如图6所示,在每次数据调度决策之前,会探测经过边缘传输节点的所有端到端传输路径的拥塞信息(通常可以用往返时延(round trip time,RTT)、显式拥塞通知(explicit congestionnotification,ECN)等指标来近似分析路径的拥塞状况),并将所有传输路径的拥塞状况记录在一个路径状况表中。在进行调度决策时,调度算法会查询路径状态表中所有端到端传输路径的拥塞状况,进而完成对数据的确定性调度。例如:将新产生的数据流调度到当前负载最轻的端到端传输路径当中(CONGA策略的方法)。该策略通过实时探测数据中心网络的拥塞状态,不断实时调整数据调度方案,以实现多传输路径的负载均衡。在调度粒度方面,为了避免逐包调度出现的数据乱序问题,CONGA采用基于微小流(flowlet)数据包突发(burst of packets)的调度方案,保证flowlet之间的包间隔大于路径最大的时延差,从而保证多路径的flowlet之间不会引起数据的乱序。然而,CONGA方案最大的缺陷在于大规模网络中探测所有传输路径的状态信息会引入大量的信息轮询耗时,导致路径状况表中的信息延迟严重。一方面,严重的信息轮询和控制耗时不利于数据流的实时调度;另一方面,大规模网络中维护所有端到端传输路径的拥塞信息并执行调度策略会引入极大的存储和计算开销,因此CONGA等策略仅能用于小规模的二层数据中心网络当中,无法应用于更大规模的网络。
7)、Drill方案,是一种基于局部状态信息的调度策略,如图7所示,局部调度策略仅利用某一节点的局部拥塞信息完成数据的局部调度。因此,应用该技术方案时,端到端传输路径上的每个节点都会重新进行一次调度决策,而非仅仅在边缘传输节点或源节点上制定调度决策。每次局部调度时,调度策略基于局部节点的拥塞信息(如各端口的数据积压量等)生成调度决策。由于该类方案仅需记录局部节点的状态信息,无需记录全局端到端传输路径的状态信息,因此信息的存储、轮询开销得到了极大的优化。可以满足实时调度的需求。然而,基于局部信息的调度策略,将全局调度决策分散到各个局部节点当中,通过端到端传输路径上各个局部节点策略的依次执行,完成对网络数据的端到端路由;此类方案最大问题是对链路及设备故障的反应较为迟钝。此策略下,某节点(如传输节点)如果出现了故障,只有其邻居节点可以及时感知到,而远端节点由于不探测端到端传输路径的状态信息,无法感知拥塞和故障状况。因此,当端到端传输路径的远端节点出现故障或拥塞时,本地节点由于无法及时感知路径状态的变化,还会沿用之前的调度方案,直至拥塞传递到其邻居节点时才会调整调度策略。因此,调度策略容易形成局部的拥塞树。并且,局部最优解也牺牲了负载均衡的精度。
另外,需要理解,在本申请实施例中,至少一个还可以描述为一个或多个,多个可以是两个、三个、四个或者更多个,本申请不做限制。
在本申请实施例中,“/”可以表示前后关联的对象是一种“或”的关系,例如,A/B可以表示A或B;“和/或”可以用于描述关联对象存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况,其中A,B可以是单数或者复数。为了便于描述本申请实施例的技术方案,在本申请实施例中,可以采用“第一”、“第二”等字样对功能相同或相似的技术特征进行区分。该“第一”、“第二”等字样并不对数量和执行次序进行限定,并且“第一”、“第二”等字样也并不限定一定不同。在本申请实施例中,“示例性的”或者“例如”等词用于表示例子、例证或说明,被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念,便于理解。
因为数据包可以提供最小单位的数据流调整可能性,本申请实施例基于最细粒度的逐包(数据包)调度方案是理论上最优的负载分担策略这一原理,旨在逐包调度的基础上,进一步解决数据乱序的问题,以实现最优的负载分担。下面结合附图详细说明本申请实施例。
【实施例一】
图8为本申请实施例提供的一种通信过程示意图,该过程包括:
S801:源节点为探测数据流中的探测数据包按发送顺序赋予第一编号,所述第一编号用于所述探测数据包的传输路径选择。
在本申请实施例中,采用探测数据包(credit)微预演的拥塞控制机制,实现业务数据包的发送,即在业务数据包发送前,通过探测数据预演业务数据包的传输,基于探测数据包的预演结果进行业务数据包的发送。
为了实现同一数据流中的数据包可以被哈希到不同的传输路径中,实现多传输路径的负载分担,本申请实施例中,在现有传输路径的哈希算法的基础上,重新设计了哈希算法。在五元组(即源IP地址,源端口,目的IP地址,目的端口和传输层协议)的基础上引入新的变量“编号(seq)”,构成六元组,使得同一数据流中,不同数据包虽然五元组相同但编号不同,基于五元组+编号哈希计算出的哈希值不同,实现同一数据流中的不同数据包可以被哈希到不同的传输路径中。
在一种可能的实施中,编号可以通过数据包包头的任一空闲字段携带。例如:通过数据包包头中的选择(options)字段、生存时间(time to live,TTL)字段等携带。
具体的,当源节点有业务数据流待传输时,源节点首先发送探测数据包探测多条传输路径的拥塞状态。为了保证同一探测数据流中多个探测数据包通过多条传输路径路由转发,源节点对同一探测数据流中的探测数据包的第一编号,可以按照探测数据包的发送顺序进行递增赋值。例如:对于探测数据流中的第一个探测数据包的第一编号赋值为“1”、第二个探测数据包的第一编号赋值为“2”、第三个探测数据包的第一编号赋值为“3”……。
同时,为了减少探测数据包带来的流量开销,探测数据包可以不包含数据域,也即探测数据包可以仅包含包头,以减少数据量。
S802:所述源节点以第一发送速率向目的节点发送所述探测数据流中的探测数据包。
在一种可能的实施例中,源节点可以以某个确定的时长为传输周期,在每个传输周期内以等间隔(pacing)的方式向目的节点发送探测数据包,其中源节点向目的节点发送探测数据包的第一发送速率可以为0.5Gbps等。
位于源节点和目的节点之间的传输节点接收到源节点发送的携带有第一编号的探测数据包(去程探测数据包)后,基于探测数据包中的五元组+第一编号共6个输入参数,进行哈希计算,得到哈希值,并根据得到的哈希值选择出端口。
示例的:第一个探测数据包的五元组+第一编号为192.168.1.1 10000TCP121.14.88.7680+1,传输节点计算后得到的哈希值为80,通过出端口80转发所述第一个探测数据包;第二个探测数据包的五元组+第一编号为192.168.1.1 10000TCP 121.14.88.7680+2,传输节点计算后得到的哈希值为85,通过出端口85转发所述第二个探测数据包。
S803:当所述目的节点每接收到一个来自于所述源节点的探测数据包时,所述目的节点向所述源节点回传所述探测数据包。
具体的,目的节点每接收到一个数据包后,可以首先判断该数据包是探测数据包还是业务数据包,如果接收到的数据包为探测数据包,对探测数据包进行回传。示例的,目的节点可以将探测数据包的源IP和目的IP对换并发送,将探测数据包回传至源节点。如果目的节点接收到的数据包为业务数据包,目的节点对业务数据包进行解析处理。示例的,目的节点对业务数据包进行解封装,并读取业务数据包中携带的数据。
同样,位于源节点和目的节点之间的传输节点接收到目的节点回传的携带有第一编号的探测数据包(回程探测数据包)后,基于探测数据包中的五元组+第一编号共6个输入参数,进行哈希计算,得到哈希值,并根据得到的哈希值选择出端口。
S804:当所述源节点每接收到一个所述目的节点回传的探测数据包时,所述源节点发送业务数据流中一个待传输的业务数据包,其中所述待传输的业务数据包被赋予与所述探测数据包对应的第二编号,所述第二编号用于所述业务数据包的传输路径选择。
源节点每接收到一个目的节点回传的探测数据包(回程探测数据包)时,源节点读取该探测数据包携带的第一编号,并将接收的到探测数据包携带的第一编号赋值给业务数据流中当前待传输的业务数据包,作为该待传输的业务数据包的第二编号,并向目的节点发送该待传输的业务数据包。
示例的,源节点接收到一个目的节点回传的探测数据包,该探测数据包携带的第一编号被赋值为“5”,源节点可以将业务数据流中当前待传输的业务数据包的第二编号赋值为“5”,并向目的节点发送该待传输的业务数据包。
位于源节点和目的节点之间的传输节点接收到源节点发送的携带有第二编号的业务数据包(去程业务数据包)后,基于业务数据包中的五元组+第二编号共6个输入参数,进行哈希计算,得到哈希值,并根据得到的哈希值选择出端口。
通过目的节点回传的探测数据包不断到达源节点,触发源节点向目的节点发送业务数据流中待传输的业务数据包,源节点会不断向目的节点发送业务数据包,直至业务数据包发送完成。
为了精确的预演业务数据包的传输,在一种可能的实施中,位于源节点和目的节点之间用于转发业务数据包和探测数据包的传输节点,可以为业务数据包的传输和探测数据包的传输分配不同的传输带宽。例如:传输节点可以根据业务数据包的平均大小与探测数据包的平均大小的比值,为业务数据包和探测数据包分配第一带宽和第二带宽。示例的:探测数据包的平均大小与业务数据包平均大小的比值为1:19,传输节点可以将自身总带宽的5%用于探测数据包传输,自身总带宽的95%用于业务数据包传输。并且传输节点还可以对超出传输能力的业务数据包和/或探测数据包进行丢弃,源节点也可以根据探测数据包的丢包率,调整发送探测数据包的第一发送速率。例如:源节点可以在探测数据包的丢包率大于设定阈值(如20%)时,下调发送探测数据包的第一发送速率(如将第一发送速率下调10%)。
同时,为了应对探测数据包的突发传输,在传输节点中还可以预留少量缓存用于应对探测数据包的突发传输,例如:传输节点中可以预留8个、10个等探测数据平均大小的缓存,用于应对探测数据包的突发传输。
如图9所示,传输节点总带宽为10Gbps,传输节点可以配置9.5Gbps的带宽用于传输业务数据包,配置0.5Gbps的带宽传输探测数据包。源节点发送探测数据包的传输速率为1Gbps,超出传输节点用于传输探测数据包的第二带宽(0.5Gbps),传输节点丢弃超出传输能力的探测数据包,传输节点对探测数据包的丢包率为50%,经由目的节点回传的探测数据包仅为源节点发送的探测数据包的50%。因此,丢弃50%的探测数据包之后,回程探测数据包(目的节点回传的探测数据包)的到达速率为1Gbps*50%=0.5Gbps。由于源节点每收到一个回程探测数据包就发送一个真正的业务数据包,参考业务数据包和探测数据包大小的比例,因此业务数据包的发送速率为0.5Gbps*19=9.5Gbps,正好完全匹配第一带宽,因此保证了业务数据包的传输既不会造成拥塞(传输节点出现缓存积压),也不会出现欠吞吐(没有完全占满第一带宽)的情况。
另外,为了避免回程探测数据包被丢弃(目的节点回传的探测数据包),回程探测数据包携带最高传输优先级的信息,并且回程探测数据包在传输节点可以通过用于传输业务数据包的第一带宽进行传输,其中最高传输优先级对应的丢包优先级最低。
上述方法中,相当于使用探测数据包作为业务数据包的“替身”在当前网络环境中预演了一遍业务数据包的传输流程,通过传输节点对探测数据包的丢弃和目的节点对探测数据包的回传,将网络中多传输路径的准确负载状况传递给了源节点。源节点基于探测数据包到达的先后顺序规划业务数据包的传输路径:最先发出的业务数据包沿用最先到达的探测数据包的传输路径进行发送(通过五元组和编号的赋值,保证业务数据包和探测数据包的哈希结果一致,即传输路径一致)。
另外,本申请实施例主要利用了数据中心网络对称性强的特点,假设以最高优先级传输的回程探测报文在对称型的数据中心网络中不会发生乱序问题,因此无需在探测数据包中携带额外的顺序信息,直接通过回程探测数据包的到达顺序判断探测数据包的去程传输路径的负载状况。如图10所示,源节点在探测数据包通道中发送了4个探测数据包:Stand-in1、Stand-in 2、Stand-in 3、Stand-in 4,其中Stand-in 4在传输过程中丢包了,目的节点收到Stand-in 1~Stand-in 3后回传给源节点。源节点首先收到Stand-in 3,说明3号探测数据包的传输路径负载最轻,因此在传输第一个业务数据包时编号赋值与Stand-in 3相同;之后探测数据包Stand-in 2到达,源节点传输业务数据包2,编号赋值与Stand-in 2相同;最后探测数据包Stand-in 1到达,源节点传输业务数据包3,编号赋值与Stand-in 1相同。业务数据包与探测数据包相关字段的编号赋值比较,如表1所示。其中src_ip表示源IP地址,src_port表示源端口,dst_ip表示目的IP地址,dst_port表示目的端口,protocol表示传输层协议,Seq表示编号。
Figure BDA0003092203120000111
表1
最终,本申请实施例保证源节点最先发出的业务数据包沿着当前负载最轻的传输路径传输,从而保证业务数据包按序到达目的节点,在网络层解决了逐包负载分担的乱序问题,无需额外的传输层保序还原操作。
如图11所示,分别测试了在随机业务数据流传输以及多对一数据传输(Incast)场景下,不同逐包负载分担策略下业务数据传输的乱序程度。在不同场景中,我们逐渐增加并发传输的业务数据流(Flows)的数目(从16个流逐渐增加至2010个流),比较不同负载情况下数据中心的整体乱序情况。学术界提出的其它负载分担策略DRILL、DRB、Presto等在仿真实验中均基于OMNET仿真平台进行了实现,用作和本申请方案的对比。可以看到,相比于其它业界最新的负载分担方法,本申请的逐包负载分担将乱序的数据包比例优化至0.4%以内,即便在2010个业务数据流并发传输的重负载场景下,本申请方案依然基本上完全杜绝了业务数据包乱序的问题。另外需要注意的是,Incast场景下的重负载场景(2010个数据流并发传输)使用本申请方案出现了0.4%左右的数据包乱序,其原因可能是高并发的探测数据包传输使得回程探测数据包出现了丢包乱序的情况,该问题可以通过如后实施例二中引入探测数据包到达顺序的方法来解决。总体上,应用本申请的负载分担方法几乎不会出现数据乱序情况。
如图12所示,进一步比较了图11所示的两种场景中,不同负载分担策略下数据流的整体完成时间。我们不断增加网络的背景流量,并对不同负载状况下(从30%负载逐渐增加至90%负载)不同负载分担策略对应的业务数据传输完成时间进行比较。本仿真实验中,经典的负载分担方案ECMP、CONGA、Prest、DRILL分别基于OMENT仿真平台完成了实现,用做本申请的对比方案。图12(A)和图12(B)分别显示了在随机数据流传输场景和Incast场景下,不同负载分担方案对应的业务数据传输完成时间的变化。可以看到,由于本申请实现的逐包负载分担更进一步均衡了多条传输路径的负载,使得整体业务数据传输完成时间相比其它方案更优。
【实施例二】
上述实施例一的方案,主要针对拓扑对称的数据中心网络,并基于回程探测数据包不会出现乱序进行方案设计。考虑到一般的WAN场景中,源节点和目的节点数据传输的去程和回程传输路径可能高度不对称,如图13所示,去程探测数据包的传输路径和回程探测数据包的传输路径不同,去程探测数据包的传输路径和回程探测数据包的传输路径的负载状况可能相差极大,导致多条路径传输的回程探测数据包的传输也会出现乱序问题,此时仅仅依靠回程探测数据包的到达源节点的顺序难以正确推测出去程探测数据包到达目的节点的顺序。
如图14描述了一个WAN场景中回程探测数据包乱序的场景。如图14所示,源节点依次传输了6个探测数据包,6个探测数据包被哈希到了不同的传输路径上。去程传输过程并未出现数据的乱序问题,目的节点依次接收到了探测数据包1、探测数据包2、……、探测数据包6。目的节点每收到一个探测数据包,就立刻回传该探测数据包给源节点。然而回程探测数据包的传输出现了数据乱序问题:由于回程路径的性能及负载的不同,探测数据包2最先抵达了源节点,接着是探测数据包1到达,探测数据包4到达,……,最后是探测数据包5到达。此场景中,如果沿用实施例一的技术方案,那么业务数据包1的第二编号将会按照探测数据包2的第一编号进行赋值,按照探测数据包2的去程路径进行传输;而第二个传输的业务数据包2的第二编号会按照探测数据包1的第一编号进行赋值,并按照探测数据包1的去程路径进行传输。而我们已知去程路径传输时,探测数据包1的传输路径比探测数据包2速度更快,因此会导致业务数据包2比业务数据包1更先到达目的节点,导致业务数据包的传输出现乱序问题。因此WAN网络场景中,需要对实施例一的技术方案进行完善,进一步解决回程探测数据包传输的乱序问题。
图15为本申请实施例提供的一种通信过程示意图,该过程包括:
S1501:源节点为探测数据流中的探测数据包按发送顺序赋予第一编号,所述第一编号用于所述探测数据包的传输路径选择。
对于探测数据包中第一编号的赋值可以参照实施例一中的相关描述,不再重复赘述。
S1502:所述源节点以第一发送速率向目的节点发送所述探测数据流中的探测数据包。
在一种可能的实施例中,源节点可以以某个确定的时长为传输周期,在每个传输周期内以等间隔(pacing)的方式向目的节点发送探测数据包,其中源节点向目的节点发送探测数据包的第一发送速率可以为0.5Gbps等。
对于传输节点基于探测数据包的第一编号,对探测数据包进行转发等的实现,可以参照实施例一中的相关描述,不再重复赘述。
S1503:当所述目的节点每接收到一个来自于源节点的探测数据包时,所述目的节点更新编号接收顺序表,所述编号接收顺序表用于按照接收顺序,记录当前周期内所述目的节点已接收到的探测数据包的第一编号。
示例的,如图16所示,假设探测数据包按照探测数据包#1~探测数据包#6的顺序依次到达,则目的节点的动作如下:探测数据包#1到达时,目的节点将第一编号Seq1记录在编号接收顺序表中;探测数据包#2到达时,目的节点将第一编号Seq2记录在编号接收顺序表中;以此类推,最后探测数据包#6到达时,目的节点将第一编号Seq6记录在编号接收顺序表中。
S1504:所述目的节点向所述源节点回传所述探测数据包,其中回传的所述探测数据包中携带所述编号接收顺序表。
示例的:目的节点每收到一个去程探测数据包后,在完成将去程探测数据包携带的第一编号更新到编号接收顺序表的操作后,立刻回传该探测数据包,并在该探测数据包的包头中记录更新后的编号接收顺序表。
如图16所示,目的节点回传探测数据包#1时,将Seq1携带于探测数据包#1当中;回传探测数据包#2时,将Seq1、Seq2携带于探测数据包#2中;回传探测数据包#3时,将Seq1、Seq2、Seq3携带于探测数据包#3中;以此类推,最后回传探测数据包#6时,之前到达的探测数据包#1~探测数据包#5的第一编号Seq1~Seq5以及探测数据包#6的第一编号Seq6都会被记录到回程探测数据包之中。
S1505:当所述源节点每接收到一个所述目的节点回传的探测数据包时,所述源节点根据所述探测数据包中携带的编号接收顺序表更新探测数据包到达顺序表。
其中,所述探测数据包到达顺序表中按照到达所述目的节点的顺序,记录当前周期内已到达所述目的节点的探测数据包的第一编号。
示例的,假设回程探测数据包出现了如图17所示的乱序情况,源节点首先会首先接收到探测数据包#2,探测数据包#2中顺序携带了Seq1、Seq2两个第一编号,源节点按顺序将这两个第一编号记录于探测数据包到达顺序表中;之后源节点收到探测数据包#1,将第一编号Seq1记录于探测数据包到达顺序表中(如探测数据包到达顺序表中已有该第一编号的记录则跳过该步骤);在之后源节点收到探测数据包#4,将Seq1~Seq4四个第一编号按序记录于探测数据包到达顺序表中;以此类推,最后探测数据包#5到达,此时源节点的探测数据包到达顺序表中按序记录了Seq1~Seq6一共6个第一编号。
S1506:所述源节点发送业务数据流中一个待传输的业务数据包,所述待传输的业务数据包携带有第二编号。
其中,所述第二编号为所述源节点根据当前周期内接收所述探测数据包的次序,在所述探测数据包到达顺序表中确定的与所述次序相符的第一编号。
源节点每收到一个目的节点回传的探测数据包就发送一个真正的业务数据包,业务数据包和探测数据包的五元组(源IP地址、目的IP地址、源端口、目的端口、传输协议)相同,源节点通过对业务数据包的第二编号进行特定的赋值,来规划业务数据包的传输路径,使得业务数据包按序到达目的节点。具体地,如图17所示的场景,源节点接收到回程探测数据包#2时,会发送业务数据包#1,此时源节点通过解析该探测数据包得到了Seq1和Seq2两个第一编号,从而得知虽然回程传输最先到达的是探测数据包#2,但是去程传输最先到达目的节点的探测数据包的第一编号其实为Seq1,因此发送业务数据包#1时会将业务数据包的第二编号赋值为Seq1;之后回程探测数据包#1到达,源节点发送业务数据包#2,通过查探测数据包到达顺序表得知去程传输第二个到达的探测数据包的第一编号是Seq2,将业务数据包#2的第二编号赋值为Seq2;再接下来源节点接收回程探测数据包#4,并发送业务数据包#3,此时探测数据包到达顺序表中按序记录了Seq1~Seq4四个第一编号(记录于回程探测数据包#4中),源节点得知去程第三个到达的探测数据包的第一编号为Seq3,因此将业务数据包#3的第二编号赋值为Seq3;以此类推,最后源节点收到回程探测数据包#5并发送业务数据包#6,此时源节点探测数据包到达顺序表中按序记录了Seq1~Seq6一共6个第一编号,并将去程最后到达的探测数据包第一编号Seq6赋值给业务数据包#6。最后,6个业务数据包的第二编号按序赋值为Seq1~Seq6,使得6个业务数据包会按照去程探测数据包的传输顺序到达目的节点。
在本申请实施例中,源节点与目的节点对探测数据包和业务数据包除赋予第二编号之外的处理,以及位于源节点与目的节点之间的传输节点,对探测数据包和业务数据包的处理,可以参照实施例一,重复之处不再进行赘述。
具体的,本申请的所设计的基于端到端传输路径状态的调度策略,其核心的方法流程归纳如图18。当源节点有数据需要传输时,首先在控制通道(对应为探测数据包传输分配的第二带宽)中发送探测数据包探测多条传输路径拥塞状况。为保证同一探测数据流中不同探测数据包按多条传输路径路由转发,源节点对同一个探测数据流中的探测数据包编号(Seq)的值依照探测数据包发送顺序进行递增赋值(如:第一个探测数据包赋值Seq=1,第二个探测数据包赋值Seq=2,第三个探测数据包赋值Seq=3…)。另,本申请改进了传统的哈希择路方法,引入编号(Seq)值作为新的输入参数,传输节点基于五元组(源IP地址、目的IP地址、源端口、目的端口、传输层协议)及Seq一共6个输入参数计算哈希结果并选择出端口。
目的节点在接收到探测数据包之后,读取该探测数据包的Seq值并按照探测数据包到达顺序依次将先后到达的探测数据包Seq值记录到编号接收顺序表中。目的节点每收到一个探测数据包便将该数据包的源/目的地址对调,以最高优先级将该探测数据包回传给源节点;通过查询编号接收顺序表,目的节点将第1~n个到达的探测数据包Seq值携带至第n个回传的探测数据包头中,以便于后续源节点解决回程探测数据包的乱序问题。
源节点收到回传的探测数据包后,读取回程探测数据包中所携带的所有Seq值并按顺序记录在探测数据包到达顺序表中。源节点每收到一个回传探测数据包便在数据通道(对应为业务数据包传输分配的第一带宽)中发送一个业务数据包。当发送第n个业务数据包时,源节点必然已经收到了n个探测数据包,探测数据包到达顺序表中至少已经记录了n个Seq值;因此源节点可以从探测数据包到达顺序表中准确查到去程第n个到达的探测数据包对应的Seq值Seq n,并赋值给第n个业务数据包。由于Seq值与五元组相同,第n个业务数据包将依照和第n个去程探测数据包相同的传输路径被传输至目的节点。综上,保证了第n个业务数据包将第n个到达目的节点,即所有业务数据包按序到达,不需要传输层额外的保序还原操作。
相比于实施例一中的技术方案,本实施例的技术方案重点针对来回程路径及流量分布严重不对称的WAN网络场景,对此我们对实施例一中的网络拓扑架构进行了改进,构建出近似WAN的非对称网络架构。具体地,我们使用OMNET++仿真工具,在图1所示的数据中心网络中,随机选取25%的链路,将其链路带宽从10Gbps减少到3Gbps,从而构建出一个类似于WAN的非对称网络架构。之后,我们在Incast场景下评估本实施技术方案作用下网络的业务数据传输完成时间(FCT)、业务数据包乱序比例(Percentage of Disordered Packets)等指标。学术界最新提出的CONGA、Presto、DRILL、DRB以及传统的ECMP方案在仿真实验中均基于OMNET++环境进行了实现,用作本实施例技术方案的对比技术。
如图19所示,显示了不同负载分担方案作用下,网络的业务数据传输完成时间(A)以及业务数据包乱序比例(B)。从图19中可以看到,在引入了探测数据包到达顺序信息之后,本申请技术方案几乎完美解决了数据乱序问题:即便在2010个数据流并发传输的重负载场景,本申请技术方案依旧成功保持零乱序。从图19的结果看到,逐包负载分担方案(DRILL、本申请方案)作用下,网络的业务数据传输完成时间整体优于粗粒度的负载分担方案(CONGA、Presto、ECMP);另外由于本申请技术方案相比于DRILL更进一步解决了数据乱序的问题,因此整体性能比DRILL更优。
之后,我们进一步构建了不稳定的网络环境,测试本申请技术方案在高度动态网络环境下的调度效果。我们在图1所示的DCN网络中随机选取两个传输节点,对经过这两个传输节点的数据流引入50%的丢包,模拟出WAN网络故障的场景。在网络故障场景下,我们进一步对本申请技术方案和业界最新负载分担方案进行性能的比较。
图20中A和B两个图分别比较了不同负载分担方法在WAN网络故障场景下的传输成功率以及传输完成时间。从图20(A)中我们看出,DRILL、Presto和本申请三个方案可以成功感知到网络的故障,在不同网络负载程度下均能保证所有数据流100%的完成传输;而拥塞状况不感知的策略如ECMP,仅基于五元组对数据包进行哈希择路,导致总有一定比例的数据被哈希到故障的路径上,导致这部分数据一直不能成功完成传输。而从图20(B)中我们进一步发现,尽管DRILL、Presto和本申请三个方案都能成功感知到网络的故障,但是本申请的技术方案的传输完成时间比DRILL和Presto更优,说明本申请方案相比业界最先技术能够更快的感知网络环境的变化,因此更适用于网络环境高度动态变化的WAN场景。
上述主要从源节点、目的节点和传输节点的角度对本申请提供的方案进行了介绍。可以理解的是,为了实现上述功能,各网元包括了执行各个功能相应的硬件结构和/或软件模块(或单元)。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
图21为本申请的实施例提供的可能的通信装置的结构示意图。这些通信装置可以用于实现上述方法实施例中源节点或目的节点或传输节点的功能,因此也能实现上述方法实施例所具备的有益效果。在本申请的实施例中,该通信装置可以是图8或图15中的任一源节点或任一目的节点或任一传输节点,还可以是应用于源节点或目的节点或传输节点中的单元(或模块)等。
如图21所示。通信装置2100可以包括:处理单元2102和通信单元2103,还可以包括存储单元2101。通信装置2100用于实现上述图8或图15中所示的方法实施例中源节点或目的节点或传输节点的功能。
一种可能的设计中,处理单元2102用于实现相应的处理功能。通信单元2103用于支持通信装置2100与其他网络实体的通信。存储单元2101,用于存储通信装置2100的程序代码和/或数据。可选地,通信单元2103可以包括接收单元和/或发送单元,分别用于执行接收和发送操作。
当通信装置2100用于实现方法实施例中源节点的功能时:处理单元2102,用于为探测数据流中的探测数据包按发送顺序赋予第一编号,所述第一编号用于所述探测数据包的传输路径选择;通信单元2103,用于以第一发送速率向目的节点发送所述探测数据流中的探测数据包;所述通信单元2103,还用于每接收到一个所述目的节点回传的探测数据包时,发送业务数据流中一个待传输的业务数据包,其中所述待传输的业务数据包被赋予与所述探测数据包对应的第二编号,所述第二编号用于所述业务数据包的传输路径选择;
其中,当第一编号和第二编号相同时,被赋予所述第一编号的探测数据包和被赋予所述第二编号的业务数据包对应的传输路径相同。
在一种可能的设计中,所述通信单元2103以第一发送速率向目的节点发送所述探测数据流中的探测数据包时,具体用于在一个或多个传输周期内以所述第一发送速率向所述目的节点发送所述探测数据流中的探测数据包。
在一种可能的设计中,所述目的节点回传的探测数据包中携带有编号接收顺序表,所述编号接收顺序表用于所述目的节点在接收到所述探测数据包时,按照接收顺序记录当前周期内已接收到的探测数据包的第一编号;所述处理单元2102,还用于当所述通信单元2103每接收到一个所述目的节点回传的探测数据包时,根据所述目的节点回传的探测数据包中携带的编号接收顺序表更新探测数据包到达顺序表,所述探测数据包到达顺序表中按照到达所述目的节点的顺序,记录当前周期内已到达所述目的节点的探测数据包的第一编号。
在一种可能的设计中,所述第二编号为所述处理单元2102根据当前周期内接收所述目的节点回传的探测数据包的次序,在所述探测数据包到达顺序表中确定的与所述次序相符的第一编号。
在一种可能的设计中,所述处理单元2102,还用于根据所述探测数据包的丢包率,调整所述第一发送速率。
在一种可能的设计中,所述探测数据包不包含数据域。
当通信装置2100用于实现方法实施例中目的节点的功能时:处理单元2102,用于当通信单元2103每接收到一个来自于源节点的探测数据包时,更新编号接收顺序表,所述编号接收顺序表用于按照接收顺序,记录当前周期内已接收到的探测数据包的第一编号;
所述通信单元2103,用于向所述源节点回传所述探测数据包,其中回传的所述探测数据包中携带所述编号接收顺序表。
在一种可能的设计中,向所述源节点回传的所述探测数据包携带最高传输优先级的信息,其中所述最高传输优先级对应的丢包优先级最低。
在一种可能的设计中,所述探测数据包不包含数据域。
当通信装置2100用于实现方法实施例中传输节点的功能时:通信单元2103,用于接收数据包,其中所述数据包携带有编号,所述编号用于所述数据包的传输路径选择;
处理单元2102,用于基于所述数据包对应的源IP地址、目的IP地址、源端口、目的端口、传输协议以及所述编号计算哈希值;以及根据所述哈希值,选择与所述哈希值对应的出端口转发所述数据包。
在一种可能的设计中,所述数据包为探测数据包或业务数据包。
在一种可能的设计中,所述处理单元2102,还用于为业务数据包传输分配第一带宽、为探测数据包传输分配第二带宽,其中所述第一带宽大于所述第二带宽。
在一种可能的设计中,所述第二宽带与所述第一带宽的比值为所述探测数据包的平均大小与所述业务数据包平均大小的比值。
在一种可能的设计中,当所通信单元2103接收的探测数据包为去程探测数据包时,所述通信单元2103通过所述第二带宽传输所述去程探测数据包;当所述通信单元2103接收的探测数据包为回传探测数据包时,所述通信单元2103通过所述第一带宽传输所述回程探测数据包;其中,所述去程探测数据包为源节点向目的节点发送的探测数据包,所述回程探测数据包为所述目的节点向所述源节点回传的探测数据包。
在一种可能的设计中,当所述通信单元2103接收所述去程探测数据包的速率大于所述第二带宽时,所述通信单元2103丢弃所述去程探测数据包,如丢弃超出传输能力(第二带宽)的去程探测数据包。
在一种可能的设计中,所述回程探测数据包携带最高传输优先级的信息,其中所述最高传输优先级对应的丢包优先级最低。
在一种可能的设计中,所述探测数据包不包含数据域。
基于以上实施例,本申请实施例还提供了一种通信装置,参照图22所示,所述通信装置2200包括:通信接口2201、处理器2202以及存储器2203,其中:
所述通信接口2201、所述处理器2202以及所述存储器2203之间相互连接。可选的,所述通信接口2201、所述处理器2202以及所述存储器2203通过总线2204相互连接;所述总线2204可以是外设部件互连标准(peripheral component interconnect,PCI)总线或扩展工业标准结构(extended industry standard architecture,EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图22中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
所述通信装置2200在实现如图8或如图15所示的适用于源节点的通信方法时:
通信接口2201,用于接收和发送数据;
处理器2202,用于调用存储在所述存储器中的程序指令以执行下述方法:
为探测数据流中的探测数据包按发送顺序赋予第一编号,所述第一编号用于所述探测数据包的传输路径选择;
通过所述通信接口2201以第一发送速率向目的节点发送所述探测数据流中的探测数据包;
当通过所述通信接口2201每接收到一个所述目的节点回传的探测数据包时,通过所述通信接口2201发送业务数据流中一个待传输的业务数据包,其中所述待传输的业务数据包被赋予与所述探测数据包对应的第二编号,所述第二编号用于所述业务数据包的传输路径选择;
其中,当第一编号和第二编号相同时,被赋予所述第一编号的探测数据包和被赋予所述第二编号的业务数据包对应的传输路径相同。
在一种可能的设计中,所述通过所述通信接口2201以第一发送速率向目的节点发送所述探测数据流中的探测数据包,包括:
通过所述通信接口2201在一个或多个传输周期内以所述第一发送速率向所述目的节点发送所述探测数据流中的探测数据包。
在一种可能的设计中,所述目的节点回传的探测数据包中携带有编号接收顺序表,所述编号接收顺序表用于所述目的节点在接收到所述探测数据包时,按照接收顺序记录当前周期内已接收到的探测数据包的第一编号;所述方法还包括:
当通过所述通信接口2201每接收到一个所述目的节点回传的探测数据包时,根据所述目的节点回传的探测数据包中携带的编号接收顺序表更新探测数据包到达顺序表,所述探测数据包到达顺序表中按照到达所述目的节点的顺序,记录当前周期内已到达所述目的节点的探测数据包的第一编号。
在一种可能的设计中,所述第二编号为根据当前周期内接收所述目的节点回传的探测数据包的次序,在所述探测数据包到达顺序表中确定的与所述次序相符的第一编号。
在一种可能的设计中,所述方法还包括:
根据所述探测数据包的丢包率,调整所述第一发送速率。
在一种可能的设计中,所述探测数据包不包含数据域。
在另一可能的实施中,所述通信装置2200在实现如图8或如图15所示的适用于目的节点的通信方法时:
通信接口2201,用于接收和发送数据;
处理器2202,用于调用存储在所述存储器中的程序指令以执行下述方法:
当所述通信接口2201每接收到一个来自于源节点的探测数据包时,更新编号接收顺序表,所述编号接收顺序表用于按照接收顺序,记录当前周期内已接收到的探测数据包的第一编号;
通过所述通信接口2201向所述源节点回传所述探测数据包,其中回传的所述探测数据包中携带所述编号接收顺序表。
在一种可能的设计中,所述目的节点向所述源节点回传的所述探测数据包携带最高传输优先级的信息,其中所述最高传输优先级对应的丢包优先级最低。
在一种可能的设计中,所述探测数据包不包含数据域。
在另一可能的实施中,所述通信装置2200在实现如图8或如图15所示的适用于传输节点的通信方法时:
通信接口2201,用于接收和发送数据;
处理器2202,用于调用存储在所述存储器中的程序指令以执行下述方法:
通过所述通信接口2201接收数据包,其中所述数据包携带有编号,所述编号用于所述数据包的传输路径选择;
基于所述数据包对应的源IP地址、目的IP地址、源端口、目的端口、传输协议以及所述编号计算哈希值;
根据所述哈希值,选择与所述哈希值对应的出端口转发所述数据包。
在一种可能的设计中,所述数据包为探测数据包或业务数据包。
在一种可能的设计中,所述方法还包括:
为业务数据包传输分配第一带宽、为探测数据包传输分配第二带宽,其中所述第一带宽大于所述第二带宽。
在一种可能的设计中,所述第二宽带与所述第一带宽的比值为所述探测数据包的平均大小与所述业务数据包平均大小的比值。
在一种可能的设计中,所述方法还包括:
当通过所述通信接口2201接收的探测数据包为去程探测数据包时,通过所述第二带宽传输所述去程探测数据包;当通过所述通信接口2201接收的探测数据包为回传探测数据包时,通过所述第一带宽传输所述回程探测数据包,所述去程探测数据包为源节点向目的节点发送的探测数据包,所述回程探测数据包为所述目的节点向所述源节点回传的探测数据包。
在一种可能的设计中,当通过所述通信接口2201接收所述去程探测数据包的速率大于所述第二带宽时,丢弃所述去程探测数据包,如丢弃超出传输能力(第二带宽)的去程探测数据包。
在一种可能的设计中,所述回程探测数据包携带最高传输优先级的信息,其中所述最高传输优先级对应的丢包优先级最低。
在一种可能的设计中,所述探测数据包不包含数据域。
作为本实施例的另一种形式,提供一种计算机可读存储介质,其上存储有指令,该指令被执行时可以执行上述方法实施例中适用于源节点或目的节点或传输节点的方法。
作为本实施例的另一种形式,提供一种包含指令的计算机程序产品,该指令被执行时可以执行上述方法实施例中适用于源节点或目的节点或传输节点的方法。
作为本实施例的另一种形式,提供一种芯片,所述芯片运行时,可以执行上述方法实施例中适用于源节点或目的节点或传输节点的方法。
在本申请实施例中,处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件,可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。
在本申请实施例中,存储器可以是非易失性存储器,比如硬盘(hard disk drive,HDD)或固态硬盘(solid-state drive,SSD)等,还可以是易失性存储器(volatilememory),例如随机存取存储器(random-access memory,RAM)。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置,用于存储程序指令和/或数据。
本申请实施例提供的技术方案可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、终端设备或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机可以存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如,数字视频光盘(digital video disc,DVD))、或者半导体介质等。
在本申请实施例中,在无逻辑矛盾的前提下,各实施例之间可以相互引用,例如方法实施例之间的方法和/或术语可以相互引用,例如装置实施例之间的功能和/或术语可以相互引用,例如装置实施例和方法实施例之间的功能和/或术语可以相互引用。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
【实施例三】
上述实施例一和实施例二的方案,主要在网络协议栈中的三层(网络层)之上完成多路径逐包传输方案的设计,因此可以使用“IP五元组+包序号”组成的六元组作为编号来标识不同的数据包。在网络协议栈中的三层(网络层)实现实施例一和实施例二中的技术方案,往往涉及对操作系统内核的修改,相对工作量较大;本实施例重点介绍如何在网络协议栈中的二层(MAC层)实现自保序的多路径逐包传输,从而避免复杂的操作系统内核修改。
网络协议栈的MAC层无法直接识别传统的IP五元组,因此无法采用实施例一和实施例二中的六元组作为数据包的唯一标识。根据IEEE 802.11MAC层的数据帧格式定义,在MAC层实现本方案时,可以采用“源MAC地址+目的MAC地址+帧序号”三元组组成的唯一编号,用于标识特定的数据帧。基于三元组完成数据帧标识之后,依然可以复用实施例一种的方案,基于回传探测数据包的到达顺序进行业务数据包编号(三元组)的赋值,从而规划业务数据的传输路径。
具体地,源节点发起MAC层数据帧传输之前,首先使用目的节点的IP地址发起ARP请求;网关节点根据目的节点的IP地址返回网关网卡的MAC地址;源节点得到网关网卡的MAC地址后,开始源以第一发送速率向目的节点发送探测数据包。
位于源节点和目的节点之间的传输节点接收到源节点发送的去程探测数据包或业务数据包后,基于探测数据包中的三元组(源MAC地址、目的MAC地址及帧序号)进行哈希计算,得到哈希值,并根据得到的哈希值选择出端口。
目的节点每接收到一个数据包后,可以首先判断该数据包是探测数据包还是业务数据包,如果接收到的数据包为探测数据包,对探测数据包进行回传。示例的,目的节点可以将探测数据包的源MAC和目的MAC对换并发送,将探测数据包回传至源节点。如果目的节点接收到的数据包为业务数据包,目的节点对业务数据包进行解析处理。示例的,目的节点对业务数据包进行解封装,并读取业务数据包中携带的数据。
源节点每接收到一个目的节点回传的探测数据包(回程探测数据包)时,源节点读取该探测数据包携带的三元组信息(源MAC地址、目的MAC地址及帧序号),并将接收的到探测数据包携带的三元组信息赋值给业务数据流中当前待传输的业务数据包,作为该待传输的业务数据包的标识,并向目的节点发送该待传输的业务数据包。从而在MAC层实现了自保序的逐包多路径数据传输。
与实施例一和实施例二不同,在MAC层实现多路径逐包传输方案时,可以不采用六元组(传统IP五元组+包序号)作为特定数据包的标号,而采用三元组(源MAC地址+目的MAC地址+帧序号)作为数据帧的唯一标识。之后数据的传输过程依然采用“探测数据包探测并回传,业务数据包基于回传探测包的三元组信息进行编号赋值及路径规划”的方法实现自保序的多路径传输。因此标识数据的编号不一定限制为六元组(传统IP五元组+包序号),任何能够唯一标识一个特定数据包的属性组合都可以作为编号在探测数据包和业务数据包之间进行赋值,并作为参数进行路径规划。

Claims (37)

1.一种通信方法,其特征在于,包括:
源节点为探测数据流中的探测数据包按发送顺序赋予第一编号,所述第一编号用于所述探测数据包的传输路径选择;
所述源节点以第一发送速率向目的节点发送所述探测数据流中的探测数据包;
当所述源节点每接收到一个所述目的节点回传的探测数据包时,所述源节点发送业务数据流中一个待传输的业务数据包,其中所述待传输的业务数据包被赋予与所述探测数据包对应的第二编号,所述第二编号用于所述业务数据包的传输路径选择;
其中,当第一编号和第二编号相同时,被赋予所述第一编号的探测数据包和被赋予所述第二编号的业务数据包对应的传输路径相同。
2.如权利要求1所述的方法,其特征在于,所述源节点以第一发送速率向目的节点发送所述探测数据流中的探测数据包,包括:
所述源节点在一个或多个传输周期内以所述第一发送速率向所述目的节点发送所述探测数据流中的探测数据包。
3.如权利要求2所述的方法,其特征在于,所述目的节点回传的探测数据包中携带有编号接收顺序表,所述编号接收顺序表用于所述目的节点在接收到所述探测数据包时,按照接收顺序记录当前周期内已接收到的探测数据包的第一编号;所述方法还包括:
当所述源节点每接收到一个所述目的节点回传的探测数据包时,所述源节点根据所述目的节点回传的探测数据包中携带的编号接收顺序表更新探测数据包到达顺序表,所述探测数据包到达顺序表中按照到达所述目的节点的顺序,记录当前周期内已到达所述目的节点的探测数据包的第一编号。
4.如权利要求3所述的方法,其特征在于,所述第二编号为所述源节点根据当前周期内接收所述目的节点回传的探测数据包的次序,在所述探测数据包到达顺序表中确定的与所述次序相符的第一编号。
5.如权利要求1所述的方法,其特征在于,所述方法还包括:
所述源节点根据所述探测数据包的丢包率,调整所述第一发送速率。
6.如权利要求1-5中任一项所述的方法,其特征在于,所述探测数据包不包含数据域。
7.一种通信方法,其特征在于,包括:
当目的节点每接收到一个来自于源节点的探测数据包时,所述目的节点更新编号接收顺序表,所述编号接收顺序表用于按照接收顺序,记录当前周期内已接收到的探测数据包的第一编号;
所述目的节点向所述源节点回传所述探测数据包,其中回传的所述探测数据包中携带所述编号接收顺序表。
8.如权利要求7所述的方法,其特征在于,所述目的节点向所述源节点回传的所述探测数据包携带最高传输优先级的信息,其中所述最高传输优先级对应的丢包优先级最低。
9.如权利要求7或8所述的方法,其特征在于,所述探测数据包不包含数据域。
10.一种通信方法,其特征在于,包括:
传输节点接收数据包,其中所述数据包携带有编号,所述编号用于所述数据包的传输路径选择;
所述传输节点基于所述数据包对应的源IP地址、目的IP地址、源端口、目的端口、传输协议以及所述编号计算哈希值;
所述传输节点根据所述哈希值,选择与所述哈希值对应的出端口转发所述数据包。
11.如权利要求10所述的方法,其特征在于,所述数据包为探测数据包或业务数据包。
12.如权利要求11所述的方法,其特征在于,所述方法还包括:
所述传输节点为业务数据包传输分配第一带宽、为探测数据包传输分配第二带宽,其中所述第一带宽大于所述第二带宽。
13.如权利要求12所述的方法,其特征在于,所述第二宽带与所述第一带宽的比值为所述探测数据包的平均大小与所述业务数据包平均大小的比值。
14.如权利要求12所述的方法,其特征在于,所述方法还包括:
当所述传输节点接收的探测数据包为去程探测数据包时,所述传输节点通过所述第二带宽传输所述去程探测数据包;
当所述传输节点接收的探测数据包为回传探测数据包时,所述传输节点通过所述第一带宽传输所述回程探测数据包;
其中,所述去程探测数据包为源节点向目的节点发送的探测数据包,所述回程探测数据包为所述目的节点向所述源节点回传的探测数据包。
15.如权利要求14所述的方法,其特征在于,所述方法还包括:
当所述传输节点接收所述去程探测数据包的速率大于所述第二带宽时,所述传输节点丢弃所述去程探测数据包。
16.如权利要求14所述的方法,其特征在于,所述回程探测数据包携带最高传输优先级的信息,其中所述最高传输优先级对应的丢包优先级最低。
17.如权利要求10-16中任一项所述的方法,其特征在于,所述探测数据包不包含数据域。
18.一种通信装置,其特征在于,包括:
处理单元,用于为探测数据流中的探测数据包按发送顺序赋予第一编号,所述第一编号用于所述探测数据包的传输路径选择;
通信单元,用于以第一发送速率向目的节点发送所述探测数据流中的探测数据包;
所述通信单元,还用于每接收到一个所述目的节点回传的探测数据包时,发送业务数据流中一个待传输的业务数据包,其中所述待传输的业务数据包被赋予与所述探测数据包对应的第二编号,所述第二编号用于所述业务数据包的传输路径选择;
其中,当第一编号和第二编号相同时,被赋予所述第一编号的探测数据包和被赋予所述第二编号的业务数据包对应的传输路径相同。
19.如权利要求18所述的通信装置,其特征在于,所述通信单元以第一发送速率向目的节点发送所述探测数据流中的探测数据包时,具体用于在一个或多个传输周期内以所述第一发送速率向所述目的节点发送所述探测数据流中的探测数据包。
20.如权利要求19所述的通信装置,其特征在于,所述目的节点回传的探测数据包中携带有编号接收顺序表,所述编号接收顺序表用于所述目的节点在接收到所述探测数据包时,按照接收顺序记录当前周期内已接收到的探测数据包的第一编号;所述处理单元,还用于当所述通信单元每接收到一个所述目的节点回传的探测数据包时,根据所述目的节点回传的探测数据包中携带的编号接收顺序表更新探测数据包到达顺序表,所述探测数据包到达顺序表中按照到达所述目的节点的顺序,记录当前周期内已到达所述目的节点的探测数据包的第一编号。
21.如权利要求20所述的通信装置,其特征在于,所述第二编号为所述处理单元根据当前周期内接收所述目的节点回传的探测数据包的次序,在所述探测数据包到达顺序表中确定的与所述次序相符的第一编号。
22.如权利要求18所述的通信装置,其特征在于,所述处理单元,还用于根据所述探测数据包的丢包率,调整所述第一发送速率。
23.如权利要求18-22中任一项所述的通信装置,其特征在于,所述探测数据包不包含数据域。
24.一种通信装置,其特征在于,包括处理器和通信接口,所述通信接口用于接收来自所述通信装置之外的其它通信装置的信号并传输至所述处理器或将来自所述处理器的信号发送给所述通信装置之外的其它通信装置,所述处理器通过逻辑电路或执行代码指令用于实现如权利要求1-6中任一项所述的方法,或者实现如权利要求7-9中任一项所述的方法,或者实现如权利要求10-17中任一项所述的方法。
25.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质包括计算机程序,当计算机程序在被一个或多个处理器读取并执行时实现如权利要求1-6中任一项所述的方法,或者实现如权利要求7-9中任一项所述的方法,或者实现如权利要求10-17中任一项所述的方法。
26.一种芯片,其特征在于,所述芯片运行时,实现如权利要求1-6中任一项所述的方法,或者实现如权利要求7-9中任一项所述的方法,或者实现如权利要求10-17中任一项所述的方法。
27.一种通信方法,其特征在于,包括:
传输节点接收数据包,其中所述数据包携带有编号,所述编号用于所述数据包的传输路径选择;
所述传输节点基于所述数据包对应的源媒体接入层MAC地址地址、目的MAC地址、源端口、帧序号计算哈希值;
所述传输节点根据所述哈希值,选择与所述哈希值对应的出端口转发所述数据包。
28.如权利要求27所述的方法,其特征在于,所述数据包为探测数据包或业务数据包。
29.如权利要求28所述的方法,其特征在于,所述方法还包括:
所述传输节点为业务数据包传输分配第一带宽、为探测数据包传输分配第二带宽,其中所述第一带宽大于所述第二带宽。
30.如权利要求29所述的方法,其特征在于,所述第二宽带与所述第一带宽的比值为所述探测数据包的平均大小与所述业务数据包平均大小的比值。
31.如权利要求29所述的方法,其特征在于,所述方法还包括:
当所述传输节点接收的探测数据包为去程探测数据包时,所述传输节点通过所述第二带宽传输所述去程探测数据包;
当所述传输节点接收的探测数据包为回传探测数据包时,所述传输节点通过所述第一带宽传输所述回程探测数据包;
其中,所述去程探测数据包为源节点向目的节点发送的探测数据包,所述回程探测数据包为所述目的节点向所述源节点回传的探测数据包。
32.如权利要求31所述的方法,其特征在于,所述方法还包括:
当所述传输节点接收所述去程探测数据包的速率大于所述第二带宽时,所述传输节点丢弃所述去程探测数据包。
33.如权利要求31所述的方法,其特征在于,所述回程探测数据包携带最高传输优先级的信息,其中所述最高传输优先级对应的丢包优先级最低。
34.如权利要求27-33中任一项所述的方法,其特征在于,所述探测数据包不包含数据域。
35.一种通信装置,其特征在于,包括处理器和通信接口,所述通信接口用于接收来自所述通信装置之外的其它通信装置的信号并传输至所述处理器或将来自所述处理器的信号发送给所述通信装置之外的其它通信装置,所述处理器通过逻辑电路或执行代码指令用于实现如权利要求27-34中任一项所述的方法。
36.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质包括计算机程序,当计算机程序在被一个或多个处理器读取并执行时实现如权利要求27-34中任一项所述的方法。
37.一种芯片,其特征在于,所述芯片运行时,实现如权利要求27-34中任一项所述的方法。
CN202110598905.3A 2020-05-30 2021-05-31 一种通信方法及装置 Pending CN113746751A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2020104807087 2020-05-30
CN202010480708 2020-05-30

Publications (1)

Publication Number Publication Date
CN113746751A true CN113746751A (zh) 2021-12-03

Family

ID=78728446

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110598905.3A Pending CN113746751A (zh) 2020-05-30 2021-05-31 一种通信方法及装置

Country Status (4)

Country Link
US (1) US11863322B2 (zh)
EP (1) EP4149066A4 (zh)
CN (1) CN113746751A (zh)
WO (1) WO2021244450A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114440712A (zh) * 2022-01-20 2022-05-06 北京理工大学 一种面向协同毁伤评估的探测载荷资源调度方法
WO2023193689A1 (zh) * 2022-04-08 2023-10-12 华为技术有限公司 报文传输方法、装置、设备及计算机可读存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114785757B (zh) * 2022-03-31 2023-10-20 东北大学 一种面向实时会话类业务的多径传输控制方法

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030128672A1 (en) * 2001-06-19 2003-07-10 Sridhar Komandur Transmission and flow control
US7984174B2 (en) * 2002-11-11 2011-07-19 Supracomm, Tm Inc. Multicast videoconferencing
US7065376B2 (en) * 2003-03-20 2006-06-20 Microsoft Corporation Multi-radio unification protocol
US20060031564A1 (en) * 2004-05-24 2006-02-09 Brassil John T Methods and systems for streaming data at increasing transmission rates
US8111649B1 (en) * 2008-03-31 2012-02-07 Google Inc. Method and apparatus for enabling a host to influence how a packet is routed through a network
CN103312607B (zh) * 2012-03-09 2016-12-21 华为技术有限公司 一种传输路径选择方法及装置
US9608789B2 (en) * 2012-05-11 2017-03-28 Interdigital Patent Holdings, Inc. Method and apparatus for transmitting acknowledgements in response to received frames
US10778584B2 (en) 2013-11-05 2020-09-15 Cisco Technology, Inc. System and method for multi-path load balancing in network fabrics
CN104639470B (zh) * 2013-11-14 2019-05-31 中兴通讯股份有限公司 流标识封装方法及系统
CN104038322B (zh) 2014-06-16 2017-12-19 北京邮电大学 中间节点、通信网络及其数据传输控制方法
CN104618236A (zh) 2015-01-21 2015-05-13 网宿科技股份有限公司 一种加速网络的并行数据传输系统及方法
US9923828B2 (en) * 2015-09-23 2018-03-20 Cisco Technology, Inc. Load balancing with flowlet granularity
CN105578553B (zh) 2015-12-23 2019-12-13 北京奇虎科技有限公司 数据通信发起、中继、接收方法及其装置
CN105681445B (zh) * 2016-02-04 2019-01-29 福建星网锐捷通讯股份有限公司 数据的点对点传输路径选择方法及装置
CN106201356B (zh) 2016-07-14 2019-07-19 北京理工大学 一种基于链路可用带宽状态的动态数据调度方法
CN107786440B (zh) * 2016-08-26 2021-05-11 华为技术有限公司 一种数据报文转发的方法及装置
CN108881008B (zh) 2017-05-12 2021-06-08 华为技术有限公司 一种数据传输的方法、装置和系统
US10680966B2 (en) * 2017-12-27 2020-06-09 Juniper Networks, Inc. Intelligent buffering for packet reordering by virtual nodes within a network device
CN110166366B (zh) * 2018-02-14 2023-02-28 华为技术有限公司 网络拥塞控制方法、装置和系统
CN108390820B (zh) 2018-04-13 2021-09-14 华为技术有限公司 负载均衡的方法、设备及系统

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114440712A (zh) * 2022-01-20 2022-05-06 北京理工大学 一种面向协同毁伤评估的探测载荷资源调度方法
CN114440712B (zh) * 2022-01-20 2022-11-08 北京理工大学 一种面向协同毁伤评估的探测载荷资源调度方法
WO2023193689A1 (zh) * 2022-04-08 2023-10-12 华为技术有限公司 报文传输方法、装置、设备及计算机可读存储介质

Also Published As

Publication number Publication date
US20230096063A1 (en) 2023-03-30
EP4149066A1 (en) 2023-03-15
WO2021244450A1 (zh) 2021-12-09
US11863322B2 (en) 2024-01-02
EP4149066A4 (en) 2023-11-01

Similar Documents

Publication Publication Date Title
US11757764B2 (en) Optimized adaptive routing to reduce number of hops
JP7417825B2 (ja) スライスベースルーティング
US10938724B2 (en) Flow rate based network load balancing
US11595315B2 (en) Quality of service in virtual service networks
CN113746751A (zh) 一种通信方法及装置
US10374945B1 (en) Application-centric method to find relative paths
Nithin et al. Efficient load balancing for multicast traffic in data center networks using SDN
CN114531399B (zh) 一种内存阻塞平衡方法、装置、电子设备和存储介质
Li et al. VMS: Traffic balancing based on virtual switches in datacenter networks
US20240056385A1 (en) Switch device for facilitating switching in data-driven intelligent network
CN116112438A (zh) 端到端数据传输方法及系统

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