CN108243111B - 确定传输路径的方法和装置 - Google Patents

确定传输路径的方法和装置 Download PDF

Info

Publication number
CN108243111B
CN108243111B CN201611229376.5A CN201611229376A CN108243111B CN 108243111 B CN108243111 B CN 108243111B CN 201611229376 A CN201611229376 A CN 201611229376A CN 108243111 B CN108243111 B CN 108243111B
Authority
CN
China
Prior art keywords
path
message
transmitted
congestion
flow
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.)
Active
Application number
CN201611229376.5A
Other languages
English (en)
Other versions
CN108243111A (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.)
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
Priority to CN201611229376.5A priority Critical patent/CN108243111B/zh
Priority to PCT/CN2017/109372 priority patent/WO2018121068A1/zh
Priority to EP17887401.2A priority patent/EP3541027B1/en
Publication of CN108243111A publication Critical patent/CN108243111A/zh
Priority to US16/452,821 priority patent/US10924413B2/en
Application granted granted Critical
Publication of CN108243111B publication Critical patent/CN108243111B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • 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/11Identifying 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
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • 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/28Flow control; Congestion control in relation to timing considerations
    • 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/33Flow control; Congestion control using forward notification

Abstract

本申请实施例提供了一种确定传输路径的方法和装置,该方法包括:确定待传输报文所属的流对应的当前路径上发生拥塞;根据路径拥塞信息表,为所述待传输报文确定目标路径,并将所述目标路径的信息添加在所述待传输报文中,以使得所述待传输报文根据所述目标路径进行传输,其中,所述目标路径的拥塞程度比所述当前路径的拥塞程度小,所述路径拥塞信息表的每个表项包括一条传输路径以及所述传输路径对应的拥塞信息,所述拥塞信息用于表示所述传输路径的拥塞程度。从而有效地解决传输路径拥塞的问题。

Description

