專利名稱：實現(xiàn)雙向流量工程隧道的方法
技術領域：
本發(fā)明涉及通信領域，尤其涉及一種實現(xiàn)雙向流量工程隧道的方法。
背景技術：
RSVP-TE(資源預留協(xié)議-流量工程)協(xié)議是對傳統(tǒng)RSVP(資源預留協(xié)議)協(xié)議的擴展，用于在MPLS/IP網(wǎng)絡中實現(xiàn)流量工程。RSVP-TE作為是一種標簽分發(fā)協(xié)議，可以基于約束路由建立TE(流量工程)隧道，并為該TE(流量工程)隧道預留帶寬。此外RSVP-TE的FRR(快速重路由)機制以及LSP(標簽交換路徑)備份機制，可以保證TE隧道的可靠性。
目前與本發(fā)明相關的現(xiàn)有技術一，其核心是利用GRE(通用路由封裝)技術建立雙向隧道。路由器R1建立隧道接口，源地址為R1的IP地址，目的地址為路由器R2的IP地址；R2也同樣建立隧道接口，源地址為R2的IP地址，目的地址為R1的IP地址；R1上隧道的源、目的地址分別與R2上隧道的目的地址、源地址相同。當R1和R2發(fā)送隧道建立請求消息給對方時，對方確認后，回送響應消息，建立雙向隧道的過程結(jié)束。
在所述已經(jīng)建立的雙向隧道的基礎上通過策略路由或虛擬路由器技術能夠構建L3 VPN(三層虛擬專網(wǎng))，該L3 VPN具有以下缺點1、GRE封裝和解封裝過程中，需要CPU進行處理，因而轉(zhuǎn)發(fā)性能較低。雖然采用網(wǎng)絡處理器(NP)進行GRE封裝和解封裝處理，可以在一定程度上提高轉(zhuǎn)發(fā)效率，但是設備成本會大幅提高。
2、GRE隧道技術采用將VPN數(shù)據(jù)作為凈荷封裝于新的IP報文中的方式，會增加大量的比特開銷。
3、GRE隧道不具有帶寬保證、流量工程機制，僅僅依靠GRE技術本身無法提供具有帶寬保證的VPN業(yè)務。
4、GRE隧道可靠性依賴于動態(tài)路由協(xié)議的路由收斂速度，無法達到50毫秒的電信級鏈路故障恢復時間要求。
為了提供具有帶寬保證的VPN業(yè)務，并提高轉(zhuǎn)發(fā)效率，提出了與本發(fā)明相關的現(xiàn)有技術二的技術方案，其核心是利用RSVP-TE協(xié)議建立基于約束路由的具有帶寬保證的單向TE隧道，并結(jié)合RFC 2547bis MPLS/BGP VPN技術構建L3VPN，提供具有帶寬保證的VPN業(yè)務。
由現(xiàn)有技術二的技術方案可以看出，其存在如下缺陷由于RSVP-TE建立的隧道是單向的，所以不能像GRE隧道一樣，僅僅通過策略路由或虛擬路由器技術就可以構建L3 VPN，還必須和RFC 2547bisMPLS/BGP VPN技術結(jié)合來提供具有帶寬保證的VPN業(yè)務。因而實現(xiàn)和配置較復雜。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種實現(xiàn)雙向流量工程隧道的方法，通過本發(fā)明建立的雙向TE隧道，不僅能夠支持RSVP-TE原有的業(yè)務應用，而且還可以像GRE隧道一樣，通過虛擬路由器技術或者策略路由技術，提供具有帶寬保證的L3 VPN業(yè)務。
本發(fā)明的目的是通過以下技術方案實現(xiàn)的本發(fā)明提供一種實現(xiàn)雙向流量工程隧道的方法，包括A、當兩臺路由器各自建立目的地為對方的單向隧道時，配置資源預留協(xié)議-流量工程RSVP-TE協(xié)議中的綁定對象；B、基于所述配置的RSVP-TE協(xié)議擴展，將雙方各自建立的目的地為對方的單向隧道進行綁定。
其中，所述步驟B具體包括B1、路由器R1通過配置好的RSVP-TE協(xié)議發(fā)送路徑消息給對端路由器R2；B2、所述R2接收所述消息，根據(jù)所述消息對R1配置的隧道進行綁定處理，然后回送預留Resv消息給R1；B3、所述R1接收到回應的Resv消息后，根據(jù)所述消息確認對端R2是否已經(jīng)與本端建立的隧道綁定成功，若確認成功，則結(jié)束此過程，否則繼續(xù)執(zhí)行步驟B1。
其中，所述步驟B2具體包括B21、所述R2接收所述消息；B22、分析所述消息中的綁定元素是否滿足條件，若全部滿足條件，則將對端需建立的隧道與自身建立的目的地為R1的隧道綁定為雙向隧道，并構造Resv消息，然后回應給R1；否則，忽略綁定對象，并回應Resv消息給R1，所述消息不攜帶綁定對象。
其中，所述綁定元素包括待綁定的對端RSVP-TE隧道的名稱、會話對象的目的地址和/或源地址。
其中，所述分析所述消息中的綁定對象中的綁定元素是否滿足條件的過程具體包括所述R2分析所述消息中的綁定對象中的待綁定的對端RSVP-TE隧道的名稱與本地建立的RSVP隧道的名稱是否一致，若一致，則滿足條件；否則，不滿足條件；和/或，所述R2分析所述消息中會話對象的目的地址是否為本地建立的RSVP-TE隧道的源地址，若是，則滿足條件；否則，不滿足條件；和/或，所述R2分析所述消息中會話對象的源地址是否為本地建立的RSVP-TE隧道的目的地址，若是，則滿足條件；否則，不滿足條件。
其中，所述綁定元素還包括綁定標志。
其中，步驟B22中，所述構造Resv消息的過程具體包括將所述消息中設置綁定對象，并將所述綁定對象中的待綁定的對端RSVP-TE隧道的名稱設置為R2建立的目的地為R1的單向隧道的名稱，綁定標志設置為確認標志；以及，將分發(fā)標簽設置為普通標簽。
其中，步驟B3中，所述根據(jù)所述消息確認對端R2是否已經(jīng)與本端建立的隧道綁定成功的過程具體包括B31、所述R1分析所述消息，當發(fā)現(xiàn)所述消息中未攜帶綁定對象時，則確認雙向隧道未綁定成功；否則，執(zhí)行步驟B32；B32、分析所述消息中攜帶的綁定對象中的待綁定的對端RSVP-TE隧道的名稱是否為對端建立隧道的名稱，若是，則執(zhí)行步驟B33；否則，認為雙向隧道未綁定成功；B33、分析所述消息中攜帶的綁定對象中的綁定標志是否為確認的標志，若是，則確認雙向隧道綁定成功；否則，認為雙向隧道未綁定成功。
由上述本發(fā)明提供的技術方案可以看出，本發(fā)明中，當雙方路由器對各自建立的目的地為對端的單向隧道上的RSVP-TE(資源預留協(xié)議-流量工程)協(xié)議進行配置時，通過配置RSVP-TE的擴展的綁定對象，將雙方各自建立的目的地為對方的單向隧道進行綁定。在本發(fā)明建立的雙向隧道，不僅能夠支持RSVP-TE原有的所有業(yè)務應用，而且像GRE隧道一樣，通過虛擬路由器技術或者策略路由技術，提供具有帶寬保證的L3 VPN業(yè)務。


