專利名稱：向路徑計算單元提供反饋的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通過網(wǎng)絡(luò)的路徑的計算，更具體地，涉及路徑計算客戶端與路徑計算單元之間的通信，以實現(xiàn)改進的路徑計算。
背景技術(shù)：
通用多協(xié)議標簽交換(GMPLS)提供了控制面框架，以管理任意面向連接的分組或電路交換網(wǎng)絡(luò)技術(shù)。GMPLS的兩個主要協(xié)議功能是流量工程(TE)信息同步和連接管理。第一功能同步網(wǎng)絡(luò)中節(jié)點的TE信息數(shù)據(jù)庫，并以開放最短路徑優(yōu)先流量工程(OSPF-TE)或中間系統(tǒng)間流量工程(ISIS-TE)來實現(xiàn)。通過資源預(yù)留協(xié)議流量工程(RSVP-TE)來實現(xiàn)管理連接的第二功能。在IETF RFC 2205中描述了資源預(yù)留協(xié)議(RSVP)，在IETF RFC 3209中描述了支 持隧道的流量工程驅(qū)動供應(yīng)的RSVP的擴展(RSVP-TE)。取決于TE信息，GMPLS支持逐跳、入口(ingress)和集中的路徑計算方案。在逐跳路徑計算中，每個節(jié)點根據(jù)其最佳知識僅確定下一跳。在入口路徑計算方案的情況下，作為請求連接的節(jié)點的入口節(jié)點也指定路由。最后，如在IETF RFC 4655 UA Path Computation Element (PCE)-BasedArchitecture”中所描述,在集中路徑計算方案中,請求連接的節(jié)點(被稱為路徑計算客戶端(PCC))的功能請求特定的單元(被稱為路徑計算單元(PCE))執(zhí)行路徑計算。如在IETFRFC 5440中所描述，在該方案中，路徑計算客戶端與路徑計算單元之間的通信可以基于路徑計算通信協(xié)議(PCEP)。當PCC開始或需要一組路徑的計算時，PCC首先選擇一個或多個PCE。一旦PCC選擇了 PCE，PCC建立到PCE的會話。在接收到連接請求時，PCC向PCE發(fā)送路徑計算請求(PCReq消息)，該請求包含各種對象，這些對象指定了針對要計算的路徑的約束和屬性的集合。每個請求由請求-id號(Request-ID-number)和PCC-PCE地址對唯一標識?！腜CC接收到路徑計算請求,PCE針對該請求計算路徑。如果PCE成功地計算出滿足給定約束的路徑，則PCE向PCC發(fā)送在其中列舉了所計算出的路徑的響應(yīng)。如果無法找到適合的路徑，則PCE對PCC做出響應(yīng)，并指示針對該請求沒有找到路徑。在PCEP中，PCRep消息實現(xiàn)PCE響應(yīng)。存在PCE想要向PCC通知特定事件的多種情況。例如，假設(shè)PCE突然過載，可能導(dǎo)致不可接受的響應(yīng)時間。PCE想要向一個或多個PCC通知(在通知中列出的)PCC的請求中的一些將不會被滿足，或者將經(jīng)歷不可接受的時延。在這些情況下，使用PCNtf消息。當滿足協(xié)議錯誤條件或當請求與PCEP規(guī)范不兼容時，發(fā)送PCEP錯誤消息(也稱為PCErr消息)以指示協(xié)議錯誤情形。文檔IETFRFC 5521 ““Extensions to the Path Computation FlementCommunication Protocol (PCEP) for Route Exclusions” 定義了 PCEP 的擴展，以從路徑計算中排除特定資源。它允許任意資源(如，接口、節(jié)點和域)的強制排除和PCC期望排除。例如，如果PCC知道資源失敗，則它可以將其指定為排除路由對象(XRO)，以告知PCE針對該特定路徑計算避免該XRO。工作組草案建議具有同步路徑計算能力的PCEP的擴展。這允許PCC請求多個并行路徑計算，例如，具有相應(yīng)保護路徑的受保護路徑。文檔IETF RFC 5557“Path ComputationElement Communication Protocol (PCEP) Requirements and Protocol Extensions inSupport of Global Concurrent Optimization”利用并發(fā)的路徑計算請求提供了全局路徑優(yōu)化能力。其它單獨的和工作組的文檔給出了在支持詳細的技術(shù)細節(jié)及多技術(shù)約束的情況下開發(fā)路徑計算請求描述，而不改變整體的PCE通信方案。為了能夠提供路徑，PCE必須了解網(wǎng)絡(luò)和空閑資源。在GMPLS中，參與控制面節(jié)點同步其對網(wǎng)絡(luò)的了解。也就是說，它們廣告其本地資源的TE信息，并收集其它節(jié)點的廣告。為此，它們使用路由協(xié)議的流量工程擴展版本，如在IETF RFC 3630 “Traffic Engineering (TE) extensions to OSPF version 2” 中描述的 0SPF-TE、或在 IETF RFC3784 “Intermediate System to Intermediate System(IS-IS) Extensions for TrafficEngineering (TE) ” 中描述的 ISIS-TE。PCE以與其它節(jié)點相同的方式參與資源廣告過程，并因而收集TE信息。PCE還可以使用如在 IETF RFC 5088 “0SPF Protocol Extensions for Path ComputationElement (PCE)Discovery” 中描述的 0SPF-TE、或如在 IETF RFC 5089 “IS-IS ProtocolExtensions for Path Computation Element (PCE) Discovery” 中描述的 ISIS-TE,向 PCC廣告其能力。IETF 單獨的草案文檔 “draft-lee-pce-ted-alternatives-02. txt” 提供了可選方法，其中PCE直接從節(jié)點收集TE信息。以上描述的資源預(yù)留協(xié)議(RSVP)協(xié)議定義了任意中間節(jié)點報告流相關(guān)失敗(即，ERR0R_SPEC對象)的簡單但有效的方法。該對象在主要錯誤代碼和詳細錯誤值的幫助下對報告問題以及錯誤實質(zhì)的節(jié)點進行編碼。隨著RSVP-TE的開發(fā)，正在制定新的錯誤代碼和新的值。因而，錯誤代碼和錯誤值對適于指定連接失敗的原因。同時，ERR0R_SPEC對象不能準確地描述哪個資源導(dǎo)致了失敗，因為它僅定義了報告節(jié)點。IETF RFC 3473定義了 ERR0R_SPEC對象的新類型，不僅對報告節(jié)點進行編碼，而且還提供攜帶Type-Length-Value (類型-長度-值，TLV)的容器，以標識有問題的用戶面接口。文檔 IETF RFC 4920 ^Crankbaek Signaling Extensions for MPLS and GMPLSRSVP-TE”使得能夠使用額外TLV來描述問題的進一步細節(jié)。利用該擴展，RSVP-TE可以向請求連接的入口節(jié)點提供與失敗的位置和上下文有關(guān)的更準確信息。如果LSP建立失敗，則通過RSVP-TE錯誤信令機制通知給初始節(jié)點，初始節(jié)點可以從PCE請求去往相同目的地的新路徑。這個新的PCReq消息可以包含附加信息，以排除特定錯誤引發(fā)資源，如節(jié)點、接口、自主系統(tǒng)(AS)號、共享風(fēng)險鏈路組(SRLG) ID、標簽或交換類型，將它們列為XRP的子對象。這會給PCE與錯誤的位置有關(guān)的一些暗示，但是并不總能準確地指出該位置或確切的原因。在許多情況下，可以將XRO添加到路徑請求中，因而XRO的出現(xiàn)并不一定意味著在路徑建立期間出現(xiàn)了錯誤，所以使用XRO作為錯誤指示并不恰當。此外，這種錯誤信息提供了機制需要后續(xù)路徑計算請求。當連接請求節(jié)點作為失敗的建立結(jié)果而刪除該信令時，將不會明確地通知PCE連接建立失敗或成功。盡管PCE在接收到對可用網(wǎng)絡(luò)資源的更新時可以推斷連接建立成功，但是這種隱式方式無法確保所計算的路徑與所通知的資源改變之間可靠的一對一映射。除此之外，沒有資源改變并不一定意味著連接建立失敗。現(xiàn)有技術(shù)的缺點意味著，PCE僅可以獲得與所計算路徑的可行性有關(guān)的有限或不適合的信息。因而，只能應(yīng)用影響網(wǎng)絡(luò)性能的有限策略集。例如，即使失敗是短暫的，也會在建立將來的連接時推斷失敗并決定避免特定資源?？蛇x地，PCE可能沒有足夠的信息來推斷資源失敗，于是，將在建立將來的連接時，考慮失敗的資源。在任一情況下，這會導(dǎo)致長的連接建立時間，以及由不成功因而不必要的信令消息導(dǎo)致的增加的信令開銷。

