CN1949740A - 针对bgp负载分担中路由下一跳变化的处理方法 - Google Patents
针对bgp负载分担中路由下一跳变化的处理方法 Download PDFInfo
- Publication number
- CN1949740A CN1949740A CNA2005101125838A CN200510112583A CN1949740A CN 1949740 A CN1949740 A CN 1949740A CN A2005101125838 A CNA2005101125838 A CN A2005101125838A CN 200510112583 A CN200510112583 A CN 200510112583A CN 1949740 A CN1949740 A CN 1949740A
- Authority
- CN
- China
- Prior art keywords
- message
- bgp
- route
- next hop
- changes
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/033—Topology update or discovery by updating distance vector protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种针对BGP负载分担中路由下一跳变化的处理方法。本发明主要包括:首先,当基于边界网关协议BGP负载分担的系统中下一跳发生变化时,将变化前、后的下一跳信息承载于更新报文中发送;之后,接收所述更新报文的BGP邻居实体根据报文中承载的变化前、后的下一跳信息进行一下跳路由信息的更新。在BGP向邻居发送多条到达相同目的地址的路由情况下,当下一跳路由发生变化时,采用本发明提供的方法可以快速准确地实现下一跳路由信息的更新,有效提高了路由更新效率。
Description
技术领域
本发明涉及网络通信技术领域,尤其涉及一种针对BGP负载分担中路由下一跳变化的处理方法。
背景技术
BGP(边界网关协议)是一种自治系统间的动态路由发现协议,其基本功能是在自治系统间自动交换无环路的路由信息。与OSPF(开放最短路径优先)和RIP(路由信息协议)等在自治区域内部运行的协议对应,BGP是一类EGP(Edge Gateway Protocol,边缘网关协议)协议,而OSPF和RIP等为IGP(Interior Gateway Protocol,内部网关协议)。
BGP连接有两种类型,具体为:IBGP(Internal BGP,内部BGP)和EBGP(External BGP,外部BGP)。在同一AS(自治区域)中建立的BGP连接称为IBGP,不同AS自治区域间的BGP连接为EBGP连接。
BGP在现有的协议中规定:在向邻居发送路由信息时,当相同目的地址存在有多条路由时,仅选择一条最优的路由发送,其余路由则不发送。但是,在一些如实现负载分担功能等情况下,为实现相应的功能,BGP需要发送多条路由信息。这就要求BGP在选路规则中,在选择最优路径上放宽选路条件,当有多条路由满足条件时,则将所有路由发送到对端。
例如,如图1所示,CE(客户端)用户路由器RTA通过路由器RTB和RTC接入运营商骨干网,为减少BGP邻居数量,骨干网中有一台RR(BGP路由反射器)路由器配置为反射器,图1中的RTB,RTC,RTD都是这个反射器的客户端,此时,各客户端之间,如RTB和RTD,RTC与RTD之间不再需要配置BGP邻居关系。
另外,在接入端,用户为了网络健壮性,一般要与骨干网建立两条路径,接入到不同的骨干网路由器中,以提供冗余备份。当然,在网络稳定的前提下,用户还希望两条链路同时负责业务的传输,以实现负载分担。
根据BGP协议可知,虽然其在通告路由可达时,提供路由的下一跳信息,但是由于当前BGP协议实现上的一个重要约束:协议在撤销路由的报文中不含有下一跳信息,只有地址前缀信息。因此,为使BGP邻居间可发送多条目的地址相同的路由,提供的如下的具体实现方案:
首先,BGP邻居在发送路由时将所有满足一定条件到达同一目的地址的路由发送到对端;
之后,当撤销路由时,报文中Withdrawn Routes(撤销路由)字段里增加下一跳信息,并通过BGP能力协商机制,增加一种能力通告,使协议做到向后兼容;
最后,当路由器收到带有下一跳信息的撤销通告消息时,则根据下一跳信息删除相应路由。
因此,当建立BGP邻居时,根据上述处理方案,接收端邻居向发送多条路由的一方通告能够处理带下一跳的withdrown路由。这样,在撤销路由时,在报文中增加指定撤销路由的下一跳来明确指定所要撤销的路由。
可以看出,当被发送的这些路由中的某个下一跳发生变化时,仅按照上述方案发送撤销消息,却并没有提供相应的更新处理过程,即目前无法针对存在多条路由的情况下的其中一个下一跳发生变化进行路由更新处理。
发明内容
本发明的目的是提供一种针对BGP负载分担中路由下一跳变化的处理方法,从而可以有效提高路由变化时的路由更新处理效率。
本发明的目的是通过以下技术方案实现的:
本发明提供了一种针对BGP负载分担中路由下一跳变化的处理方法,包括:
A、当基于边界网关协议BGP负载分担的系统中下一跳发生变化时,将变化前、后的下一跳信息承载于更新报文中发送;
B、接收所述更新报文的BGP邻居实体根据报文中承载的变化前、后的下一跳信息进行一下跳路由信息的更新。
所述的更新报文包括:
基于第四版IP协议IPv4或第六版IP协议IPv6,网络报文交换协议IPX,IPv4虚拟专网VPN-IPv4地址族的更新报文。
所述的步骤A包括:
当下一跳发生变化时,在BGP的更新报文中指示变化后的下一跳信息长度值及具体的下一跳信息,并在所述更新报文中还指示变化前的下一跳信息长度值及具体的下一跳信息。
所述的步骤B包括:
接收端接收所述的更新报文后,利用报文中描述的变化前的下一跳信息和地址前缀作为索引,查找路由表中相应的路由,并进行对应下一跳路由信息的更新。
所述的步骤B具体包括:
当接收端接收到所述的更新报文后,若确定报文中的多协议网络层不可达信息MP_UNREACH_NLRI属性字段中包含下一跳信息,则将该下一跳信息和MP_REACH_NLRI中的地址信息作为索引查找路由表,并更新相应的下一跳路由信息。
本发明中,对于基于IPv4的更新报文,所述的步骤B具体包括:
当接收端接收到所述的更新报文后,根据报文中的下一跳Next Hop字段中包含变化前下一跳信息,以及地址前缀查找路由表,并将相应的下一跳路由信息更新为路径属性Path Attribute中描述的下一跳。
本发明中,在执行所述的步骤A之前还包括:
通过BGP能力协商过程确定对端实体能够识别步骤A所述的更新报文后,执行所述的步骤A。
由上述本发明提供的技术方案可以看出,本发明提供的处理方法可以解决在BGP向邻居发送多条到达相同目的地址的路由情况下,当下一跳路由发生变化时的路由更新问题。而且,本发明提供的解决方法可以准确地更新发生变化的下一跳信息,有效提高了上述情况下的路由更新效率。
附图说明
图1为BGP网络结构示意图;
图2为本发明所述的方法的流程图。
具体实施方式
本发明的目的是为了完善BGP发多条路由特性上在下一跳变化时,仅发送一次报文给邻居实体便可以实现相应的处理。
下面首先对本发明在实现过程中的主要处理进行说明。
本发明中,当下一跳路由发生变化时,则通过在BGP的update(更新)报文中增加路由变化前的下一跳信息进行相应的更新处理。接收端处理下一跳变化的更新报文时,则根据变化前的下一跳和路由地址前缀为索引查找路由表,并根据变化后的下一跳信息进行更新处理。
为对本发明有进一步的理解,下面将对本发明进行详细的说明。
本发明提供的方法适用于各类地址族的下一跳变化的路由更新处理,如IPv4、IPV6、IPX(网络报文交换协议)、VPN-IPv4(IPv4虚拟专网)等。
多协议地址族的路由可达信息和不可达信息具体通过两个新增属性通告:MP_REACH_NLRI通告地址可达信息和MP_UNREACH_NLRI通告地址不可达信息,下面将分别对两通告报文格式进行说明。
其中,MP_REACH_NLRI通告报文的格式如表1所示:
表1
+---------------------------------------------------------+
|Address Family Identifier(2octets) |
+---------------------------------------------------------+
|Subsequent Address Family Identifier(1octet) |
+---------------------------------------------------------+
|Length of Next Hop Network Address(1octet) |
+---------------------------------------------------------+
|Network Address of Next Hop(variable) |
+---------------------------------------------------------+
|Number of SNPAs(1octet) |
+---------------------------------------------------------+
|Length of first SNPA(1octet) |
+---------------------------------------------------------+
|First SNPA(variable) |
+---------------------------------------------------------+
|Length of second SNPA(1octet) |
+---------------------------------------------------------+
|Second SNPA(variable) |
+---------------------------------------------------------+
|... |
+---------------------------------------------------------+
|Length of Last SNPA(1octet) |
+---------------------------------------------------------+
|Last SNPA(variable) |
+---------------------------------------------------------+
|Network Layer Reachability Information(variable) |
+---------------------------------------------------------+
|Length of Last SNPA(1octet) |
+---------------------------------------------------------+
|Last SNPA(variable) |
+---------------------------------------------------------+
|Network Layer Reachability Information(variable) |
+---------------------------------------------------------+
所述的MP_UNREACH_NLRI通告报文的格式如表2所示:
表2
+---------------------------------------------------------+
|Address Family Identifier(2octets) |
+---------------------------------------------------------+
|Subsequent Address Family Identifier(1octet) |
+---------------------------------------------------------+
|Withdrawn Routes(variable) |
+---------------------------------------------------------+
因此,当相应地址族的下一跳路由发生变化时,MP_UNREACH_NLRI(不可达的多协议NLRI)属性字段内容格式更改如表3所示:
表3
Address Family Identifier(2octets)-地址族标识 |
Subsequent Address Family Identifier(1octet)-子地址族标识 |
Length of Next Hop Network Address(1octet)-下一跳网络地址长度 |
Network Address of Next Hop(variable)-下一跳网络地址 |
与原有的MP_UNREACH_NLRI字段内容相比,表3所示的属性字段中只包含了下一跳变化前的地址信息,而不包含withdrawn routes信息,同时在该报文中还将有MP_REACH_NLRI(可达的多协议NRLI)字段,内容与协议相比不变,其中的下一跳为变化后的地址。
这样,当确定下一跳路由发生变化的一端实体发送包含表3所示内容信息的更新报文后,接收端接收并解析所述报文时,便可以发现在所述更新报文中的MP_UNREACH_NLRI属性字段中只包含下一跳信息,则以该下一跳和MP_REACH_NLRI属性字段中的地址信息(地址前缀信息)作为索引,查找路由表,将其下一跳改为更新后的下一跳,即MP_REACH_NLRI属性字段中承载的变化后的下一跳地址信息。
下面再结合附图,以基于IPv4地址的报文进行路由更新的过程对本发明所述的方法的具体实现方式进行说明。
如图2所示,本发明所述的方法具体包括以下处理步骤:
步骤21:在BGP向邻居发送多条到达相同目的地址的路由情况下,确定下一跳路由发生变化;
具体确定下一跳路由发生的方法可以是采用已有的故障检测机制、路由发现机制等等,本发明不关注,故不详述;
步骤21:确定下一跳路由发生变化的一端实体构造包含变化前及变化后的下一跳信息的报文,并发送给对端实体;
当向对端发送多条到达同一目的地址的路由,且其中一条下一跳路由发生变化时,为提高路由更新的效率,本发明中采用仅发送一次update(更新)报文的方式实现;
所述的update报文构成除了包括普通update内容外,增加UnfeasibleRoutes Length(不可靠路由器长度)和Next Hop(下一跳)字段,但不包含Withdrawn Routes(撤销路由)字段;
所述的update报文中承载变化前、后下一跳信息的格式如表4所示:
表4
Unfeasible Routes Length(2octets)-不可靠路由器长度 |
Next Hop(variable)-下一跳 |
Total Path Attribute Length(2octets)-总计路径属性长度 |
Path Attributes(variable)-路径属性 |
Network Layer Reachability Information(variable)-即NLRI,网络层可达性信息 |
上述报文格式不同现有协议的格式之处在于,通过该特性的能力协商后,针对下一跳变化的路由,Unfeasible Routes Length字段后面跟随的是首先是Next Hop,而不包括要撤销的路由(即Withdrawn Routes字段)。NextHop字段中的下一跳含义代表变化前的下一跳地址,在Path Attributes中包含的下一跳信息是变化后的下一跳。
步骤23:接收端接收所述的update报文并解析获得其中承载的变化前、后下一跳路由信息;
步骤24:利用所述的变化前的下一跳路由信息作为索引查找路由表确定发生路由变化并需要更新的路由表项;
步骤25:利用所述的变化后的下一跳路由信息更新所述的需要更新的路由表项,实现发生变化的下一跳路由信息的更新。
总之,当某条路由的下一跳发生变化时,报文构成按表4所示,与原有的撤销路由的报文相比,报文中将不再包括Withdrawn Routes字段,但是还需要包括Path Attributes和NLRI字段。接收处理该报文时,根据UnfeasibleRoutes Length的值可以判断该字段后面只有下一跳信息,而没有待撤销的路由前缀。根据Next Hop和NLRI中地址前缀索引在本端路由表中寻找路由,将该路由的下一跳改为Path Attributes中的下一跳,完成对下一跳变化的处理。
另外,在本发明中,在邻居之间协商了能力建立邻居后的撤销路由处理过程中,仍可以基于现有技术的方式进行路由的撤销处理,具体为:
发送撤销路由报文中必须在Unfeasible Routes Length字段后面跟随NextHop,接收端在接收、解析报文时,默认Unfeasible Routes Length后面跟随的是Next Hop字段,以该下一跳和Withdrawn Routes字段内的路由地址前缀作为双重索引,查找待撤销的路由。
综上所述,本发明的实现很好地完善了BGP向邻居发送多条到达相同目的地址的路由情况下,当路由下一跳发生变化时的处理过程,从而有效提高了相应的处理过程的效率。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。
Claims (7)
1、一种针对BGP负载分担中路由下一跳变化的处理方法,其特征在于,包括:
A、当基于边界网关协议BGP负载分担的系统中下一跳发生变化时,将变化前、后的下一跳信息承载于更新报文中发送;
B、接收所述更新报文的BGP邻居实体根据报文中承载的变化前、后的下一跳信息进行一下跳路由信息的更新。
2、根据权利要求1所述的针对BGP负载分担中路由下一跳变化的处理方法,其特征在于,所述的更新报文包括:
基于第四版IP协议IPv4或第六版IP协议IPv6,网络报文交换协议IPX,IPv4虚拟专网VPN-IPv4地址族的更新报文。
3、根据权利要求1所述的针对BGP负载分担中路由下一跳变化的处理方法,其特征在于,所述的步骤A包括:
当下一跳发生变化时,在BGP的更新报文中指示变化后的下一跳信息长度值及具体的下一跳信息,并在所述更新报文中还指示变化前的下一跳信息长度值及具体的下一跳信息。
4、根据权利要求1、2或3所述的针对BGP负载分担中路由下一跳变化的处理方法,其特征在于,所述的步骤B包括:
接收端接收所述的更新报文后,利用报文中描述的变化前的下一跳信息和地址前缀作为索引,查找路由表中相应的路由,并进行对应下一跳路由信息的更新。
5、根据权利要求要求4所述的针对BGP负载分担中路由下一跳变化的处理方法,其特征在于,所述的步骤B具体包括:
当接收端接收到所述的更新报文后,若确定报文中的多协议网络层不可达信息MP_UNREACH_NLRI属性字段中包含下一跳信息,则将该下一跳信息和MP_REACH_NLRI中的地址信息作为索引查找路由表,并更新相应的下一跳路由信息。
6、根据权利要求要求4所述的针对BGP负载分担中路由下一跳变化的处理方法,其特征在于,对于基于IPv4的更新报文,所述的步骤B具体包括:
当接收端接收到所述的更新报文后,根据报文中的下一跳Next Hop字段中包含变化前下一跳信息,以及地址前缀查找路由表,并将相应的下一跳路由信息更新为路径属性Path Attribute中描述的下一跳。
7、根据权利要求1、2或3所述的针对BGP负载分担中路由下一跳变化的处理方法,其特征在于,在执行所述的步骤A之前还包括:
通过BGP能力协商过程确定对端实体能够识别步骤A所述的更新报文后,执行所述的步骤A。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2005101125838A CN1949740A (zh) | 2005-10-11 | 2005-10-11 | 针对bgp负载分担中路由下一跳变化的处理方法 |
PCT/CN2006/002270 WO2007041926A1 (en) | 2005-10-11 | 2006-09-04 | A method and network appratus for processing the bgp route’s next hop change |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2005101125838A CN1949740A (zh) | 2005-10-11 | 2005-10-11 | 针对bgp负载分担中路由下一跳变化的处理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1949740A true CN1949740A (zh) | 2007-04-18 |
Family
ID=37942300
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2005101125838A Pending CN1949740A (zh) | 2005-10-11 | 2005-10-11 | 针对bgp负载分担中路由下一跳变化的处理方法 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN1949740A (zh) |
WO (1) | WO2007041926A1 (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012058990A1 (zh) * | 2010-11-03 | 2012-05-10 | 中兴通讯股份有限公司 | 一种组播方法及装置 |
CN102833172A (zh) * | 2012-09-12 | 2012-12-19 | 杭州华三通信技术有限公司 | 路由处理方法及路由转发设备 |
CN102891799A (zh) * | 2011-07-22 | 2013-01-23 | 华为技术有限公司 | 一种选择路由的方法及设备 |
CN104394079A (zh) * | 2014-11-26 | 2015-03-04 | 迈普通信技术股份有限公司 | 一种基于边界网关协议的下一跳路由检测方法及装置 |
CN104506440A (zh) * | 2014-12-26 | 2015-04-08 | 成都致云科技有限公司 | 路由器的数据包发送方法和路由表修改方法 |
CN106059924A (zh) * | 2016-08-19 | 2016-10-26 | 华为技术有限公司 | 一种管理信息的方法,装置及系统 |
CN106878186A (zh) * | 2017-02-04 | 2017-06-20 | 华为技术有限公司 | 网络中路由更新的方法、网络设备和系统 |
CN107317751A (zh) * | 2016-04-26 | 2017-11-03 | 瞻博网络公司 | 使用IPv4映射的IPv6地址的出口对等工程 |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9923799B2 (en) | 2014-04-25 | 2018-03-20 | Metaswitch Networks Ltd. | Data processing |
US10063456B2 (en) | 2014-04-25 | 2018-08-28 | Metaswitch Networks Ltd | Data processing |
US9871717B2 (en) | 2014-04-25 | 2018-01-16 | Metaswitch Networks Ltd | Data processing |
CN114697251A (zh) * | 2020-12-28 | 2022-07-01 | 华为技术有限公司 | 一种路由处理方法、相关装置以及网络系统 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4044007B2 (ja) * | 2003-06-27 | 2008-02-06 | 古河電気工業株式会社 | 経路情報管理方法および経路情報管理装置 |
JP4231766B2 (ja) * | 2003-10-24 | 2009-03-04 | 株式会社日立コミュニケーションテクノロジー | As間の経路制御を行う通信装置および通信方法。 |
US8190772B2 (en) * | 2003-12-29 | 2012-05-29 | Nortel Networks Limited | Apparatus and method for layer-2 and layer-3 VPN discovery |
-
2005
- 2005-10-11 CN CNA2005101125838A patent/CN1949740A/zh active Pending
-
2006
- 2006-09-04 WO PCT/CN2006/002270 patent/WO2007041926A1/zh active Application Filing
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012058990A1 (zh) * | 2010-11-03 | 2012-05-10 | 中兴通讯股份有限公司 | 一种组播方法及装置 |
CN102891799A (zh) * | 2011-07-22 | 2013-01-23 | 华为技术有限公司 | 一种选择路由的方法及设备 |
CN102891799B (zh) * | 2011-07-22 | 2017-04-12 | 华为技术有限公司 | 一种选择路由的方法及设备 |
CN102833172A (zh) * | 2012-09-12 | 2012-12-19 | 杭州华三通信技术有限公司 | 路由处理方法及路由转发设备 |
CN102833172B (zh) * | 2012-09-12 | 2015-10-21 | 杭州华三通信技术有限公司 | 路由处理方法及路由转发设备 |
CN104394079B (zh) * | 2014-11-26 | 2017-07-04 | 迈普通信技术股份有限公司 | 一种基于边界网关协议的下一跳路由检测方法及装置 |
CN104394079A (zh) * | 2014-11-26 | 2015-03-04 | 迈普通信技术股份有限公司 | 一种基于边界网关协议的下一跳路由检测方法及装置 |
CN104506440A (zh) * | 2014-12-26 | 2015-04-08 | 成都致云科技有限公司 | 路由器的数据包发送方法和路由表修改方法 |
CN104506440B (zh) * | 2014-12-26 | 2017-12-26 | 成都致云科技有限公司 | 路由器的数据包发送方法和路由表修改方法 |
CN107317751A (zh) * | 2016-04-26 | 2017-11-03 | 瞻博网络公司 | 使用IPv4映射的IPv6地址的出口对等工程 |
CN107317751B (zh) * | 2016-04-26 | 2020-07-24 | 瞻博网络公司 | 用于提供路由的设备和方法 |
CN106059924A (zh) * | 2016-08-19 | 2016-10-26 | 华为技术有限公司 | 一种管理信息的方法,装置及系统 |
WO2018032961A1 (zh) * | 2016-08-19 | 2018-02-22 | 华为技术有限公司 | 一种管理信息的方法,装置及系统 |
US20190182145A1 (en) * | 2016-08-19 | 2019-06-13 | Huawei Technologies Co., Ltd. | Information Management Method, Apparatus, and System |
CN106059924B (zh) * | 2016-08-19 | 2020-04-03 | 华为技术有限公司 | 一种管理信息的方法,装置及系统 |
US11855877B2 (en) | 2016-08-19 | 2023-12-26 | Huawei Technologies Co., Ltd. | Information management method, apparatus, and system |
CN106878186A (zh) * | 2017-02-04 | 2017-06-20 | 华为技术有限公司 | 网络中路由更新的方法、网络设备和系统 |
WO2018141215A1 (zh) * | 2017-02-04 | 2018-08-09 | 华为技术有限公司 | 网络中路由更新的方法、网络设备和系统 |
CN106878186B (zh) * | 2017-02-04 | 2019-11-29 | 华为技术有限公司 | 网络中路由更新的方法、网络设备和系统 |
US10892982B2 (en) | 2017-02-04 | 2021-01-12 | Huawei Technologies Co., Ltd. | Method for updating route in network, network device, and system |
US11411858B2 (en) | 2017-02-04 | 2022-08-09 | Huawei Technologies Co., Ltd. | Method for updating route in network, network device, and system |
Also Published As
Publication number | Publication date |
---|---|
WO2007041926A1 (en) | 2007-04-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1949740A (zh) | 针对bgp负载分担中路由下一跳变化的处理方法 | |
US6295296B1 (en) | Use of a single data structure for label forwarding and imposition | |
US5991300A (en) | Technique for efficiently performing optional TTL propagation during label imposition | |
EP1344152B1 (en) | Apparatus and method for performing high-speed ip route lookup and managing routing/forwarding tables | |
US7885268B2 (en) | Method and system for hash table based routing via table and prefix aggregation | |
US7885294B2 (en) | Signaling compression information using routing protocols | |
Ogier et al. | Mobile ad hoc network (MANET) extension of OSPF using connected dominating set (CDS) flooding | |
EP1913731B1 (en) | Method and apparatus for enabling routing of label switched data packets | |
CN1852214A (zh) | 一种虚拟专用网络的路由方法 | |
US20070030852A1 (en) | Method and apparatus for enabling routing of label switched data packets | |
CN1848792A (zh) | 跨混合网络的多协议标签交换虚拟专用网的实现方法 | |
CN101047651A (zh) | 设置ip优先级的方法、系统和设备 | |
EP2254285A1 (en) | Network route establishing and data transmitting method and network node | |
US20100208744A1 (en) | System and method for compressing internet protocol rounting tables | |
CN1496154A (zh) | 移动通信控制系统、移动通信控制方法、路由器、服务器以及数据结构 | |
CN1893419A (zh) | 一种路由更新方法 | |
CN1744563A (zh) | 在以太网交换机上实现策略路由的方法 | |
WO2017198131A1 (zh) | 用于重定向数据流的方法和系统、网络设备和控制设备 | |
US7940668B2 (en) | Method and apparatus to enable an IPe domain through EIGRP | |
CN1855872A (zh) | 跨不同自治系统的混合网络vpn站点间的通信方法和系统 | |
CN1801783A (zh) | 一种基于ip/mpls/bgp的多域组播一体化数据分发结构及方法 | |
CN1503539A (zh) | 在IPv6中使用接口标识符的路由选择表管理方法 | |
US20220286383A1 (en) | Method and Apparatus for Processing Forwarding Entry | |
CN1741500A (zh) | 一种可路由的虚交换方法 | |
CN101047625A (zh) | 一种策略路由装置和方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20070418 |