本發(fā)明涉及基于流量工程擴(kuò)展的資源預(yù)留協(xié)議(RSVP-TE，Resource ReSerVation Protocol-Traffic Engineering)技術(shù)，尤指一種發(fā)送RSVP消息的方法和裝置、接收RSVP消息的裝置。

背景技術(shù)：

RSVP-TE用于為多協(xié)議標(biāo)簽交換(MPLS，Multi-Protocol Label Switching)網(wǎng)絡(luò)建立標(biāo)簽切換路徑(LSP，Label Switch Path)以及維持LSP的狀態(tài)信息?？焖僦芈酚?FRR，F(xiàn)ast ReRoute)技術(shù)在MPLS網(wǎng)絡(luò)中提供鏈路保護(hù)和節(jié)點(diǎn)包含機(jī)制，當(dāng)LSP鏈路或節(jié)點(diǎn)故障時(shí)，在發(fā)現(xiàn)故障的節(jié)點(diǎn)進(jìn)行保護(hù)，使流量繼續(xù)從保護(hù)鏈路或節(jié)點(diǎn)的LSP中通過(guò)。FRR機(jī)制依賴(lài)于LSP的狀態(tài)信息，滿(mǎn)足一定條件的LSP才能形成FRR保護(hù)，而LSP的狀態(tài)信息需要RSVP消息的刷新來(lái)維持。

RSVP-TE中的FRR保護(hù)有鏈路保護(hù)和節(jié)點(diǎn)保護(hù)兩種本地保護(hù)類(lèi)型。其中，鏈路保護(hù)如圖1所示，主LSP(即被保護(hù)LSP)路徑為R1-L12-R2，備LSP(即保護(hù)LSP)路徑為R1-L13-R2。R1稱(chēng)為本地修復(fù)點(diǎn)(PLR，Point Local Repair)，R2稱(chēng)為匯聚點(diǎn)(MP，Merge Point)。其中，節(jié)點(diǎn)保護(hù)如圖2所示，主LSP(即被保護(hù)LSP)路徑為R3-L21-R4-L22-R5，備LSP(即保護(hù)LSP)路徑為R3-L23-R5。R3稱(chēng)為PLR，R5稱(chēng)為MP。

現(xiàn)有的發(fā)送RSVP消息的方法大致包括：PLR進(jìn)行主備切換后，分別將每一條被保護(hù)LSP對(duì)應(yīng)的RSVP消息(如PATH消息)發(fā)送給MP，MP接收到RSVP消息后，進(jìn)行主備合并處理。

現(xiàn)有的發(fā)送RSVP消息的方法中，當(dāng)被保護(hù)LSP數(shù)量較多(幾萬(wàn)甚至幾十萬(wàn)條)時(shí)，PLR切換后，PLR需要將大量的RSVP消息逐條發(fā)送給MP，網(wǎng)絡(luò)開(kāi)銷(xiāo)較大，并且由于路由節(jié)點(diǎn)的處理性能問(wèn)題，某些RSVP消息到達(dá) MP時(shí)會(huì)產(chǎn)生較大的時(shí)延，而由于如果MP在規(guī)定時(shí)間內(nèi)沒(méi)有收到RSVP消息，則MP中的主LSP的狀態(tài)信息便會(huì)老化，導(dǎo)致MP將被保護(hù)LSP拆除，從而使被保護(hù)LSP斷流，使得主備保護(hù)失敗的概率較大。

技術(shù)實(shí)現(xiàn)要素：

為了解決上述問(wèn)題，本發(fā)明提出了一種發(fā)送RSVP消息的方法和裝置、接收RSVP消息的裝置，能夠降低主備保護(hù)失敗的概率。

為了達(dá)到上述目的，本發(fā)明提出了一種發(fā)送資源預(yù)留協(xié)議RSVP消息的方法，包括：

本地修復(fù)點(diǎn)PLR進(jìn)行主備切換后，將捆綁Bundle消息發(fā)送給匯聚點(diǎn)MP；

其中，Bundle消息中包含有被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息。

優(yōu)選地，所述Bundle消息中包含的RSVP消息的個(gè)數(shù)為所述PLR對(duì)應(yīng)的主標(biāo)簽切換路徑LSP的條數(shù)；或者，所述Bundle消息的大小小于或等于系統(tǒng)允許傳輸?shù)淖畲笾怠?/p>

優(yōu)選地，所述RSVP消息為路徑PATH消息。

優(yōu)選地，所述Bundle消息包括Bundle頭和一個(gè)或一個(gè)以上子消息；其中，每一個(gè)所述RSVP消息作為所述Bundle消息中的一個(gè)子消息。

優(yōu)選地，所述Bundle頭包括協(xié)議版本號(hào)Vers、標(biāo)識(shí)Flags、消息類(lèi)型、RSVP校驗(yàn)和checksum、發(fā)送的生存時(shí)間Send_TTL、保留Reserved、RSVP長(zhǎng)度length。

