專利名稱：一種處理報文的方法和裝置的制作方法
技術領域：
本發(fā)明涉及通信技術，具體涉及一種處理報文的方法和裝置。
背景技術：
隨著人們對通信需求在不斷增長，導致網(wǎng)絡規(guī)模越來越大，提供商邊緣(Provider edge,ΡΕ)節(jié)點越來越多。而且，網(wǎng)絡扁平化的趨勢也使得每一層的網(wǎng)絡規(guī)模在變大。在大 規(guī)模網(wǎng)絡下，如何規(guī)劃流量，使得網(wǎng)絡整體利用效率提高，是關系到運營商投資收益的重要 問題。另外，差異化服務是運營商營銷的重要策略，如何在同一張網(wǎng)絡中提供差異化服務， 直接關系到運營商市場的成功與否。同時，隨著市場競爭激烈化，用戶要求也越來越高，其 中高可靠性的通信質量是至關重要的，這種要求反映到到網(wǎng)絡技術上，就是PE之間通信如 何保證服務質量(QoS，Qualityof Service)和可靠性。流量工程(TE，Traffic Engineering)技術能很好的滿足上述要求。TE能指定顯 式路徑，滿足用戶網(wǎng)絡規(guī)劃的需求；TE通過區(qū)分服務流量工程(DS-TE，Diffserv Traffic Engineering)，可以提供差異化服務；TE支持快速重路由(FRR，F(xiàn)ast Reroute)、端到端保 護，能滿足不同層次的可靠性需求。但是隨著網(wǎng)絡的規(guī)模變大，TE擴展性不足的情況開始呈 現(xiàn)由于TE是軟狀態(tài)刷新協(xié)議，每條標簽交換路徑(LSP，Label-Switch Path)的狀態(tài)塊需 要定期刷新，限制了單個資源預留協(xié)議(RSVP，Resource Reservation Protocol)實例能夠 支持的LSP數(shù)量，并且，每條LSP都需要占用狀態(tài)塊，耗用內存資源，也限制了單個RSVP實 例能夠支持的LSP數(shù)量?，F(xiàn)有技術采用標簽分發(fā)協(xié)議(LDP，Label Distribution Protocol)疊加在TE上 (LDP over TE, Laber Distribution Protocol over TE)，來減少單個 RSVP 實例中的 LSP 的數(shù)量，如圖1所示，LDP over TE技術的特點是在網(wǎng)絡的核心節(jié)點部署TE，在邊緣節(jié)點部 署LDP。這種方式既具有部分TE的特點，又能夠避免網(wǎng)絡過大帶來的TE擴展性問題。但 是，在LDP區(qū)域不能實現(xiàn)帶寬預留功能，因此，不能在PE節(jié)點間提供完整的流量規(guī)劃，也不 能提供差分服務，降低數(shù)據(jù)傳輸?shù)目煽啃?。也可以采用TE層次化的方法來減少核心節(jié)點或者RSVP實例中的狀態(tài)塊的數(shù)量和 開銷。如圖2所示，提供商(P，Provider)節(jié)點之間可以先建立互聯(lián)的TE隧道，PE之間互 聯(lián)的隧道可以疊加在P節(jié)點之間的隧道上，這樣PE之間的TE隧道僅在相近的兩個P節(jié)點 上存在控制塊和刷新開銷。當兩個PE需要通信時，兩個PE之間的P節(jié)點已經(jīng)建立互聯(lián)TE 隧道作為底層隧道，兩個PE節(jié)點的互聯(lián)隧道的狀態(tài)塊和刷新僅被與PE相連的P節(jié)點感知， 其他P節(jié)點不感知。該方案采用TE層次化技術需要以網(wǎng)絡拓撲層次化作為基礎，本質上需 要引入更多的設備，去分擔PE互聯(lián)帶來的大量LSP，不能從根源上解決單個RSVP實例不能 支持大量LSP的問題。發(fā)明人在實現(xiàn)本發(fā)明的過程中，發(fā)現(xiàn)現(xiàn)有技術至少存在的缺陷是單個RSVP實例 支持的LSP數(shù)量非常有限，嚴重影響網(wǎng)絡側對數(shù)據(jù)的傳輸速度，需要增加網(wǎng)絡設備，造成網(wǎng) 絡布局復雜，成為擴大網(wǎng)絡規(guī)模的瓶頸。

發(fā)明內容
本發(fā)明實施例提供的一種處理報文的方法和裝置，克服了現(xiàn)有技術中單個RSVP 實例支持的LSP數(shù)量非常有限，嚴重影響網(wǎng)絡側對數(shù)據(jù)的傳輸速度的缺點。本發(fā)明實施例提供了一種處理報文的方法，包括第一套接字接收上游節(jié)點發(fā)送的報文，將接收到的報文發(fā)送給上游鄰居管理；上游鄰居管理將接收到的報文發(fā)送給核心處理實例；所述核心處理實例根據(jù)接收到的所述報文，執(zhí)行業(yè)務處理，生成處理后的第一報 文；所述核心處理實例將所述處理后的第一報文發(fā)送給下游鄰居管理，由下游鄰居管 理將處理后的第一報文通過第二套接字發(fā)送給下游節(jié)點。本發(fā)明實施例還提供了一種處理報文的裝置，包括第一套接字，上游鄰居管理， 核心處理實例，下游鄰居管理，和第二套接字；所述第一套接字，用于接收上游節(jié)點發(fā)送的報文，將接收到的報文發(fā)送給上游鄰
居管理；上游鄰居管理，用于接收第一套接字發(fā)送的報文，將接收到的報文發(fā)送給所述核 心處理實例；核心處理實例，用于接收上游鄰居管理發(fā)送的報文，執(zhí)行業(yè)務處理，生成處理后的 第一報文；將所述處理后的第一報文發(fā)送給下游鄰居管理；下游鄰居管理，用于接收所述核心處理實例發(fā)送的處理后的第一報文，將所述處 理后的第一報文發(fā)送給第二套接字；第二套接字，用于接收下游鄰居管理發(fā)送的處理后的第一報文，將所述處理后的 第一報文發(fā)送給下游節(jié)點。本發(fā)明實施例提供的一種處理報文的方法和裝置，通過采用將RSVP實例劃分為 匪和CORE兩部分，實現(xiàn)對上游節(jié)點發(fā)送的報文的處理，可以靈活的擴展匪和CORE的數(shù)量， 且可以將業(yè)務更合理的分配到多個CORE中，從而大大提高了 RSVP實例所支持的LSP數(shù)量， 且大大提高了 RSVP的工作效率。


