CN115208746B - 故障路由通知的有效传播 - Google Patents

故障路由通知的有效传播 Download PDF

Info

Publication number
CN115208746B
CN115208746B CN202210231271.2A CN202210231271A CN115208746B CN 115208746 B CN115208746 B CN 115208746B CN 202210231271 A CN202210231271 A CN 202210231271A CN 115208746 B CN115208746 B CN 115208746B
Authority
CN
China
Prior art keywords
notification
port
given
network element
address group
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
CN202210231271.2A
Other languages
English (en)
Other versions
CN115208746A (zh
Inventor
J·亚鲁兹
L·利瓦伊
G·梅伊-塔尔
D·克莱因
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.)
Mellanox Technologies Ltd
Original Assignee
Mellanox Technologies 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 Mellanox Technologies Ltd filed Critical Mellanox Technologies Ltd
Publication of CN115208746A publication Critical patent/CN115208746A/zh
Application granted granted Critical
Publication of CN115208746B publication Critical patent/CN115208746B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • H04L45/123Evaluation of link metrics
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0686Additional information in the notification, e.g. enhancement of specific meta-data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0631Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/42Centralised routing

Landscapes

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

Abstract

公开了故障路由通知的有效传播。一种网络元件包括处理电路和多个端口。端口使用链路连接至通信网络。处理电路被配置为经由端口接收分组并且经由端口将所接收的分组转发至相应的目的地地址。目的地地址被组织在地址组中,每个地址组包括连接至通信网络中的公共网络元件的节点的多个目的地地址。所述处理电路还被配置为:响应于识别出给定端口连接至故障链路,确定由于所述故障链路而变得经由所述给定端口不可到达的一个或更多个地址组,生成通知,该通知报告所确定的地址组中的经由除了所述给定端口之外的任何端口不可到达的一个或更多个地址组,以及经由除了所述给定端口之外的一个或更多个端口将所述通知传输到一个或更多个其他网络元件。

Description

