專利名稱：針對(duì)bgp負(fù)載分擔(dān)中路由下一跳變化的處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，尤其涉及一種針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法。
背景技術(shù)：
BGP(邊界網(wǎng)關(guān)協(xié)議)是一種自治系統(tǒng)間的動(dòng)態(tài)路由發(fā)現(xiàn)協(xié)議，其基本功能是在自治系統(tǒng)間自動(dòng)交換無環(huán)路的路由信息。與OSPF(開放最短路徑優(yōu)先)和RIP(路由信息協(xié)議)等在自治區(qū)域內(nèi)部運(yùn)行的協(xié)議對(duì)應(yīng)，BGP是一類EGP(Edge Gateway Protocol，邊緣網(wǎng)關(guān)協(xié)議)協(xié)議，而OSPF和RIP等為IGP(Interior Gateway Protocol，內(nèi)部網(wǎng)關(guān)協(xié)議)。
BGP連接有兩種類型，具體為IBGP(Internal BGP，內(nèi)部BGP)和EBGP(External BGP，外部BGP)。在同一AS(自治區(qū)域)中建立的BGP連接稱為IBGP，不同AS自治區(qū)域間的BGP連接為EBGP連接。
BGP在現(xiàn)有的協(xié)議中規(guī)定在向鄰居發(fā)送路由信息時(shí)，當(dāng)相同目的地址存在有多條路由時(shí)，僅選擇一條最優(yōu)的路由發(fā)送，其余路由則不發(fā)送。但是，在一些如實(shí)現(xiàn)負(fù)載分擔(dān)功能等情況下，為實(shí)現(xiàn)相應(yīng)的功能，BGP需要發(fā)送多條路由信息。這就要求BGP在選路規(guī)則中，在選擇最優(yōu)路徑上放寬選路條件，當(dāng)有多條路由滿足條件時(shí)，則將所有路由發(fā)送到對(duì)端。
例如，如圖1所示，CE(客戶端)用戶路由器RTA通過路由器RTB和RTC接入運(yùn)營(yíng)商骨干網(wǎng)，為減少BGP鄰居數(shù)量，骨干網(wǎng)中有一臺(tái)RR(BGP路由反射器)路由器配置為反射器，圖1中的RTB，RTC，RTD都是這個(gè)反射器的客戶端，此時(shí)，各客戶端之間，如RTB和RTD，RTC與RTD之間不再需要配置BGP鄰居關(guān)系。
另外，在接入端，用戶為了網(wǎng)絡(luò)健壯性，一般要與骨干網(wǎng)建立兩條路徑，接入到不同的骨干網(wǎng)路由器中，以提供冗余備份。當(dāng)然，在網(wǎng)絡(luò)穩(wěn)定的前提下，用戶還希望兩條鏈路同時(shí)負(fù)責(zé)業(yè)務(wù)的傳輸，以實(shí)現(xiàn)負(fù)載分擔(dān)。
根據(jù)BGP協(xié)議可知，雖然其在通告路由可達(dá)時(shí)，提供路由的下一跳信息，但是由于當(dāng)前BGP協(xié)議實(shí)現(xiàn)上的一個(gè)重要約束協(xié)議在撤銷路由的報(bào)文中不含有下一跳信息，只有地址前綴信息。因此，為使BGP鄰居間可發(fā)送多條目的地址相同的路由，提供的如下的具體實(shí)現(xiàn)方案首先，BGP鄰居在發(fā)送路由時(shí)將所有滿足一定條件到達(dá)同一目的地址的路由發(fā)送到對(duì)端；之后，當(dāng)撤銷路由時(shí)，報(bào)文中Withdrawn Routes(撤銷路由)字段里增加下一跳信息，并通過BGP能力協(xié)商機(jī)制，增加一種能力通告，使協(xié)議做到向后兼容；最后，當(dāng)路由器收到帶有下一跳信息的撤銷通告消息時(shí)，則根據(jù)下一跳信息刪除相應(yīng)路由。
因此，當(dāng)建立BGP鄰居時(shí)，根據(jù)上述處理方案，接收端鄰居向發(fā)送多條路由的一方通告能夠處理帶下一跳的withdrown路由。這樣，在撤銷路由時(shí)，在報(bào)文中增加指定撤銷路由的下一跳來明確指定所要撤銷的路由。
可以看出，當(dāng)被發(fā)送的這些路由中的某個(gè)下一跳發(fā)生變化時(shí)，僅按照上述方案發(fā)送撤銷消息，卻并沒有提供相應(yīng)的更新處理過程，即目前無法針對(duì)存在多條路由的情況下的其中一個(gè)下一跳發(fā)生變化進(jìn)行路由更新處理。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法，從而可以有效提高路由變化時(shí)的路由更新處理效率。
本發(fā)明的目的是通過以下技術(shù)方案實(shí)現(xiàn)的本發(fā)明提供了一種針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法，包括A、當(dāng)基于邊界網(wǎng)關(guān)協(xié)議BGP負(fù)載分擔(dān)的系統(tǒng)中下一跳發(fā)生變化時(shí)，將變化前、后的下一跳信息承載于更新報(bào)文中發(fā)送；B、接收所述更新報(bào)文的BGP鄰居實(shí)體根據(jù)報(bào)文中承載的變化前、后的下一跳信息進(jìn)行一下跳路由信息的更新。
所述的更新報(bào)文包括基于第四版IP協(xié)議IPv4或第六版IP協(xié)議IPv6，網(wǎng)絡(luò)報(bào)文交換協(xié)議IPX，IPv4虛擬專網(wǎng)VPN-IPv4地址族的更新報(bào)文。
所述的步驟A包括當(dāng)下一跳發(fā)生變化時(shí)，在BGP的更新報(bào)文中指示變化后的下一跳信息長(zhǎng)度值及具體的下一跳信息，并在所述更新報(bào)文中還指示變化前的下一跳信息長(zhǎng)度值及具體的下一跳信息。
所述的步驟B包括接收端接收所述的更新報(bào)文后，利用報(bào)文中描述的變化前的下一跳信息和地址前綴作為索引，查找路由表中相應(yīng)的路由，并進(jìn)行對(duì)應(yīng)下一跳路由信息的更新。
所述的步驟B具體包括當(dāng)接收端接收到所述的更新報(bào)文后，若確定報(bào)文中的多協(xié)議網(wǎng)絡(luò)層不可達(dá)信息MP_UNREACH_NLRI屬性字段中包含下一跳信息，則將該下一跳信息和MP_REACH_NLRI中的地址信息作為索引查找路由表，并更新相應(yīng)的下一跳路由信息。
本發(fā)明中，對(duì)于基于IPv4的更新報(bào)文，所述的步驟B具體包括
當(dāng)接收端接收到所述的更新報(bào)文后，根據(jù)報(bào)文中的下一跳Next Hop字段中包含變化前下一跳信息，以及地址前綴查找路由表，并將相應(yīng)的下一跳路由信息更新為路徑屬性Path Attribute中描述的下一跳。
本發(fā)明中，在執(zhí)行所述的步驟A之前還包括通過BGP能力協(xié)商過程確定對(duì)端實(shí)體能夠識(shí)別步驟A所述的更新報(bào)文后，執(zhí)行所述的步驟A。
由上述本發(fā)明提供的技術(shù)方案可以看出，本發(fā)明提供的處理方法可以解決在BGP向鄰居發(fā)送多條到達(dá)相同目的地址的路由情況下，當(dāng)下一跳路由發(fā)生變化時(shí)的路由更新問題。而且，本發(fā)明提供的解決方法可以準(zhǔn)確地更新發(fā)生變化的下一跳信息，有效提高了上述情況下的路由更新效率。