本發(fā)明還提出了一種發(fā)送資源預(yù)留協(xié)議RSVP消息的方法，包括：

匯聚點(diǎn)MP接收到來(lái)自本地修復(fù)點(diǎn)PLR的Bundle消息，對(duì)Bundle消息進(jìn)行解析得到RSVP消息，根據(jù)得到的RSVP消息刷新主LSP；

其中，Bundle消息中包含有被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息。

優(yōu)選地，所述對(duì)Bundle消息進(jìn)行解析得到RSVP消息包括：

讀取所述Bundle消息中的子消息得到所述RSVP消息。

本發(fā)明還提出了一種發(fā)送資源預(yù)留協(xié)議RSVP消息的裝置，至少包括：

發(fā)送模塊，用于進(jìn)行主備切換后，將Bundle消息發(fā)送給匯聚點(diǎn)MP；

其中，Bundle消息中包含有被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息。

本發(fā)明還提出了一種接收資源預(yù)留協(xié)議RSVP消息的裝置，至少包括：

接收模塊，用于接收到來(lái)自本地修復(fù)點(diǎn)PLR的Bundle消息；

解析模塊，用于對(duì)Bundle消息進(jìn)行解析得到RSVP消息；

刷新模塊，用于根據(jù)得到的RSVP消息刷新主LSP；

其中，Bundle消息中包含有被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息。

優(yōu)選地，所述解析模塊具體用于：

讀取所述Bundle消息中的子消息得到所述RSVP消息。

與現(xiàn)有技術(shù)相比，本發(fā)明包括：PLR進(jìn)行主備切換后，將Bundle消息發(fā)送給MP；其中，Bundle消息中包含有被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息。通過(guò)本發(fā)明的方案，將被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息包含在Bundle消息中同時(shí)發(fā)送給MP，減小了RSVP消息到達(dá)MP的時(shí)延，從而降低了主備保護(hù)失敗的概率。

附圖說(shuō)明

下面對(duì)本發(fā)明實(shí)施例中的附圖進(jìn)行說(shuō)明，實(shí)施例中的附圖是用于對(duì)本發(fā)明的進(jìn)一步理解，與說(shuō)明書(shū)一起用于解釋本發(fā)明，并不構(gòu)成對(duì)本發(fā)明保護(hù)范圍的限制。

圖1為現(xiàn)有鏈路保護(hù)的結(jié)構(gòu)組成示意圖；

圖2為現(xiàn)有節(jié)點(diǎn)保護(hù)的結(jié)構(gòu)組成示意圖；

圖3為本發(fā)明發(fā)送RSVP消息的方法的流程圖；

圖4為本發(fā)明接收RSVP消息的裝置的結(jié)構(gòu)組成示意圖。

具體實(shí)施方式

為了便于本領(lǐng)域技術(shù)人員的理解，下面結(jié)合附圖對(duì)本發(fā)明作進(jìn)一步的描述，并不能用來(lái)限制本發(fā)明的保護(hù)范圍。需要說(shuō)明的是，在不沖突的情況下，本申請(qǐng)中的實(shí)施例及實(shí)施例中的各種方式可以相互組合。

參見(jiàn)圖3，本發(fā)明提出了一種發(fā)送RSVP消息的方法，包括：

步驟300、PLR進(jìn)行主備切換后，將Bundle消息發(fā)送給MP。

本步驟中，Bundle消息中包含有被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息。

其中，RSVP消息為路徑(PATH)消息。

其中，優(yōu)選地，Bundle消息中包含的RSVP消息的個(gè)數(shù)為PLR對(duì)應(yīng)的主LSP的條數(shù)；或者，Bundle消息的大小小于或等于系統(tǒng)允許傳輸?shù)淖畲笾怠?/p>

其中，Bundle消息中包含的RSVP消息的個(gè)數(shù)越多，RSVP消息到達(dá)MP的時(shí)延越短，主備保護(hù)失敗的概率越小。

本步驟中，Bundle消息包括Bundle頭和一個(gè)或一個(gè)以上子消息。

其中，Bundle頭包括：協(xié)議版本號(hào)(Vers)、標(biāo)識(shí)(Flags)、消息類(lèi)型、RSVP校驗(yàn)和(checksum)、發(fā)送的生存時(shí)間(Send_TTL)、Reserved、RSVP長(zhǎng)度(length)。

其中，F(xiàn)lags取0x01時(shí)表示刷新減少，0x02-0x08為保留狀態(tài)；消息類(lèi)型取12時(shí)表示Bundle消息；RSVP checksum用來(lái)校驗(yàn)報(bào)文是否正確；Send_TTL用來(lái)跟IP頭中的生存時(shí)間(TTL，Time To Live)進(jìn)行比較發(fā)現(xiàn)一個(gè)非RSVP節(jié)點(diǎn)；Reserved為保留字段；RSVP length為Bundle消息的長(zhǎng)度。