發(fā)明內(nèi)容
本發(fā)明的目的是允許PCE從PCC獲得PCE能夠在建立將來的連接時使用的有用信
肩、O根據(jù)本發(fā)明的第一方案，提供了一種在網(wǎng)絡(luò)中節(jié)點的路徑計算客戶端中使用的方法。所述方法包括向網(wǎng)絡(luò)的路徑計算單元發(fā)送請求計算路徑的請求消息；從路徑計算單元接收響應(yīng)消息，所述響應(yīng)消息包括標識所計算的路徑的信息；以及基于所計算的路徑，嘗試建立連接。所述方法還包括從路徑計算單元接收請求反饋嘗試建立連接的結(jié)果的請求；以及向路徑計算單元報告嘗試建立連接的結(jié)果。這使得PCE能夠改進其對網(wǎng)絡(luò)的了解，并對將來的路徑計算請求提供更好的應(yīng)答。所述方法可以包括例如，通過路徑計算單元協(xié)議對象、或通過路徑計算單元協(xié)議對象的Type-Length-Value (類型-長度-值)，在路徑計算單元協(xié)議消息中向路徑計算單元報告嘗試建立連接的結(jié)果。向路徑計算單元報告嘗試建立連接的結(jié)果可以包括報告嘗試是否成功；以及如果嘗試失敗，則提供關(guān)于失敗的附加信息。例如，所述報告可以提供與失敗的原因和/或失敗的位置有關(guān)的附加信息。在一些實施例中，請求反饋嘗試建立連接的結(jié)果的請求包括在來自路徑計算單元的、包括標識所計算的路徑的信息的響應(yīng)消息中。在這種情況下，來自路徑計算單元的、包括標識所計算的路徑的信息的響應(yīng)消息可以包括標識請求消息的對象；所述方法還可以包括當向路徑計算單元報告嘗試建立連接的結(jié)果時，包括標識請求消息的對象。所述方法可以包括作為向路徑計算單元請求計算路徑的后續(xù)請求消息的一部分，向路徑計算單元報告嘗試建立連接的結(jié)果。 所述方法還可以包括廣告路徑客戶端能夠向路徑計算單元提供這種報告。根據(jù)本發(fā)明的第二方案，提供了一種在網(wǎng)絡(luò)的路徑計算單元中使用的方法，所述方法包括從網(wǎng)絡(luò)中的節(jié)點的路徑計算客戶端接收請求計算路徑的請求；基于所述請求，計算路徑；以及向路徑計算客戶端發(fā)送響應(yīng)消息，所述響應(yīng)消息包含標識所計算的路徑的信息。所述方法還包括向路徑計算客戶端發(fā)送請求反饋嘗試建立連接的結(jié)果的請求；以及從路徑計算客戶端接收與嘗試建立連接的結(jié)果有關(guān)的報告。于是，可以在將來的路徑計算中使用與嘗試建立連接的結(jié)果有關(guān)的報告。
例如，可以通過路徑計算單元協(xié)議對象、或通過路徑計算單元協(xié)議對象的Type-Length-Value (類型-長度-值)，在路徑計算單元協(xié)議消息中，接收與嘗試建立連接的結(jié)果有關(guān)的報告。從路徑計算客戶端接收報告的步驟可以包括接收關(guān)于嘗試是否成功的報告；以及如果嘗試失敗，則提供關(guān)于失敗的附加信息。例如，所述報告可以提供與失敗的原因和/或失敗的位置有關(guān)的附加信息。路徑計算單元可以將請求反饋嘗試建立連接的結(jié)果的請求包括在給路徑計算客戶端的響應(yīng)消息中。在這種情況下，可以將標識所述請求的對象包括在給路徑計算客戶端的響應(yīng)消息中；所述方法還可以包括當接收與嘗試建立 連接的結(jié)果有關(guān)的報告時，接收標識請求消息的對象。在一些實施例中，所述方法還可以包括作為從路徑計算客戶端請求計算路徑的后續(xù)請求消息的一部分，從路徑計算客戶端接收嘗試建立連接的結(jié)果。所述方法可以包括僅當接收到路徑計算客戶端能夠向路徑計算單元提供這種報告的通知時，發(fā)送反饋請求。根據(jù)本發(fā)明的其它方案，提供了被配置為執(zhí)行這些方法的路徑計算客戶端和路徑計算單元。