圖1為BGP網(wǎng)絡(luò)結(jié)構(gòu)示意圖；圖2為本發(fā)明所述的方法的流程圖。
具體實(shí)施例方式
本發(fā)明的目的是為了完善BGP發(fā)多條路由特性上在下一跳變化時(shí)，僅發(fā)送一次報(bào)文給鄰居實(shí)體便可以實(shí)現(xiàn)相應(yīng)的處理。
下面首先對(duì)本發(fā)明在實(shí)現(xiàn)過程中的主要處理進(jìn)行說明。
本發(fā)明中，當(dāng)下一跳路由發(fā)生變化時(shí)，則通過在BGP的update(更新)報(bào)文中增加路由變化前的下一跳信息進(jìn)行相應(yīng)的更新處理。接收端處理下一跳變化的更新報(bào)文時(shí)，則根據(jù)變化前的下一跳和路由地址前綴為索引查找路由表，并根據(jù)變化后的下一跳信息進(jìn)行更新處理。
為對(duì)本發(fā)明有進(jìn)一步的理解，下面將對(duì)本發(fā)明進(jìn)行詳細(xì)的說明。
本發(fā)明提供的方法適用于各類地址族的下一跳變化的路由更新處理，如IPv4、IPV6、IPX(網(wǎng)絡(luò)報(bào)文交換協(xié)議)、VPN-IPv4(IPv4虛擬專網(wǎng))等。
多協(xié)議地址族的路由可達(dá)信息和不可達(dá)信息具體通過兩個(gè)新增屬性通告MP_REACH_NLRI通告地址可達(dá)信息和MP_UNREACH_NLRI通告地址不可達(dá)信息，下面將分別對(duì)兩通告報(bào)文格式進(jìn)行說明。
其中，MP_REACH_NLRI通告報(bào)文的格式如表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通告報(bào)文的格式如表2所示表2+---------------------------------------------------------+|Address Family Identifier(2octets) |+---------------------------------------------------------+|Subsequent Address Family Identifier(1octet) |+---------------------------------------------------------+|Withdrawn Routes(variable) |+---------------------------------------------------------+
因此，當(dāng)相應(yīng)地址族的下一跳路由發(fā)生變化時(shí)，MP_UNREACH_NLRI(不可達(dá)的多協(xié)議NLRI)屬性字段內(nèi)容格式更改如表3所示表3