故障路由通知的有效传播
技术领域
本文描述的实施例一般涉及数据通信,尤其涉及用于有效传播故障路由通知的方法和系统。
背景技术
通信系统可能遭受降低性能的各个故障。例如,链路故障可导致丢失数据、拥塞或两者。
用于减轻由于链路故障引起的性能降级的方法在本领域中是已知的。例如,美国专利9391874描述了一种在跨网络的路径上发生故障的情况下在通信网络中重新路由流量(traffic)的方法,该方法包括:确定位于故障与网络入口节点之间的第一节点是否能够将流量切换至避开故障的替代路径,并且如果确定第一节点不能这样做,则确定位于第一节点上游的第二节点是否能够将流量切换至避开故障的替代路径。
作为另一个示例,美国专利8619546描述了用于处理中央控制平面架构中的链路故障的能力。用于处理链路故障的能力使得能够以防止网络内的链路故障消息(LFM)的泛洪的方式针对性地报告网络内的链路故障。一种用于报告与节点相关联的链路的故障的方法包括:检测与所述节点相关联的链路的故障;识别与所述故障链路相关联的所述节点的接口;从所述节点的流表中识别所述节点的入口接口,经由所述入口接口接收针对所述故障链路的流;生成用于所识别的所述入口接口的LFM;以及经由所识别的所述入口接口发送所述LFM。
2019年由技术的白皮书描述了一种被称为SHIELDTM—(智能数据中心的自修复互连增强)的解决方案,该解决方案利用已经内置在最新一代无限带宽交换机(InfiniBand switch)中的智能。通过使该结构具有自我修复自主性,可以在面对链路故障时校正通信的速度可以加速5000x,足够快以节省来自昂贵的重传或绝对故障的通信。例如,在美国专利9729473描述了SHIELD解决方案的各方面。
发明内容
本文描述的实施例提供了包括处理电路和多个端口的网络元件。端口被配置为使用链路连接至通信网络。处理电路被配置为经由端口接收分组并且经由端口将所接收的分组转发至相应的目的地地址。目的地地址被组织在地址组中,每个地址组包括连接至通信网络中的公共网络元件的端节点的多个目的地地址。所述处理电路还被配置为:响应于识别出给定端口连接至故障链路,确定由于所述故障链路而变得经由所述给定端口不可到达的一个或更多个地址组,生成通知,所述通知报告所确定的地址组中的经由除了所述给定端口之外的任何端口不可到达的一个或更多个地址组,以及经由除了所述给定端口之外的一个或更多个端口将所述通知传输到一个或更多个其他网络元件。
在一些实施例中,所述处理电路被配置为响应于接收到要被转发到给定端口的分组,识别所述给定端口连接至故障链路。在其他实施例中,处理电路被配置为独立于接收用于转发到给定端口的任何分组,识别给定端口连接至故障链路。在又一些其他实施例中,地址组与相应的唯一地址组标识符相关联,并且处理电路被配置为在通知中报告所确定的地址组的地址组标识符。
在一个实施例中,所述处理电路被配置为保持将所述网络元件的每个端口映射到经由所述端口可到达的相应地址组的映射,并且通过使用所述映射将所述给定端口映射到相应地址组来确定所述一个或更多个地址组。在另一实施例中,处理电路被配置为在传输报告给定地址组的通知之后,抑制传输报告给定地址组的另一通知。
根据在此描述的实施例,另外提供了一种方法,该方法包括:在包括用于使用链路连接至通信网络的多个端口的网络元件中,经由端口接收分组并且经由端口将所接收的分组转发至相应的目的地地址。目的地地址被组织在地址组中,每个地址组包括连接至通信网络中的公共网络元件的端节点的多个目的地地址。响应于识别出给定端口连接至故障链路,确定由于故障链路而变得经由给定端口不可到达的一个或更多个地址组。生成通知,所述通知报告所确定的地址组中的经由除了所述给定端口之外的任何端口不可到达的一个或更多个地址组。经由除给定端口之外的一个或更多个端口将通知传输至一个或更多个其他网络元件。
根据本文描述的实施例,还提供了一种包括处理电路和多个端口的网络元件。多个端口被配置为使用链路连接至通信网络。处理电路被配置为经由端口接收分组并且经由端口将所接收的分组转发至相应的目的地地址。目的地地址被组织在地址组中,每个地址组包括连接至通信网络中的公共网络元件的端节点的多个目的地地址。所述处理电路还被配置为:经由给定端口接收报告由于另一网络元件中的链路故障而变得经由所述给定端口不可到达的一个或更多个地址组的通知,以及在确定所接收到的通知中的经由所述网络元件的任何端口不可到达的一个或更多个地址组时,经由除了所述给定端口之外的一个或更多个端口传输报告所确定的地址组的输出通知。
在一些实施例中,处理电路被配置为在确定通知中的给定地址组经由替代路径可到达时,抑制在输出通知中包括给定地址组,并且经由替代路径转发寻址到给定地址组的后续接收的分组。在其他实施例中,处理电路被配置为响应于通知,抑制经由给定端口将要传送的分组转发至确定的地址组。在其他实施例中,处理电路被配置为接收第一通知,随后是第二通知,第一通知和第二通知均报告变得经由相应的第一端口和第二端口不可到达的给定地址组,并且响应于第一通知,在接收第二通知之前,经由第二端口发送报告给定地址组的输出通知。
在一个实施例中,处理电路被配置为在输出通知中报告仅经由具有到相应地址组的非最短路径的端口可到达的地址组。在另一实施例中,所述处理电路被配置为:针对给定地址组,将高优先级指派给具有到所述给定地址组的最短路径的端口,以及将低优先级指派给具有到所述给定地址组的非最短路径的端口,以及响应于接收到包括所述给定地址组的通知,仅经由针对所述给定地址组被指派了低优先级的端口发送报告所述给定地址组的输出通知。
在又一实施例中,通信网络包括从拓扑列表中选择的拓扑,该拓扑列表包括:Fat-Tree拓扑、克洛斯(Clos)拓扑、龙飞加(DragonFly Plus)拓扑和Xpander拓扑。
根据在此描述的实施例,另外提供了一种方法,该方法包括:在包括用于使用链路连接至通信网络的多个端口的网络元件中,经由端口接收分组并且经由端口将所接收的分组转发至相应的目的地地址。目的地地址被组织在地址组中,每个地址组包括连接至通信网络中的公共网络元件的端节点的多个目的地地址。经由给定端口接收通知,所述通知报告由于另一网络元件中的链路故障而变得经由所述给定端口不可到达的一个或更多个地址组。在确定接收到的通知中的经由网络元件的任何端口不可到达的一个或更多个地址组时,经由除了给定端口之外的一个或更多个端口传输报告所确定的地址组的输出通知。
从下面结合附图对实施例的详细描述,将更全面地理解这些和其他实施例。
附图说明
图1是示意性地示出了根据本文描述的实施例的支持从链路故障的基于通知的恢复的计算机网络的框图;
图2是示意性示出了根据本文描述的实施例的可用于图1的计算机网络的网络中的网络元件的框图;
图3是示意性地示出了根据本文所描述的实施例的用于向相邻网络元件通知由于链路故障而变得不可到达的地址组的方法的流程图;
图4A和图4B是示意性地示出了根据本文所描述的实施例的用于从具有Fat-Tree拓扑的通信网络中的链路故障恢复的方法的示图;
图5是示意性地示出了根据本文描述的实施例的用于基于指派给替代路径的优先级通知链路故障的方法的流程图;
图6A、图6B和图6C是示意性地示出了根据本文描述的实施例用于从具有DragonFly Plus拓扑的通信网络中的链路故障恢复的方法的示图;以及
图7是示意性地示出了根据本文描述的实施例从具有Xpander拓扑的通信网络中的链路故障恢复的方法的示图。
具体实施方式
概述
本文描述的实施例提供了用于从通信网络中的链路故障恢复的改进的方法和系统。
通信网络通常由通过一些拓扑中的链路互连的多个网络元件构建。当网络中的链路发生故障时,耦合至网络的包括发生故障的链路的一对网络节点之间的任何路径变成“断开”。这种情况可持续到建立到目的地的替代路径。
原则上,连接至网络的中央实体可检测到故障链路或被通知故障链路,并且作为响应,重新配置一个或更多个网络元件以创建至目的地的替代路径。然而,基于集中式实体的恢复方法通常缓慢地(例如,大约几秒或者甚至几分钟(取决于所使用的恢复方法))反应以重建替代路径,这可能降低网络可靠性。
在所公开的实施例中,网络元件保存关于分别由该网络元件的每个端口可到达的一组或更多组目的地地址的信息。当耦合到给定端口的链路出现故障时,网络元件触发将故障通知传输到耦合到网络元件的其他端口的相邻网络元件。故障通知可进一步传播到网络中的其他网络元件,直到建立到由于故障链路变得不可到达的每个地址组的替代路径。参与该协议的每个网络元件仅针对给定地址组发送一次通知,因此限制发送的故障通知的最大数量。
故障通知的传播继续,直到在链路故障之前具有经由给定链路到相应目的地节点的路径的所有源节点具有到目的地节点的替代路径,从而在给定链路故障之后跳过该给定链路。
在以下描述中,在本地检测到故障链路并且作为响应发起故障通知的传输的网络元件称为“发起方”,而响应于另一网络元件中的链路故障而接收故障通知的网络元件称为“接收方”。
在一些实施例中,网络元件响应于接收到有待转发至给定端口的分组而识别给定端口连接至故障链路。可替代地,网络元件例如通过监测链路状态来检测故障链路,独立于接收到任何用于转发到给定端口的分组。
在以下描述中,短语“将分组发送至地址组”(或相似的措辞)表示将分组发送至目的地地址属于该地址组的网络节点。
可以以各种方式标识地址组。在一些实施例中,地址组与具有紧凑表示的相应的唯一地址组标识符相关联,并且网络元件在通知中报告相关地址组的地址组标识符。
当给定端口处的链路发生故障时,网络元件需要知道哪些地址组由于故障而变得不可到达。为此,在一些实施例中,网络元件保持将网络元件的每个端口映射到通常经由端口可到达的相应地址组的映射。在这样的实施例中,网络元件通过使用映射将给定端口映射到相应的地址组来确定变得不可到达(由于故障链路)的地址组。
通过传播故障通知从链路故障恢复可以导致“泛洪”网络。为了防止这一点,在一些实施例中,在传输报告给定地址组的通知之后,网络元件抑制传输报告相同地址组的另一通知。
在实施例中,网络元件充当经由给定端口接收故障通知的接收方。一旦确定通知中的给定地址组可经由替代路径(经由另一端口)到达,则网络元件抑制在输出通知中包括给定地址组,并且经由替代路径转发寻址到给定地址组的后续接收的分组。所述网络元件还抑制经由连接至所述故障链路的给定端口转发寻址到所确定的地址组的分组。
在一些实施例中,网络元件接收全部报告共同地址组的多个通知。例如,网络元件接收均报告经由相应的第一端口和第二端口变得不可到达的给定地址组的第一通知和第二通知。例如,假设网络元件在接收第二通知之前接收第一通知。在这种情况下,响应于接收到第一通知,网络元件在接收第二通知之前经由第二端口发送报告给定地址组的输出通知。
在一些实施例中,在本文中称为“最短路径”方法的方法中,仅最短路径可用作替代路径。在此类实施例中,网络元件在输出通知中仅报告可经由具有到各个地址组的非最短路径的端口到达的地址组。
在一些实施例中,在本文中称为“基于优先级的”方法的方法中,对于给定地址组,网络元件将高优先级指派给具有到给定地址组的最短路径的端口,并且将低优先级指派给具有到给定地址组的非最短路径的端口。响应于接收到包括给定地址组的通知,网络元件仅经由被指派给给定地址组的低优先级的端口发送报告给定地址组的输出通知。需要说明的是,在基于优先级的方法中,保留了在最短路径方式中被淘汰的一些路径。
所公开的实施例适用于各种拓扑,诸如但不限于Fat-Tree拓扑、Clos拓扑、DragonFly Plus拓扑和Xpander拓扑。
在所公开的技术中,给定网络元件向其他网络元件通知由于故障链路变得经由给定网络元件不可到达的地址组。以地址组的分辨率而不是报告单独的目的地地址来处理通知是非常高效的并且在网络元件中需要非常小的处理功率。此外,在每个网络元件中,相关的地址组仅报告一次,这防止了通知泛洪。在跨拓扑的网络元件发起故障通知的传播中涉及的方法可被视为执行通知协议。该协议收敛到所有源节点具有到其目的地节点的替代路径、跳过故障链路的状态。与由中央实体从链路故障恢复相比,协议的收敛时间快得多。
系统描述
图1是示意性地示出了根据本文描述的实施例的支持从链路故障的基于通知的恢复的计算机网络20的框图。
在计算机网络20中,网络节点24通过通信网络30彼此通信。通信网络30可以包括具有任何合适的拓扑并且在任何合适的协议下操作的任何合适的通信网络。例如,通信网络30可以包括以太网网络或无限带宽结构。
计算机网络20可以在各个应用中使用,例如在云应用中、在AI应用中和在高性能计算(HPC)环境中。
在本示例中,表示为S1和S2的网络节点24用作源节点,而表示为D1…D4的网络节点24用作目的地节点。在此配置中,源节点S1和S2中的每一者可将数据发送到目的地节点D1…D4中的每一者。在实际应用中,计算机网络20通常包括数千个网络节点24,每个网络节点既作为源节点又作为目的地节点。
通信网络30包括使用链路38彼此连接并且连接至网络节点24的多个网络元件34。网络元件34可包括在通信网络30中转发分组的任何合适类型的网络元件,例如网络交换机或路由器。在图1的示例中,网络元件34包括表示为SW1…SW6的网络交换机。
在图1中,源节点S1和S2经由包括交换机SW3、SW2、SW1、SW4和SW5的通信网络中的路径与目的地节点D1和D2通信。类似地,源节点S1和S2经由包括SW3、SW2、SW1、SW4和SW6的路径与目的地节点D3和D4通信。注意,除了从SW2经由S1至SW4的路径段之外,网络还具有跳过SW1的从SW2至SW4的替代路径段42。替代路径段42在图中以虚线描绘,且可包括直接链路38或由链路38互连的一个或更多个网络元件34。
中央实体44被耦合至通信网络30。中央实体44可包括例如子网管理器(SM)或用于管理通信网络30的任何其他合适的计算机或服务器。除了其他任务之外,中央实体44将网络元件34配置有转发信息,该转发信息指定将应用于传入分组的转发规则。在一些实施例中,中央实体44检测通信网络30中的故障链路38或被通知通信网络30中的故障链路38。响应于故障链路中心实体44,重新配置一个或更多个网络元件34以建立到目的地的替代路径。然而,由中央实体从链路故障恢复通常很慢(例如,取决于所使用的基础协议,大约几秒或者甚至几分钟),这降低了网络可靠性。
在所公开的实施例中,连接至故障链路的网络元件向其相邻者发送指定变得经由给定网络元件不可到达的一组或更多组目的地地址的通知。接收到通知的相邻网络元件开始使用至目的地的替代路径(当可用时)或将另一通知传播至其相邻者。
在所公开的实施例中,端节点的目的地地址成组布置。如下面将描述的,按照地址组而不是按照单独的目的地地址来通知链路故障,这使得通知机制非常高效。在本上下文中并且在权利要求中,“地址组”(AG)包括连接至通信网络中的公共网络元件的端节点的多个目的地地址。
在一些实施例中,地址组与相应的地址组标识符相关联。一般而言,地址组的标识符可从底层拓扑的结构导出。例如,在Fat-Tree拓扑中,地址组可与连接至顶架(ToR)交换机的所有服务器关联,或者甚至与连接至拓扑中的网荚(pod)的所有服务器关联。在图1的示例中,包括网络节点D1和D2的目的地地址的地址组被表示为AG1,并且包括网络节点D3和D4的目的地地址的地址组被表示为AG2。
例如,假设SW1和SW4之间的链路38A发生故障。因此,SW1不再能向目的地地址属于AG1或AG2的网络节点发送分组。作为对检测到链路故障的响应,SW1阻止经由连接至链路38A的端口转发寻址到AG1和AG2的分组,例如,通过更新其转发表。另外,SW1向除SW4以外的所有相邻网络元件发送报告AG1和AG2的通知46。该通知表示为FRN(AG1,AG2)——报告地址组AG1和AG2的故障路由通知(FRN)。
在本示例中,响应于接收到通知46,SW2开始经由替代分段路径42而不是经由SW1转发寻址到AG1和AG2的分组。由于SW2具有到AG1和AG2的替代路径,因此SW2不需要进一步传播任何通知。
图2是示意性地示出了根据本文所述的实施例的可用于图1的计算机网络20的网络中的网络元件34的框图。
网络元件34包括被配置成使用链路38连接至通信网络30的多个端口60。具体地,取决于其在下划线拓扑中的位置,网络元件34可以连接至其他网络元件34、网络节点24、中央实体44和/或通信网络的任何其他元件。
网络元件34包括存储器64和处理逻辑68。存储器64存储所接收的分组的队列,并且通常还存储其他数据。处理逻辑68处理传入分组并且例如使用转发表72转发它们。转发表在目的地地址和网络元件的相应输出端口之间进行转换。在一些实施例中,转发表将目的地地址(例如,写入传入分组的报头中)映射到具有到通信网络中的该目的地地址的路径的端口60中。在一些实施例中,对于给定分组,网络元件34具有经由多个相应端口到相同目的地地址的多条路径。在这样的实施例中,处理逻辑68例如基于分组所属的流来确定针对每个分组使用哪些可用路径。
网络元件34包括交换机控制器76,该交换机控制器76执行网络元件34的各种管理任务和一些分组处理功能。例如,交换机控制器76将转发表72配置为应用所期望的路由计划。通过控制路由计划,网络元件34可促使分组通过通信网络30遍历各个路径。
在一些实施例中,处理逻辑68监测链路38的链路状态。响应于检测到连接至给定端口的链路已经发生故障,处理逻辑68生成通知(例如,FRN),该通知报告由于链路故障而变得经由给定端口不可到达的地址组(AG)。AG映射84映射在端口和AG之间,当所有链路都操作时,AG可经由端口访问。在一些实施例中,处理逻辑68使用AG映射84将故障链路的端口映射到相应的地址组,并且将映射的AG包括在FRN中。在一些实施例中,FRN报告相关AG的紧凑地址组标识符。处理逻辑68将FRN传输至其相邻网络元件,如上所述。
在一些实施例中,网络元件34从另一个网络元件接收报告一个或更多个不可到达AG的FRN。如下面将详细描述的,该网络元件识别所接收的FRN中的AG,对于该FAG,没有任何经由任何端口的替代路径,并且该网络元件传输FRN,该FRN将所识别的AG报告给其相邻网络元件(不包括从其接收FRN的网络元件)。
图1中的计算机网络20和图2中的网络元件34的配置是纯粹为了概念清晰而选择的示例性配置。在替代实施例中,也可以使用任何其他合适的计算机网络和网络元件配置。网络元件34的不同元件可以在硬件中实现,诸如使用一个或更多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)。在替代实施例中,网络元件34的一些元件(例如,处理逻辑68和/或交换机控制器76)可以在合适的处理器上执行的软件中实现,或使用硬件和软件元件的组合来实现。
存储器64可包括任何合适的存储技术的任何合适的存储设备。例如,存储器64可包括随机存取存储器(RAM)或诸如闪存的非易失性存储器。
为了清楚起见,从图1和图2中省略了对于理解本申请的原理而言不必要的元件,诸如各种接口、寻址电路、时序和定序电路以及调试电路。
在一些实施例中,处理逻辑68和/或交换机控制器76可以包括通用处理器,所述通用处理器被编程在软件中以执行本文所述的网络管理器和/或交换机功能。软件可以例如通过网络以电子形式下载到处理器,或者它可以替换地或附加地被提供和/或存储在非暂态有形介质上,诸如磁性、光学或电子存储器。
在本上下文中并且在权利要求中,网络元件的除了端口60之外的元件统称为“处理电路”86。在图2的示例性网络元件中,处理电路包括处理逻辑68、存储器64和交换机控制器76。
使用故障路由通知从链路故障恢复的方法
图3是示意性地示出了根据本文所描述的实施例的用于向相邻网络元件通知由于链路故障而变得不可到达的地址组的方法的流程图。
该方法将被描述为由以上图1和图2的网络元件34的处理逻辑68执行。
在描述图3的方法时,假设网络元件的AG映射84被配置为将网络元件的每个端口映射至经由该端口可到达的相应的一个或更多个目的地AG。进一步假设转发表72保存用于将目的地地址转换成相应输出端口的信息。转发表72将给定AG的所有目的地地址映射到公共端口。
在一些实施例中,网络元件34管理每个AG的标记。该标记最初被清除,并且响应于发送报告与该标记相关联的AG的FRN而被设置。当相应的标记被设置时,网络元件抑制发送针对AG的FRN。该机制对于限制在建立至目的地AG的替代路径之前发送的FRN的总数目是重要的。在替代实施例中,也可使用用于在网络元件中每AG仅发送一次FRN的其他合适的方法。
图3的方法开始于处理逻辑68在故障检测步骤100A检测与给定端口相关联的故障链路,或者在FRN接收步骤100B经由给定端口从相邻网络元件接收FRN。在步骤100A,处理逻辑可以响应于接收到要通过故障链路传送的分组,或者独立于任何分组接收,来检测故障链路。执行步骤100A或100B的网络元件也分别被称为“发起方”或“接收方”。
在标记检查步骤104,处理逻辑检查由于故障链路而变得不可到达的AG之中(在步骤100A)或者在所接收的FRN中报告的AG之中(在步骤100B)的至少一个AG的标记是否被清除。当设置了所有相关标记时,处理逻辑前进到终止步骤106,并且该方法终止。否则,在任何FRN中都有一个或更多个AG尚未被网络元件上报,处理逻辑进行到AG识别步骤108。在步骤108,处理逻辑68识别变得经由给定端口不可到达的AG并且清除它们对应的标记。在一些实施例中,在步骤108,处理逻辑通过使用AG映射84将给定端口的标识符映射到不可到达AG的一个或更多个AG标识符来识别AG。
在表更新步骤112中,处理逻辑通过从转发表中排除用于将分组转发到给定端口的信息来更新转发表72。这意味着通常经由给定端口流向对应AG的所有流量现在被阻塞。
在替代路径查询步骤116,处理逻辑检查网络元件是否具有到达AGi的目的地地址的替代路径,其中AGi表示在步骤108识别的AG中的第i个(ith)AG。当在步骤116,网络元件不具有替代路径时,处理逻辑在输出FRN中包括AGi,并且在报告步骤120,设置AGi的标记。在步骤116或120之后,处理逻辑前进至循环处理步骤124,以检查在步骤108识别出的所有AG是否被处理。当仍然有AG要处理时,处理逻辑在AG选择步骤128选择后续的AGi,并且循环回到步骤116以检查替代路径。否则,处理逻辑68前进到通知传输步骤132,以传输如上所述通过循环经过步骤120而产生的输出FRN(如果有的话)。处理逻辑在步骤132经由除给定端口之外的所有端口传输输出FRN。在步骤132之后,该方法在步骤106终止。
在图3的方法中,发起方网络元件生成稍后由作为接收方操作的网络元件传播的第一FRN。在本上下文中,术语“通知传播”是指由发起方或接收方网络元件向相邻网络元件发送FRN所执行的过程。取决于替代路径的可用性,接收FRN的接收方网络元件可(i)在具有到在所接收的FRN中报告的AG中的每一者的替代路径时抑制发送任何FRN,或(ii)发送包含在所接收的FRN中报告的不具有替代路径的AG的FRN。接收方网络元件可通过操纵所接收的FRN或通过将信息从所接收的FRN复制到所述输出FRN来生成所述输出FRN。
在图3的方法的步骤116,处理逻辑检查替代路径。如以下将详细描述的,在一些实施例中,还可使用附加约束,例如,检查替代路径是否包括最短路径,或基于预先指派的优先级对替代路径进行分类。
在通信网络中应用图3的方法产生有效的通知协议。该协议由网络元件检测到故障链路而触发,并且当所有源节点具有到其目的地节点的跳过故障链路的替代路径时(当这种收敛可行时)收敛。对于给定拓扑,直到协议收敛为止发送的故障通知的总数被拓扑中的网络元件对之间的链路数量进行上限。此外,将故障通知传播到所有相关网络元件所需的时间被与网络直径成比例的持续时间进行上限。
从Fat-Tree拓扑中的链路故障恢复
图4A和图4B是示意性地示出了根据本文所描述的实施例的用于从具有Fat-Tree拓扑的通信网络150中的链路故障恢复的方法的图示。
在图4A和图4B中,使用链路38以三级Fat-Tree拓扑将网络元件34互连。在本示例中,网络元件34包括网络交换机。图4A和图4B中的拓扑也可以被视为Clos拓扑的特殊情况。拓扑的下级包括八个表示为S11…S18的网络元件34,中级包括八个表示为S21…S28的网络元件34,并且上级包括四个表示为S31…S34的网络元件34。在图4A和图4B中,为了清楚起见,仅编号了网络元件和链路的一部分。在描述图4A和图4B时,假设网络元件34包括网络交换机。然而,该假设不是强制性的,并且还可以使用诸如路由器等其他类型的网络元件。
在本示例中,较低级中的每个交换机使用链路38直接连接至网络节点24。直接连接至网络节点的交换机也被称为顶架(ToR)交换机。在图4A和图4B的示例中,每个ToR交换机连接至两个网络节点24。然而,在实际实现中,ToR交换机通常连接至几十个网络节点。每个ToR交换机的网络节点的实际数量取决于交换机的基数(即,端口的总数)。ToR交换机有时被连接,使得一半端口连接至网络节点(例如,使用网络适配器)并且另一半连接至拓扑中的其他交换机。
网络节点24被预先指派了相应的目的地地址。例如,在包括无限宽带(InfiniBand)结构的子网中,向每个网络节点指派唯一的目的地本地标识符(DLID),而在以太网网络中,每个网络节点包括相应的MAC地址。
如上所述,目的地地址布置在表示为地址组(AG)的组中,每个AG包括耦合至公共交换机34的网络节点24的目的地地址。在图4A和图4B的示例中,耦合至交换机S11…S18的网络节点24与表示为AG1…AG8的相应AG相关联,其中,AG中的每一个包括相关网络节点的两个目的地地址。
接下来,描述使用上述图3的方法从链路故障恢复的示例场景。
图4A涉及第二级别的交换机S27和第一级别的交换机S17之间的链路发生故障的场景,如故障链路上描述的“X”符号所示。在该示例中,连接至S17的表示为d1和d2的目的地节点变得经由S27不可到达(但仍经由S28可到达)。
响应于检测到故障链路,S27在其转发表进行阻塞,将分组转发至S17。S27进一步检查其是否具有至AG7的替代路径。由于S27没有到S17的替代路径(因此在AG7中没有到d1和d2的替代路径),因此S27(作为发起方)经由除了连接至S17的端口之外的所有端口向其相邻者传输报告AG7的FRN。S27还设置对应于AG7的标记。在该示例中,FRN(AG7)经由S27通知交换机S31、S32和S18不能到达AG7的目的地地址。
作为接收方,交换机S18具有经由S28到S17的路径并且因此忽略通知FRN(AG7)。另一方面,S31和S32中没有一个具有至S17的替代路径。因此,S31和S32中的每一个经由除了接收FRN(AG7)所经由的端口之外的所有端口将FRN(AG7)通知传播至其相邻交换机。具体地,S31和S32中的每一个将FRN(AG7)传输至S21、S23和S25。应注意,S31和S32中的每一个独立于另一交换机传输FRN(AG7)。
交换机S21、S23以及S25中的每个接收来自S31的FRN(AG7)以及来自S32的另一个FRN(AG7)。例如,假设S21首先接收到S31发送的FRN(AG7)。结果,S21停止向S31转发分组,而不停止向S32转发分组。此外,在从S32接收到FRN(AG7)之前,从S21至S32的链路仍被视为可操作的,并且因此S21不将任何FRN传输至其相邻交换机并且不设置AG7的标记。当S21稍后从S32接收到FRN(AG7)时,交换机S21识别其没有至AG7的替代路径,并且因此停止将分组转发至S32,将FRN(AG7)传输至S11和S12,并且设置AG7的标记。由于S11和S12中的每一个具有经由S22、S34、S28和S17至AG7的目的地地址d1和d2的路径,S11和S12避免进一步传播任何FRN。
图4B涉及上层级别的交换机S31与第二级别的交换机S27之间的链路出现故障的场景,如“X”符号所示。由于故障链路,连接至S17的目的地网络节点d1、d2和连接至S18的目的地网络节点d3、d4经由S31不可到达。
S31检测到朝向S27的故障链路,但是由于S31没有到S27的替代路径(并且因此没有到AG7和AG8中的d1…d4的替代路径),所以S31经由除故障链路的端口之外的所有端口向其相邻者传输报告AG7和AG8两者的FRN。S31还阻止将分组转发至S27并设置AG7和AG8的标记。FRN(AG7,AG8)通知相邻交换机AG7和AG8不能经由S31到达。
在图4B的示例中,S31将FRN(AG7、AG8)传输至S21、S23以及S25。响应于FRN,S21、S23和S25中的每一个均阻止经由从其接收FRN的端口将分组转发至S31。然而,S21、S23和S25中的每一个均具有经由S32到S27的替代路径,并且因此不再发送FRN。
可显示出,具有高度‘h’(即,h+1级别)的Fat-Tree拓扑中的收敛时间被与2h成比例的持续时间进行上限。当链路故障发生在级别‘l’时,其中l≤h,收敛时间与(2h-2l+1)成比例。
用于执行FRN传播的准则
在一些拓扑中,给定链路由多个路径共享。这可以例如在DragonFly Plus拓扑中发生。在这种情况下,接收报告AG的FRN的网络元件可以具有经由公共链路到该AG的替代路径,并且因此未能向其相邻者发送FRN。在一些实施例中,可在处理FRN时对替代路径施加各种约束,如下文将详细描述。现在描述被称为“最短路径”和“基于优先级”的两种不同方法。
在一些实施例中,为了实现最短路径方法,修改图3的方法中的步骤116以查询网络元件是否具有作为到AGi的最短路径的替代路径。当有到AGi的最短路径时,网络元件可以使用该路径,因此输出FRN中不包括AGi。否则,到AGi的所有替代路径(如果有的话)是非最短路径,并且在步骤132,处理逻辑将AGi包括在FRN中以经由所有其他端口发送。需要说明的是,该最短路径方法既适用于发起方网络元件,也适用于接收方网络元件。
在基于优先级的方法中,与AG相关联的端口被指派相应的优先级。在一些实施例中,当具有到目的地AG的最短路径时,端口被指派高优先级,并且当具有到目的地AG的非最短路径时,端口被指派低优先级。
图5是示意性地示出了根据本文描述的实施例基于指派给替代路径的优先级来通知链路故障的方法的流程图。描述了用于接收方网络元件的方法。
假设网络元件的端口如上所述被预指派高优先级和低优先级。
该方法开始于在FRN接收步骤200处,处理逻辑68经由给定端口从相邻网络接收FRN(AG),该FRN(AG)报告变得经由给定端口不可到达的AG。在该示例中,FRN报告单个AG。在替代实施例中,FRN可报告共享替代路径的多个AG。
在标记检查步骤204,处理逻辑检查与所报告的AG相关联的标记是否已经被设置,如果是,则进行到终止步骤206,在此终止该方法。否则,清除AG标记,处理逻辑进行到替代路径查询步骤208。
在步骤208,处理逻辑检查网络元件是否具有到所报告的AG的替代路径,如果没有,则进行标记设置步骤212,以设置与所报告的AG相关联的标记。在全部端口选择步骤216处,处理逻辑选择除给定端口之外的所有端口,并且在传输步骤220处,处理逻辑经由所选择的端口传输FRN(AG)。在步骤220之后,该方法在步骤206处终止。
在步骤208,当网络元件具有到所报告的AG的替代路径时,处理逻辑进行到优先级检查步骤224。在步骤224,处理逻辑检查步骤208的替代路径的优先级是否低于经由故障链路的路径的优先级。当与经由故障链路的路径的优先级相比,替代路径具有更高的或相同的优先级时,处理逻辑开始使用该替代路径,并进行到终止步骤206。否则,处理逻辑在更低优先级选择步骤228中选择连接至优先级比经由故障链路的路径低的路径的端口,并且在步骤220中经由所选择的端口传输FRN(AG)。在步骤220之后,该方法在步骤206处终止。
如下面将描述的,基于优先级的方法保留利用最短路径方法消除的一些路径。
虽然图1的方法被描述用于接收方网络元件,但是该方法类似地应用于发起方网络元件。在这种情况下,步骤200被替换成替代的步骤(例如,200’未示出),在该步骤中,发起方识别与AG相关联的给定端口已经故障。
在DragonFly Plus拓扑中从链路故障恢复
在本节中,将最短路径和基于优先级的方法应用于DagonFly Plus拓扑。
图6A、图6B和图6C是示意性地示出了根据本文描述的实施例用于从具有DragonFly Plus拓扑的通信网络300中的链路故障恢复的方法的示图。例如,2017年2月在美国德克萨斯州奥斯汀,会议:HiPINEB 2017第三届IEEE百万兆级和大数据时代高性能互联网络国际研讨会,“Dragonfly+:可扩展数据中心的低成本拓扑(Dragonfly+:Low CostTopology for Scaling Datacenters)”中描述了Dragonfly Plus(DF+)拓扑。
在图6A、图6B和图6C的示例中,DragonFly Plus拓扑包括表示为G1…G4的四个组304,每个组包括表示为Li1和Li2的叶网络元件以及表示为Si1和Si2的脊网络元件,其中‘i’表示第i个组Gi。使用链路308来连接组内的和不同组之间的网络元件34。在图6A、图6B和图6C中,为了清楚起见,仅部分链路被编号308。
在以下描述中,为了简洁起见,叶网络元件和脊网络元件也被简称为“叶”和“脊”。在实际应用中,DragonFly Plus拓扑可以包括任何合适数量的组,每个组包括任何合适数量的脊和叶。
在本示例中,组G1…G4中的每个内的脊和叶以完全连接的二部拓扑(bipartitetopology)互连,即,每个脊连接至组中的所有叶,并且每个叶连接至组中的所有脊。二部拓扑也可被视为2级Fat-Tree(FT)拓扑。网络节点312仅连接至叶。在替代拓扑中,还可以使用的是,脊连接至该组中的叶的部分子集,和/或叶连接至脊的部分子集。
在DagonFly Plus拓扑中,组使用脊彼此连接。具体地,给定组中的每个脊连接至其他组中的每个组中的脊。例如,G1中的脊S11连接至G2中的S21、G3中的S31以及G4中的S41。
在本示例中,每个叶连接至属于公共AG的两个网络节点。例如,组G1中的叶L11连接至目的地地址属于被表示为AG1的地址组的网络节点,叶L12连接至目的地地址属于被表示为AG2的地址组的网络节点。
接下来,描述DragonFly Plus拓扑中的链路故障场景,这些链路故障场景可使用最短路径方法(例如,使用图3的方法)恢复,其中步骤116如上所述修改。
假设在图6A中,组G1的S11与L11之间的链路出现故障。因此,S11无法向目的地地址属于AG1的网络节点转发流量。在一些实施例中,响应于检测到故障链路,S11从其转发表中排除了将流量转发到L11。此外,由于S11不具有到AG1的替代路径,S11(i)将FRN(AG1)发送到其所有相邻者且(ii)设置与AG1相关联的标记。在该示例中,S11将FRN(AG1)发送至S21、S31、S41以及L12。
L12接收FRN(AG1),但是由于其具有至AG1的替代最短路径(经由S12),L12不再发送FRN。S21、S31和S41均没有到AG1的替代最短路径。因此,S21、S31以及S41中的每一个经由除了接收FRN(AG1)所经由的端口之外的端口将FRN(AG1)发送至所有其相邻者。例如,G2组的S21向G2内的L21和L22发送FRN(AG1),向G3中的S31发送FRN(AG1),并且向G4中的S41发送FRN(AG1)。
G2、G3和G4中的叶具有到AG1的替代最短路径。响应于FRN(AG1),S21、S31和S41中的每一个设置AG1的其标记,并且因此如果接收到,则将忽略进一步的FRN(AG1)。
从故障链路恢复后,与L31耦合的网络节点例如可通过G3的L31和S32,再通过G1的S12和L11,向AG1中的网络节点发送流量。还可以使用更长的路径,包括例如G2的S22或G4的S42。
在图6B的示例中,组G1的S11与组G3的S31之间的链路发生故障。因此,S31不能经由直接链路将流量发送到S11。在这种情况下,AG1和AG2两者经由S31直接到S11变得不可到达。
在一些实施例中,响应于检测到所述故障链路,S31从其转发表中排除经由所述故障链路将流量转发到S11。此外,由于S31没有到AG1和AG2的替代最短路径,因此S31(i)将FRN(AG1、AG2)发送到其所有相邻者以及(ii)设置与AG1和AG2相关联的标记。在该示例中,S31向G3中的L31和L32以及G2中的S21和G4中的S41发送FRN(AG1、AG2)。
响应于接收到FRN(AG1、AG2),L31和L32中的每一个更新其转发表以阻止将流量转发至S31。此外,L31和L32具有到AG1和AG2的最短路径并且因此不传播任何FRN。例如,L31具有经由S32、S12和L11到AG1和AG2的最短路径。
响应于从S31接收到FRN(AG1、AG2),S21阻止将流量转发至S31。因此,S21保留经由S11到(AG1、AG2)的最短路径,并且保留经由S41和S11到(AG1、AG2)的较长路径。在这种情况下,由于S21具有到(AG1、AG2)的最短路径,所以S21不发送任何进一步的FRN。
在图6B的示例中可以看出,最短路径方法可能导致某些路径的不必要的消除。例如,消除了包括S31的从AG5中的网络节点到AG1中的网络节点的路径,即使该路径原则上可用于绕过故障链路。
在图6C中,S31与S11之间的链路发生故障,如上面在图6B中所述。与使用最短路径方法的图6B不同,在图6C中,使用图5的基于优先级的方法。
在图6C中,具有到目的地AG的最短路径的端口被指派高优先级,在图中表示为“HP”,而具有到该AG的非最短路径的端口被指派低优先级,在图中表示为“LP”。例如,为了向地址组AG1和AG2发送流量,S31具有经由S11到最短路径的高优先级端口(在链路失败之前),并且具有经由S21和S41到相应的非最短路径的两个低优先级端口。作为另一示例,S21具有高优先级端口(其具有经由S11直接到AG1和AG2的路径)、低优先级端口(其具有经由S41和S11到AG1和AG2的路径)以及另一低优先级端口(其具有经由S31、S41和S11到AG1和AG2的路径)。
根据以上图5的方法,网络元件仅将FRN发送至到所讨论的AG的替代路径中的具有低优先级路径的端口。在图6C中,响应于检测到到AG1和AG2的具有高优先级路径的端口的链路出现故障,S31经由低优先级端口将FRN(AG1、AG2)发送给S21和S41。由于S31经由L31或L32到AG1和AG2的路径无效,S31不向L31和L32发送FRN,因此L31和L32到S32的路径保持有效。
S21和S41中的每一个从S31接收FRN(AG1、AG2)并且阻止经由S31将流量转发至AG1和AG2。此外,由于S21和S41中的每个均具有具有到AG1和AG2的最短路径的高优先级端口,所以网络元件S11、S21和S41不发送任何进一步的FRN。
在图6C的示例中,在从故障链路恢复之后(例如,在协议收敛之后),AG5中的网络节点可经由包括L31、S31、S21、S11和L11的路径将流量发送至AG1和AG2中的网络节点。如上所述,使用最短路径方法来消除这种路径。
在DagonFly Plus拓扑中,网络直径是3,其限制收敛时间。设R表示拓扑中(例如,图6A和图6B中)的交换机的基数。对于组内链路故障(例如,图6A),发送的FRN的总数被R/2*(R-1)进行上限。对于组间链路故障(例如,图6B),发送的FRN的总数被2*(R-1)进行上限。
从Xpander拓扑中的链路故障恢复
图7是示意性地示出了根据本文描述的实施例从具有Xpander拓扑的通信网络400中的链路故障恢复的方法的示图。
例如,由Valadarsky等人在2016年12月第205-219页中CoNEXT'16:第12届新兴网络实验与技术国际会议论文集“Xpander:迈向最优性能数据中心(Xpander:TowardsOptimal-Performance Datacenters)”描述了Xpander拓扑。
Xpander拓扑包括多个组404,该多个组包括使用链路412互连的网络元件408。每一组中的各网络元件与所有其他组中的各网络元件相连。在本示例中,Xpander拓扑包括表示为G1…G4的四个组,其中,第i个Gi组包括表示为Sij的网络元件,j=1…3。然而,在实际的Xpander网络中,也可以使用其他适当数量的组和每组的网络元件数量。
在通信网络400中,网络节点416耦合至网络元件408。在本示例中,每个网络元件408连接至两个网络节点416。然而,在其他实施例中,也可以使用每个网络元件的其他合适数量的网络节点。与普通网络元件相连的网络节点属于普通AG。例如,目的地地址属于AG1的网络节点416连接至S11。在图7的示例中,网络节点布置在表示为AG1…AG12的十二个AG中。
在图7的Xpander拓扑中,网络元件可以通过三条不相交路径将流量发送至另一网络元件。例如,考虑G4中的S43向S22发送流量。第一路径包括S43、S32和S22,第二路径包括S43、S23、S31、S12、S41和S22,第三路径包括S43、S13和S22。
考虑从S32到S22的链路发生故障的场景。这意味着由于链路故障,属于AG5的网络节点经由S32不可到达。假设使用以上图3的方法恢复链路故障,一旦检测到故障链路,作为发起方的S22将FRN(AG5)发送至其相邻者S13和S43。在接收到FRN(AG5)时,S13和S43中的每一个从其转发表(72)中排除将分组转发至S32的可能性。然而,S13和S43两者都具有到AG5的替代路径,并且因此不发送任何另外的FRN。
在一些实施例中,网络元件408的转发表被配置为仅经由具有一跳或两跳长度的路径将分组转发至最终网络元件。在此类实施例中,从S43到S22(在任何链路故障发生之前)的唯一有效路径是经由S32或经由S13。在这种情况下,在从S32接收到FRN(A5)之后,S43可以仅经由S13到达S22。
利用Xpander拓扑,在FRN传播的单跳之后,通知协议(例如,基于图3的方法)收敛。所发送的FRN的总数由(R-1)给出,其中R表示拓扑中的交换机的基数。
虽然在本节中描述的实施例主要解决Xpander拓扑,但是在图7中的方法也以类似方式适用于其他扩展器拓扑,例如,FlimFly和水母(Jellyfish)拓扑。例如,由Besta等人在2014年IEEE第348-359页中的SC”14:高性能计算、网络、存储和分析国际会议论文集,“Slimfly:低直径网络拓扑的成本效益(Slim fly:A cost efficient low-diameter networktopology)”中描述了SlimFly拓扑。例如,由Singla等人在2012年的第九届{USENIX}网络系统设计与实现研讨会({NSDI}12)第225-238页中“Jellyfish:随机联网数据中心(Jellyfish:Networking data centers randomly)”中描述了Jellyfish拓扑。
以上描述的实施例是通过示例给出的,并且还可以使用其他适合的实施例。
应当理解,上述实施例是以示例的方式引用的,并且所附权利要求不限于在上文中具体示出和描述的内容。相反,该范围包括上述各种特征的组合和子组合,以及本领域技术人员在阅读上述描述时将想到的并且在现有技术中未公开的其变化和修改。通过引用结合在本专利申请中的文献被认为是本申请的组成部分,除了在这些并入的文献中以与本说明书中明确或隐含的定义相冲突的方式定义任何术语的程度上,仅应当考虑本说明书中的定义。

