算路處理方法及裝置的制造方法
【技術領域】
[0001] 本發(fā)明涉及通信領域，具體而言，涉及一種算路處理方法及裝置。
【背景技術】
[0002] 在多協(xié)議標簽交換（Multiprotocol Label Switching，簡稱為MPLS)網(wǎng)絡中，利 用資源預留協(xié)議（Resource Reservation Protocol，簡稱為RSVP-TE)建立一條隧道。通 常來說，建立隧道時對于鏈路代價Metric的約束有兩種，一種是內部網(wǎng)關協(xié)議鏈路代價 (Interior Gateway Protocol Metric，簡稱為 IGP Metric)，另一種是流量工程鏈路代價 (Traffic Engineering Metric，簡稱為 TE Metric) 〇
[0003] 如圖1所示，R1、R2、R3、R4四節(jié)點拓撲，圖中各個鏈路的IGP Metric和TE Metic 分別標注了相應的數(shù)值，從Rl建立一條隧道到R3,如果我們選取的是IGP Metric方式約 束，那么算路結果走的路徑為L12、L23,即Rl - R2 - R3,因為這條路徑總的IGP Metric值 是所有可達路徑中最小的；如果選取的是TE Metric方式約束，那么算路走的路徑為L14、 L34,即Rl - R4 - R3,因為這條路徑總的TE Metric值是所有可達路徑中最小的。
[0004] 在實際應用中，部署隧道的時候，存在跨域等應用場景，進行算路時候，并不能從 頭結點直接算路到尾節(jié)點，可能需要經過中間節(jié)點再次算路。如圖2所示，AREAO和AREAl 兩個域，同樣Rl建立隧道至R3,由于源地址和目的地址不在一個域內，所以頭結點Rl算路 只能算到域的邊界R2或者R4,從R2或者R4再次算路到R3。如果在R2或者R4上再次算 路，算路的Metric約束應該與頭結點算路方式一致才能保證整條隧道的Metric約束符合 隧道頭結點的策略。目前來說這一約束沒有一個明確的信令機制，從頭結點傳遞給下游。 [0005]目前解決上述問題存在如下幾種方案：
[0006] 第一種：中間節(jié)點算路，如果不知道隧道頭結點的Metric約束方式，用約定默認 的算路方式。這種方案存在的弊端就是可能造成一條隧道頭結點Metric約束方式與中間 節(jié)點Metric約束方式不一致。
[0007] 第二種：各個節(jié)點全局配置Metric算路方式，如果配置了全局Metric算路方式 的節(jié)點對于一條隧道是頭結點，隧道下沒有配置隧道的Metric算路方式，那么以全局的配 置為準；如果隧道下配置了 Metric算路方式，那么以隧道下配置為準。如果配置了全局 Metric算路方式的節(jié)點對于一條隧道是中間節(jié)點，并且需要算路，那么算路方式以全局配 置的為準。這種解決方式，也是會導致隧道頭結點Metric約束方式與中間節(jié)點Metric約 束方式不一致。
[0008] 針對相關技術中，隧道頭結點Metric約束方式與中間節(jié)點Metric約束方式不一 致的問題，還沒有提出有效的解決方案。

【發(fā)明內容】