圖1為本發(fā)明的流程圖；圖2為通過RSVP-TE雙向隧道實現(xiàn)虛擬路由器的原理示意圖。
具體實施例方式
本發(fā)明提供了一種實現(xiàn)雙向流量工程隧道的方法，其主要思想是參照GRE雙向隧道實現(xiàn)機制，利用RSVP-TE的協(xié)議報文中攜帶的TE隧道源地址、目的地址和TE隧道名稱實現(xiàn)兩個單向TE隧道的綁定。同時為了保證TE隧道的EGRESS節(jié)點能夠識別出不同TE隧道傳遞過來的數(shù)據(jù)包，在EGRESS(出口)節(jié)點上RSVP-TE進行標簽分配時不能使用倒數(shù)第二跳彈出機制，而采用分發(fā)普通標簽，這樣不同的TE隧道的報文到達EGRESS節(jié)點之后仍然攜帶著EGRESS分配的不同標簽。
本發(fā)明提供的實施例，如圖1所示，包括步驟101，在現(xiàn)有標準RSVP-TE協(xié)議中設置綁定對象，用于設置綁定標識。
為實現(xiàn)本發(fā)明，需要對現(xiàn)有RSVP-TE協(xié)議進行擴展。新增加一個綁定對象(Binding Object)，定義如下class＝TBD(尚未定義)，C_Type＝TBD(尚未定義)0 1 230 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reserved | flag | Name Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |// Session Name (NULL padded display string)//| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+其中，Reserved16位保留字段，必須為0。
Flag8位標志字段，目前定義如下0x1要求綁定標志，僅在Path消息中有效；0x2綁定成功確認，僅在Resv消息中有效。
Name LengthSession名稱長度。
Session Name待綁定的對端RSVP Tunnel名稱。
基于上述設置，本發(fā)明能夠基于擴展后的RSVP-TE協(xié)議實現(xiàn)雙向TE隧道，具體實現(xiàn)步驟如下步驟102，當雙方路由器PE對各自建立的單向隧道上的資源預留協(xié)議RSVP進行配置時，配置RSVP中的綁定對象。
在本地R1按現(xiàn)有方式配置隧道A(Tunnel A)的RSVP配置后，再增加本發(fā)明的綁定配置，配置協(xié)議中的綁定對象中的綁定元素，以綁定元素包括待綁定的對端RSVP-TE隧道的名稱、目的地址和源地址三種信息為例，此時需要指明需要綁定的對端RSVP-TE隧道名稱為隧道B(Tunnel B)；同時指明RSVP報文攜帶的Session Object(會話對象)的源地址為Tunnel A的地址，目的地址為Tunnel B的地址。當然綁定元素不限于上述三元組。
同時，對端R2也需要進行類似配置，即指明需要綁定的對端RSVP-TE隧道名稱為Tunnel A。同時指明Session Object的源地址為Tunnel B的地址，目的地址為Tunnel A的地址。
下面以R1發(fā)送RSVP報文給R2為例說明，在R2端將Tunnel A與自身建立的Tunnel B進行綁定的過程。
步驟103，路由器R1通過配置好的RSVP-TE協(xié)議發(fā)送消息報文給對端路由器R2。
R1完成TunnelA的現(xiàn)有RSVP配置和本發(fā)明綁定配置之后，RSVP協(xié)議將會發(fā)送Path消息報文給對端R2，其中攜帶有新擴展的Binding Object，該Object的Session Name為對端PE的對應RSVP-TE隧道的名稱，長度則為該Name的長度；Bindding Object中的flag字段的要求綁定標志設置為1。
步驟104，中間路由器轉(zhuǎn)發(fā)R1發(fā)送的消息報文。
步驟105，當所述R2接收到所述消息后，分析所述消息中的綁定元素是否滿足條件，若全部滿足條件，則執(zhí)行步驟106，即將對端需建立的隧道與自身建立的隧道綁定為雙向隧道，并構造Resv消息，然后回應給R1；否則，執(zhí)行步驟107，即忽略綁定對象，并回應Resv消息給R1，所述消息不攜帶綁定對象。
當所述R2接收到所述消息后，根據(jù)所述消息中的Session Object(會話對象)和Binding Object(綁定對象)，檢查以下條件是否全部符合仍然以綁定元素包括待綁定的對端RSVP-TE隧道的名稱、Session Object的目的地址和/或源地址三種信息為例，描述本發(fā)明在分析所述消息中綁定元素是否滿足條件的過程，具體如下所述R2分析所述消息中的綁定對象中的待綁定的對端RSVP隧道的名稱與本地建立的RSVP隧道的名稱是否一致，若一致，則滿足條件；否則，不滿足條件；所述R2分析所述消息中的綁定對象中Session Object的目的地址是否為本地建立的RSVP隧道的源地址，若是，則滿足條件；否則，不滿足條件；所述R2分析所述消息中的綁定對象中Session Object的源地址是否為本地建立的RSVP隧道的目的地址，若是，則滿足條件；否則，不滿足條件。
若全部滿足以上條件，所述R2則認為收到的TunnelA的Path消息要求將TunnelA和TunnelB綁定為雙向隧道，于是將對端需建立的隧道與自身建立的隧道綁定為雙向隧道，并構造Resv消息將所述消息中設置綁定對象，并將所述綁定對象中的待綁定的對端RSVP-TE隧道的名稱設置為R2建立的單向隧道的名稱，將flag字段的綁定標志設置為確認標志，即設置為1；而且不再分發(fā)要求倒數(shù)第二跳彈出的IMPLICIT NULL標簽，而將分發(fā)標簽設置為普通標簽。
將經(jīng)過上述構造后的Resv消息回應給R1。
當上述條件由一項未滿足時，所述R2會忽略綁定對象，并回應Resv消息給R1，此時所述消息不攜帶綁定對象。
步驟108，中間路由器轉(zhuǎn)發(fā)R2發(fā)送的消息報文。
步驟109、所述R1接收到回應的Resv消息后，根據(jù)所述消息確認對端R2是否已經(jīng)與本端建立的隧道綁定成功，若確認成功，則執(zhí)行步驟110，即結(jié)束此過程，否則繼續(xù)執(zhí)行步驟103。具體包括步驟1、所述R1接收到回應的Resv消息后，分析所述消息，當發(fā)現(xiàn)所述消息中未攜帶綁定對象時，則確認雙向隧道未綁定成功；否則，執(zhí)行步驟2；步驟2、分析所述消息中攜帶的綁定對象中的待綁定的對端RSVP-TE隧道的名稱是否為對端建立隧道的名稱，若是，則執(zhí)行步驟3；否則，認為雙向隧道未綁定成功，然后轉(zhuǎn)入步驟103；步驟3、分析所述消息中攜帶的綁定對象中的綁定標志是否為確認的標志，若是，則確認雙向隧道綁定成功；否則，認為雙向隧道未綁定成功，然后轉(zhuǎn)入步驟103。
對端R2上的流程與本地R1類似，這里不再詳細描述。
當LSR-A與LSR-B都成功進行了綁定并且為對端確認后，整個綁定的RSVP Tunnel就建立起來了。
由上述本發(fā)明的具體實施方案可以看出，RSVP-TE經(jīng)過協(xié)議擴展之后，RSVP-TE在已有的QoS、TE和可靠性等眾多優(yōu)勢的基礎之上，融入了GRE和IPsec具有的雙向隧道的優(yōu)勢。
利用本發(fā)明提供的RSVP-TE雙向隧道技術，除了支持RSVP-TE原有的業(yè)務應用之外，還可以支持GRE隧道所支持的所有業(yè)務應用，例如，虛擬路由器功能、作為MPLS VPN的外層隧道，和通過隧道互連兩個分離的路由域等等。通過虛擬路由器或策略路由可方便地提供L3 VPN業(yè)務，這種L3 VPN技術兼具RSVP-TE的QoS保證、TE和可靠性優(yōu)勢以及GRE雙向隧道方便建立VPN的優(yōu)勢。
以下僅以虛擬路由器功能為例，簡單說明RSVP-TE雙向隧道的使用方法。
利用RSVP-TE的雙向TE隧道技術實現(xiàn)虛擬路由器的方法如圖2所示，PE-1和PE-2上分別建立兩個虛擬路由器實例VRF Red和VRF Blue。PE-1、PE-2連接兩個CE設備的接口分別綁定虛擬路由器實例VRF Red和VRFBlue。在PE-1和PE-2之間建立兩個雙向TE隧道Tunnel 1和Tunnel 2，分別綁定虛擬路由器實例VRF Red和VRF Blue，通過虛擬路由器實例上配置靜態(tài)路由或動態(tài)路由，接入到兩個PE設備上相同虛擬路由器實例的CE設備之間就可以相互訪問了。
以上所述，僅為本發(fā)明較佳的具體實施方式
，但本發(fā)明的保護范圍并不局限于此，例如本發(fā)明所述綁定元素不僅僅限于隧道名稱、源地址和目的地址三元組。通過其它綁定元素實現(xiàn)兩個單向隧道綁定為雙向隧道的做法，是任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內(nèi)，可輕易想到的變化或替換，都應涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應該以權利要求的保護范圍為準。
權利要求
1.一種實現(xiàn)雙向流量工程隧道的方法，其特征在于，包括A、當兩臺路由器各自建立目的地為對方的單向隧道時，配置資源預留協(xié)議-流量工程RSVP-TE協(xié)議中的綁定對象；B、基于所述配置的RSVP-TE協(xié)議擴展，將雙方各自建立的目的地為對方的單向隧道進行綁定。
2.根據(jù)權利要求1所述的方法，其特征在于，所述步驟B具體包括B1、路由器R1通過配置好的RSVP-TE協(xié)議發(fā)送路徑消息給對端路由器R2；B2、所述R2接收所述消息，根據(jù)所述消息對R1配置的隧道進行綁定處理，然后回送預留Resv消息給R1；B3、所述R1接收到回應的Resv消息后，根據(jù)所述消息確認對端R2是否已經(jīng)與本端建立的隧道綁定成功，若確認成功，則結(jié)束此過程，否則繼續(xù)執(zhí)行步驟B1。
3.根據(jù)權利要求2所述的方法，其特征在于，所述步驟B2具體包括B21、所述R2接收所述消息；B22、分析所述消息中的綁定元素是否滿足條件，若全部滿足條件，則將對端需建立的隧道與自身建立的目的地為R1的隧道綁定為雙向隧道，并構造Resv消息，然后回應給R1；否則，忽略綁定對象，并回應Resv消息給R1，所述消息不攜帶綁定對象。
4.根據(jù)權利要求3所述的方法，其特征在于，所述綁定元素包括待綁定的對端RSVP-TE隧道的名稱、會話對象的目的地址和/或源地址。
5.根據(jù)權利要求4所述的方法，其特征在于，所述分析所述消息中的綁定對象中的綁定元素是否滿足條件的過程具體包括所述R2分析所述消息中的綁定對象中的待綁定的對端RSVP-TE隧道的名稱與本地建立的RSVP隧道的名稱是否一致，若一致，則滿足條件；否則，不滿足條件；和/或，所述R2分析所述消息中會話對象的目的地址是否為本地建立的RSVP-TE隧道的源地址，若是，則滿足條件；否則，不滿足條件；和/或，所述R2分析所述消息中會話對象的源地址是否為本地建立的RSVP-TE隧道的目的地址，若是，則滿足條件；否則，不滿足條件。
6.根據(jù)權利要求所述3的方法，其特征在于，所述綁定元素還包括綁定標志。
7.根據(jù)權利要求所述6的方法，其特征在于，步驟B22中，所述構造Resv消息的過程具體包括將所述消息中設置綁定對象，并將所述綁定對象中的待綁定的對端RSVP-TE隧道的名稱設置為R2建立的目的地為R1的單向隧道的名稱，綁定標志設置為確認標志；以及，將分發(fā)標簽設置為普通標簽。
8.根據(jù)權利要求2所述的方法，其特征在于，步驟B3中，所述根據(jù)所述消息確認對端R2是否已經(jīng)與本端建立的隧道綁定成功的過程具體包括B31、所述R1分析所述消息，當發(fā)現(xiàn)所述消息中未攜帶綁定對象時，則確認雙向隧道未綁定成功；否則，執(zhí)行步驟B32；B32、分析所述消息中攜帶的綁定對象中的待綁定的對端RSVP-TE隧道的名稱是否為對端建立隧道的名稱，若是，則執(zhí)行步驟B33；否則，認為雙向隧道未綁定成功；B33、分析所述消息中攜帶的綁定對象中的綁定標志是否為確認的標志，若是，則確認雙向隧道綁定成功；否則，認為雙向隧道未綁定成功。
全文摘要
本發(fā)明涉及一種實現(xiàn)雙向流量工程隧道的方法，其核心是當兩臺路由器各自建立目的地為對方的單向隧道時，配置資源預留協(xié)議－流量工程RSVP－TE協(xié)議中的綁定對象；基于所述配置的RSVP－TE協(xié)議擴展，將雙方各自建立的目的地為對方的單向隧道進行綁定。通過本發(fā)明建立的雙向隧道，不僅能夠支持RSVP－TE原有的所有業(yè)務應用，而且可以像通用路由封裝GRE隧道一樣，靈活方便地提供三層虛擬專網(wǎng)VPN業(yè)務，而且該VPN具有帶寬保證和TE屬性。
文檔編號H04L12/54GK1863151SQ20051010248
公開日2006年11月15日 申請日期2005年9月14日 優(yōu)先權日2005年9月14日
發(fā)明者李賀軍 申請人:華為技術有限公司