其中，vers占用4個(gè)比特，F(xiàn)lags占用4個(gè)比特，12占用8比特，RSVP checksum占用16比特，Send_TTL占用8比特，RSVP length占用16比特。

其中，每一個(gè)RSVP消息作為Bundle消息中的一個(gè)子消息。

其中，PLR如何將Bundle消息發(fā)送給MP屬于本領(lǐng)域技術(shù)人員的公知技術(shù)，并不用于限定本發(fā)明的保護(hù)范圍，這里不再贅述。

步驟301、MP接收到來(lái)自PLR的Bundle消息，對(duì)Bundle消息進(jìn)行解析得到RSVP消息，根據(jù)得到的RSVP消息刷新主LSP。

本步驟中，MP對(duì)Bundle消息進(jìn)行解析得到RSVP消息包括：

MP讀取Bundle消息中的子消息得到RSVP消息。

本步驟中，MP如何根據(jù)得到的RSVP消息刷新主LSP屬于本領(lǐng)域技術(shù)人員的公知技術(shù)，并不用于限定本發(fā)明的保護(hù)范圍，這里不再贅述。

通過(guò)本發(fā)明的方案，將被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息包含在Bundle消息中同時(shí)發(fā)送給MP，減小了切換后單個(gè)RSVP消息的網(wǎng)絡(luò)開(kāi)銷(xiāo)，減小了RSVP消息到達(dá)MP的時(shí)延，從而降低了主備保護(hù)失敗的概率。

下面通過(guò)具體實(shí)施例詳細(xì)說(shuō)明本發(fā)明的方法。

第一實(shí)施例，如圖1所示，從R1經(jīng)過(guò)L12到R2建立一萬(wàn)條主LSP，從R1經(jīng)過(guò)L13到R2建立一條備LSP，配置FRR保護(hù)，走L13鏈路的備LSP與走L12鏈路的一萬(wàn)條主LSP形成FRR保護(hù)關(guān)系，在PLR即R1決策使用Bundle消息攜帶切換后的PATH消息。

L12鏈路發(fā)生故障，觸發(fā)R1進(jìn)行FRR主備切換，R1切換后采用Bundle消息攜帶被同一條備LSP保護(hù)的主LSP的PATH消息，攜帶的PATH消息的個(gè)數(shù)為兩個(gè)或兩個(gè)以上。R1將攜帶PATH消息的Bundle消息通過(guò)備LSP發(fā)送至R2。R2接收到Bundle消息，解析還原PATH消息，進(jìn)行主備合并處理。

第二實(shí)施例，如圖2所示，從R3經(jīng)過(guò)L21、R4、L22到R5建立一萬(wàn)條主LSP，從R3經(jīng)過(guò)L23到R5建立一條備LSP，配置FRR保護(hù)，走L23鏈路的備LSP與走R3-L21-R4—L22—R5鏈路的一萬(wàn)條主LSP形成FRR保護(hù)關(guān)系，在PLR即R3決策使用Bundle消息攜帶切換后的PATH消息。

L21鏈路發(fā)生故障，觸發(fā)R3進(jìn)行FRR主備切換，R3切換后的被同一條 備LSP保護(hù)的主LSP的PATH消息采用Bundle消息攜帶，攜帶的PATH消息的個(gè)數(shù)為兩個(gè)或兩個(gè)以上。R3將攜帶PATH消息的Bundle消息通過(guò)備LSP發(fā)送至R5。R5接收到Bundle消息，解析還原PATH消息，進(jìn)行主備合并處理。

本發(fā)明還提出了一種發(fā)送RSVP的裝置，可以設(shè)置在PLR中，至少包括：

發(fā)送模塊，用于進(jìn)行主備切換后，將Bundle消息發(fā)送給MP；

其中，Bundle消息中包含有被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息。

參見(jiàn)圖4，本發(fā)明還提出了一種接收RSVP消息的裝置，至少包括：

接收模塊，用于接收到來(lái)自本地修復(fù)點(diǎn)PLR的Bundle消息；

解析模塊，用于對(duì)Bundle消息進(jìn)行解析得到RSVP消息；

刷新模塊，用于根據(jù)得到的RSVP消息刷新主LSP；

其中，Bundle消息中包含有被同一條備LSP保護(hù)的主LSP的兩個(gè)或兩個(gè)以上RSVP消息。

本發(fā)明的裝置中，解析模塊具體用于：

讀取Bundle消息中的子消息得到RSVP消息。

需要說(shuō)明的是，以上所述的實(shí)施例僅是為了便于本領(lǐng)域的技術(shù)人員理解而已，并不用于限制本發(fā)明的保護(hù)范圍，在不脫離本發(fā)明的發(fā)明構(gòu)思的前提下，本領(lǐng)域技術(shù)人員對(duì)本發(fā)明所做出的任何顯而易見(jiàn)的替換和改進(jìn)等均在本發(fā)明的保護(hù)范圍之內(nèi)。