[0009] 本發(fā)明提供了一種算路處理方法及裝置，以至少解決現(xiàn)有技術中隧道頭結點 Metric約束方式與中間節(jié)點Metric約束方式不一致的問題。
[0010] 根據(jù)本發(fā)明的一個方面，提供了一種算路處理方法，包括：下游結點接收來自頭結 點的所述頭結點的算路方式；所述下游結點使用所述算路方式進行算路。
[0011] 優(yōu)選地，所述下游結點接收來自所述頭結點的算路方式包括：所述下游結點接收 來自所述頭結點的PATH報文；從所述PATH報文中獲取所述頭結點的算路方式。
[0012] 優(yōu)選地，所述算路方式通過以下之一方式攜帶于所述PATH報文中：在所述PATH報 文中的新增字段添加所述算路方式、在所述PATH報文中的未使用的字段添加所述算路方 式。
[0013] 優(yōu)選地，在所述PATH報文中的未使用的字段添加所述算路方式包括：在SESSI0N_ ATTRIBUTE對象的FLAG字段中添加所述算路方式。
[0014] 優(yōu)選地，所述算路方式包括：內部網(wǎng)關協(xié)議鏈路代價IGP Metric、流量工程鏈路代 價 TE Metric。
[0015] 根據(jù)本發(fā)明的一個方面，提供了另一種算路處理方法，包括：頭結點確定所述頭結 點的算路方式，其中，所述算路方式為下游結點進行算路所使用的算路方式；所述頭結點將 所述算路方式發(fā)送給所述下游結點。
[0016] 優(yōu)選地，所述頭結點將所述頭結點的算路方式發(fā)送給所述下游結點包括：所述頭 結點將PATH報文發(fā)送給所述下游結點，其中，所述PATH報文中攜帶有所述頭結點的算路方 式。
[0017] 根據(jù)本發(fā)明的一個方面，提供了一種算路處理裝置，該裝置應用于下游結點，包 括：接收模塊，用于接收來自頭結點的所述頭結點的算路方式；算路模塊，用于使用所述算 路方式進行算路。
[0018] 優(yōu)選地，所述接收模塊還用于接收來自所述頭結點的PATH報文；從所述PATH報文 中獲取所述頭結點的算路方式。
[0019] 根據(jù)本發(fā)明的一個方面，還提供了另一種算路處理裝置，該裝置應用于頭結點，包 括：確定模塊，用于確定所述頭結點的算路方式，其中，所述算路方式為下游結點進行算路 所使用的算路方式；發(fā)送模塊，用于將所述算路方式發(fā)送給所述下游結點。
[0020] 通過本發(fā)明，采用下游結點接收來自頭結點的算路方式；下游結點使用該算路方 式進行算路。解決了現(xiàn)有技術中隧道頭結點的算路方式與中間節(jié)點的算路方式不一致的問 題，進而可以得到最優(yōu)的路徑，提升了用戶體驗。
【附圖說明】
[0021] 此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，本發(fā) 明的示意性實施例及其說明用于解釋本發(fā)明，并不構成對本發(fā)明的不當限定。在附圖中：
[0022] 圖1是根據(jù)本發(fā)明實施例的四節(jié)點Metric算路示意圖；
[0023] 圖2是根據(jù)本發(fā)明實施例的跨域四節(jié)點示意圖；
[0024] 圖3是根據(jù)本發(fā)明實施例的算路處理方法的流程圖；
[0025] 圖4是根據(jù)本發(fā)明實施例的算路處理裝置的結構框圖；
[0026] 圖5是根據(jù)本發(fā)明實施例的算路處理方法的流程圖一；
[0027] 圖6是根據(jù)本發(fā)明實施例的算路處理裝置的結構框圖一；
[0028] 圖7是根據(jù)本發(fā)明優(yōu)選實施例的SESSION_ATTRIBUTE對象格式圖；
[0029] 圖8是根據(jù)本發(fā)明優(yōu)選實施例的隧道Metric算路約束的通知方法流程圖；
[0030] 圖9是根據(jù)本發(fā)明優(yōu)選實施例的隧道中間節(jié)點算路的方法流程圖。
【具體實施方式】
[0031] 下文中將參考附圖并結合實施例來詳細說明本發(fā)明。需要說明的是，在不沖突的 情況下，本申請中的實施例及實施例中的特征可以相互組合。
[0032] 在本實施例中提供了一種算路處理方法，圖3是根據(jù)本發(fā)明實施例的算路處理方 法的流程圖，如圖3所示，該流程包括如下步驟：
[0033] 步驟S302,下游結點接收來自頭結點的算路方式；
[0034] 步驟S304,下游結點使用該算路方式進行算路。
[0035] 通過上述步驟，下游結點使用接收到的來自頭結點的算路方式進行算路，相比于 現(xiàn)有技術中采用默認的算路方式及為各個結點全局配置算路方式仍然會出現(xiàn)頭結點和下 游結點所使用了算路方式不一致，上述步驟解決了隧道頭結點的算路方式與中間節(jié)點的算 路方式不一致的問題，進而可以得到最優(yōu)的路徑，提升了用戶體驗。
[0036] 上述步驟S302涉及到下游結點接收來自頭結點的算路方式，需要說明的是，下游 結點可以通過多種方式接收頭結點的算路方式，下面對此進行舉例說明。在一個優(yōu)選實施 例中，下游結點接收來自頭結點的PATH報文，從PATH報文中獲取頭結點的算路方式。
[0037] 同時，算路方式可以通過多種方式攜帶于PATH報文中，在一個優(yōu)選實施例中，算 路方式可以存在于PATH報文中的新增字段中或者PATH報文中的未使用的字段中。
[0038] 當算路方式存在于PATH報文中的未使用的字段中時，在一個優(yōu)選實施例中，算路 方式存在于SESSION_ATTRIBUTE對象的FLAG字段中。
[0039] 在一個優(yōu)選實施例中，頭結點和下游結點處于不同的域或者相同的域。
[0040] 具體地，算路方式包括：內部網(wǎng)關協(xié)議鏈路代價IGP Metric、流量工程鏈路代價TE Metric0
[0041] 在本實施例中還提供了一種算路處理裝置，該裝置用于實現(xiàn)上述實施例及優(yōu)選實 施方式，已經進行過說明的不再贅述。如以下所使用的，術語"模塊"可以實現(xiàn)預定功能的 軟件和/或硬件的組合。盡管以下實施例所描述的裝置較佳地以軟件來實現(xiàn)，但是硬件，或 者軟件和硬件的組合的實現(xiàn)也是可能并被構想的。
[0042] 圖4是根據(jù)本發(fā)明實施例的算路處理裝置的結構框圖，該裝置應用于下游結點， 如圖4所示，該裝置包括：接收模塊42,用于接收來自頭結點的該頭結點的算路方式；算路 模塊44,用于使用該算路方式進行算路。
[0043] 需要說明的是，上述各個模塊是可以通過軟件或硬件來實現(xiàn)的，對于后者，可以通 過以下方式實現(xiàn)，但不限于此：接收模塊22和算路模塊24均位于同一處理器中；或者，接 收模塊22和算路模塊24分別位于第一處理器、第二處理器中。
[0044] 優(yōu)選地，接收模塊22還用于接收來自所述頭結點的PATH報文；從該PATH報文中 獲取頭結點的算路方式。
[0045] 在本實施例中提供了另一種算路處理方法，圖5是根據(jù)本發(fā)明實施例的算路處理 方法的流程圖一，如圖5所示，該流程包括如下步驟：
[0046] 步驟S502,頭結點確定該頭結點的算路方式，其中，算路方式為下游結點進行算路 所使用的算路方式；
[0047] 步驟S504,頭結點將該算路方式發(fā)送給下游結點。
[0048] 通過上述步驟，頭結點將該頭結點的算路方式發(fā)送給下游結點，下游結點使用該 算路方式進行算路，相比于現(xiàn)有技術中采用默認的算路方式及為各個結點全局配置算路方 式仍然會出現(xiàn)頭結點和下游結點所使用了算路方式不一致，上述步驟解決了隧道頭結點的 算路方式與中間節(jié)點的算路方式不一致的問題，進而可以得到最優(yōu)的路徑，提升了用戶體 驗。
[0049] 上述步驟S504涉及到頭結點將算路方式發(fā)送給下游結點，需要說明的是，頭結點 可以通過多種方式將算路