圖I是示出了根據(jù)本發(fā)明的方案進行操作的網(wǎng)絡(luò)的一部分的示意圖。圖2是示出了根據(jù)本發(fā)明的方法的第一信令時序圖。圖3是示出了根據(jù)本發(fā)明的方法的第二信令時序圖。圖4示出了用于根據(jù)本發(fā)明的一個方案的第一報告對象的形式。圖5示出了用于根據(jù)本發(fā)明的一個方案的第二報告對象的形式。
具體實施例方式圖I示出了基于通用多協(xié)議標簽交換(GMPLS)的網(wǎng)絡(luò)10，具有多個節(jié)點12、14、16、18、20。應(yīng)該理解，在現(xiàn)實中，網(wǎng)絡(luò)可能包含比這里所示出的數(shù)量多的模式節(jié)點，但是這里所示出的數(shù)量足以理解本發(fā)明。如圖I中的箭頭所示，節(jié)點12、14、16、18、20相互連接。節(jié)點12具有用于控制與其它節(jié)點的交互的接口 22，以及運行在處理器26上的路徑計算客戶端(PCC) 24，PCC的行為將在以下進行更加詳細的描述。將會理解，節(jié)點12具有各種其它傳統(tǒng)特征，但是該描述足以理解本發(fā)明。其它節(jié)點14、16、18、20可以與節(jié)點12基本類似，但是對節(jié)點12的操作的理解足以理解本發(fā)明。如網(wǎng)絡(luò)10中的其它節(jié)點一樣，節(jié)點12具有與路徑計算單元(PCE) 28的連接。路徑計算單元28具有與其它節(jié)點的路徑計算客戶端連接的接口 30，以及用于控制其操作的處理器32。如將在以下更加詳細地描述的，本發(fā)明的一個方案在于，針對PCE的請求，連接入口節(jié)點中的PCC應(yīng)通知PCE基于所計算的路徑建立連接成功還是出現(xiàn)錯誤。為了實現(xiàn)上述操作，優(yōu)選地，每個PCC應(yīng)發(fā)信號通知或廣告它發(fā)送這種連接建立報告的能力。例如，該能力可以在PCC-PCE握手期間(即，在兩個實體建立連接時)傳送給PCE。可以利用描述節(jié)點的這一能力的可選Type-Length-Value (類型-長度-值,TLV)來擴展開放對象，或者可以使用開放對象的未分配標記?？蛇x地，如在RFC 5073中描述的，PCC的能力可以使用用于廣告節(jié)點能力的開放最短路徑優(yōu)先流量工程(OSPF-TE)或中間系統(tǒng)間流量工程(ISIS-TE)鏈路狀態(tài)廣告(LSA)來廣告PCC的能力。一個實施方式可以利用節(jié)點能力(子)TLV尚未分配的比特之一。第三可選方案是在請求路徑計算的消息中發(fā)信令通知該能力(即，按照每個請求)。再次，消息中未使用的比特可以用作針對此目的的標記。針對此目的使用PCEP會話建 立消息具有以下優(yōu)點定義開放對象來傳遞各種會話特性。如果PCC想要限制必須發(fā)送的連接建立報告的數(shù)量，則基于每個請求發(fā)信令通知該能力是有益的。這些可選方案中的任何一個使PCE知道PCC具有這里所描述的附加能力，因而PCE可以請求PCC報告連接建立的結(jié)果。圖2是信號流時序圖，示出了在使用集中式路徑計算方案的情況下針對典型的標簽交換路徑(LSP)建立過程的消息流。特別地，這里假設(shè)節(jié)點12是入口節(jié)點，即，數(shù)據(jù)50進入網(wǎng)絡(luò)10并請求連接的節(jié)點，并假設(shè)節(jié)點12想要與出口節(jié)點(例如，節(jié)點18)建立LSP。為了建立路徑，節(jié)點12的PCC 24首先選擇PCE，在這種情況下是PCE 28。如在路徑計算通信協(xié)議(PCEP)中定義的，一旦PCC 24選擇了 PCE 28，PCC 24便與PCE建立會話(如果會話還未建立)，并以PCReq消息的形式向PCE發(fā)送路徑計算請求消息52。PCReq消息可以包含指定了針對要計算的路徑的約束和屬性的集合的對象。PCReq消息包含請求參數(shù)(RP)對象,該RP對象包含Request-ID-number (請求ID號)和一些附加標記和數(shù)據(jù)。通過Request-ID-number和PCC-PCE地址對來唯一地標識每個請求。一旦從PCC 24接收到路徑計算請求，PCE 28嘗試針對該請求計算路徑(即，從入口節(jié)點12到出口節(jié)點28的中間節(jié)點集合)。如在路徑計算通信協(xié)議(PCEP)中定義的，PCRep消息實現(xiàn)PCE響應(yīng)。如果PCE 28成功計算出滿足給定約束的路徑，則PCE 28向PCC24發(fā)送通過顯式路由對象(ERO)列舉了所計算出的路徑的響應(yīng)54。響應(yīng)消息54還包括RP對象(包含Request-ID-number),從而響應(yīng)消息54可以與請求消息52正確地相關(guān)聯(lián)。如果不能找出合適的路徑，則PCE以具有“無路徑”對象的PCRep消息對PCC進行響應(yīng)。然后，節(jié)點12可以刪除路徑建立，并向請求功能發(fā)布錯誤，或者可以改變約束并重試路徑計算。如上所述，將向PCE 28通知在入口節(jié)點12處的PCC 24接受PCR印消息，其中PCE請求連接建立結(jié)果報告。因而，對PCC 24的列舉了所計算路徑的響應(yīng)54可以具有標記集合，以指示請求連接建立結(jié)果報告。如果請求連接建立結(jié)果報告，則PCE 28可以采取準備接收報告所必須的其它步驟。例如，PCE 28可以臨時存儲全部原始請求，或者可以延遲其它計算請求。因此，在該示例中，PCE通過在消息中設(shè)置指示所計算路徑的標記，請求與嘗試建立連接的結(jié)果有關(guān)的反饋。然而，同樣可能的是，PCE會獨立于標識所計算路徑的消息，發(fā)送請求反饋嘗試建立連接的結(jié)果的消息。在這種情況下，可以在標識所計算路徑的消息之前或之后發(fā)送請求反饋的消息。如果在響應(yīng)消息54中設(shè)置標記，則PCC 24 (在56)存儲唯一地標識了(從RP對象獲得的)請求的請求ID，使得PCC 24將能夠在發(fā)送建立報告時回引到該請求。在以包含路由的PCR印消息的形式接收到肯定響應(yīng)之后，入口節(jié)點12嘗試使用資源預(yù)留協(xié)議(RSVP)信令58建立數(shù)據(jù)路徑。立即或稍后，入口節(jié)點12將在消息60中接收Resv消息(指示在建立期間成功的路徑建立和資源預(yù)留)或PathEn■消息(指示建立失敗)。任意PathErr消息指定錯誤對象。例如,PathErr消息包括詳細描述失敗的位置和原因的ErrorSpec對象。接收到Resv消息或PathErr消息，PCC 24 (在62)再調(diào)用所存儲的包含針對RSVP會話的PCEP Request-ID-number的RP對象。然后，PCC 24向PCE 28發(fā)送包含RP對象的消息64,該RP對象包括該Request-ID-number和發(fā)信息通知建立的成功或失敗的報告。在嘗試建立路徑不成功的情況下，消息64還可以包含來自ErrorSpec對象的將失敗的原因和位置細節(jié)化的信息。以下將更加詳細地描述PER印消息64的形式。
圖2中示出的過程期望PCE 28的有狀態(tài)行為，即，在響應(yīng)請求之后不立即丟棄該請求的細節(jié)。在本發(fā)明的一些實施例中，PCE可能無法存儲這種信息，或者這種信息可以被認為是不期望的。圖3示出了可以用于PCE 28的行為是無狀態(tài)的情況的過程。圖3中示出的過程與圖2中示出的過程有些類似，以相同的參考數(shù)字標注的步驟是相同的，在此不再進行描述。在這種情況下，當PCC 24接收列舉了所計算出的路徑、具有標記集合、指示請求連接建立結(jié)果報告的響應(yīng)54時，PCC 24 (在70)不僅存儲請求ID，還存儲響應(yīng)54中包含的原始請求和ERO。然后，已經(jīng)在60接收到Resv消息或PathErr消息，PCC 24 (在72)針對RSVP會話不僅調(diào)用如在70所存儲的PCEP請求ID，還調(diào)用在響應(yīng)54中包含的原始請求和ER0。然后，在PER印響應(yīng)消息74中，PCC 24還向PCE 28發(fā)送該附加信息。因而，即使在這種情況下，報告路徑計算的結(jié)果也是有意義的，因為PCE 28可以將該信息包括在其TE數(shù)據(jù)庫中。盡管提供對原始請求的回引可能是無意義的，但是PCC利用原始請求和PCE的應(yīng)答的細節(jié)來擴展報告可以克服這一點。
因此，針對PCE的請求，連接入口節(jié)點中的PCC通知PCE基于所計算路徑建立連接是否是成功的，或者是否出現(xiàn)錯誤。在失敗的情況下，PCC可以提供與失敗的位置有關(guān)的詳細信息、以及與失敗的原因有關(guān)的信息。針對成功的連接建立，PCC可以向PCE提供信令發(fā)送期間收集的多個屬性。這使得PCE能夠改進其對網(wǎng)絡(luò)的了解，并對將來的路徑計算請求提供更好的應(yīng)答。現(xiàn)在將更加詳細地描述在本發(fā)明的一個實施例中的報告的結(jié)構(gòu)。在該實施例中，通過對PCEP的擴展，來提供報告，更新標準PCC-PCE通信方案?？梢砸詥为毜南崿F(xiàn)該報告步驟，或者該報告步驟可以包括在同一連接請求的后續(xù)路徑計算請求消息中?！愣?，建立結(jié)果報告結(jié)構(gòu)應(yīng)包含關(guān)于LSP建立是否成功的指不；以及失敗原因的編碼(如果發(fā)生失敗)；連接建立失敗的節(jié)點的標識符；以及連接建立失敗的數(shù)據(jù)面接口的標識符。報告消息可以包含失敗引發(fā)資源的詳細信息；以及PCE提供的路由(失敗情況下)或連接建立期間記錄的路由(在連接建立成功情況下)。圖4示出了在建立結(jié)果結(jié)構(gòu)是單獨的PCEP對象90的情況下、一種可能的報告形式，該報告包括在PCEP消息中。圖5示出了報告的可選形式，其中將報告定義為TLV 92，以便包括在其它PCEP對象中。在任一情況下，利用錯誤代碼94和錯誤值96屬性對，對關(guān)于嘗試建立路徑是成功還是失敗的指示與失敗原因一起進行編碼。將錯誤代碼字段的值設(shè)置為0指示成功建立了連接，在這種情況下，錯誤值字段的內(nèi)容不相關(guān)。錯誤代碼字段的非零值指示失敗，同時錯誤值提供了錯誤的原因。這里也應(yīng)用被定義用在RSVP-TE中的錯誤代碼和錯誤值對。使用IPv4或IPv6路由器ID標識連接建立失敗的節(jié)點，也包含在RSVP-TE錯誤規(guī)范(ERR0R_SPEC)對象之一中。建立結(jié)果結(jié)構(gòu)在“報告節(jié)點的路由器ID”字段98中攜帶該屬性。將引起故障的數(shù)據(jù)面接口標識為RSVP-TE IF_ID ERR0R_SPEC對象的特定TLV。如在IETF RFC 4920中所定義的，RSVP-TE可以提供對導(dǎo)致失敗的資源的進一步細節(jié)進行編碼的其它TLV，作為TLV集合。從RSVP-TE IF_ID ERR0R_SPEC對象中獲得該標識的用戶面接口和任何這種進一步的細節(jié)，并且該標識的用戶面接口和任何這種進一步的細節(jié)作為子 TLV包括在建立結(jié)果結(jié)構(gòu)90、92的預(yù)留TLV空間100中。如上所述，PCEP是用于路徑請求和PCC與PCE之間的響應(yīng)的協(xié)議，其消息格式和編碼在IETF RFC 5440中定義。這里描述的擴展可以使PCC向PCE傳送LSP建立的結(jié)果，包括與失敗原因有關(guān)的細節(jié)。如參照圖4或5所述，例如，可以通過對PCEP進行擴展來實現(xiàn)包括SETUP_RESULT的PER印消息構(gòu)造64或74的傳輸，但也可以使用其它方法?！N可能是利用了現(xiàn)有通知消息對象的一般通知選項。它定義了新的通知類型(NT = 3)，用于指示當前通知對連接建立的結(jié)果進行編碼。該類型的任何通知總是必須確切地引用一個計算請求這意味著，建立結(jié)果報告通知必須跟隨單個RP對象。如果這種通知對象引用0個或多于I個請求(RP對象)，則必須引發(fā)無效對象的PCErr消息。在控制標記中，R比特必須為0，同時如常配置所有其它標記。通知值(NV)對連接建立的結(jié)果進行編碼。定義以下值NV = 0 :無回溯地建立了連接(SETUP_RESULT的錯誤代碼和值必須被設(shè)為0)。NV = I :有回溯地建立了連接(SETUP_RESULT的錯誤代碼和值必須被設(shè)為0)。NV = 2 :連接建立失敗(SETUP_RESULT的錯誤代碼和值詳細描述錯誤原因)。為了向通知添加內(nèi)容，可以將SETUP_RESULT TLV嵌入通知對象。該TLV攜帶在連接建立期間獲得的多個或全部屬性。PCE計算的路由可以作為ERO對象提供，并且可以包括在PCntf消息中緊挨在通知對象之后?？蛇x方案是顯式消息選項，定義全新的PCEP消息，被稱為PCE路徑計算結(jié)果(PCRes)。該消息的格式如下所描述
<PCKes Message) : :=<C()mmon lleadcr)
<report,- I i st,>
<rcporl-lisl>: : =<rc、r)orI.) [<report-list>]