Claims (12)

1.一种网络元件,包括:
多个端口,其用于使用链路连接至通信网络;以及
处理电路,其用于:
经由所述端口接收分组并且经由所述端口将所接收的分组转发到相应的目的地地址,其中所述目的地地址被组织在地址组中,每个地址组包括连接至所述通信网络中的公共网络元件的端节点的多个目的地地址;
经由给定端口接收报告一个或更多个地址组的通知,所述一个或更多个地址组由于另一网络元件中的链路故障而变得经由所述给定端口不可到达;以及
在确定所接收的通知中的经由所述网络元件的任何端口不可到达的一个或更多个地址组时,经由除了所述给定端口之外的一个或更多个端口传输报告所确定的地址组的输出通知,
其中所述处理电路还用于:针对给定地址组,将高优先级指派给具有到所述给定地址组的最短路径的端口,并且将低优先级指派给具有到所述给定地址组的非最短路径的端口,并且响应于接收到包括所述给定地址组的通知,仅经由针对所述给定地址组被指派了所述低优先级的端口发送报告所述给定地址组的对应的输出通知。
2.根据权利要求1所述的网络元件,其中所述处理电路用于在确定所述通知中的给定地址组经由替代路径可到达时,抑制在所述输出通知中包括所述给定地址组,并且经由所述替代路径转发寻址至所述给定地址组的后续接收的分组。
3.根据权利要求1所述的网络元件,其中所述处理电路用于响应于所述通知,抑制经由所述给定端口将要传送的分组转发至所确定的地址组。
4.根据权利要求1所述的网络元件,其中所述处理电路用于接收第一通知,随后是第二通知,其中,所述第一通知和所述第二通知两者均报告变得经由相应的第一端口和第二端口不可到达的给定地址组,并且响应于所述第一通知,在接收所述第二通知之前,经由所述第二端口发送报告所述给定地址组的输出通知。
5.根据权利要求1所述的网络元件,其中所述处理电路用于在所述输出通知中报告仅经由具有到相应地址组的非最短路径的端口可到达的地址组。
6.根据权利要求1所述的网络元件,其中,所述通信网络包括选自包括以下各项的拓扑的列表的拓扑:Fat-Tree拓扑、Clos拓扑、DragonFly Plus拓扑以及Xpander拓扑。
7.一种传播故障路由通知的方法,包括:
在包括用于使用链路连接至通信网络的多个端口的网络元件中,经由所述端口接收分组并且经由所述端口将所接收的分组转发到相应的目的地地址,其中所述目的地地址被组织在地址组中,每个地址组包括连接至所述通信网络中的公共网络元件的端节点的多个目的地地址;
经由给定端口接收通知,所述通知报告由于另一网络元件中的链路故障而变得经由所述给定端口不可到达的一个或更多个地址组;以及
在确定所接收的通知中的经由所述网络元件的任何端口不可到达的一个或更多个地址组时,经由除了所述给定端口之外的一个或更多个端口传输报告所确定的地址组的输出通知,
其中所述方法还包括:对于给定地址组,将高优先级指派给具有到所述给定地址组的最短路径的端口以及将低优先级指派给具有到所述给定地址组的非最短路径的端口,以及响应于接收到包括所述给定地址组的通知,仅经由针对所述给定地址组被指派了所述低优先级的端口发送报告所述给定地址组的对应的输出通知。
8.根据权利要求7所述的方法,并且包括:在确定所述通知中的给定地址组经由替代路径可到达时,抑制在所述输出通知中包括所述给定地址组,并且经由所述替代路径转发寻址到所述给定地址组的后续接收的分组。
9.根据权利要求7所述的方法,并且包括:响应于所述通知,抑制经由所述给定端口将要传送的分组转发至所确定的地址组。
10.根据权利要求7所述的方法,并且包括:接收第一通知,随后是第二通知,其中所述第一通知和所述第二通知两者均报告变得经由相应的第一端口和第二端口不可到达的给定地址组,并且响应于所述第一通知,在接收所述第二通知之前,经由所述第二端口发送报告所述给定地址组的输出通知。
11.根据权利要求7所述的方法,并且包括:在所述输出通知中报告仅经由具有到相应地址组的非最短路径的端口可到达的地址组。
12.根据权利要求7所述的方法,其中,所述通信网络包括选自包括以下各项的拓扑的列表的拓扑:Fat-Tree拓扑、Clos拓扑、DragonFly Plus拓扑以及Xpander拓扑。
CN202210231271.2A 2021-03-25 2022-03-10 故障路由通知的有效传播 Active CN115208746B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/211,904 US11552882B2 (en) 2021-03-25 2021-03-25 Efficient propagation of fault routing notifications
US17/211,904 2021-03-25