為了更清楚地說明本發(fā)明實施例中的技術方案，下面將對實施例描述中所需要使 用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于 本領域普通技術人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其 他的附圖。圖1為LDP over TE技術的組網(wǎng)示意圖；圖2為采用TE層次化方案組網(wǎng)示意圖；圖3為建立TE的LSP的網(wǎng)絡示意圖；圖4為本發(fā)明實施例提供的處理報文方法的總體流程圖；圖5為本發(fā)明實施例提供的處理報文方法的流程示意圖；圖6為本發(fā)明實施例提供的建立Peer地址與匪關聯(lián)關系示意簡圖7為本發(fā)明實施例中業(yè)務分配器為業(yè)務分配CORE操作的示意簡圖；圖8為本發(fā)明實施例提供當裝置中匪與CORE數(shù)量比為1 1時，節(jié)點的處理流 程示意簡圖；圖9為本發(fā)明實施例提供的部署的包括一個匪和多于一個的CORE的裝置示意 圖；圖10為本發(fā)明實施例提供的部署的包括多于一個NM和一個CORE的裝置示意圖；圖11為本發(fā)明實施例提供的部署匪與CORE的數(shù)量比值為1 1的裝置；圖12為本發(fā)明實施例提供的一種裝置的示意圖。
具體實施例方式為了使本技術領域的人員更好地理解本發(fā)明實施例的方案，下面結合附圖和實施 方式對本發(fā)明實施例作進一步的詳細說明。圖3所示為建立TE的LSP的網(wǎng)絡示意圖。LSP的建立是由正向的path消息和反向 的resv消息來實現(xiàn)的。并且path消息和resv消息會定期刷新。在本實施例中，節(jié)點將消息 刷新業(yè)務按照報文分發(fā)規(guī)則分配到該節(jié)點的一個或者多于一個的鄰居管理(匪，Neighbor Manager)實例中，將核心業(yè)務處理按照業(yè)務分布規(guī)則分配到該節(jié)點一個或者多于一個核心 處理實例中，這種核心處理實例可以稱為CORE。其中，核心業(yè)務處理是指在LSP建立過程 中，需要本節(jié)點進行的資源和表項處理。具體可包括為LSP分配入標簽；為LSP申請預留 帶寬；將入標簽和出標簽表項下發(fā)到接口板，用于MPLS報文轉發(fā)等。因此，在一個節(jié)點內存 在至少一個匪和至少一個CORE，且匪和CORE之間具有對應關系。匪和CORE是根據(jù)功能 上的不同而劃分的，匪和CORE可以分別由相應的獨立的硬件資源實現(xiàn)，通常在多核、多主 控板、或者多中央處理單元(CPU，Central Process Unit)時，可以充分顯現(xiàn)出分布式節(jié)點 比現(xiàn)有集中式節(jié)點的優(yōu)勢。NM的功能是維持軟狀態(tài)刷新，多個匪可以分擔刷新的CPU壓 力，CORE的功能是為LSP分配標簽、帶寬、下發(fā)表項，它需要保存LSP控制塊，分布在多個硬 件資源上的CORE之間可以分擔內存壓力，CORE的空閑、繁忙區(qū)別可以體現(xiàn)在對其所在的硬 件資源的內存使用上。在對本發(fā)明實施例做說明之前，對套接字(SOCKET)進行說明，SOCKET中相當于 接口，主要包括三個參數(shù)，即通信的目的IP地址、使用的傳輸層協(xié)議(如傳輸控制協(xié)議 (TCP,Transmission Control Protocol))和使用的端口號，應用層和傳輸層可以通過套接 字，區(qū)分來自不同網(wǎng)絡連接的通信。為了更好的理解本發(fā)明實施例提供的處理報文方法，參考圖4至圖11及其說明。圖4所示為本發(fā)明實施例提供的處理報文方法的總體流程圖，該方法包括步驟S401 第一套接字接收上游節(jié)點發(fā)送的報文，將接收到的報文發(fā)送給上游鄰 居管理(NM)；步驟S402 上游匪將接收到的報文發(fā)送給核心處理實例(CORE)；步驟S403 所述CORE根據(jù)接收到的所述報文，執(zhí)行核心業(yè)務處理，生成處理后的 第一報文；步驟S404 所述CORE將所述處理后的第一報文發(fā)送給下游匪，由下游匪將處理 后的第一報文通過第二套接字發(fā)送給下游節(jié)點。
通過對圖4中提供的一種處理報文方法的說明，該方法采用將節(jié)點劃分為匪和 CORE兩部分，實現(xiàn)對上游節(jié)點發(fā)送的報文的處理，由于在一個節(jié)點內存在至少一個匪和至 少一個CORE，且匪和CORE之間具有對應關系，匪和CORE是根據(jù)功能上的不同而劃分的， NM和CORE可以分別由相應的獨立的硬件資源實現(xiàn)，當有大量的報文需要處理時，可以擴展 NM和CORE的數(shù)量，使得節(jié)點可以支持更多的LSP，同時不會降低該節(jié)點的性能。進一步，該節(jié)點還可以實現(xiàn)對下游節(jié)點發(fā)送的報文的處理，則在步驟404之后，該 方法還包括步驟S405 第二套接字接收所述下游節(jié)點發(fā)送的報文，將所述報文發(fā)送給下游
匪；需要理解的是，下游節(jié)點發(fā)送的報文和步驟401中上游節(jié)點發(fā)送的報文是歸屬于 相同的業(yè)務的。步驟S406 下游匪將所述報文發(fā)送給所述CORE ；其中，下游NM將接收到的報文(如resv消息)，發(fā)送到該報文所歸屬的業(yè)務所在 的CORE中，該CORE與步驟S403中的CORE是同一個CORE。步驟S407 所述CORE根據(jù)接收到的所述下游匪發(fā)送的報文，執(zhí)行業(yè)務處理，生成 處理后的第二報文；步驟S408 所述CORE將所述處理后的第二報文發(fā)送給上游匪，由上游匪將處理 后的第二報文通過第一套接字發(fā)送至所述上游節(jié)點。通過對步驟S405至S408的說明，實現(xiàn)對下游節(jié)點發(fā)送的報文的處理，由于該方法 采用將RSVP實例劃分為匪和CORE兩部分，由于在一個節(jié)點內存在至少一個匪和至少一 個CORE，且匪和CORE之間具有對應關系，匪和CORE是根據(jù)功能上的不同而劃分的，匪和 CORE可以分別由相應的獨立的硬件資源實現(xiàn)，當有大量的報文需要處理時，可以擴展NM和 CORE的數(shù)量，使得節(jié)點可以支持更多的LSP，同時不會降低該節(jié)點的性能。圖5為本發(fā)明實施例提供的處理報文方法的具體流程圖。該方法包括步驟501 第一套接字接收上游節(jié)點發(fā)送的path消息，將該path消息發(fā)送給上游
匪；需要理解的是，該節(jié)點中可以包括多個匪，則接收到path消息后，節(jié)點可以按照 報文分發(fā)規(guī)則將該path消息發(fā)送到對應的NM中。具體可以是按SOCKET中接收報文的端 口號將該報文分布到不同匪中；或者按接收報文的目的地址分布到不同匪中；或者按接 收報文的源地址分布到不同NM中；或者上述規(guī)則的任意組合，將報文發(fā)送給對應的匪中。步驟502 上游匪根據(jù)接收到的path消息，建立接收path消息狀態(tài)塊，其中，建立 的接收path消息狀態(tài)塊中記錄path消息中攜帶的信息，將path消息上報給CORE ；其中，上 游NM在接收到的path消息后，可以檢查該path消息的合法性，當判斷path消息合法后， 執(zhí)行上述建立消息狀態(tài)塊的操作。其中，步驟502中建立的path消息狀態(tài)塊為接收path消息狀態(tài)塊，后續(xù)刷新操作 中，該NM根據(jù)建立的接收path消息狀態(tài)塊，開啟NM中的超時器，接收上游節(jié)點定期發(fā)送的 path消息，當該NM接收到的path消息中攜帶的信息與當前接收path消息狀態(tài)塊中的信 息沒有變化時，匪不會將path消息上報給CORE。當該匪接收到path消息有變化時，匪 更新接收path消息狀態(tài)塊中的記錄，并將path消息上報給CORE。從而減輕了刷新操作對
9CORE的壓力。RSVP同一條業(yè)務需要集中處理，完成資源檢查、申請、下發(fā)表項等過程。但是同一 條LSP的path、resv消息分別來自不同鄰居，且這兩個消息通常會定向到不同的匪中，所 以NM必須能夠將相同LSP的消息發(fā)送到相同的CORE里進行集中業(yè)務處理。從協(xié)議定義的 角度來看，RSVP處理業(yè)務的最小粒度為會話(session)。同一個session下可能存在多條 LSP，在清晰共享(SE，ShareExplicit)風格下，這些LSP在同一個節(jié)點內和共享出接口時通 常需要共享帶寬資源(由協(xié)議選項決定)。所以在SE風格下匪必須能夠保證相同session 的消息能定向到相同的CORE中處理。匪也可以以LSP為粒度將消息分發(fā)到CORE中，并設 立一個集中的資源管理模塊，來實現(xiàn)多個CORE中相同session的LSP的帶寬共享。將同一 session，或者同一 LSP的報文發(fā)送給對應的同一 CORE中進行處理，稱為業(yè)務分布。步驟 502中將path消息上報給CORE的操作可以具體包括根據(jù)業(yè)務分布規(guī)則，NM將path消息 上報給CORE。其中，業(yè)務分布規(guī)則可以包括散列(Hash)方式，集中分配方式，或者部署方 式其中任一種或者任意組合。Hash方式是指按照業(yè)務關鍵字進行hash運算，由hash結果決定執(zhí)行業(yè)務處理 的CORE ；集中分配方式是指設立業(yè)務分發(fā)器構件，將業(yè)務均衡的分發(fā)到多個CORE ；部署方 式是指采用特殊的部署方式，根據(jù)部署特點決定將業(yè)務定向到CORE。在后續(xù)的實施例中 會詳細說明。步驟503 =CORE根據(jù)接收到的path消息，執(zhí)行生成LSP控制塊的處理，生成LSP控 制塊；其中，執(zhí)行生成LSP控制塊的處理，生成LSP控制塊的具體操作可以包括C0RE計算 LSP的下一跳，以及出接口，檢查該節(jié)點是否有足夠資源建立LSP，當判斷出資源充足后，生 成LSP控制塊。否則顯示建立LSP失敗。其中，LSP控制塊用于記錄LSP的屬性(這些屬性來自path消息和resv消息)、 記錄下游節(jié)點給本節(jié)點分配的標簽(即出標簽)，記錄本節(jié)點為上游節(jié)點分配的標簽(即入 標簽)，記錄分配的帶寬。步驟504 =CORE生成發(fā)送給下游節(jié)點的path消息，將該path消息發(fā)送給下游匪， 其中，此處的下游匪可以是與步驟501中的上游匪為同一個匪，也可以是不同于步驟501 中的上游匪。其中，CORE生成發(fā)送給下游節(jié)點的path消息與接收到的path消息相似，但也有 不同，不同在于路徑對象，路徑地址等。同理，后續(xù)的resv消息有相同的說明。步驟504中操作，具體可以是C0RE根據(jù)報文分發(fā)規(guī)則將發(fā)送給下游節(jié)點的path 消息發(fā)送給下游NM。其中，該報文分發(fā)規(guī)則具體可以是按照發(fā)送報文的SOCKET的端口號 (可以理解為報文的出接口，后續(xù)為了便于說明，簡稱“出接口”)分布到不同匪中；或者按 照發(fā)送報文的源地址分布到不同匪中；或者按照發(fā)送報文的目的地址分布到不同匪中； 或者上述規(guī)則的任意組合。步驟505 下游匪接收CORE發(fā)送的path消息，建立path消息狀態(tài)塊，將該path 消息通過套接字(SOCKET)發(fā)送給下游節(jié)點，其中，下游匪具體可以通過第二套接字將path 消息發(fā)送給下游節(jié)點。為了便于和步驟502中上游匪建立的path消息狀態(tài)塊進行區(qū)分，將步驟502中 建立的path消息狀態(tài)塊稱為“接收path消息狀態(tài)塊”，步驟505中下游匪建立的path消息狀態(tài)塊稱為“發(fā)送path消息狀態(tài)塊”。其中，后續(xù)為了維持LSP，定期進行path消息的刷 新的操作，由下游匪，根據(jù)發(fā)送path消息狀態(tài)塊來完成，CORE可以不再干預。上述步驟501至505是節(jié)點對接收到上游節(jié)點發(fā)送的path消息處理的過程，后續(xù) 步驟506至510是節(jié)點對接收到下游節(jié)點發(fā)送的resv消息的處理過程，需要理解的是，節(jié) 點中匪和CROE對resv消息的處理方法與對path消息的處理方法是相似的。下面具體說 明節(jié)點中匪和CROE對resv消息的處理過程。步驟506 該節(jié)點的第二套接字接收到下游節(jié)點發(fā)送的resv消息，將該resv消息 發(fā)送給下游匪；其中，節(jié)點的套接字可以根據(jù)報文分發(fā)規(guī)則，將接收到的報文發(fā)送到對應的匪中。步驟507 下游匪根據(jù)接收到的resv消息，建立resv消息狀態(tài)塊，其中，建立的 resv消息狀態(tài)塊中記錄resv消息中攜帶的信息，將resv消息上報給CORE ；其中，下游匪 在接收到的resv消息后，可以檢查該resv消息的合法性，當判斷resv消息合法后，執(zhí)行上 述建立消息狀態(tài)塊的操作。還需要說明的是，步驟507中的CORE應當和對該resv消息相 應的path消息進行處理的CORE相同。其中，步驟507中建立的resv消息狀態(tài)塊為接收resv消息狀態(tài)塊，后續(xù)刷新操作 中，下游NM根據(jù)建立的接收resv消息狀態(tài)塊，定期的接收下游節(jié)點發(fā)送的resv消息進行 刷新，當下游匪接收到刷新resv消息沒有變化時，匪不會將刷新resv消息上報給CORE， 當該匪接收到刷新resv消息有變化時，匪將刷新resv消息上報給CORE。從而減輕了刷 新操作對CORE的壓力。步驟507中將resv消息上報給CORE的操作，具體可以是下游匪向節(jié)點中的每 個CORE發(fā)送查詢信息，用于查詢resv消息歸屬業(yè)務所在的CORE，當其中一個CORE中判斷 出resv消息歸屬業(yè)務在自身處理時，回復查詢響應給該下游NM，從而將resv消息發(fā)送給對 應CORE ；或者，對于節(jié)點中設立有業(yè)務集中點的，下游NM可以向業(yè)務集中點查詢resv消息 歸屬業(yè)務所在的CORE，從而將resv消息發(fā)送給與上游NM綁定的CORE ；或者，下游NM根據(jù) 記錄的發(fā)送path消息的CORE，將resv消息發(fā)送給與上游匪綁定的CORE。在后續(xù)的實施 例中將會詳細說明。步驟508 =CORE根據(jù)接收到resv消息，預留資源，生成發(fā)送給上游節(jié)點的resv消 息，其中，發(fā)送給上游節(jié)點的resv消息中包含自身為上游節(jié)點分配的LSP的標簽(即入標 簽)；LSP是依靠標簽進行轉發(fā)的，下游節(jié)點負責給上游節(jié)點分配標簽，這個標簽通過 resv消息從下游攜帶給上游。對于一個節(jié)點來說，它收到下游的resv消息，獲得出標簽； 同時它給上游分配一個相應的標簽(稱為入標簽)，通過resv消息發(fā)給上游。如果收到一 個報文，它的標簽是本節(jié)點分配的入標簽，那么就會把這個標簽換成對應的出標簽，繼續(xù)轉 發(fā)給分配該出標簽的下游節(jié)點。這個過程一直重復直到到達LSP末端。步驟509 =CORE將生成的發(fā)送給上游節(jié)點的resv消息發(fā)送給上游匪；其中，CORE具體可以根據(jù)報文分發(fā)規(guī)則，將發(fā)送給上游節(jié)點的resv消息發(fā)送給對 應的匪。步驟510 上游匪接收到發(fā)送給上游節(jié)點的resv消息后，建立resv消息狀態(tài)塊，將該resv消息通過SOCKET發(fā)送給上游節(jié)點。為了便于和步驟507中下游匪建立的resv 消息狀態(tài)塊進行區(qū)分，將步驟507中建立的resv消息狀態(tài)塊稱為“接收resv消息狀態(tài)塊”， 步驟510中上游NM建立的resv消息狀態(tài)塊稱為“發(fā)送resv消息狀態(tài)塊”，其中，后續(xù)為了維 持LSP，定期進行resv消息的刷新將由上游的匪，根據(jù)發(fā)送resv消息狀態(tài)塊來完成，CORE 可以不再干預。通過上述步驟501至步驟510的說明，可以建立一條LSP，后續(xù)如果收到相同的 LSP的path消息或者resv消息執(zhí)行刷新，path消息將會被發(fā)送到與上述建立LSP時處理 path消息的匪中，同理，resv消息也將會被發(fā)送到與上述建立LSP時處理resv消息的匪 中。上游匪檢查resv消息與本地記錄狀態(tài)塊是否一致，且下游匪檢查path消息與本地 記錄狀態(tài)塊是否一致，當兩個匪判斷都一致時，完成一次刷新操作。否則將檢查到的與本 地記錄不一致的消息上報給CORE處理。通過上述步驟501至步驟510對本實施例提供的一種處理報文的說明，該方法采 用將RSVP實例劃分為匪和CORE兩部分，通過靈活部署匪和CORE的數(shù)量，以及匪與CORE 的對應關系，使得一個節(jié)點上可以支持的LSP數(shù)量遠遠大于現(xiàn)有技術。為了更清楚的理解上述步驟501、504、506和步驟509中提出報文分發(fā)規(guī)則，下面 詳細說明報文分發(fā)規(guī)則，包括第一、報文分發(fā)規(guī)則可以是接口分布規(guī)則。該規(guī)則可以通過手工干預或者其它方 法，建立RSVP實例中接口與NM的關聯(lián)關系，并且將該關聯(lián)關系表發(fā)送給CORE和SOCKET。其 中，當SOCKE接收到報文時，可以根據(jù)接收到報文的SOCKET的端口號(可以理解為該報文 的入接口，后續(xù)為了便于說明，簡稱“入接口”)查詢關聯(lián)關系表，SOCKE將報文發(fā)送給與入 接口對應的NM ；當CORE生成處理后的報文時，根據(jù)該報文的出接口查詢關聯(lián)關系表，CORE 將處理后的報文發(fā)送給與出接口對應的匪。其中，SOCKET和入接口可以是一對多的關系，SOCKET可以根據(jù)報文分發(fā)規(guī)則與多 個NM具有對應關系。從SOCKET收到報文后，首先會上送給特定SOCKET，SOCKET需要查詢 關聯(lián)表才能確定送給哪個NM進行處理。CORE獲得LSP的出接口的具體操作可以是LSP的首節(jié)點事先算好一條路徑(或 者用戶顯式指定一條路徑)，路徑信息是一串IP地址，通過path消息的顯式路徑對象 (ER0, Explicit path object)攜帶給沿途各個節(jié)點，各個節(jié)點可以通過ERO得知出接口 ； 在沒有ERO的情況下，CORE實例可以根據(jù)LSP的目的地址(在path消息里面會指明)查 詢本地存儲的路由信息中的出接口。采用接口分布規(guī)則時，匪(可以是上游匪，或者下游NM)還執(zhí)行鄰居處理，具體可 以包括產生和接收處理基于接口的哈羅(Hello)消息。具體包括匪可以為Hello消息 建立狀態(tài)塊，處理Hello消息和發(fā)送Hello消息，維護Hello消息狀態(tài)塊。當匪超時未收 到Hello消息時，判斷Hello消息丟失，匪可以停止該鄰居的LSP狀態(tài)塊超時器，進入自刷 新狀態(tài)；當鄰居之間通過Hello消息在預置的時間內重新連接上，匪可以通知TORE，CORE 產生path消息和resv消息協(xié)助鄰居恢復狀態(tài)塊；如果通過Hello消息在預置的時間內鄰 居之間無法連接，匪通知CORE，CORE按照協(xié)議規(guī)定，刪除LSP資源和表項，匪也刪除自身 保留的LSP狀態(tài)塊。其中，上述LSP狀態(tài)塊超時器是RSVP協(xié)議是軟狀態(tài)刷新的協(xié)議中規(guī)定的模塊，每個節(jié)點會定時發(fā)送path或resv消息給下游或上游節(jié)點來“?；睢?LSP，同樣，上游或下游節(jié) 點會為LSP啟動超時器等待LSP “保活”，超時收不到刷新消息就會把LSP刪除。其中，上述自刷新狀態(tài)是指因為停止了超時器，即使LSP收不到刷新消息，LSP也 不會因為超時而被刪除，這種狀態(tài)稱為“自刷新狀態(tài)”。第二、報文分發(fā)規(guī)則可以是本地地址分布規(guī)則。該規(guī)則可以通過手工干預或者其 它方法，建立本地地址與NM的關聯(lián)關系，并且將該關聯(lián)關系表發(fā)送給CORE和S0CKE。其中， 當SOCKE接收到報文時，可以根據(jù)接收到報文的目的地址查詢關聯(lián)關系表，SOCKE將報文發(fā) 送給對應的匪；當CORE生成處理后的報文時，根據(jù)該報文的源地址查詢關聯(lián)關系表，CORE 將處理后的報文發(fā)送給對應的NM。其中，目的地址、源地址都可以是本地地址，一個節(jié)點有 多個本地地址，本地地址與NM的關系是記錄在關聯(lián)關系表中。這里的本地地址分布規(guī)則與接口分布規(guī)則相似，本地地址可以唯一關聯(lián)到一個接 口。對于上游節(jié)點發(fā)送的報文中包括有路由警告(router-alert)選項的(如path消息， path-tear消息，resvconfirm消息)，其目的地址是LSP末節(jié)點的標簽交換路由器標識 (lsr-id,Laber-Switch Router Identity)，中間節(jié)點的 SOCKET根據(jù)接收到的 path 消息的 目的地址(即末節(jié)點的lsr-id)查詢關聯(lián)關系表，將該報文發(fā)送到lsr-id對應的匪中，而 末節(jié)點中向上游節(jié)點發(fā)送resv消息時，resv消息的出接口作為該resv消息的源地址。當 中間節(jié)點從接收到resv消息中獲取的resv消息的源地址，與path消息中l(wèi)sr-id不相同 時，則末節(jié)點中處理path消息的匪，與根據(jù)resv消息處理鄰居關系的匪是不同的匪，從 而導致了末節(jié)點中處理業(yè)務的錯誤。因此，對于報文中包括有路由警告(router-alert)選項的，可以不采用本地地址 分布規(guī)則。第三、報文分發(fā)規(guī)則可以是鄰居(Peer)地址分布規(guī)則。該規(guī)則可以通過手工干 預或者其它方法，建立peer地址與NM的關聯(lián)關系，并且將該關聯(lián)關系表發(fā)送給CORE和 S0CKE。其中，當SOCKE接收到報文時，可以根據(jù)接收到報文的源地址分配關聯(lián)關系表， SOCKE將報文發(fā)送給對應的NM ；當CORE生成處理后的報文時，根據(jù)該報文的目的地址查詢 關聯(lián)關系表，CORE將處理后的報文發(fā)送給對應的NM。根據(jù)RSVP協(xié)議規(guī)定，節(jié)點的鄰居信息是隨著業(yè)務報文攜帶而獲得的，在處理業(yè)務 的過程中建立鄰居關系，在刪除業(yè)務的過程中刪除鄰居關系，其中鄰居是指上下游節(jié)點，與 鄰居有關的信息稱為鄰居信息，鄰居信息具體可以是path/resv消息里面的標識的下一跳 (hop)地址。因此，節(jié)點可以通過學習鄰居關系建立與匪之間的關聯(lián)關系。如圖6所示建 立Peer地址與匪關聯(lián)關系示意簡圖，包括步驟611 當SOCKET接收到報文，且該報文的源地址尚未分配匪時，請求peer分 配器分配匪；步驟612 =Peer分配器將分配結果發(fā)送給SOCKET，SOCKET記錄分配結果，將接收到 的報文發(fā)送給分配的匪處理；步驟621 當CORE要對外發(fā)送報文時，如果該報文的目的地址尚未分配匪，則 CORE請求peer分配器分配匪；步驟622 :peer分配器為該目的地址分配對應的NM，將分配結果發(fā)送給CORE，CORE 記錄分配結果，將報文下發(fā)給分配的ML
其中，為SOCKET分配匪的peer分配器，與為CORE分配匪的peer分配器可以是 相同的peer分配器。其中，匪和CORE中分別都可以感知承載其中的業(yè)務，當匪發(fā)現(xiàn)本地的peer地址 與業(yè)務無關時，通知peer分配器釋放建立的關聯(lián)關系；或者當CORE發(fā)現(xiàn)本地的peer地址 與業(yè)務無關時，通知peer分配器釋放建立的關聯(lián)關系。例如在步驟612中peer分配器 為SOCKET分配的匪，與不同于上述圖6中說明業(yè)務的其他業(yè)務中使用到該peer分配器為 SOCKET分配的匪，且SOCKET接收到的報文都來自相同的源地址(即peer地址相同)；或 者，在步驟622中peer分配器根據(jù)報文的目的地址(即peer地址)分配對應的匪，CORE 將報文下發(fā)給分配的該匪，且該peer地址與分配對應的匪恰好被其它業(yè)務所使用到。也 就是說，在peer地址與匪的對應關系被不同的業(yè)務同時利用到，那么，需要對該peer地址 與NM的對應關系被利用到的次數(shù)進行計數(shù)，當有業(yè)務執(zhí)行完畢，不需要利用該peer地址與 匪的對應關系，相應的減少該peer地址與匪的對應關系被利用到的次數(shù)，當沒有業(yè)務再利 用該peer地址與匪的對應關系時，相應的計數(shù)可以是零，才可以釋放peer地址與匪的對 應關系。其中，在SOCKET中是不能感知業(yè)務，因此，通常由匪或者CORE通知peer分配器改 變peer地址與匪的對應關系被利用到的次數(shù)，peer分配器可以在計數(shù)為零時，釋放peer 地址與匪的對應關系。當業(yè)務刪除時，SOCKET和CORE可以釋放peer地址與匪的關聯(lián)關系。由于SOCKET 不感知RSVP業(yè)務，無法釋放Peer地址與匪的關聯(lián)關系，因此，當匪發(fā)現(xiàn)本地的peer地址 與業(yè)務無關時，通知peer分配器釋放建立的關聯(lián)關系。CORE可以感知RSVP業(yè)務，當發(fā)現(xiàn)本 地的peer地址與業(yè)務無關時，通知peer分配器釋放建立的關聯(lián)關系。當SOCKET和CORE 引用相同的peer地址用于根據(jù)該peer地址分配匪時，peer分配器需要記錄peer地址的 引用計數(shù)，便于peer分配器判斷peer地址的引用次數(shù)，用來判斷是否可以釋放該peer地 址，如果有任何一個peer地址與匪的關聯(lián)關系仍然與業(yè)務有關，則不可以釋放該peer地 址。上述是對一種自動建立peer與匪關聯(lián)關系的舉例，采用鄰居(Peer)地址分布規(guī) 則部署……具有更好的靈活性，匪的數(shù)量可以隨著Peer增多(減少)而自動增加(減少)。 peer與NM的關聯(lián)關系也可以是手工干預建立的。還需要說明的是，第一 SOCKET還可以根據(jù)報文的其它特征(如首節(jié)點地址、末節(jié) 點地址)建立與匪的關聯(lián)關系，將接收到的報文發(fā)送給對應的匪(也可以稱為“上游匪”)。上述說明的報文分發(fā)規(guī)則并非是對本發(fā)明實施例的窮舉，不應該理解為對本發(fā)明 實施例的限制。為了更清楚的理解上述步驟502提出的業(yè)務分布規(guī)則，下面詳細說明業(yè)務分布規(guī) 則，包括第一、業(yè)務分布規(guī)則采用Hash方式。在CORE中可以預設規(guī)則，例如某種Hash算 法，以取模算法為例，如下式(1)所示K = χ% η (1)其中，K為CORE實例標識，χ為Session或者LSP標識，η為部署的CORE實例的數(shù) 目，％表示取模。假設部署η個CORE實例，每個CORE賦予一個實例標識，從0開始到n_l。對于特定session或者LSP，它所處理的CORE實例標識K按照如式(1)可以快速定位CORE。 將業(yè)務分布的到合理的CORE中。Hash算法也可以是循環(huán)冗余校驗(Cyclic redundancy check, CRC)、縱向冗余校驗(Longitudinal redundancy check, LRC)、信息-摘要算法 5 (Message-Digest Algorithm 5，MD5)、安全散列算法(Secure Hash Algorithm)等其他散 列算法。第二、業(yè)務分布規(guī)則采用集中分配方式。采用集中分配的方式時，可以增加單獨的 業(yè)務分配器，由業(yè)務分配器為業(yè)務分配CORE。如圖7，業(yè)務分配器為業(yè)務分配CORE操作具 體包括步驟701 =NM在接收到新的業(yè)務消息時，向業(yè)務分配器發(fā)送分配CORE請求；其中， 為該新業(yè)務分配CORE可以是按照Session為粒度，也可以是按照LSP為粒度。在本實施例 中以Session為粒度舉例，對于以LSP為粒度分配CORE的操作可以容易推出。步驟702 業(yè)務分配器為該新業(yè)務分配CORE，將分配結果發(fā)送給匪。其中，業(yè)務分配器可以根據(jù)該節(jié)點中可使用的CORE數(shù)量和各CORE中的使用率，為 業(yè)務分配合理的CORE。如果該業(yè)務所屬的Session已經(jīng)分配給一個CORE，則增加用于處理 該Session的CORE的計數(shù)，或者，分配一個空閑的CORE，將其分配給Session，記錄該空閑 的CORE與歸屬于Session的關系，如果當前的CORE都非常繁忙，可以增加一個新的CORE來 支撐業(yè)務。如果是以LSP為粒度，假設為該LSP歸屬的業(yè)務分配一個CORE，則記錄該CORE 上業(yè)務的計數(shù)。步驟703 匪接收到分配結果，將報文發(fā)送給對應的CORE處理。還需要說明的是，當匪在刪除業(yè)務狀態(tài)塊時，向業(yè)務分配器請求釋放CORE。業(yè)務 分配器減少歸屬于CORE的Session的計數(shù)，當計數(shù)為0時，則釋放該CORE。如果CORE中沒 有任何業(yè)務承載，可以根據(jù)策略將該CORE占用的物理資源所在的實體脫離該節(jié)點。上述說明的兩種業(yè)務分布規(guī)則，都可以將同一個業(yè)務的報文分配到相同的CORE 中處理。第三、業(yè)務分布規(guī)則采用部署方式。通過部署該節(jié)點中的CORE和匪的之間的關 系，從而完成NM到CORE的業(yè)務關聯(lián)。其中，部署節(jié)點中的CORE何NM的關系的具體情況可 以包括當有η個匪和1個CORE來部署時，如果一個CORE就已經(jīng)能夠提供足夠大容量支 持LSP，那么CORE可以固定部署一個，匪可以直接命中CORE來處理業(yè)務?；蛘?，匪與CORE以1 1的數(shù)量比來部署。其中，一個匪(例如上游NM)綁定 一個CORE。當匪收到新業(yè)務消息時，固定上送到與自己綁定的CORE去處理。為了使得歸 屬于該新業(yè)務的所有報文都由同一個CORE處理，對應1 1方式還需要其它控制來完成整 個過程，如圖8所示具體包括步驟801 接收到新業(yè)務的path消息的匪(稱為上游NM)，將消息上送給與該匪 綁定的CORE處理；步驟802 與匪綁定的CORE接收到path消息后，根據(jù)上述說明的報文分發(fā)規(guī)則， 將path消息轉發(fā)到下游匪；步驟803 下游匪接收到新業(yè)務的resv消息，該消息被發(fā)送到處理path消息的 CORE中。其中，將resv消息發(fā)送到處理path消息的CORE中的具體操作可以包括
15
下游匪通過廣播查詢業(yè)務所在的CORE，從而實現(xiàn)將reSV消息發(fā)送到處理path消 息的CORE中；或者，對于設立業(yè)務集中點的情況下，下游匪在業(yè)務集中點中查詢業(yè)務所屬的 CORE,從而實現(xiàn)將resv消息發(fā)送到處理path消息的CORE中；或者，下游匪在步驟802中記錄業(yè)務(具體是path消息)與CORE的關系，收到 Resv消息時查表得知CORE所在實例。步驟804 =CORE將向上游節(jié)點回復的resv消息發(fā)給上游匪。上述對業(yè)務分布規(guī)則的說明，還需要說明的是，報文分發(fā)規(guī)則和業(yè)務分布規(guī)則可 以不限于上述說明的實例，還可以采取其它方式。綜上對本實施例的說明，可以獲知將RSVP實例劃分為匪和CORE兩部分，且匪和 CORE的數(shù)量可以靈活部署。具體可以根據(jù)實際需要，將多個構件(其中，一個構件指單個 的NM或者CORE)合并部署為一個實例；或者將一個構件的功能分拆為多個，分別部署到不 同實例上；或者將一個構件的功能分拆為多個，然后再與其他構件合并部署為一個實例。這 種部署方式的改變仍然是基于本方案實現(xiàn)原理，屬于本實施例的覆蓋范圍內。下面結合圖 9、圖10、圖11舉例說明構件的部署方式。如圖9所示部署一個匪和多于一個的CORE，采用這種部署方式下RSVP實例的接 口與匪之間不需要報文分分發(fā)規(guī)則，匪將要發(fā)送的報文通過業(yè)務分布規(guī)則發(fā)送給對應的 CORE中處理。其中，如果業(yè)務分布規(guī)則采用集中方式，則上述說明的業(yè)務分配器可以集中在 匪中。采用圖9所示的部署方式極大的簡化了 RSVP的實現(xiàn)方法。圖10所示部署多于一個匪和一個CORE。采用這種部署方式下RSVP實例的 SOCKET (SOCKET)與匪之間根據(jù)報文分發(fā)規(guī)則具有關聯(lián)。匪與CORE之間不需要業(yè)務分布 規(guī)則，直接命中。匪承擔了大量報文刷新工作，單個CORE可以通過減少LSP狀態(tài)塊內存開 銷來承載更多LSP。采用圖10所示的部署方式可以節(jié)省業(yè)務分配所需要的控制和開銷。圖11所示部署匪與CORE的數(shù)量比值為1 1。采用這種部署方式下SOCKET給 RSVP實例之間的報文傳輸可以根據(jù)上述說明的報文分發(fā)規(guī)則，NM與CORE之間的關系實際 上變成了 RSVP實例之間的關系。詳細說明可以參考圖8中及其說明，此處不重述。圖12所示為本發(fā)明實施還提供的一種處理報文的裝置，該節(jié)點包括第
一SOCKET 101,上游鄰居管理(NM) 102，核心處理實例(CORE) 103，下游匪104，和第二 S0CKET105 ；第一 SOCKET，用于接收上游節(jié)點發(fā)送的報文，將接收到的報文發(fā)送給上游鄰居管 理(NM)；上游匪，用于接收第一 SOCKET發(fā)送的報文，將接收到的報文發(fā)送給CORE ；CORE，用于接收上游匪發(fā)送的報文，執(zhí)行業(yè)務處理，生成處理后的第一報文；將處 理后的第一報文發(fā)送給下游匪；下游匪，用于接收CORE發(fā)送的處理后的第一報文，將處理后的第一報文發(fā)送給第
二SOCKET ；第二 SOCKET，用于接收下游匪發(fā)送的處理后的第一報文，將處理后的第一報文發(fā) 送給下游節(jié)點。通過上述對該節(jié)點的說明，該節(jié)點中將RSVP實例劃分為匪和CORE兩部分，實現(xiàn)對上游節(jié)點發(fā)送的報文的處理，可以靈活的擴展匪和CORE的數(shù)量，且可以將業(yè)務更合理的 分配到多個CORE中，從而大大提高了 RSVP實例所支持的LSP數(shù)量，且大大提高了 RSVP的
工作效率。進一步，該裝置還可以實現(xiàn)對下游節(jié)點發(fā)送的報文的處理，則第二 SOCKET，還用于接收下游節(jié)點發(fā)送的報文，將報文發(fā)送給下游NM ；下游匪，還用于接收第二 SOCKET發(fā)送的報文，將報文發(fā)送給CORE ；CORE，還用于接收下游匪發(fā)送的報文，根據(jù)報文，執(zhí)行業(yè)務處理，生成處理后的第 二報文；將處理后的第二報文發(fā)送給上游匪；上游匪，還用于接收處理后的第二報文，將處理后的第二報文發(fā)送給第一 SOCKET ；第一 SOCKET，還用于接收處理后的第二報文，將處理后的第二報文發(fā)送給上游節(jié)
點ο進一步，若第一 SOCKET接收上游節(jié)點發(fā)送的報文為path消息，且上游匪中沒有接收path 消息狀態(tài)塊，則上游NM，還用于根據(jù)接收到的path消息，建立接收path消息狀態(tài)塊；若第一 SOCKET接收上游節(jié)點發(fā)送的報文為path消息，上游NM中有接收path消 息狀態(tài)塊，則上游匪，還用于判斷接收到path消息中狀態(tài)與接收path消息狀態(tài)塊中的狀態(tài) 是否一致，如果不一致，將接收到的path消息發(fā)送給CORE ；若處理后的第一報文為處理后的path消息，且下游匪中沒有發(fā)送path消息狀態(tài) 塊，則下游NM，還用于根據(jù)接收到的處理后的path消息，建立發(fā)送path消息狀態(tài)塊； 根據(jù)發(fā)送path消息狀態(tài)塊中信息，通過第二 SOCKET發(fā)送處理后的path消息給下一跳進行 刷新；若第二 SOCKET接收下游節(jié)點發(fā)送的報文為resv消息，且下游匪中沒有接收resv 消息狀態(tài)塊，則下游匪，還用于根據(jù)接收到的resv消息，建立接收resv消息狀態(tài)塊；若第二 SOCKET接收下游節(jié)點發(fā)送的報文為resv消息，且下游匪中有接收resv 消息狀態(tài)塊，則下游匪，還用于判斷接收到resv消息中狀態(tài)與接收resv消息狀態(tài)塊中的狀態(tài) 是否一致，如果不一致，將接收到的報文發(fā)送給與CORE ；若處理后的第二報文為處理后的resv消息，且上游匪中沒有發(fā)送resv消息狀態(tài) 塊，則上游匪，還用于根據(jù)接收到的處理后的resv消息，建立發(fā)送resv消息狀態(tài)塊； 根據(jù)發(fā)送resv消息狀態(tài)塊中信息，發(fā)送處理后的resv消息給下一跳進行刷新。進一步，第一 SOCKET，具體用于接收上游節(jié)點發(fā)送的報文，根據(jù)報文分發(fā)規(guī)則，將 接收到的報文發(fā)送給上游匪，所述報文分發(fā)規(guī)則包括套接字中接收所述報文的端口號與 NM的關聯(lián)關系，所述報文的目的地址與NM的關聯(lián)關系，或者所述報文的源地址與NM的關聯(lián)關系中的一種或多種；則CORE，具體用于根據(jù)所述業(yè)務分布規(guī)則，將所述處理后的報文發(fā)送給下游匪， 所述下游匪根據(jù)所述報文分發(fā)規(guī)則，將所述處理后的報文通過第二套接字發(fā)送給下游節(jié)
點ο進一步，裝置中包括多于一個的CORE時，上游匪，具體用于以報文所歸屬會話為 粒度，或者以報文所使用的標簽選擇路徑(LSP)為粒度，根據(jù)業(yè)務分布規(guī)則，將接收到的報 文發(fā)送給CORE。進一步，業(yè)務分布規(guī)則為哈希(Hash)方式。進一步，裝置還包括業(yè)務分配器106，用于接收上游匪發(fā)送的分配CORE請求，為 報文歸屬的業(yè)務分配CORE，將分配結果發(fā)送給上游NM ；則上游匪，具體用于根據(jù)分配結果，將接收到的報文發(fā)送給CORE ；進一步，若裝置中匪與CORE以1 1的數(shù)量比來部署，且第一 SOCKET所歸屬的 裝置包括多于一個的NM時，上游NM,具體用于將接收到的path消息發(fā)送給與上游NM綁定 的 CORE ；且下游匪，具體用于將接收到的resv消息，發(fā)送給與上游匪綁定的CORE。進一步，下游匪中將接收到的resv消息，發(fā)送給與上游匪綁定的CORE，具體包 括下游NM通過廣播查詢resv消息歸屬業(yè)務所在的CORE，從而將resv消息發(fā)送給與 上游匪綁定的CORE ；或者，下游匪向業(yè)務集中點查詢resv消息歸屬業(yè)務所在的CORE，從而將resv消 息發(fā)送給與上游匪綁定的CORE ；或者，下游匪根據(jù)記錄的發(fā)送path消息的CORE，將resv消息發(fā)送給與上游匪綁 定的CORE。上述是對本發(fā)明實施例提供的裝置的說明，需要理解的是，對裝置的更詳細的說 明也可以參考圖3至圖11中關于報文處理方法中有關的說明，此處不重述。本領域普通技術人員可以理解實現(xiàn)上述實施例方法中的全部或部分流程，是可以 通過計算機程序來指令相關的硬件來完成，所述的程序可存儲于一計算機可讀取存儲介質 中，該程序在執(zhí)行時，可包括如上述各方法的實施例的流程。其中，所述的存儲介質可為磁 碟、光盤、只讀存儲記憶體(Read-Only Memory, ROM)或隨機存儲記憶體(Random Access Memory, RAM)等。以上對本發(fā)明實施例進行了詳細介紹，本文中應用了具體實施方式
對本發(fā)明進行 了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及設備；同時，對于本領域的 一般技術人員，依據(jù)本發(fā)明的思想，在具體實施方式
及應用范圍上均會有改變之處，綜上所 述，本說明書內容不應理解為對本發(fā)明的限制。
權利要求
1.一種處理報文的方法，其特征在于，包括第一套接字接收上游節(jié)點發(fā)送的報文，將接收到的報文發(fā)送給上游鄰居管理；上游鄰居管理將接收到的報文發(fā)送給核心處理實例；所述核心處理實例根據(jù)接收到的所述報文，執(zhí)行業(yè)務處理，生成處理后的第一報文；所述核心處理實例將所述處理后的第一報文發(fā)送給下游鄰居管理，由下游鄰居管理將 處理后的第一報文通過第二套接字發(fā)送給下游節(jié)點。
2.根據(jù)權利要求1所述的方法，其特征在于，所述方法還包括第二套接字接收所述下游節(jié)點發(fā)送的報文，將所述報文發(fā)送給下游鄰居管理；下游鄰居管理將所述報文發(fā)送給所述核心處理實例；所述核心處理實例根據(jù)接收到的所述下游鄰居管理發(fā)送的報文，執(zhí)行業(yè)務處理，生成 處理后的第二報文；所述核心處理實例將所述處理后的第二報文發(fā)送給上游鄰居管理，由上游鄰居管理將 處理后的第二報文通過第一套接字發(fā)送至所述上游節(jié)點。
3.根據(jù)權利要求2所述的方法，其特征在于，若第一套接字接收上游節(jié)點發(fā)送的報文為path消息，且上游鄰居管理中沒有接收 path消息狀態(tài)塊，則所述方法還包括所述上游鄰居管理根據(jù)接收到的path消息，建立所 述接收path消息狀態(tài)塊；若第一套接字接收上游節(jié)點發(fā)送的報文為path消息，所述上游鄰居管理中有接收 path消息狀態(tài)塊，則所述方法還包括上游鄰居管理判斷接收到path消息中狀態(tài)與所述接 收path消息狀態(tài)塊中的狀態(tài)是否一致，如果不一致，上游鄰居管理將接收到的報文發(fā)送給 所述核心處理實例；若所述處理后的第一報文為處理后的path消息，且下游鄰居管理中沒有發(fā)送path消 息狀態(tài)塊，則所述方法還包括下游鄰居管理根據(jù)接收到的處理后的path消息，建立所述 發(fā)送payh消息狀態(tài)塊；其中，所述下游鄰居管理根據(jù)所述發(fā)送path消息狀態(tài)塊中信息，通 過第二套接字發(fā)送處理后的path消息給下一跳進行刷新。
4.根據(jù)權利要求3所述的方法，其特征在于，若第二套接字接收所述下游節(jié)點發(fā)送的報文為resv消息，且所述下游鄰居管理中沒 有接收resv消息狀態(tài)塊，則所述方法還包括所述下游鄰居管理根據(jù)接收到的resv消息， 建立所述接收resv消息狀態(tài)塊；若第二套接字接收所述下游節(jié)點發(fā)送的報文為resv消息，且所述下游鄰居管理中有 接收resv消息狀態(tài)塊，則所述方法還包括所述下游鄰居管理判斷接收到resv消息中狀態(tài) 與所述接收resv消息狀態(tài)塊中的狀態(tài)是否一致，如果不一致，執(zhí)行所述下游鄰居管理將接 收到的報文發(fā)送給與所述核心處理實例；若所述處理后的第二報文為處理后的resv消息，且所述所述上游鄰居管理中沒有發(fā) 送resv消息狀態(tài)塊，則所述方法還包括所述上游鄰居管理根據(jù)接收到的處理后的resv消 息，建立所述發(fā)送resv消息狀態(tài)塊；其中，所述上游鄰居管理根據(jù)所述發(fā)送resv消息狀態(tài) 塊中信息，發(fā)送處理后的resv消息給下一跳進行刷新。
5.根據(jù)權利要求1所述的方法，其特征在于，所述第一套接字接收上游節(jié)點發(fā)送的報文，將接收到的報文發(fā)送給上游鄰居管理，具體包括第一套接字接收上游節(jié)點發(fā)送的報文，根據(jù)報文分發(fā)規(guī)則，將接收到的報文發(fā)送給 上游鄰居管理，所述報文分發(fā)規(guī)則包括套接字中接收所述報文的端口號與鄰居管理的關聯(lián) 關系，所述報文的目的地址與鄰居管理的關聯(lián)關系，或者所述報文的源地址與鄰居管理的 關聯(lián)關系中的一種或多種；則所述核心處理實例將所述處理后的第一報文發(fā)送給下游鄰居管理，由下游鄰居管理 將處理后的第一報文通過第二套接字發(fā)送給下游節(jié)點，具體包括核心處理實例根據(jù)所述 業(yè)務分布規(guī)則，將所述處理后的報文發(fā)送給下游鄰居管理，所述下游鄰居管理根據(jù)所述報 文分發(fā)規(guī)則，將所述處理后的報文通過第二套接字發(fā)送給下游節(jié)點。
6.根據(jù)權利要求1至5任一項所述的方法，其特征在于，當?shù)谝惶捉幼炙鶜w屬的節(jié)點包 括多于一個的核心處理實例時，所述上游鄰居管理將接收到的報文發(fā)送給核心處理實例， 具體包括上游鄰居管理以報文所歸屬會話為粒度，或者以報文所使用的標簽選擇路徑為粒度， 根據(jù)業(yè)務分布規(guī)則，將接收到的報文發(fā)送給核心處理實例。
7.根據(jù)權利要求1所述的方法，其特征在于，當?shù)谝惶捉幼炙鶜w屬的節(jié)點包括多于 一個的核心處理實例時，所述上游鄰居管理將接收到的報文發(fā)送給核心處理實例，具體包 括所述上游鄰居管理根據(jù)接收到的報文，觸發(fā)執(zhí)行向業(yè)務分配器發(fā)送分配核心處理實例 請求；業(yè)務分配器接收到所述請求，為所述報文歸屬的業(yè)務分配核心處理實例，將分配結果 發(fā)送給所述上游鄰居管理；所述上游鄰居管理接收所述分配結果；所述上游鄰居管理根據(jù)分配結果，將接收到的報文發(fā)送給核心處理實例。
8.—種處理報文的裝置，其特征在于，包括第一套接字，上游鄰居管理，核心處理實 例，下游鄰居管理，和第二套接字；所述第一套接字，用于接收上游節(jié)點發(fā)送的報文，將接收到的報文發(fā)送給上游鄰居管理；上游鄰居管理，用于接收第一套接字發(fā)送的報文，將接收到的報文發(fā)送給所述核心處 理實例；核心處理實例，用于接收上游鄰居管理發(fā)送的報文，執(zhí)行業(yè)務處理，生成處理后的第一 報文；將所述處理后的第一報文發(fā)送給下游鄰居管理；下游鄰居管理，用于接收所述核心處理實例發(fā)送的處理后的第一報文，將所述處理后 的第一報文發(fā)送給第二套接字；第二套接字，用于接收下游鄰居管理發(fā)送的處理后的第一報文，將所述處理后的第一 報文發(fā)送給下游節(jié)點。
9.根據(jù)權利要求8所述的裝置，其特征在于，所述第二套接字，還用于接收所述下游節(jié)點發(fā)送的報文，將所述報文發(fā)送給下游鄰居管理；所述下游鄰居管理，還用于接收第二套接字發(fā)送的報文，將所述報文發(fā)送給所述核心 處理實例；所述核心處理實例，還用于接收所述下游鄰居管理發(fā)送的報文，根據(jù)所述報文，執(zhí)行業(yè) 務處理，生成處理后的第二報文；將所述處理后的第二報文發(fā)送給上游鄰居管理；所述上游鄰居管理，還用于接收所述處理后的第二報文，將處理后的第二報文發(fā)送給 所述第一套接字；所述第一套接字，還用于接收所述處理后的第二報文，將處理后的第二報文發(fā)送給所 述上游節(jié)點。
10.根據(jù)權利要求9所述的裝置，其特征在于，若第一套接字接收上游節(jié)點發(fā)送的報文為path消息，且上游鄰居管理中沒有接收 path消息狀態(tài)塊，則所述上游鄰居管理，還用于根據(jù)接收到的path消息，建立所述接收path消息狀態(tài)塊；若第一套接字接收上游節(jié)點發(fā)送的報文為path消息，所述上游鄰居管理中有接收 path消息狀態(tài)塊，則所述上游鄰居管理，還用于判斷接收到path消息中狀態(tài)與所述接收path消息狀態(tài) 塊中的狀態(tài)是否一致，如果不一致，將接收到的path消息發(fā)送給所述核心處理實例；若所述處理后的第一報文為處理后的path消息，且下游鄰居管理中沒有發(fā)送path消 息狀態(tài)塊，則所述下游鄰居管理，還用于根據(jù)接收到的處理后的path消息，建立所述發(fā)送path消 息狀態(tài)塊；根據(jù)所述發(fā)送path消息狀態(tài)塊中信息，通過第二套接字發(fā)送處理后的path消息 給下一跳進行刷新；若第二套接字接收所述下游節(jié)點發(fā)送的報文為resv消息，且所述下游鄰居管理中沒 有接收resv消息狀態(tài)塊，則所述下游鄰居管理，還用于根據(jù)接收到的resv消息，建立所述接收resv消息狀態(tài)塊；若第二套接字接收所述下游節(jié)點發(fā)送的報文為resv消息，且所述下游鄰居管理中有 接收resv消息狀態(tài)塊，則所述下游鄰居管理，還用于判斷接收到resv消息中狀態(tài)與所述接收resv消息狀態(tài) 塊中的狀態(tài)是否一致，如果不一致，將接收到的報文發(fā)送給與所述核心處理實例；若所述處理后的第二報文為處理后的resv消息，且所述所述上游鄰居管理中沒有發(fā) 送resv消息狀態(tài)塊，則所述上游鄰居管理，還用于根據(jù)接收到的處理后的resv消息，建立所述發(fā)送resv消 息狀態(tài)塊；根據(jù)所述發(fā)送resv消息狀態(tài)塊中信息，發(fā)送處理后的resv消息給下一跳進行刷 新。
11.根據(jù)權利要求10所述的裝置，其特征在于，所述第一套接字，具體用于接收上游節(jié) 點發(fā)送的報文，根據(jù)報文分發(fā)規(guī)則，將接收到的報文發(fā)送給上游鄰居管理，所述報文分發(fā)規(guī) 則包括套接字中接收所述報文的端口號與鄰居管理的關聯(lián)關系，所述報文的目的地址與鄰 居管理的關聯(lián)關系，或者所述報文的源地址與鄰居管理的關聯(lián)關系中的一種或多種；則所述核心處理實例，具體用于根據(jù)所述業(yè)務分布規(guī)則，將所述處理后的報文發(fā)送給 下游鄰居管理，所述下游鄰居管理根據(jù)所述報文分發(fā)規(guī)則，將所述處理后的報文通過第二套接字發(fā)送給下游節(jié)點。
12.根據(jù)權利要求9至11任一項所述的裝置，其特征在于，所述裝置中包括多于一個的 核心處理實例時，所述上游鄰居管理，具體用于以報文所歸屬會話為粒度，或者以報文所使 用的標簽選擇路徑為粒度，根據(jù)業(yè)務分布規(guī)則，將接收到的報文發(fā)送給核心處理實例。
13.根據(jù)權利要求12所述的裝置，其特征在于，所述裝置還包括業(yè)務分配器，用于接 收所述上游鄰居管理發(fā)送的分配核心處理實例請求，為所述報文歸屬的業(yè)務分配核心處理 實例，將分配結果發(fā)送給所述上游鄰居管理；則所述上游鄰居管理，具體用于根據(jù)分配結果，將接收到的報文發(fā)送給核心處理實例。
全文摘要
本發(fā)明實施例涉及通信技術領域，公開了一種處理報文的方法和裝置，其中該方法包括第一套接字接收上游節(jié)點發(fā)送的報文，將接收到的報文發(fā)送給上游鄰居管理；上游鄰居管理將接收到的報文發(fā)送給核心處理實例；所述核心處理實例根據(jù)接收到的所述報文，執(zhí)行業(yè)務處理，生成處理后的第一報文；所述核心處理實例將所述處理后的第一報文發(fā)送給下游鄰居管理，由下游鄰居管理將處理后的第一報文通過第二套接字發(fā)送給下游節(jié)點。采用將RSVP實例劃分為NM和CORE兩部分，從而大大提高了RSVP實例所支持的LSP數(shù)量。
文檔編號H04L12/56GK102143037SQ20101021386
公開日2011年8月3日 申請日期2010年6月23日 優(yōu)先權日2010年6月23日
發(fā)明者呂鑫, 祝廣東, 賀志國, 賴曉, 饒國義 申請人:華為技術有限公司