〈report〉 = <KP><S!TLI)_KI-SLLT>[<orig-rcq><!K()>] <()rig-req> ::= <l；\l)-l)() I\TS>
[<LSPA>]
[<BANDWIDTH)]
[<moIric-Iist>]]
[<IR0>]
[〈LOAD-BALANCING〉]
<mc lric-!ist>: : =<M!；Tk IO [ <me tric-1 ist>]單個PCRes消息可以包含一個或多個在先的計算請求的建立結(jié)果報告。每個報告包含對路徑計算請求標識符進行編碼的RP對象、對結(jié)果編碼的SETUP_RESULT對象。可選地，可以攜帶原始請求的說明以及PCE報告路徑(ERO)。另一可選方案是基于對現(xiàn)有路徑計算請求對象進行擴展的捎帶選項。這僅能用于在請求去往相同目的地的新路徑時的否定LSP建立結(jié)果的情況。更新的PCReq消息格式是
<I5CKeq MesSfige) : : =〈Common Header)
[<svec- I i s t.>]
<>叫11081'-丄 I SI
<svec- I i sl>: : =<SV!^C> [<svec- I i st,>]
<request..- I i sI> : : =<roqiicsl> [<request,- I i sI>]
<rcqucsl> : = <RI)>
<['NIH)0l\TS>
[<LSPA>]
[<!))/\\[)W!I)T!l>]
[<RK()>[<!,>A\[)WM)TH>]]