Publications (2)

Publication Number Publication Date
CN115208746A CN115208746A (zh) 2022-10-18
CN115208746B true CN115208746B (zh) 2024-05-24

Family

ID=83192529

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210231271.2A Active CN115208746B (zh) 2021-03-25 2022-03-10 故障路由通知的有效传播

Country Status (3)

Country Link
US (1) US11552882B2 (zh)
CN (1) CN115208746B (zh)
DE (1) DE102022202781A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116055382A (zh) * 2022-11-22 2023-05-02 浪潮思科网络科技有限公司 一种组网的网络收敛方法、装置、设备及介质
WO2024183885A1 (en) * 2023-03-07 2024-09-12 Huawei Technologies Co., Ltd. Fault restoration in fat-tree based networks
CN117938743B (zh) * 2024-01-23 2024-09-10 无锡众星微系统技术有限公司 一种基于胖树拓扑的数据中心网络链路恢复方法和装置

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101953124A (zh) * 2008-02-15 2011-01-19 思科技术公司 在数据通信网络中构造绕过多条不可用链路的修复路径
CN102118317A (zh) * 2011-03-24 2011-07-06 北京星网锐捷网络技术有限公司 一种虚链路地址的选择方法、装置及网络设备
CN102387077A (zh) * 2011-10-19 2012-03-21 西安电子科技大学 具有容错功能的热量均衡片上网络路径选择方法
CN102629912A (zh) * 2012-03-27 2012-08-08 中国人民解放军国防科学技术大学 面向无缓冲片上网络的容错偏转路由方法及装置
CN103155485A (zh) * 2010-09-29 2013-06-12 瑞典爱立信有限公司 基于快速洪泛的快速收敛以从网络故障恢复
CN104158738A (zh) * 2014-08-29 2014-11-19 中国航空无线电电子研究所 一种低缓冲区片上网络路由器及路由方法
US9544185B1 (en) * 2013-11-05 2017-01-10 Cisco Technology, Inc. Hardware based fast convergence for network failures
CN107104903A (zh) * 2012-12-14 2017-08-29 英特尔公司 通过分组循环进行网络拥塞管理
CN107547159A (zh) * 2016-06-28 2018-01-05 华为技术有限公司 一种时钟跟踪路径的规划方法及管理设备
CN109391543A (zh) * 2017-08-02 2019-02-26 中国电信股份有限公司 用于多业务故障恢复的方法和系统、业务恢复辅助系统

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7180857B2 (en) * 2000-11-24 2007-02-20 Matsushita Electric Industrial Co., Ltd Apparatus and method for flow control
US7085224B1 (en) * 2001-06-14 2006-08-01 Cisco Technology, Inc. Method and apparatus for fast failure detection in switched LAN networks
US7103008B2 (en) * 2001-07-02 2006-09-05 Conexant, Inc. Communications system using rings architecture
JP4544415B2 (ja) * 2004-12-22 2010-09-15 日本電気株式会社 中継ネットワークシステム、ノード装置、および障害通知方法
JP4681049B2 (ja) 2005-06-14 2011-05-11 テレフオンアクチーボラゲット エル エム エリクソン(パブル) ネットワークにおける障害処理のための方法および装置
IL176330A0 (en) * 2006-06-15 2007-07-04 Eci Telecom Ltd Technique of traffic protection loop-free interconnection for ethernet and/or vpls networks
EP2277289A1 (en) 2008-05-12 2011-01-26 Telefonaktiebolaget L M Ericsson (PUBL) Re-routing traffic in a communications network
US8923112B2 (en) 2009-10-02 2014-12-30 Telefonaktiebolaget L M Ericsson (Publ) Technique for controlling data forwarding in computer networks
US8619546B2 (en) 2010-08-17 2013-12-31 Alcatel Lucent Method and apparatus for coping with link failures in central control plane architectures
CN103036794A (zh) * 2011-10-10 2013-04-10 华为技术有限公司 一种报文的学习方法、装置和系统
US9014006B2 (en) 2013-01-31 2015-04-21 Mellanox Technologies Ltd. Adaptive routing using inter-switch notifications
US9729473B2 (en) 2014-06-23 2017-08-08 Mellanox Technologies, Ltd. Network high availability using temporary re-routing
CN105871674B (zh) * 2015-01-23 2019-10-22 华为技术有限公司 环保护链路故障保护方法、设备及系统
US10819621B2 (en) 2016-02-23 2020-10-27 Mellanox Technologies Tlv Ltd. Unicast forwarding of adaptive-routing notifications

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101953124A (zh) * 2008-02-15 2011-01-19 思科技术公司 在数据通信网络中构造绕过多条不可用链路的修复路径
CN103155485A (zh) * 2010-09-29 2013-06-12 瑞典爱立信有限公司 基于快速洪泛的快速收敛以从网络故障恢复
CN102118317A (zh) * 2011-03-24 2011-07-06 北京星网锐捷网络技术有限公司 一种虚链路地址的选择方法、装置及网络设备
CN102387077A (zh) * 2011-10-19 2012-03-21 西安电子科技大学 具有容错功能的热量均衡片上网络路径选择方法
CN102629912A (zh) * 2012-03-27 2012-08-08 中国人民解放军国防科学技术大学 面向无缓冲片上网络的容错偏转路由方法及装置
CN107104903A (zh) * 2012-12-14 2017-08-29 英特尔公司 通过分组循环进行网络拥塞管理
US9544185B1 (en) * 2013-11-05 2017-01-10 Cisco Technology, Inc. Hardware based fast convergence for network failures
CN104158738A (zh) * 2014-08-29 2014-11-19 中国航空无线电电子研究所 一种低缓冲区片上网络路由器及路由方法
CN107547159A (zh) * 2016-06-28 2018-01-05 华为技术有限公司 一种时钟跟踪路径的规划方法及管理设备
CN109391543A (zh) * 2017-08-02 2019-02-26 中国电信股份有限公司 用于多业务故障恢复的方法和系统、业务恢复辅助系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
基于OpenFlow的路由机制的研究;邱翔;;电子设计工程;20170220(04);全文 *
基于OSPF的保护隧道实现研究;杨思杰;徐明伟;王文东;;微计算机应用(01);全文 *
网络通信中动态路由协议的应用和漏洞的防范措施;王冶;;硅谷(22);全文 *

Also Published As

Publication number Publication date
CN115208746A (zh) 2022-10-18
US20220311702A1 (en) 2022-09-29
DE102022202781A1 (de) 2022-09-29
US11552882B2 (en) 2023-01-10

Similar Documents

Publication Publication Date Title
CN115208746B (zh) 故障路由通知的有效传播
JP3739798B2 (ja) ダイナミックなネットワークトポロジー探査のシステム及び方法
JP4060378B2 (ja) 多層分散ネットワーク要素
US7359383B2 (en) Load balancing with mesh tagging
US20050044211A1 (en) Self-healing tree network
CN114257540B (zh) 使用绕行路径解决本地链路故障的无死锁重新路由
JP2002507364A (ja) 多層分散ネットワーク要素におけるパケット・フィールド置換のための機構
US6343330B1 (en) Arrangement for preventing looping of explorer frames in a transparent bridging domain having multiple entry points
US7477612B2 (en) Topology discovery process and mechanism for a network of managed devices
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands
Cisco Novell IPX Commands

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