确定传输路径的方法和装置
技术领域
本申请实施例涉及通信领域,并且更具体地,涉及一种确定传输路径的方法和装置。
背景技术
互联网数据正在以爆炸性的方式增长,中国的新浪微博注册用户数量已经破3亿,腾讯的即时通讯工具活跃用户达到7.1亿,Facebook全球用户数量则正逼近10亿,仅次于中国和印度的人口数字。仅社交网络这一项所产生的数据就已经非常惊人。据国际数据公司IDC发布的报告《Digital Universe Study 2011》显示,全球信息总量每过两年就会增长一倍。仅在2011年,全球被创建和被复制的数据总量为1.8ZB(即1.8万亿GB)。相较2010年同期上涨超过1ZB,到2020年这一数值将增长到35ZB。大数据的出现正迫使企业不断提升自身以数据中心为平台的数据处理能力。
Google、Microsoft及Facebook等巨头在数据中心的网络领域走在业界最前沿,这些业界引领者的多年研究及实践表明,基于克劳斯(英文:Clos)架构的数据中心网络扩展性佳,等价路径多,因此正得到越来越广泛的部署。
Clos数据中心网络架构尽管有等价路径多的优势,但是在传统的负载均衡(英文:load balancing,简称“LB”)机制下却容易出现严重的路径拥塞。图1是一个典型的数据中心3层Clos网络构架的示意图,每层设备例如可以为交换机、路由器等网络设备,其中,底层设备为架顶设备,或称为叶子设备(英文:leaf device,简称“Leaf”);中间层设备为汇集设备(英文:aggregation device,简称“Agg”);顶层设备为核心设备(英文:core device,简称Core)。如图1所示,该Clos网络中有四条流(Flow)即Flow A、Flow B、Flow C和Flow D,分别从不同的源设备转发到不同的目的设备。尽管网络中存在不止四条路径可以完成这四条流的转发,但是由于传统的负载均衡机制的缺陷,会导致转发路径出现重叠。如图1所示,Flow A与Flow B在中间层设备Agg0处发生了本地冲突(英文:local collision),即,FlowA与Flow B本可以通过走不同路径(例如分别通过路径Agg 0→Core 0和路径Agg 0→Core1)进行传输,但由于某些控制机制的缺陷等导致Flow A与Flow B都使用路径Agg 0→Core0进行传输,假设Flow A与Flow B的流速均为6G,Agg 0最大能满足的流速为10G,当Flow A与Flow B在Agg 0处交汇时,由于6G×2=12G超过了10G,导致了Flow A与Flow B在Agg 0处发生冲突。图1中的Flow C与Flow D在Core 2处发生下游冲突(英文:downstreamcollision),即,由于Core 2到下游目的设备之间只存在一条路径(即Core 2→Agg 3),从而导致Flow C与Flow D必然会在Core 2处发生冲突。因此,如何通过优化负载均衡机制避免网络中出现局部拥塞导致丢包已成为当下业内的焦点。
发明内容
本申请实施例提供一种确定传输路径的方法和装置,能够有效地解决传输路径拥塞的问题。
第一方面,提供了一种确定传输路径的方法,该方法包括:
确定待传输报文所属的流对应的当前路径上发生拥塞;
根据路径拥塞信息表,为所述待传输报文确定目标路径,并将所述目标路径的信息添加在所述待传输报文中,以使得所述待传输报文根据所述目标路径进行传输,其中,所述目标路径的拥塞程度比所述当前路径的拥塞程度小,所述路径拥塞信息表的每个表项包括一条传输路径以及所述传输路径对应的拥塞信息,所述拥塞信息用于表示所述传输路径的拥塞程度;
根据所述目标路径,发送所述待传输报文。
因此,本申请实施例中,通过确定传输路径发生拥塞,并在发生路径拥塞时根据路径拥塞信息表为待传输报文确定新的路径,能够有效地解决传输路径拥塞的问题。
由于本申请实施例只有在当前路径确实发生拥塞、确实有必要进行路径切换时,才会进行传输路径的切换,避免了拥塞不匹配等问题,且切换后的路径的拥塞程度小于该当前路径,避免了长尾效应。
另外,本申请实施例中,交换机、路由器等网络设备上可以不做任何修改,整个路径的决策可以由其他装置例如主机来执行,拥塞信息表可以保存在主机中,从而解决了表项规格受限的问题,能够适用于3级Clos甚至N级Clos架构中。其中,N大于3。
可选地,在第一方面的一种实现方式中,所述确定待传输报文所属的流对应的当前路径上发生拥塞,包括:确定所述流在所述当前路径上传输时被标记显式拥塞通知ECN,或者所述当前路径对应的往返时间RTT大于时间阈值,或者所述当前路径发生故障
可选地,在第一方面的一种实现方式中,所述拥塞信息包括以下信息中的至少一种:所述传输路径的平均ECN次数、所述传输路径的RTT、用于表示所述传输路径是否故障的标识、以及所述传输路径上同时存在的流的个数。
相比于现有技术中仅仅依靠一段时间内出端口的利用率来表示路径的拥塞程度,本申请实施例通过包括平均ECN次数、往返时间RTT、用于表示路径是否故障的标识、以及路径上同时存在的流的个数等参数的拥塞信息来表征传输路径的拥塞程度,能够更加准确的对路径的拥塞程度进行评价,从而更有效地指导路径切换。
可选地,在第一方面的一种实现方式中,所述根据路径拥塞信息表,为所述待传输报文确定目标路径之前,所述方法还包括:确定所述待传输报文所属的流的流速是否大于预设阈值;若所述流的流速大于所述预设阈值,执行所述根据所述路径拥塞信息表,为所述待传输报文确定目标路径的步骤。
由于只在流速超过预设的阈值时才对该待传输报文进行路径切换操作,从而避免了不必要的切换,例如对较小的流进行切片就完全没有必要。
可选地,在第一方面的一种实现方式中,所述根据路径拥塞信息表,为所述待传输报文确定目标路径,包括:在所述待传输报文和所述当前路径上待传输的其他报文中,若所述待传输报文以预设概率被选择到,则根据所述路径拥塞信息表,为所述待传输报文确定所述目标路径,以使得所述待传输报文根据所述目标路径进行传输。
这样,当前路径发生拥塞时,在该路径上将要传输的至少一个流中,不是所有流一起进行路径切换,而是根据预设概率选择一部分流进行路径切换,从而降低了切换后再次发生拥塞的概率,提高了报文传输的成功率。
可选地,在第一方面的一种实现方式中,所述方法还包括:确定所述目标路径的RTT与所述当前路径的RTT之间的时间差;在经过所述时间差的时长后,发送所述待传输报文。
为了避免乱序的发生,主机确定待传输报文对应的当前路径发生拥塞而为该报文所属的流确定了新的路径即目标路径后,主机可以确定该目标路径的RTT与该当前路径的RTT之间的时间差,从而主机在等于该时间差的时长后,再发送该待传输报文。这样可以避免路径切换导致的报文乱序。例如对报文1所述的流进行路径切换没有成功,则需要等待固定时长例如100ms后,再对报文1所述的流执行路径切换操作。
可选地,在第一方面的一种实现方式中,所述在根据路径拥塞信息表,为所述待传输报文确定目标路径之前,所述方法还包括:在至少一条传输路径中的每条传输路径上发送探测报文;接收针对所述探测报文的响应报文;根据所述响应报文,确定至少一条传输路径中每条传输路径对应的所述拥塞信息;根据所述至少一条传输路径中每条传输路径对应的所述拥塞信息,生成所述路径拥塞信息表。
进一步地,主机还可以周期性地或者实时地,对该路径拥塞信息表进行更新,对路径拥塞信息表的更新例如可以通过有源探测器(英文:active probe)发起定期主动探测,记录平均ECN次数、RTT等等信息并保存到路径拥塞信息表中,以主机为例,保存目的地可以为主机本地例如主机内存或硬盘中。同时还可以依据平均ECN次数、RTT等信息为路径划分等级,以对路径切换进行指导。
可选地,在第一方面的一种实现方式中,所述方法还包括:若获取的一条传输路径的拥塞信息中包括表示所述传输路径发生故障的标识,将所述传输路径对应的表项从所述路径拥塞信息表中删除。
也就是说,主机在获取到哪条路径故障后,可以及时将该路径以及该路径的相关信息从该路径拥塞信息表中删除,路径拥塞信息表可以实时地进行该更新操作。在后续的路径选择过程中,就可以在没有故障的路径中进行路径选择。
第二方面,提供了一种确定传输路径的装置,该装置可以用于执行前述第一方面及各种实现方式中所述的确定传输路径的方法中的各个过程。该装置包括确定单元和发送单元,其中,确定单元,用于确定待传输报文所属的流对应的当前路径上发生拥塞;所述确定单元还用于,根据路径拥塞信息表,为所述待传输报文确定目标路径,并将所述目标路径的信息添加在所述待传输报文中,以使得所述待传输报文通过所述目标路径进行传输,其中,所述目标路径的拥塞程度比所述当前路径的拥塞程度小,所述路径拥塞信息表的每个表项包括一条传输路径以及所述传输路径对应的拥塞信息,所述拥塞信息用于表示所述传输路径的拥塞程度;
发送单元,用于根据所述确定单元确定的目标路径,发送所述待传输报文。
第三方面,提供了一种确定传输路径的装置,该装置包括收发器、处理器和存储器。所述存储器存储了程序,所述处理器执行所述程序,以用于执行前述第一方面及各种实现方式中所述的确定传输路径的方法中的各个过程。其中,所述处理器具体用于:确定待传输报文所属的流对应的当前路径上发生拥塞;根据路径拥塞信息表,为所述待传输报文确定目标路径,并将所述目标路径的信息添加在所述待传输报文中,以使得所述待传输报文根据所述目标路径进行传输,其中,所述目标路径的拥塞程度比所述当前路径的拥塞程度小,所述路径拥塞信息表的每个表项包括一条传输路径以及所述传输路径对应的拥塞信息,所述拥塞信息用于表示所述传输路径的拥塞程度;所述收发器用于,根据所述目标路径,发送所述待传输报文。
第四方面,提供了一种计算机可读存储介质,所述计算机可读存储介质存储有程序,所述程序使得上述装置执行上述第一方面及其各种实现方式中的任一种确定传输路径的方法。
基于上述技术方案,本申请实施例通过确定传输路径是否发生拥塞,并在发生路径拥塞时根据路径拥塞信息表为待传输报文确定新的路径,能够有效地解决传输路径拥塞的问题。
由于本申请实施例是在当前路径确实发生拥塞、确实有必要进行路径切换时,才会进行传输路径的切换,避免了拥塞不匹配等问题,且由于路径切换的依据是当前路径上是否发生拥塞,而不是依靠前后报文到达的时间差,因而避免了长尾效应。
并且,本申请实施例中,整个路径的决策并不需要由交换机、路由器等网络设备来执行,拥塞信息表等信息可以保存在主机中,从而解决了网络设备的表项规格有限导致的不能支持大规模网络的问题,能够适用于3级Clos甚至N级Clos架构中。
另外,本申请实施例还引入了新的评价指标用来评价路径的拥塞程度,例如平均ECN次数、往返时间RTT、用于表示路径是否故障的标识、以及路径上同时同时存在的流的个数等参数,从而能够更加准确的对路径的拥塞程度进行评价,更有效地指导路径切换。
附图说明
图1是现有技术中报文传输的示意性架构图;
图2是现有技术中能够实现负载均衡的报文传输的路径示意图。
图3是适用本申请实施例提供的确定传输路径的方法的通信系统的示意性架构图。
图4是本申请实施例的修改前后的TCP/IP协议栈的示意图。
图5是本申请实施例的确定传输路径的方法的示意性流程图。
图6是本申请实施例的路径切换的示意图。
图7是根据本申请实施例的确定传输路径的装置的示意性框图。
图8是根据本申请实施例的确定传输路径的装置的结构示意图。
具体实施方式
下面将结合附图,对本申请实施例中的技术方案进行描述。
应理解,本申请实施例中以Clos网络架构为例进行描述,但是本申请不限于此,所有等价路径存在的场景下,都可以实现本申请实施例提出的确定传输路径的方法。
现有的针对2级Clos(2Stage Clos)提出的负载均衡方案中,每个底层设备,又称为叶子设备(英文:leaf device,简称“Leaf”),测量所述Leaf与整个网络中其他所有Leaf之间路径的拥塞程度,并记录在拥塞信息表(Congestion-To-Leaf)内,当收到新的数据流(后面也简称为“流”)时,会选取当前拥塞程度最低的路径转发该流。
这里,2级Clos指有2层架构的Clos网络,其最底层设备一般称为Leaf,最高层设备称为骨干设备(英文:spine device,简称Spine)。同样,3级Clos指具有3层架构的Clos网络,其最底层设备为Leaf,中间层设备为汇聚设备(英文:aggregation device,简称Aggregation或Agg),最高层设备称为Spine(或Core)。N级Clos指有N层架构的Clos。
换句话说,Leaf为2级Clos架构、3级Clos架构、甚至N级Clos架构下最底层的设备,一般为交换机或路由器;Aggregation为3级Clos架构下的中间层设备;Spine为2级Clos架构、3级Clos架构、甚至N级Clos架构下的最高层的设备,一般为交换机或路由器。
流包括可以用特定的五元组(五个关键字段)唯一标识的一组传输控制协议(英文:transmission control protocol,简称“TCP”)/互联网协议(英文:internetprotocol,简称“IP”)报文。例如,某用户从源IP地址为202.100.1.2的主机向目的IP地址为100.1.1.2的网页主机发起超文本传输协议(英文:hypertext transport protocol,简称“HTTP”)访问,这是一条TCP流,该流的另外两个五元组字段是源TCP端口20000,目的TCP端口8080,则202.100.1.2+100.1.1.2+TCP+20000+8080可用于惟一标识网络中传输的这条流。
该流中包括多个报文,若前后两个报文到达的时间差大于一个配置的值(例如500微秒)则可将后一个报文作为一个新短流(英文:flowlet)的第一个报文;若前面两个报文达到的时间差小于该配置的值,则这两个报文属于同一个flowlet。
源Leaf在进行传输报文时,首先检测flowlet,如果前后两个报文到达的时间差大于配置的值(例如500微秒),则将后一个报文作为一个新的flowlet的第一个报文,否则认为该两个报文属于同一个flowlet。若当前报文属于新的flowlet,则按下面流程查找出端口:查找路径拥塞程度表(Congestion-To-Leaf表);根据报文的目的IP地址找到路径拥塞程度表中的目的Leaf;根据目的Leaf找到可转发所述报文的所有出端口;比较可转发所述报文的的所有出端口的拥塞程度,选择其中路径拥塞程度最低的端口转发所述报文;如果所述路径拥塞程度表没有存储所述目的IP地址对应的目的Leaf,或初始时尚未建立起到目的Leaf的拥塞程度信息,则从可供转发的多个出端口中随机选择一个;若当前报文属于上一个flowlet,则查找flowlet表,在表中找到该flowlet对应的出端口转发。
路径拥塞程度表的建立方式分为前向探测和后向反馈两步。前向探测过程主要为:(1)探测报文从源Leaf上转发出去时,源Leaf为该探测报文添加Leaf标识、源Leaf中用于转发该探测报文的出端口的标识、以及表示该出端口对应的路径的拥塞程度的标识等;(2)探测报文从源Leaf转发到Spine时,Spine确定用于继续转发该探测报文的出端口,如果发现该出端口对应的路径的拥塞程度,比从源Leaf接收的探测报文中显示的拥塞程度更高,则Spine更新探测报文里用于记录路径拥塞程度的标识的字段;(3)探测报文到达目的Leaf时,目的Leaf记录探测报文中显示的拥塞程度;(4)目的Leaf转发该探测报文给主机。
后向反馈过程主要为:主机返回针对该探测报文的TCP响应报文给源Leaf;目的Leaf查找该TCP响应对应的源Leaf,将之前前向探测过程里记录的拥塞信息写到报文内容里,并执行前述类似转发过程;源Leaf得到该响应报文以后,提取其中携带的路径拥塞信息;源Leaf用刚刚得到的路径拥塞信息指导下一次转发。
可以看出,现有技术中实现负载均衡的报文传输过程中,主要思想是将一条流(英文:flow)切成多个flowlet,不同的flowlet通过查表走不同的传输路径,从而实现精细化地负载均衡。如果以图1为例,假设Flow A为带宽为10KB的网页浏览应用流速,Flow B为带宽10MB的视频直播流,如果只是按照flow来简单调度,例如采用传统的等价多路径(英文:equal-cost multi-path,简称“ECMP”)哈希机制,那么这两条流分别对应两条传输路径,由于其带宽是不同的,因此两条路径的带宽比为1:1000,这样造成了两条路径上的负载不均衡。当能够通过上述现有技术的方式实现负载均衡时,则FlowA和Flow B可以散列至两条甚至多条传输路径上,达到负载均衡的效果,从而避免了传输路径的拥塞。
但是,上面现有技术中用于实现负载均衡的报文传输的方法中,存在很多问题,这些问题直接影响报文传输的过程,在某些情况下并不能有效地避免报文传输过程中的路径拥塞问题。
首先,是表项规格的问题。上面描述的方法仅适用于Leaf-Spine架构的2-StageClos,原因是拥塞信息表都是记录在Leaf上的,每个Leaf上的拥塞信息表记录该Leaf到所有其他Leaf的全部路径,因此表项开销非常大。对于2-Stage Clos,该表项规格是O(K2);但在3-Stage Clos时,该表项规格是O(K4)!,明显超出了网络设备的承受能力。
其次,是长尾效应。因为flowlet的切分是依赖于前后两个报文的时间差大于配置的值,但当某条流带宽较大如千兆比特每秒(Gbps)时,报文的前后时间差非常小,在纳秒(ns)级别,无法切分开。
另外,是拥塞不匹配(英文:Congestion Mismatch)的问题。传统的ECMP中一条流严格对应一条路径,而上述方法中是将一个流划分成多个flowlet,将不同的flowlet散列到不同路径,因此一条流同时在两条或多条路径上传输。而在两条拥塞程度不等的路径上进行flowlet的切换时,无论当前路径是否真正发生拥塞,都会进行flowlet的切换,不仅增加了不必要的切换,甚至还可能导致报文传输的失败。
例如图2所示的现有技术中能够实现负载均衡的报文传输的示意图。其中Flow A为一个流,flowlet 1和flowlet 2分别为该Flow A中的两个flowlet,L0和L1分别为两个Leaf,S0和S1分别为两个Spine。如图2所示,Flow A从Leaf 0到Leaf 1交换机可以走两条路径,分别是L0→S0→L1与L0→S1→L1。
Flow A中的flowlet 1首先到达L0,假设flowlet 1的速率为1G,此时路径L0→S0→L1与路径L0→S1→L1的拥塞程度都是0,假设L0选择了L0→S1→L1路径转发flowlet 1。
假设路径L0→S1→L1的能够支持的最大流速为10G,L0发现L0→S1→L1这条路径没有发生拥塞,于是增加流速率发送flowlet 1之后的flowlet 2,这时,路径L0→S0→L1的路径拥塞程度为0,而路径L0→S1→L1由于转发flowlet 1,其拥塞程度变为1G/10G=10%。L0比较后发现路径L0→S1→L1的拥塞程度高于路径L0→S0→L1,因此,L0控制flowlet 2通过拥塞程度为0的路径L0→S0→L1转发出去。
然而,假设L0→S0→L1路径的能够支持的最大流速为5G,而flowlet 2的流速为10G,由于flowlet 2的流速超过5G,从而路径L0→S0→L1发生拥塞,导致flowlet 2被丢弃。
可以看出,现行协议栈机制的缺陷可能导致拥塞不匹配的问题,即Flow A在两条拥塞程度不等的路径上进行的切换操作并不能有效地指导Flow A进行传输,用于指导FlowA进行路径切换的仅仅是不同路径之间拥塞程度的比较,而不考虑具体路径对flowlet 2来说是否真正会发生拥塞。
本申请实施例中,只有在当前路径确实发生拥塞、确实有必要进行路径切换时,才会进行传输路径的切换,解决了拥塞不匹配的问题,且由于路径切换的依据是当前路径上是否发生拥塞,而不是依靠前后报文到达的时间差,因而避免了长尾效应。
本申请实施例通过将拥塞信息表保存在主机中,并且由主机执行路径选择策略,解决了网络设备的表项规格不够的问题,能够适用于3级Clos甚至N级Clos架构中。
进一步地,本申请实施例还引入了新的指标用来评价路径的拥塞程度,能够更加准确的对路径的拥塞程度进行评价,从而更有效地指导路径切换。
图3是适用本申请实施例提供的确定传输路径的方法的通信系统的示意性架构图。在Clos架构中,每个Leaf都与所有的Spine之间存在传输路径。图3中示出了主机(Host)10、Host 20、Leaf 30(用L 30表示)、Leaf 60(用L 60表示)、Spine 50(用S 50表示)和Spine 40(用S 40表示)。这里的Leaf例如为Leaf交换机,Leaf交换机底下连接有主机。在图3所示的通信系统中,从Host 10到Host 20之间存在两条传输路径,即Host 10→L 30→S40→L 60→Host 20和Host 10→L 30→S 50→L 60→Host 20这两条路径。Host 10发送报文后,经L 30转发到S 40,若S 40到L 60的路径发生了拥塞,则S 40会给报文标记显式拥塞通知(英文:explicit congestion notification,简称“ECN”),表示该报文所属的流在本设备上经历了拥塞。报文经过L 60转发给Host 20后,Host 20看到带有CE标记的报文后,会返回显式拥塞通知响应(英文:explicit congestion notification echo,简称“ECN-Echo”)给Host 10。Host 10收到ECN-Echo后,即感知到该传输路径上发生了拥塞,会降低自己的发送速率,并且发出拥塞窗口降速(英文:congestion window reduced,简称“CWR”)报文告知目的端Host 20,以告知Host 20自己已经执行了降速操作。
应理解,图3中仅示出了包括2个Leaf和2个Spine的2级Clos架构,但本申请实施例的方法同样适用于3级Clos或者更高级别的Clos架构中。本申请实施例的确定传输路径的方法也可以称为传输层感知负载均衡(英文:transport layer aware load balancing,简称“TLB”)。
还应理解,所有能够通过本申请实施例所述的方法确定传输路径的装置,均应落入本申请的保护范围。下面仅以主机为例进行本申请实施例的描述。
本申请实施例中,在传输路径发生拥塞时可以由主机根据路径拥塞信息表来进行路径的重新选择,也就是说,本申请实施例的确定传输路径的方法可以在主机的操作系统中实现,而无需对网络设备例如交换机、路由器等设备上作任何修改。所述主机的操作系统例如可以是Windows/Linux操作系统内核代码的网络处理部分等。本申请实施例的方法可以应用于但不限于TCP/IP协议栈的套接口(socket)通信、应用程序编程接口(英文:application programming interface,简称“API”)接口等与网络交互部分形态的功能模块。本申请实施例的方法还可以应用于虚拟机系统,例如VMware、Xen虚拟机、Openstack等等云服务操作系统、以及虚拟化操作系统的虚拟机监视器(Hypervisor)功能模块部分。
图4所示为本申请实施例的修改前后的TCP/IP协议栈的示意图。图4中,左图为修改前的TCP/IP协议栈的示意图,右图为修改后的TCP/IP协议栈的示意图。其中,对主机的操作系统中的传输层和网络层进行合适的修改后,就可以实现本申请实施例的确定传输路径的方法。
由于本申请中路径的选择由主机来执行,拥塞信息表保存在主机中,可以不受网络设备的表项规格的限制,从而能够灵活地适用于3级Clos架构甚至N级Clos架构中。
图5示出了本申请实施例的确定传输路径的方法500的示意性流程图。以该方法由主机执行为例进行描述,如图5所示,该方法500包括:
S510,主机确定待传输报文所属的流对应的当前路径上发生拥塞。
具体来说,主机在发送每个流的第一个报文时,在流-路径表中,记录所述流和所述主机为所述流选择的转发路径的对应关系。即,所述流-路径表中的每个表项包括流的标识和所述主机为所述流选择的转发路径的对应关系。
当主机接收到待传输报文时,确定所述待传输报文所属的流,然后查找所述流-路径表,得到所述流对应的转发路径,所述得到的路径即为所述待传输报文所属的流对应的当前路径。
S520,主机根据路径拥塞信息表,为该待传输报文确定目标路径,并将该目标路径的信息添加在该待传输报文中,以使得该待传输报文根据该目标路径进行传输,其中,该目标路径的拥塞程度比该当前路径的拥塞程度小。
本申请一个实施方式中,所述主机上还设置有转发路径表。所述转发路径表记录了所述主机连接的Leaf到所述网络中其他任意一个Leaf的所有路径。例如图2中,Host 10上的转发路径表包括L30到L60的全部路径:L30→S40→L60;L30→S50→L60。
主机根据路径拥塞信息表,为该待传输报文确定目标路径包括:所述主机确定所述待传输报文的目的地址对应的目的Leaf,所述主机根据所述转发路径表确定所述主机连接的Leaf到所述目的Leaf的所有路径,并根据所述拥塞信息表,从所述主机连接的Leaf到所述目的Leaf的所有路径中选择所述目标路径。
S530,主机根据该目标路径,发送该待传输报文
其中,该路径拥塞信息表的每个表项包括一条传输路径的标识以及所述传输路径对应的拥塞信息,所述拥塞信息用于表示所述传输路径的拥塞程度。
另外,该路径拥塞信息表存储在主机中,该路径拥塞信息表中记录有多条传输路径的标识,以及多条传输路径各自对应的拥塞信息,其中,传输路径的标识例如可以记录为:目的地40.0.0.2,交换机标识L30、L40、L60,表示该条传输路径所到达的目的地(例如另一主机)的地址为40.0.0.2,其中经过的设备依次为L30、L40和L60。
可选地,一条传输路径的拥塞信息可以包括以下信息中的至少一种:该传输路径的平均ECN次数、该传输路径的往返时间RTT、用于表示该传输路路径是否故障的标识、以及该传路径上同时存在的流的个数。
其中,平均ECN次数表示该传输路径上特定时间内传输的流中被标记ECN的平均个数,例如,该条传输路径上传输了100个报文,其中有50个报文在传输过程中都发生了拥塞,那么这50个报文都被设置了ECN标记,该传输路径的平均ECN次数就是50/100=0.5。
具体地说,若主机在确定该待传输报文对应的当前路径上发送拥塞时,可以根据路径拥塞信息表,为该待传输报文确定目标路径,并将该目标路径的信息添加在该待传输报文中,以使得该待传输报文通过该目标路径进行传输,其中,该目标路径的拥塞程度比该当前路径的拥塞程度小。在这里,主机只有在确定了该待传输报文对应的当前路径上真正发生了拥塞时,才会为该待传输报文确定目标路径。并通过确定的目标路径发送该待传输报文。此外,该待传输的报文成为该待传输报文所属的流的一个新的flowlet的第一个报文。
应理解,这里的当前路径为该待传输报文当前待使用的路径,即为该待传输报文所属的流中的前一个报文所走的路径。如果待传输报文的前一个报文所走的路径没有发生拥塞,那么主机仍会在这条路径上继续传输后续的报文,这时,该待传输报文的当前路径就为其前一个报文所走的路径。如果前一个报文所走的路径发生了拥塞,则主机会为待传输报文所属的流确定新的路径(即上述的目标路径),该待传输报文就会在目标路径上进行传输,而不在当前路径上进行传输,该待传输的报文成为该待传输报文所属的流的一个新的flowlet的第一个报文。
可见,在本申请实施例中,是否为一个流生成新的短流并不是根据前后两个报文到达时间差来确定的,而是根据当前传输路径是否发生拥塞来确定的。如果待传输报文所属的流对应的当前路径上发生拥塞,才会对流进行切片以生成新的短流。也就是说,只有待传输报文所属的流对应的当前路径发生拥塞,才会重新确定该报文的传输路径。
本申请实施例中可以称流传输过程的第一次路径选择为路由(Routing),该流中的新的短流切换至与前一个短流不一样的路径的操作可以称为重路由(Rerouting)。
可选地,在S510中主机可以通过待传输报文所述的流是否被标记显式拥塞通知ECN、传输路径的RTT或用于表示传输路径是否故障的标识等来判断当前路径是否发生拥塞。即,主机确定待传输报文所属的流在当前路径进行传输时被设置了ECN标记、或者当前路径对应的往返时间RTT大于时间阈值、或者当前路径发生故障时,表明当前路径发生拥塞,主机为该待传输报文重新确定目标路径。
也就是说,主机如果发现待传输报文所属的流在当前路径进行传输时被设置了ECN标记,那么表明当前路径上发生了拥塞;或者可以设定一个时间阈值,如果网络设备发现从发送报文到接收针对该报文的响应报文之间的时间,即往返时间RTT突然变长,大于了预设的时间阈值,那么表明当前路径上发生了拥塞;又或者当前路径发生了故障,那么必然在当前路径上进行传输时会发生拥塞。
另外,在每次发生路径拥塞时,主机都会将拥塞信息记录在路径拥塞信息表中,例如,主机一旦发现在一条路径上进行传输的某条流被设置了ECN标记,那么就会更新路径拥塞信息表中该路径的平均ECN次数。例如,假设该路径拥塞信息表中记录的该路径的平均ECN次数为50/100=0.5,如果主机发现了之后在该路径上传输的某条流也被设置了ECN标记,那么就会更新路径拥塞信息表中记录该路径的平均ECN次数为51/100=0.51。
主机这时可以查询路径拥塞信息表,通过该拥塞信息表为该待传输报文确定目标路径,该目标路径的拥塞程度低于当前路径,从而该待传输报文可以切换至更好的路径上进行传输标识主机根据该路径拥塞信息表确定的目标路径,满足以下条件中的至少一种:目标路径的平均ECN次数小于当前路径的平均ECN次数、目标路径的RTT小于当前路径的RTT、和目标路径上同时存在的流个数小于当前路径上同时存在的流的个数,且该目标路径没有发生故障。
相比于现有技术中仅仅依靠一段时间内出端口的利用率来表示路径的拥塞程度,本申请实施例通过包括平均ECN次数、往返时间RTT、用于表示路径是否故障的标识、以及路径上同时传输的报文个数等参数的拥塞信息来表征传输路径的拥塞程度,能够更加准确的对路径的拥塞程度进行评价,从而更有效地指导路径切换。
可选地,在主机根据路径拥塞信息表,为该待传输报文确定目标路径之前,该方法还包括:主机获至少一条传输路径中每条传输路径对应的拥塞信息;主机根据该至少一条传输路径中每条传输路径对应的拥塞信息,建立或更新该路径拥塞信息表。
具体地说,主机获取可用于报文传输的每条路径,以及每条路径的拥塞信息,从而建立路径拥塞信息表,主机可以在至少一条传输路径中的每条传输路径上发送探测报文,并接收针对所述探测报文的响应报文,从而根据所述响应报文,确定至少一条传输路径中每条传输路径对应的拥塞信息,根据该至少一条传输路径中每条传输路径对应的拥塞信息,生成路径拥塞信息表。
进一步地,在建立该路径拥塞信息表后,主机还可以按照一定的周期,对该路径信息表不断地进行更新。
主机可以通过发送探测报文的方式获取每条路径对应的拥塞信息,通过源路由、X路径(Xpath)或其他类似方式使探测报文在指定的路径上进行传输,从而获取每条路径的拥塞信息,建立起路径拥塞信息表。这里的源路由或Xpath是基于源地址进行路由选择的路由策略,可以实现根据多个不同地址,有选择性地将数据包发往不同目的地址的功能。
举例来说,源主机可以按照前面描述的前向探测的方法,依次在所有存在的传输路径上发送探测报文。如果在探测报文传输的过程中,在某个设备处发生了拥塞,那么该设备就会在该探测报文上标记ECN,该探测报文传输至目的主机时,目的设备就获知该路径上发生了拥塞,在向主机返回针对该探测报文的响应报文时,就会将该路径拥塞的消息携带在响应报文中,从而源主机就知道该路径上发生了拥塞。
又例如,源主机在获取拥塞信息表中每条路径的拥塞信息中的RTT时,可以记录发送探测报文的时刻和接收到响应报文的时刻,两个时刻之间的时长即为RTT,RTT越长说明该路径的拥塞程度越高。
该路径拥塞信息表可以例如表1所示,表1中每个表项记录的信息除了包括路径(path)标识(英文:identifier,简称“ID”)和目的设备(Dest)(即目的Host),还包括拥塞信息:平均ECN次数、往返时间RTT、是否故障链路(英文:failure)和传输路径上同时存在的流的数目。
表1
路径标识 Dest 平均ECN次数 RTT 是否故障链路 流的数目
Path A Dest 1 N<sub>1</sub> T<sub>1</sub> NO M<sub>1</sub>
Path B Dest 2 N<sub>2</sub> T<sub>2</sub> NO M<sub>2</sub>
Path C Dest 3 N<sub>3</sub> T<sub>3</sub> NO M<sub>3</sub>
Path D Dest 4 N<sub>4</sub> T<sub>4</sub> NO M<sub>4</sub>
Path E Dest 5 N<sub>5</sub> T<sub>5</sub> NO M<sub>5</sub>
Path F Dest 6 N<sub>6</sub> T<sub>6</sub> NO M<sub>6</sub>
Path G Dest 7 N<sub>7</sub> T<sub>7</sub> NO M<sub>7</sub>
Path H Dest 8 N<sub>8</sub> T<sub>8</sub> NO M<sub>8</sub>
假设Path A、Path B、Path C和Path D用于传输流1(flow 1),Path E和Path F用于传输flow 2,Path G和Path H用于传输flow 3。流flow 1、flow 2和flow 3的五元组信息可以存储在表2所示的流表(英文:flow table)中,并且表2中还包括了每个流可能使用的至少一个传输路径。
表2
Figure BDA0001194237870000151
主机对路径拥塞信息表的更新例如可以通过有源探测器(英文:active probe)发起定期主动探测,记录每条传输路径的平均ECN次数、RTT、用于表示传输路径是否故障的标识等信息并保存到该主机的路径拥塞信息表中。主机同时还可以依据这些信息为路径划分等级,以指导路径切换。
应注意,端到端RTT大的不一定是差路径(英文:bad path),也可能是主机OS处理延时导致的,但是RTT小的一定是好路径(英文:good path);流的平均ECN次数小的不一定是好路径,可能是交换机阈值临界或采样不够导致,但是平均ECN次数大的一定是差路径。
这里的bad path可以指拥塞程度较高的路径,主要是以每条路径的平均ECN次数、RTT等来作为标准的,比如一条路径上的平均ECN次数越大,就说明这条路径越差,假设ECN为50/100=0.5,表示条传输路径上传输了100个报文,其中有50个报文在传输过程中都被设置了ECN标记,也就意味着这条路径上有50%的报文都遇到了拥塞,那显然这条路径相比于平均ECN次数为0.1的路径来说是bad path。又例如,若某条路径故障了,那么这条路径肯定是bad path,需要避开。
进一步,可选地,在主机获取路径的拥塞信息的过程中,若主机获取的多个拥塞信息中包括表示路径发生故障的标识,则主机将该标识对应的传输路径从该路径拥塞信息表中删除。
也就是说主机在获取到哪条路径故障后,可以及时将该路径以及该路径的相关信息从该路径拥塞信息表中删除,路径拥塞信息表可以实时地进行该更新操作。在后续的路径选择过程中,就可以在没有故障的路径中进行路径选择。
因此,本申请实施例中,通过确定传输路径发生拥塞,并在发生路径拥塞时根据路径拥塞信息表为待传输报文确定新的路径,能够有效地解决传输路径拥塞的问题。
本申请实施例只有在当前路径确实发生拥塞、确实有必要进行路径切换时,才会进行传输路径的切换,避免了拥塞不匹配等问题,且由于路径切换的依据是当前路径上是否发生拥塞,而不是依靠前后报文到达的时间差,因而避免了长尾效应。
并且整个路径的决策由主机来执行,拥塞信息表保存在主机中,从而解决了网络设备的表项规格不够的问题,能够适用于3级Clos甚至N级Clos架构中。
另外,本申请实施例还引入了新的指标用来评价路径的拥塞程度,能够更加准确的对路径的拥塞程度进行评价,从而更有效地指导路径切换。
可选地,在S520中,主机根据路径拥塞信息表,为该待传输报文确定目标路径,包括:在所述待传输报文和所述当前路径上待传输的其他报文中,若所述待传输报文以预设概率被选择到,则主机根据该路径拥塞信息表,为该待传输报文确定目标路径,以使得所述待传输报文根据所述目标路径进行传输。
例如,假设待传输的且属于不同流的报文1、报文2和报文3的当前路径均为路径1,即三个报文都打算在路径1上传输,假设路径1这时发生了拥塞,则需要分别对报文1所属的流1、报文2所属的流2和报文3所属的流3重新选择目标路径进行传输,但是,主机选择新的传输路径时,并不是对流1、流2和流3都进行传输路径的切换,而是对三个流中的一个或两个流进行路径切换。举例来说,预设一个概率1/3,就表明三个流中只对一个流进行路径切换,例如流1的服务器对流1进行路径切换,根据路径拥塞信息表为流1中的报文1确定目标路径作为新的传输路径,而对流2和流3不进行路径切换,让流2中的报文2和流3中的报文3仍在当前路径上进行传输。这样的好处是降低了切换后再次发生拥塞的概率,如果只存在路径1和路径2,三个流同时进行切换的话,流1、流2和流3就会都切换至路径2上传输,那么报文1、报文2和报文3仍有可能发生冲突。该实施例可以适当避免多条流同时切换到另一条相同的路径上而导致另一条路径发生拥塞的情况,有效地将负载均衡到不同的传输路径上,从而降低了切换后再次发生拥塞的概率,提高了报文传输的成功率。
在确定到底对流1、流2和流3中的哪条流进行路径切换时,可以是随机选择;也可以产生一个随机数看是不是可以被3整除,如果可以被3整除就切换路径,否则不切换路径;也可以选择流速最大的一条或两条流进行路径切换等,本申请实施例不做限定。
另外,如果一次切换不成功,可以等待一个短时延(英文:short delay)之后才再次切换,以提高再次切换的成功率。例如主机对报文1所属的流1进行路径切换没有成功,则需要等待固定时长例如100ms后,再对流1执行路径切换操作。
可选地,在S520中,主机根据路径拥塞信息表,为该待传输报文确定目标路径,还可以包括:若该待传输报文对应的流的流速大于预设阈值,主机根据该路径拥塞信息表,为所述待传输报文确定目标路径。
具体地说,主机选择的对象可以是流速超过一定大小的流,在流的流速超过一定阈值时,主机才对该流进行路径切换的操作。在待传输报文所属的流对应的当前路径上发生拥塞时,主机对流的流速进行感知,例如对TCP发送窗口速率计算,无丢包时根据RTT来计算,有丢包时根据丢包率和RTT并按照TCP吞吐公式计算。只有当流的流速超过预设的阈值时才对该待传输报文所属的流进行路径切换操作,否则不进行路径切换,因为对流速较小的流进行切片完全没有必要。从而避免了不必要的路径切换。
可选地,该方法还可以包括:主机确定该目标路径的RTT与该当前路径的RTT之间的时间差;主机在等于该时间差的时长后,发送该待传输报文。
在进行路径切换后,容易带来的一个问题就是报文乱序。举例来说,Flow A中依次被分为flowlet 1、flowlet 2和flowlet 3,flowlet 1和flowlet 2在路径1上传输,flowlet 3切换至路径2上传输,如果因路径2的拥塞程度小于路径1导致flowlet 3在flowlet 1和flowlet 2之前到达目的设备,则该Flow A中的报文的顺序就由原来的flowlet 1→flowlet 2→flowlet 3变为flowlet 3→flowlet 1→flowlet 2,则发生了乱序。
为了避免乱序的发生,主机确定待传输报文所属的流对应的当前路径发生拥塞而为该报文确定了新的路径即目标路径后,主机可以确定该目标路径的RTT与该当前路径的RTT之间的时间差,从而主机在经过该时间差的时长后,再发送该待传输报文。这样可以避免路径切换导致的报文乱序。
下面结合图6,详细地描述本申请实施例的确定传输路径的方法。图6为根据本申请实施例的方法进行路径切换的示意图,包括发送端(sender)10、接收端(receiver)20、Leaf 30、Spine 40、Spine 50和Leaf 60。如图6所示,发送端10和接收端20之间存在两条传输路径,分别为Path 1和Path 2,传输的流为Flow A,Flow A假设被分为两个flowlet,即flowlet 1和flowlet 2。发送端10的主机的传输层可以实现传输层感知负载均衡TLB,接收端20的主机的传输层也可以实现传输层感知负载均衡TLB,该确定传输路径的方法具体包括:
(1)当有新流需要发送时,主机将该流的五元组记录到流表内。
(2)首次路由操作(Route):主机针对该新流查找路径拥塞信息表,在除了badpath之外的路径中随机选择传输路径,该bad path可以由主机按照前述方式即依据平均ECN次数、RTT等信息来确定。如图6所示,主机首先为当前Flow A中的flowlet 1选择Path 1进行报文发送。
(3)flowlet 1在Path 1上发送顺利,主机继续在Path 1上发送Flow A中的flowlet 2。
(4)Path 1发生路径拥塞,主机确定是否为Flow A执行重路由操作。
其中,Path 1发生路径拥塞可以是:发送端Host 10确定Flow A在Path 1上传输时被设置了ECN标记、Path 1的平均ECN次数大于预设值、Path 1的RTT超过预设阈值、或者Path 1发生链路故障。
主机可以是根据Flow A的流速确定是否为flowlet 2执行重路由操作,当流速大于预设阈值时,对Flow A进行重路由,否则跳过选择下一个流是否符合要求;主机也可以根据预先设定的概率值,确定是否为Flow A执行重路由操作。
(5)主机确定需要为Flow A执行重路由操作时,根据路径拥塞信息表确定目标路径以用于传输为Flow A中的flowlet 2。
主机查找路径拥塞信息表,选择目标路径例如这里的Path 2,并将Path 2的信息携带在flowlet 2中,以使得flowlet 2按照Path 2进行传输。Path 2满足以下条件中的至少一个:Path 2的平均ECN次数小于Path 1的平均ECN次数,Path 2的RTT比Path 1的RTT短,Path 2上同时传输的报文个数小于Path 1上同时传输的报文个数。
(6)主机确定Path 1的RTT与Path 2的RTT之间的时间差。
主机计算主机Path 1的RTT与Path 2的RTT之间的时间差例如为100us。
(7)主机将flowlet 2在本地缓存100us后,将flowlet 2在Path 2上进行发送。
这样,主机在发生路径拥塞时根据路径拥塞信息表为待传输报文确定新的路径,有效地解决了传输路径拥塞的问题。
应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
下面将结合图7,描述根据本申请实施例的确定传输路径的装置,方法实施例所描述的技术特征可以适用于以下装置实施例。
图7示出了根据本申请实施例的确定传输路径的装置700。如图7所示,该装置700包括确定单元710和发送单元720。其中:
确定单元710用于:确定待传输报文所属的流对应的当前路径上发生拥塞;根据路径拥塞信息表,为所述待传输报文确定目标路径,并将所述目标路径的信息添加在所述待传输报文中,以使得所述待传输报文通过所述目标路径进行传输,其中,所述目标路径的拥塞程度比所述当前路径的拥塞程度小,所述路径拥塞信息表的每个表项包括一条传输路径以及所述传输路径对应的拥塞信息,所述拥塞信息用于表示所述传输路径的拥塞程度;
发送单元720用于:根据所述确定单元确定的目标路径,发送所述待传输报文。
因此,本申请实施例的确定传输路径的装置,通过确定传输路径是否发生拥塞,并在发生路径拥塞时根据路径拥塞信息表为待传输报文确定新的路径,能够有效地解决传输路径拥塞的问题。
由于本申请实施例只有在当前路径确实发生拥塞、确实有必要进行路径切换时,才会进行传输路径的切换,避免了拥塞不匹配等问题,且切换后的路径的拥塞程度小于该当前路径,避免了长尾效应。
并且本申请实施例中,整个路径的决策并不需要由交换机、路由器等网络设备来执行,而是通过其他装置例如主机来实现,拥塞信息表等信息也可以保存在主机中,从而解决了表项规格受限的问题,能够适用于3级Clos甚至N级Clos架构中。
另外,本申请实施例还引入了新的评价指标用来评价路径的拥塞程度,例如平均ECN次数、往返时间RTT、用于表示路径是否故障的标识、以及路径上同时存在的流的个数等参数,从而能够更加准确的对路径的拥塞程度进行评价,更有效地指导路径切换。
可选地,所述确定单元710具体用于:确定所述流在所述当前路径上传输时被标记显式拥塞通知ECN,或者所述当前路径对应的往返时间RTT大于时间阈值,或者所述当前路径发生故障。
可选地,所述拥塞信息包括以下信息中的至少一种:所述传输路径的平均ECN次数、所述传输路径的往返时间RTT、用于表示所述传输路径是否故障的标识、以及所述传输路径上同时存在的流的个数。
可选地,若所述待传输报文对应的流的流速大于预设阈值,根据所述路径拥塞信息表,为所述待传输报文确定目标路径。
可选地,所述确定单元710具体用于:在所述待传输报文和所述当前路径上待传输的其他报文中,若所述待传输报文以预设的概率被选择到,则根据所述路径拥塞信息表,为所述待传输报文确定所述目标路径,以使得所述待传输报文根据所述目标路径进行传输。
可选地,所述确定单元710还用于:确定所述目标路径的RTT与所述当前路径的RTT之间的时间差;所述发送单元还用于:在经过所述时间差的时长后,发送所述待传输报文。
可选地,所述装置还包括接收单元,其中,所述发送单元720还用于:在至少一条传输路径中的每条传输路径上发送探测报文;所述接收单元用于,接收针对所述探测报文的响应报文;所述确定单元还用于,根据所述响应报文,确定至少一条传输路径中每条传输路径对应的所述拥塞信息;所述确定单元还用于,根据所述至少一条传输路径中每条传输路径对应的所述拥塞信息,生成所述路径拥塞信息表。
可选地,所述确定单元还用于:若获取的一条传输路径的拥塞信息中包括表示所述传输路径发生故障的标识,将所述传输路径对应的表项从所述路径拥塞信息表中删除。
图8示出了本申请实施例提供的确定传输路径的装置的结构,处理器810、收发器820和存储器830,其中,该处理器810、收发器820和存储器830之间通过内部连接通路互相通信。该存储器830用于存储指令,该处理器810用于执行该存储器830存储的指令,以控制该收发器820接收信号或发送信号。其中:
处理器810用于:根据路径拥塞信息表,为所述待传输报文确定目标路径,并将所述目标路径的信息添加在所述待传输报文中,以使得所述待传输报文通过所述目标路径进行传输,其中,所述目标路径的拥塞程度比所述当前路径的拥塞程度小,所述路径拥塞信息表的每个表项包括一条传输路径以及所述传输路径对应的拥塞信息,所述拥塞信息用于表示所述传输路径的拥塞程度;
收发器820用于:根据所述确定单元确定的目标路径,发送所述待传输报文。
因此,本申请实施例的确定传输路径的装置,通过确定传输路径是否发生拥塞,并在发生路径拥塞时根据路径拥塞信息表为待传输报文确定新的路径,能够有效地解决传输路径拥塞的问题。
可选地,所述处理器810具体用于:确定所述流在所述当前路径上传输时被标记显式拥塞通知ECN,或者所述当前路径对应的往返时间RTT大于时间阈值,或者所述当前路径发生故障。
可选地,所述拥塞信息包括以下信息中的至少一种:所述传输路径的平均ECN次数、所述传输路径的往返时间RTT、用于表示所述传输路径是否故障的标识、以及所述传输路径上同时存在的流的个数。
可选地,若所述待传输报文对应的流的流速大于预设阈值,根据所述路径拥塞信息表,为所述待传输报文确定目标路径。
可选地,所述处理器810具体用于:在所述待传输报文和所述当前路径上待传输的其他报文中,若所述待传输报文以预设的概率被选择到,则根据所述路径拥塞信息表,为所述待传输报文确定所述目标路径,以使得所述待传输报文根据所述目标路径进行传输。
可选地,所述处理器810还用于:确定所述目标路径的RTT与所述当前路径的RTT之间的时间差;所述收发器820还用于:在经过所述时间差的时长后,发送所述待传输报文。
可选地,所述收发器820还用于:在至少一条传输路径中的每条传输路径上发送探测报文;所述收发器820还用于,接收针对所述探测报文的响应报文;所述处理器810还用于,根据所述响应报文,确定至少一条传输路径中每条传输路径对应的所述拥塞信息;所述处理器810还用于,根据所述至少一条传输路径中每条传输路径对应的所述拥塞信息,生成所述路径拥塞信息表。
可选地,所述确定单元还用于:若获取的一条传输路径的拥塞信息中包括表示所述传输路径发生故障的标识,将所述传输路径对应的表项从所述路径拥塞信息表中删除。
应理解,在本申请实施例中,该处理器810可以是中央处理单元(centralprocessing unit,简称“CPU”),该处理器810还可以是其他通用处理器、数字信号处理器(英文:digital signal processor,简称“DSP”)、专用集成电路(英文:application-specific integrated circuit,简称“ASIC”)、现成可编程门阵列(英文:fieldprogrammable gate qrray,简称“FPGA”)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
该存储器830可以包括只读存储器和随机存取存储器,并向处理器810提供指令和数据。存储器830的一部分还可以包括非易失性随机存取存储器。例如,存储器830还可以存储设备类型的信息。所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在实现过程中,上述方法的各步骤可以通过处理器810中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的定位方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器810中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器830,处理器810读取存储器830中的信息,结合其硬件完成上述方法的步骤。为避免重复,这里不再详细描述。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,主机,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(英文:read-only memory,简称“ROM”)、随机存取存储器(英文:random access memory,简称“RAM”)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请实施例的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种确定传输路径的方法,其特征在于,所述方法包括:
确定待传输报文所属的流对应的当前路径上发生拥塞;
确定所述待传输报文所属的流的流速是否大于预设阈值;
若所述流的流速大于所述预设阈值,则根据路径拥塞信息表,为所述待传输报文确定目标路径,并将所述目标路径的信息添加在所述待传输报文中,以使得所述待传输报文根据所述目标路径进行传输,其中,所述目标路径的拥塞程度比所述当前路径的拥塞程度小,包括所述目标路径的平均显式拥塞通知ECN次数小于所述当前路径的平均ECN次数,以及所述目标路径的往返时间RTT小于所述当前路径的RTT,所述路径拥塞信息表的每个表项包括一条传输路径以及所述传输路径对应的拥塞信息,所述拥塞信息用于表示所述传输路径的拥塞程度,所述路径拥塞信息表的至少一个表项在确定所述当前路径上发生拥塞之前获取;
确定所述目标路径的RTT与所述当前路径的RTT之间的时间差;
在经过所述时间差的时长后,根据所述目标路径,发送所述待传输报文;
若所述待传输报文所属的流的流速小于或等于所述预设阈值,则根据所述当前路径,发送所述待传输报文。
2.根据权利要求1所述的方法,其特征在于,所述确定待传输报文所属的流对应的当前路径上发生拥塞,包括:
确定所述流在所述当前路径上传输时被标记显式拥塞通知ECN,或者所述当前路径对应的往返时间RTT大于时间阈值,或者所述当前路径发生故障。
3.根据权利要求1或2所述的方法,其特征在于,所述拥塞信息包括以下信息中的至少一种:
所述传输路径的平均ECN次数、所述传输路径的RTT、用于表示所述传输路径是否故障的标识、以及所述传输路径上同时存在的流的个数。
4.根据权利要求1或2所述的方法,其特征在于,所述根据路径拥塞信息表,为所述待传输报文确定目标路径,包括:
在所述待传输报文和所述当前路径上待传输的其他报文中,若所述待传输报文以预设概率被选择到,则根据所述路径拥塞信息表,为所述待传输报文确定所述目标路径,以使得所述待传输报文根据所述目标路径进行传输。
5.根据权利要求1或2所述的方法,其特征在于,所述在根据路径拥塞信息表,为所述待传输报文确定目标路径之前,所述方法还包括:
在至少一条传输路径中的每条传输路径上发送探测报文;
接收针对所述探测报文的响应报文;
根据所述响应报文,确定至少一条传输路径中每条传输路径对应的所述拥塞信息;
根据所述至少一条传输路径中每条传输路径对应的所述拥塞信息,生成所述路径拥塞信息表。
6.根据权利要求5所述的方法,其特征在于,所述方法还包括:
若获取的一条传输路径的拥塞信息中包括表示所述传输路径发生故障的标识,将所述传输路径对应的表项从所述路径拥塞信息表中删除。
7.一种确定传输路径的装置,其特征在于,所述装置包括:
确定单元,用于确定待传输报文所属的流对应的当前路径上发生拥塞;
所述确定单元还用于,确定所述待传输报文所属的流的流速是否大于预设阈值;
所述确定单元还用于,若所述待传输报文所属的流的流速大于所述预设阈值,则根据路径拥塞信息表,为所述待传输报文确定目标路径,并将所述目标路径的信息添加在所述待传输报文中,以使得所述待传输报文通过所述目标路径进行传输,其中,所述目标路径的拥塞程度比所述当前路径的拥塞程度小,包括所述目标路径的平均显式拥塞通知ECN次数小于所述当前路径的平均ECN次数,以及所述目标路径的往返时间RTT小于所述当前路径的RTT,所述路径拥塞信息表的每个表项包括一条传输路径以及所述传输路径对应的拥塞信息,所述拥塞信息用于表示所述传输路径的拥塞程度,所述路径拥塞信息表的至少一个表项在确定所述当前路径上发生拥塞之前获取;
所述确定单元还用于,确定所述目标路径的RTT与所述当前路径的RTT之间的时间差;
发送单元,用于在经过所述时间差的时长后,根据所述确定单元确定的目标路径,发送所述待传输报文;
发送单元还用于,若所述待传输报文所属的流的流速小于或等于所述预设阈值,则根据所述当前路径,发送所述待传输报文。
8.根据权利要求7所述的装置,其特征在于,所述确定单元具体用于:
确定所述流在所述当前路径上传输时被标记显式拥塞通知ECN,或者所述当前路径对应的往返时间RTT大于时间阈值,或者所述当前路径发生故障。
9.根据权利要求7或8所述的装置,其特征在于,所述拥塞信息包括以下信息中的至少一种:
所述传输路径的平均ECN次数、所述传输路径的往返时间RTT、用于表示所述传输路径是否故障的标识、以及所述传输路径上同时存在的流的个数。
10.根据权利要求7或8所述的装置,其特征在于,所述确定单元具体用于:
在所述待传输报文和所述当前路径上待传输的其他报文中,若所述待传输报文以预设的概率被选择到,则根据所述路径拥塞信息表,为所述待传输报文确定所述目标路径,以使得所述待传输报文根据所述目标路径进行传输。
11.根据权利要求7或8所述的装置,其特征在于,所述装置还包括接收单元,其中,所述发送单元还用于:
在至少一条传输路径中的每条传输路径上发送探测报文;
所述接收单元用于,接收针对所述探测报文的响应报文;
所述确定单元还用于,根据所述响应报文,确定至少一条传输路径中每条传输路径对应的所述拥塞信息;
所述确定单元还用于,根据所述至少一条传输路径中每条传输路径对应的所述拥塞信息,生成所述路径拥塞信息表。
12.根据权利要求11所述的装置,其特征在于,所述确定单元还用于:
若获取的一条传输路径的拥塞信息中包括表示所述传输路径发生故障的标识,将所述传输路径对应的表项从所述路径拥塞信息表中删除。
CN201611229376.5A 2016-12-27 2016-12-27 确定传输路径的方法和装置 Active CN108243111B (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201611229376.5A CN108243111B (zh) 2016-12-27 2016-12-27 确定传输路径的方法和装置
PCT/CN2017/109372 WO2018121068A1 (zh) 2016-12-27 2017-11-03 确定传输路径的方法和装置
EP17887401.2A EP3541027B1 (en) 2016-12-27 2017-11-03 Method and device for determining transmission path
US16/452,821 US10924413B2 (en) 2016-12-27 2019-06-26 Transmission path determining method and apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611229376.5A CN108243111B (zh) 2016-12-27 2016-12-27 确定传输路径的方法和装置

Publications (2)

Publication Number Publication Date
CN108243111A CN108243111A (zh) 2018-07-03
CN108243111B true CN108243111B (zh) 2021-08-27

Family

ID=62702903

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611229376.5A Active CN108243111B (zh) 2016-12-27 2016-12-27 确定传输路径的方法和装置

Country Status (4)

Country Link
US (1) US10924413B2 (zh)
EP (1) EP3541027B1 (zh)
CN (1) CN108243111B (zh)
WO (1) WO2018121068A1 (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102380619B1 (ko) * 2017-08-11 2022-03-30 삼성전자 주식회사 이동 통신 시스템 망에서 혼잡 제어를 효율적으로 수행하는 방법 및 장치
CN108881010A (zh) * 2018-07-13 2018-11-23 北京瀚海星云科技有限公司 基于损益评估的拥塞路径调整方法
CN109039930A (zh) * 2018-07-13 2018-12-18 北京瀚海星云科技有限公司 一种评估Clos网络路径拥塞的方法
CN108683602B (zh) * 2018-07-13 2022-05-13 深圳致星科技有限公司 一种数据中心网络负载均衡方法
CN109167704A (zh) * 2018-08-31 2019-01-08 赛尔网络有限公司 空间链路增强的传输协议tcp+监测方法
CN109067665B (zh) * 2018-09-25 2022-01-11 华为技术有限公司 拥塞控制方法和网络设备
WO2020169170A1 (en) * 2019-02-18 2020-08-27 Lenovo (Singapore) Pte. Ltd. Calculating round trip time in a mobile communication network
CN111490934B (zh) * 2020-04-24 2021-09-14 电子科技大学 基于流突发性的多路径路由系统
CN112040352B (zh) * 2020-08-21 2022-03-01 烽火通信科技股份有限公司 路径切换方法、装置、设备及可读存储介质
CN112787925B (zh) * 2020-10-12 2022-07-19 中兴通讯股份有限公司 拥塞信息收集方法、确定最优路径方法、网络交换机
CN112910795B (zh) * 2021-01-19 2023-01-06 南京大学 一种基于众源的边缘负载均衡方法和系统
US20220294737A1 (en) * 2021-03-09 2022-09-15 Nokia Solutions And Networks Oy Path congestion notification
CN113810459A (zh) * 2021-07-29 2021-12-17 奇安信科技集团股份有限公司 数据传输方法、装置、电子设备及存储介质
WO2023110067A1 (en) * 2021-12-15 2023-06-22 Huawei Technologies Co., Ltd. Load management in communication networks

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103051546A (zh) * 2012-12-12 2013-04-17 中国科学院计算技术研究所 一种基于迟滞调度的网络流量冲突避免方法及系统
CN106230722A (zh) * 2016-08-05 2016-12-14 山东省计算中心(国家超级计算济南中心) 基于转移代价的sdn网络拥塞链路调整方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW589826B (en) * 2003-01-15 2004-06-01 Via Tech Inc Distribution method of data packet flow
US8223634B2 (en) * 2004-02-18 2012-07-17 Fortinet, Inc. Mechanism for implementing load balancing in a network
JP4460358B2 (ja) * 2004-05-19 2010-05-12 Kddi株式会社 障害救済処理方法およびプログラム
CN101436976B (zh) * 2007-11-13 2012-02-15 华为技术有限公司 一种转发数据帧的方法、系统和设备
CN101335714A (zh) * 2008-07-18 2008-12-31 华为技术有限公司 一种负载分担的方法及设备或快速重路由的方法及设备
CN102025644B (zh) * 2010-12-31 2012-10-17 华为技术有限公司 一种负载分担方法及设备
US20150334024A1 (en) * 2012-04-20 2015-11-19 Jeffrey Clifford Mogul Controlling Data Rates of Data Flows Based on Information Indicating Congestion
US20140040526A1 (en) * 2012-07-31 2014-02-06 Bruce J. Chang Coherent data forwarding when link congestion occurs in a multi-node coherent system
US10778584B2 (en) 2013-11-05 2020-09-15 Cisco Technology, Inc. System and method for multi-path load balancing in network fabrics
US9419908B2 (en) * 2013-11-27 2016-08-16 Cisco Technology, Inc. Network congestion management using flow rebalancing
CN105991435B (zh) * 2015-02-05 2019-08-27 华为技术有限公司 用于获取端口路径的方法及装置
US20170048144A1 (en) * 2015-08-13 2017-02-16 Futurewei Technologies, Inc. Congestion Avoidance Traffic Steering (CATS) in Datacenter Networks
US10320681B2 (en) * 2016-04-12 2019-06-11 Nicira, Inc. Virtual tunnel endpoints for congestion-aware load balancing

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103051546A (zh) * 2012-12-12 2013-04-17 中国科学院计算技术研究所 一种基于迟滞调度的网络流量冲突避免方法及系统
CN106230722A (zh) * 2016-08-05 2016-12-14 山东省计算中心(国家超级计算济南中心) 基于转移代价的sdn网络拥塞链路调整方法

Also Published As

Publication number Publication date
EP3541027B1 (en) 2021-06-30
CN108243111A (zh) 2018-07-03
EP3541027A4 (en) 2019-11-27
US20190319882A1 (en) 2019-10-17
US10924413B2 (en) 2021-02-16
EP3541027A1 (en) 2019-09-18
WO2018121068A1 (zh) 2018-07-05

Similar Documents

Publication Publication Date Title
CN108243111B (zh) 确定传输路径的方法和装置
US9246818B2 (en) Congestion notification in leaf and spine networks
US10075338B2 (en) Relay control unit, relay control system, relay control method, and relay control program
CN108141416B (zh) 一种报文处理方法、计算设备以及报文处理装置
US9049131B2 (en) Network system and load balancing method
CN109691037B (zh) 用于数据中心负载均衡的方法和系统
RU2612599C1 (ru) Устройство управления, система связи, способ управления коммутаторами и программа
US9602428B2 (en) Method and apparatus for locality sensitive hash-based load balancing
US10778588B1 (en) Load balancing for multipath groups routed flows by re-associating routes to multipath groups
US10693790B1 (en) Load balancing for multipath group routed flows by re-routing the congested route
CN108965121B (zh) 传输数据的方法、主机和交换机
US10560367B2 (en) Bidirectional constrained path search
CN112152924A (zh) 一种在数据中心网络中转发报文的方法及相关装置
US20140040477A1 (en) Connection mesh in mirroring asymmetric clustered multiprocessor systems
US10389615B2 (en) Enhanced packet flow monitoring in a network
CN103348636A (zh) 用于应对多播路由选择中的冲突的方法
CN111654437A (zh) 基于数据中心的报文转发方法及装置
US20180062966A1 (en) Selective transmission of bidirectional forwarding detection (bfd) messages for verifying multicast connectivity
KR101707355B1 (ko) 통신 노드, 통신 시스템, 제어 장치, 패킷 전송 방법 및 프로그램
US9537764B2 (en) Communication apparatus, control apparatus, communication system, communication method, method for controlling communication apparatus, and program
US20190268263A1 (en) Flow cache based mechanism of packet redirection in multiple border routers for application awareness
US20170070473A1 (en) A switching fabric including a virtual switch
CN108337181B (zh) 一种交换网拥塞管理方法和装置
JP5720524B2 (ja) 中継のためのプログラム、中継装置及び制御方法
CN107113244B (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
GR01 Patent grant
GR01 Patent grant