與原有的MP_UNREACH_NLRI字段內(nèi)容相比，表3所示的屬性字段中只包含了下一跳變化前的地址信息，而不包含withdrawn routes信息，同時(shí)在該報(bào)文中還將有MP_REACH_NLRI(可達(dá)的多協(xié)議NRLI)字段，內(nèi)容與協(xié)議相比不變，其中的下一跳為變化后的地址。
這樣，當(dāng)確定下一跳路由發(fā)生變化的一端實(shí)體發(fā)送包含表3所示內(nèi)容信息的更新報(bào)文后，接收端接收并解析所述報(bào)文時(shí)，便可以發(fā)現(xiàn)在所述更新報(bào)文中的MP_UNREACH_NLRI屬性字段中只包含下一跳信息，則以該下一跳和MP_REACH_NLRI屬性字段中的地址信息(地址前綴信息)作為索引，查找路由表，將其下一跳改為更新后的下一跳，即MP_REACH_NLRI屬性字段中承載的變化后的下一跳地址信息。
下面再結(jié)合附圖，以基于IPv4地址的報(bào)文進(jìn)行路由更新的過程對(duì)本發(fā)明所述的方法的具體實(shí)現(xiàn)方式進(jìn)行說明。
如圖2所示，本發(fā)明所述的方法具體包括以下處理步驟步驟21在BGP向鄰居發(fā)送多條到達(dá)相同目的地址的路由情況下，確定下一跳路由發(fā)生變化；具體確定下一跳路由發(fā)生的方法可以是采用已有的故障檢測(cè)機(jī)制、路由發(fā)現(xiàn)機(jī)制等等，本發(fā)明不關(guān)注，故不詳述；
步驟21確定下一跳路由發(fā)生變化的一端實(shí)體構(gòu)造包含變化前及變化后的下一跳信息的報(bào)文，并發(fā)送給對(duì)端實(shí)體；當(dāng)向?qū)Χ税l(fā)送多條到達(dá)同一目的地址的路由，且其中一條下一跳路由發(fā)生變化時(shí)，為提高路由更新的效率，本發(fā)明中采用僅發(fā)送一次update(更新)報(bào)文的方式實(shí)現(xiàn)；所述的update報(bào)文構(gòu)成除了包括普通update內(nèi)容外，增加UnfeasibleRoutes Length(不可靠路由器長(zhǎng)度)和Next Hop(下一跳)字段，但不包含Withdrawn Routes(撤銷路由)字段；所述的update報(bào)文中承載變化前、后下一跳信息的格式如表4所示表4