[<IRO>]
[〈SI:11 丨)—K丨:SLI；T><o!d_req_desc>]
<o 丨 d—ck:'sc> : : =<()I,!)_RI)> [<or i g—rcgXI'R()>]
<orig-rcq> ::= <[；\I)-P()I\TS>
[<LSPA>]
[<!,.A\[)WM)T[!>]
[<mct.r i c- I i s t.>]
[<RKO>[<[))/\\I)W[DTH>]]
[<IRO>]
[<L()A[)-I5ALA\C[\(；>]
〈metric-11 si > :=<MI:；TR IO [<inc'lr i.c-list〉]SETUP_RESULT對象對在先的連接建立嘗試的結(jié)果進行編碼。因而，由于可以假設(shè)該在先的嘗試不成功，錯誤代碼不應(yīng)被設(shè)為O。old_req_desc結(jié)構(gòu)定義了失敗的連接建立嘗試的細節(jié)，并包含請求描述符(0LD_RP)以及所計算的路徑，原始請求的其它細節(jié)(orig-req結(jié)構(gòu))?？梢砸孕聦ο蠡騌P對象的變體來實現(xiàn)0LD_RP對象。在后一1清況下，“對象類型”用于區(qū)分后續(xù)請求(在請求的前端RP對象中攜帶)和失敗的請求(由在先的請求使用并在0LD_RP對象中攜帶)。因此，以上描述了 PCC可以向PCE提供與建立路徑的成功嘗試有關(guān)的反饋所使用的方法。當PCE從PCC接收到LSP建立錯誤指示時，PCE可以將該信息包括在其數(shù)據(jù)庫中，以便使用該信息表明針對之后的路徑計算請求的臨時策略，有助于在將來提供更好的路徑計算。類似地，當接收詳細的路徑建立信息時，PCE可以將該信息包括在其數(shù)據(jù)庫中。這可以提供附加信息(如，所選波長和估計的光衰減)，出于可擴縮性(scalability)的考慮，不可能通過內(nèi)部網(wǎng)關(guān)協(xié)議流量工程(IGP-TE)對該信息進行廣告。例如，在波長交換 光網(wǎng)絡(luò)(WSON)的情況下，期望光節(jié)點的內(nèi)部結(jié)構(gòu)的信息模型來提供這些節(jié)點的非常復(fù)雜的TE描述符。因而，出于可擴縮性的原因，運營商可以決定不利于鏈路狀態(tài)路由協(xié)議來廣告完整的描述。因而，PCE不可能具有來自路由協(xié)議的、關(guān)于哪個(哪些)波長可以通過網(wǎng)絡(luò)從一端路由到另一端的精確信息。然而，這里所提出的擴展使PCE能夠收集波長可用性信息，即使波長分配是分布式的。特別地，連接入口節(jié)點可以在連接建立結(jié)果中報告最終預(yù)留的分配波長。因而描述了這樣一種系統(tǒng)，在該系統(tǒng)中，在通用多協(xié)議標簽交換網(wǎng)絡(luò)中，路徑計算客戶端可以向路徑計算單元提供反饋，使得路徑計算單元可以將該信息用于進一步的路徑計算決策。
權(quán)利要求
1.一種在網(wǎng)絡(luò)中節(jié)點的路徑計算客戶端(24)中使用的方法，所述方法包括 向網(wǎng)絡(luò)的路徑計算單元(28)發(fā)送請求計算路徑的請求消息(52)； 從路徑計算單元接收響應(yīng)消息(54)，所述響應(yīng)消息(54)包括標識所計算的路徑的信息；以及 基于所計算的路徑，嘗試(58)建立連接； 其特征在于，所述方法還包括 從路徑計算單元接收請求反饋嘗試建立連接的結(jié)果的請求；以及 向路徑計算單元報告(64)嘗試建立連接的結(jié)果。
2.根據(jù)權(quán)利要求I所述的方法，包括 在路徑計算單元協(xié)議消息中報告嘗試建立連接的結(jié)果。
3.根據(jù)權(quán)利要求I或2所述的方法，其中向路徑計算單元報告嘗試建立連接的結(jié)果包括 報告嘗試是否成功；以及 如果嘗試失敗，則提供關(guān)于失敗的附加信息。
4.根據(jù)權(quán)利要求1、2或3所述的方法，其中請求反饋嘗試建立連接的結(jié)果的請求包括在來自路徑計算單元的、包括標識所計算的路徑的信息的響應(yīng)消息中。
5.根據(jù)權(quán)利要求4所述的方法，其中來自路徑計算單元的、包括標識所計算的路徑的信息的響應(yīng)消息包括標識請求消息的對象；以及所述方法還包括 當向路徑計算單元報告嘗試建立連接的結(jié)果時，包括標識請求消息的對象。
6.根據(jù)權(quán)利要求I所述的方法，包括 作為向路徑計算單元請求計算路徑的后續(xù)請求消息的一部分，向路徑計算單元報告(64)嘗試建立連接的結(jié)果。
7.—種網(wǎng)絡(luò)中節(jié)點的路徑計算客戶端(24)，其中所述路徑計算客戶端被配置為 向網(wǎng)絡(luò)的路徑計算單元(28)發(fā)送請求計算路徑的請求消息(52);以及 從路徑計算單元接收響應(yīng)消息(54)，所述響應(yīng)消息(54)包括標識所計算的路徑的信息； 基于所計算的路徑，嘗試(58)建立連接； 其特征在于，所述路徑計算客戶端還被配置為 從路徑計算單元接收請求反饋嘗試建立連接的結(jié)果的請求；以及 向路徑計算單元報告(64)嘗試建立連接的結(jié)果。
8.—種在網(wǎng)絡(luò)中的路徑計算單元(28)中使用的方法，所述方法包括 從網(wǎng)絡(luò)中的節(jié)點的路徑計算客戶端(24)接收請求計算路徑的請求(52)； 基于所述請求，計算路徑；以及 向路徑計算客戶端發(fā)送響應(yīng)消息(54)，所述響應(yīng)消息包含標識所計算的路徑的信息； 其特征在于，所述方法還包括 向路徑計算客戶端發(fā)送請求反饋嘗試建立連接的結(jié)果的請求；以及 從路徑計算客戶端接收與嘗試建立連接的結(jié)果有關(guān)的報告(64)。
9.根據(jù)權(quán)利要求8所述的方法，還包括 在將來的路徑計算中使用與嘗試建立連接的結(jié)果有關(guān)的報告。
10.根據(jù)權(quán)利要求8或9所述的方法，包括 在路徑計算單元協(xié)議消息中，接收與嘗試建立連接的結(jié)果有關(guān)的報告。
11.根據(jù)權(quán)利要求8、9或10所述的方法，其中從路徑計算客戶端接收報告的步驟包括 接收關(guān)于嘗試是否成功的報告；以及 如果嘗試失敗，則提供關(guān)于失敗的附加信息。
12.根據(jù)權(quán)利要求8、9、10或11所述的方法，包括將請求反饋嘗試建立連接的結(jié)果的請求包括在給路徑計算客戶端的響應(yīng)消息中。
13.根據(jù)權(quán)利要求12所述的方法，還包括 將標識所述請求的對象包括在給路徑計算客戶端的響應(yīng)消息中，以及所述方法還包括 當接收與嘗試建立連接的結(jié)果有關(guān)的報告時，接收標識請求消息的對象。
14.根據(jù)權(quán)利要求8所述的方法，還包括 作為從路徑計算客戶端請求計算路徑的后續(xù)請求消息的一部分，從路徑計算客戶端接收嘗試建立連接的結(jié)果。
15.一種網(wǎng)絡(luò)的路徑計算單元，其中所述路徑計算單元被配置為 從網(wǎng)絡(luò)中的節(jié)點的路徑計算客戶端接收請求計算路徑的請求； 基于所述請求，計算路徑；以及 向路徑計算客戶端發(fā)送響應(yīng)消息，所述響應(yīng)消息包含標識所計算的路徑的信息； 其特征在于，所述路徑計算單元還被配置為 向路徑計算客戶端發(fā)送請求反饋嘗試建立連接的結(jié)果的請求；以及 從路徑計算客戶端接收與嘗試建立連接的結(jié)果有關(guān)的報告。
全文摘要
網(wǎng)絡(luò)中節(jié)點的路徑計算客戶端(24)向網(wǎng)絡(luò)的路徑計算單元(28)發(fā)送請求計算路徑的請求消息(52)；以及路徑計算單元發(fā)送包含標識所計算的路徑的信息的響應(yīng)消息(54)。路徑計算單元還發(fā)送請求反饋嘗試建立連接的結(jié)果的請求。路徑計算單元基于所計算的路徑嘗試建立連接，并向路徑計算單元報告嘗試建立連接的結(jié)果。
文檔編號H04L12/56GK102714621SQ201080059796
公開日2012年10月3日 申請日期2010年1月4日 優(yōu)先權(quán)日2010年1月4日
發(fā)明者大衛(wèi)·約查, 安德拉斯·塞薩, 安德拉斯·科恩 申請人:瑞典愛立信有限公司