上述報(bào)文格式不同現(xiàn)有協(xié)議的格式之處在于，通過該特性的能力協(xié)商后，針對(duì)下一跳變化的路由，Unfeasible Routes Length字段后面跟隨的是首先是Next Hop，而不包括要撤銷的路由(即Withdrawn Routes字段)。NextHop字段中的下一跳含義代表變化前的下一跳地址，在Path Attributes中包含的下一跳信息是變化后的下一跳。
步驟23接收端接收所述的update報(bào)文并解析獲得其中承載的變化前、后下一跳路由信息；步驟24利用所述的變化前的下一跳路由信息作為索引查找路由表確定發(fā)生路由變化并需要更新的路由表項(xiàng)；
步驟25利用所述的變化后的下一跳路由信息更新所述的需要更新的路由表項(xiàng)，實(shí)現(xiàn)發(fā)生變化的下一跳路由信息的更新。
總之，當(dāng)某條路由的下一跳發(fā)生變化時(shí)，報(bào)文構(gòu)成按表4所示，與原有的撤銷路由的報(bào)文相比，報(bào)文中將不再包括Withdrawn Routes字段，但是還需要包括Path Attributes和NLRI字段。接收處理該報(bào)文時(shí)，根據(jù)UnfeasibleRoutes Length的值可以判斷該字段后面只有下一跳信息，而沒有待撤銷的路由前綴。根據(jù)Next Hop和NLRI中地址前綴索引在本端路由表中尋找路由，將該路由的下一跳改為Path Attributes中的下一跳，完成對(duì)下一跳變化的處理。
另外，在本發(fā)明中，在鄰居之間協(xié)商了能力建立鄰居后的撤銷路由處理過程中，仍可以基于現(xiàn)有技術(shù)的方式進(jìn)行路由的撤銷處理，具體為發(fā)送撤銷路由報(bào)文中必須在Unfeasible Routes Length字段后面跟隨NextHop，接收端在接收、解析報(bào)文時(shí)，默認(rèn)Unfeasible Routes Length后面跟隨的是Next Hop字段，以該下一跳和Withdrawn Routes字段內(nèi)的路由地址前綴作為雙重索引，查找待撤銷的路由。
綜上所述，本發(fā)明的實(shí)現(xiàn)很好地完善了BGP向鄰居發(fā)送多條到達(dá)相同目的地址的路由情況下，當(dāng)路由下一跳發(fā)生變化時(shí)的處理過程，從而有效提高了相應(yīng)的處理過程的效率。
以上所述，僅為本發(fā)明較佳的具體實(shí)施方式
，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)該以權(quán)利要求的保護(hù)范圍為準(zhǔn)。
權(quán)利要求
1.一種針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法，其特征在于，包括A、當(dāng)基于邊界網(wǎng)關(guān)協(xié)議BGP負(fù)載分擔(dān)的系統(tǒng)中下一跳發(fā)生變化時(shí)，將變化前、后的下一跳信息承載于更新報(bào)文中發(fā)送；B、接收所述更新報(bào)文的BGP鄰居實(shí)體根據(jù)報(bào)文中承載的變化前、后的下一跳信息進(jìn)行一下跳路由信息的更新。
2.根據(jù)權(quán)利要求1所述的針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法，其特征在于，所述的更新報(bào)文包括基于第四版IP協(xié)議IPv4或第六版IP協(xié)議IPv6，網(wǎng)絡(luò)報(bào)文交換協(xié)議IPX，IPv4虛擬專網(wǎng)VPN-IPv4地址族的更新報(bào)文。
3.根據(jù)權(quán)利要求1所述的針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法，其特征在于，所述的步驟A包括當(dāng)下一跳發(fā)生變化時(shí)，在BGP的更新報(bào)文中指示變化后的下一跳信息長(zhǎng)度值及具體的下一跳信息，并在所述更新報(bào)文中還指示變化前的下一跳信息長(zhǎng)度值及具體的下一跳信息。
4.根據(jù)權(quán)利要求1、2或3所述的針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法，其特征在于，所述的步驟B包括接收端接收所述的更新報(bào)文后，利用報(bào)文中描述的變化前的下一跳信息和地址前綴作為索引，查找路由表中相應(yīng)的路由，并進(jìn)行對(duì)應(yīng)下一跳路由信息的更新。
5.根據(jù)權(quán)利要求要求4所述的針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法，其特征在于，所述的步驟B具體包括當(dāng)接收端接收到所述的更新報(bào)文后，若確定報(bào)文中的多協(xié)議網(wǎng)絡(luò)層不可達(dá)信息MP_UNREACH_NLRI屬性字段中包含下一跳信息，則將該下一跳信息和MP_REACH_NLRI中的地址信息作為索引查找路由表，并更新相應(yīng)的下一跳路由信息。
6.根據(jù)權(quán)利要求要求4所述的針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法，其特征在于，對(duì)于基于IPv4的更新報(bào)文，所述的步驟B具體包括當(dāng)接收端接收到所述的更新報(bào)文后，根據(jù)報(bào)文中的下一跳Next Hop字段中包含變化前下一跳信息，以及地址前綴查找路由表，并將相應(yīng)的下一跳路由信息更新為路徑屬性Path Attribute中描述的下一跳。
7.根據(jù)權(quán)利要求1、2或3所述的針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法，其特征在于，在執(zhí)行所述的步驟A之前還包括通過BGP能力協(xié)商過程確定對(duì)端實(shí)體能夠識(shí)別步驟A所述的更新報(bào)文后，執(zhí)行所述的步驟A。
全文摘要
本發(fā)明涉及一種針對(duì)BGP負(fù)載分擔(dān)中路由下一跳變化的處理方法。本發(fā)明主要包括首先，當(dāng)基于邊界網(wǎng)關(guān)協(xié)議BGP負(fù)載分擔(dān)的系統(tǒng)中下一跳發(fā)生變化時(shí)，將變化前、后的下一跳信息承載于更新報(bào)文中發(fā)送；之后，接收所述更新報(bào)文的BGP鄰居實(shí)體根據(jù)報(bào)文中承載的變化前、后的下一跳信息進(jìn)行一下跳路由信息的更新。在BGP向鄰居發(fā)送多條到達(dá)相同目的地址的路由情況下，當(dāng)下一跳路由發(fā)生變化時(shí)，采用本發(fā)明提供的方法可以快速準(zhǔn)確地實(shí)現(xiàn)下一跳路由信息的更新，有效提高了路由更新效率。
文檔編號(hào)H04L29/06GK1949740SQ20051011258
公開日2007年4月18日 申請(qǐng)日期2005年10月11日 優(yōu)先權(quán)日2005年10月11日
發(fā)明者張仁海 申請(qǐng)人:華為技術(shù)有限公司