專利名稱：用于ip多播的協(xié)議無關(guān)實(shí)現(xiàn)的方法和設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)據(jù)聯(lián)網(wǎng)，并且在一個(gè)實(shí)施例中，更具體而言，本發(fā)明涉及數(shù)據(jù)聯(lián)網(wǎng)協(xié)議。
背景技術(shù)：
傳統(tǒng)的因特網(wǎng)協(xié)議(IP)通信允許一臺(tái)主機(jī)向單個(gè)主機(jī)(單播傳輸)或向所有主機(jī)(廣播傳輸)發(fā)送分組。為了支持對提供涉及向多個(gè)主機(jī)的高數(shù)據(jù)速率傳輸?shù)膽?yīng)用(例如音頻和視頻會(huì)議呼叫、音頻廣播和視頻廣播)的需求，已經(jīng)發(fā)展到第三路由技術(shù)，即多播路由。在多播路由中，一臺(tái)主機(jī)向所有主機(jī)的子集發(fā)送分組，以作為組傳輸。多播路由協(xié)議已被開發(fā)，以通過使分組復(fù)制最小化來節(jié)省帶寬。為了實(shí)現(xiàn)最高效的數(shù)據(jù)傳遞，多播分組在網(wǎng)絡(luò)中去往多個(gè)接收者的路徑分散的點(diǎn)上被復(fù)制，而不是在源處被復(fù)制。
多播路由協(xié)議很大程度上依賴于支持單播路由的相同底層因特網(wǎng)基礎(chǔ)設(shè)施。一個(gè)關(guān)鍵差異在于，單播路由一般基于分組的目的地IP地址，而多播路由協(xié)議卻通?；诮M地址并且可能基于分組源的地址來執(zhí)行轉(zhuǎn)發(fā)判決，所述組地址標(biāo)識(shí)出一組預(yù)期的受者。
但是，除了所使用的地址的本質(zhì)之外，單播和多播操作之間存在重要差異。單播轉(zhuǎn)發(fā)是一個(gè)較簡單的過程，其涉及正被轉(zhuǎn)發(fā)的分組的目的地IP地址的路由查找。該查找返回下一跳節(jié)點(diǎn)和為獲得下一跳而使用的轉(zhuǎn)發(fā)接口。單播轉(zhuǎn)發(fā)過程的一個(gè)非常重要的特征在于，在被稱為FIB的預(yù)先計(jì)算的數(shù)據(jù)庫中執(zhí)行路由查找的可能性。至于所涉及的轉(zhuǎn)發(fā)過程，在路由查找期間，可以認(rèn)為FIB是靜態(tài)的。經(jīng)過較長時(shí)間，F(xiàn)IB的內(nèi)容將由于路由協(xié)議傳達(dá)出由網(wǎng)絡(luò)連接和配置的改變所引起的更新而發(fā)生改變。
但是，如下假設(shè)能夠高度有益于路由器體系結(jié)構(gòu)的模塊化假設(shè)FIB在特定的路由查找期間保持靜態(tài)，并不會(huì)響應(yīng)于將被轉(zhuǎn)發(fā)的分組的接收而改變。高速轉(zhuǎn)發(fā)引擎執(zhí)行路由查找，并基于查找結(jié)果而采取行動(dòng)。路由處理器通過填充FIB并隨網(wǎng)絡(luò)連接和配置改變而修改其內(nèi)容來實(shí)現(xiàn)控制平面的功能。
但是，相比之下，多播路由實(shí)現(xiàn)方式當(dāng)前無法利用這種類型的模塊化。現(xiàn)在使用的大多數(shù)多播路由協(xié)議都是數(shù)據(jù)驅(qū)動(dòng)的。它們使用將被轉(zhuǎn)發(fā)的多播分組的接收來推斷當(dāng)前網(wǎng)絡(luò)拓?fù)渲斜挥糜谵D(zhuǎn)發(fā)分組的部分，所述分組包括已經(jīng)推斷出其接收拓?fù)涞哪切┓纸M。多播分組的接收可以被理解為用于修改多播FIB(MFIB)的內(nèi)容的事件信號(hào)。所產(chǎn)生的MFIB修改會(huì)影響對接收到的導(dǎo)致修改的分組的處理。
從而，取代多播轉(zhuǎn)發(fā)引擎和操作多播協(xié)議的路由處理器之間脆弱的模塊化，代之以這些元件之間高度復(fù)雜的交互。轉(zhuǎn)發(fā)引擎維持對協(xié)議狀態(tài)的某種感知能力。而且，影響多播路由狀態(tài)的分組不能立即被轉(zhuǎn)發(fā)引擎單獨(dú)地完全處理，而是可以首先被傳輸?shù)铰酚商幚砥鳌?br> 這種控制和轉(zhuǎn)發(fā)之間分離的缺乏使多播轉(zhuǎn)發(fā)引擎的設(shè)計(jì)極大地復(fù)雜化。此外，在多播路由協(xié)議操作中的改變需要改變轉(zhuǎn)發(fā)引擎的實(shí)現(xiàn)方式，而不僅僅是改變路由處理器。而且，經(jīng)由通常相對較低帶寬連接向路由處理器傳輸某些多播分組的需求增大了分組處理延遲。
我們需要改良的系統(tǒng)和方法，用于處理數(shù)據(jù)驅(qū)動(dòng)的協(xié)議，例如多播路由協(xié)議。

發(fā)明內(nèi)容
根據(jù)本發(fā)明的實(shí)施例，提供了用于實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)協(xié)議的改進(jìn)系統(tǒng)和方法。在一個(gè)實(shí)施例中，提供了改進(jìn)的多播路由協(xié)議的實(shí)現(xiàn)方式。通過將功能強(qiáng)大而簡單的應(yīng)用程序接口(API)用于模塊間通信，從而提供多播轉(zhuǎn)發(fā)和控制元件之間的分離。API是多播路由協(xié)議無關(guān)的，并且可以被用于表示任意現(xiàn)有多播協(xié)議的轉(zhuǎn)發(fā)狀態(tài)。從而使有效的平臺(tái)專用實(shí)現(xiàn)方式更便利。
本發(fā)明的第一方面提供了一種用于操作轉(zhuǎn)發(fā)引擎以處理多播分組的方法。該方法包括提供轉(zhuǎn)發(fā)引擎可訪問的多播轉(zhuǎn)發(fā)表；在多播轉(zhuǎn)發(fā)表的條目中提供多播操作標(biāo)志；在接收到多播分組之后，基于多播分組的地址，在多播轉(zhuǎn)發(fā)表中識(shí)別匹配條目；以及在不知道多播協(xié)議狀態(tài)的情況下，基于對識(shí)別出的條目中的一個(gè)或多個(gè)多播操作標(biāo)志的檢查，來選擇對多播分組的處理。
本發(fā)明的第二方面提供了一種操作網(wǎng)絡(luò)設(shè)備以轉(zhuǎn)發(fā)信息的方法。該方法包括提供數(shù)據(jù)驅(qū)動(dòng)的數(shù)據(jù)路由協(xié)議；采用轉(zhuǎn)發(fā)引擎來基于由轉(zhuǎn)發(fā)引擎維護(hù)的至少一個(gè)標(biāo)志選擇對接收到的分組的處理，其中轉(zhuǎn)發(fā)引擎不知道數(shù)據(jù)路由協(xié)議的協(xié)議狀態(tài)；以及從轉(zhuǎn)發(fā)引擎向控制平面處理器發(fā)信號(hào)，以協(xié)助在控制平面處理器處維護(hù)數(shù)據(jù)路由協(xié)議的協(xié)議狀態(tài)。
本發(fā)明的第三方面提供了用于處理多播分組的裝置。該裝置包括轉(zhuǎn)發(fā)引擎，其1)存儲(chǔ)具有保存著多播操作標(biāo)志的條目的多播轉(zhuǎn)發(fā)表，2)在接收到多播分組時(shí)，基于分組的地址在多播轉(zhuǎn)發(fā)表中識(shí)別匹配條目，以及3)在不知道多播路由協(xié)議狀態(tài)的情況下，選擇對所述多播分組的處理；以及路由處理器，該路由處理器在模塊上不同于維護(hù)協(xié)議狀態(tài)的轉(zhuǎn)發(fā)引擎。
通過參考說明書的其余部分以及附圖，可以進(jìn)一步理解本發(fā)明的本質(zhì)和優(yōu)點(diǎn)。


圖1示出了根據(jù)本發(fā)明一個(gè)實(shí)施例的網(wǎng)絡(luò)設(shè)備。
圖2示出了根據(jù)本發(fā)明一個(gè)實(shí)施例的線路卡。
圖3示出了根據(jù)本發(fā)明一個(gè)實(shí)施例的多播FIB(MFIB)。
圖4示出了根據(jù)本發(fā)明一個(gè)實(shí)施例的圖3中的MFIB中的一個(gè)條目。
圖5是示出根據(jù)本發(fā)明一個(gè)實(shí)施例的多播轉(zhuǎn)發(fā)引擎的操作的狀態(tài)圖。
具體實(shí)施例方式
本發(fā)明可以被應(yīng)用于數(shù)據(jù)網(wǎng)絡(luò)，包括采用數(shù)據(jù)驅(qū)動(dòng)協(xié)議的數(shù)據(jù)網(wǎng)絡(luò)。在這里將描述的特定實(shí)現(xiàn)方式中，本發(fā)明可以被用于實(shí)現(xiàn)多播路由方案。
多播路由原理對多播路由基本原理的簡單論述將有助于引入本發(fā)明的概念。在以下文獻(xiàn)中可以找到多播路由協(xié)議操作的更多細(xì)節(jié)，這里為了所有用途通過參考而并入了這些文獻(xiàn)的全部內(nèi)容。
Deering，“Host Extensions for IP Multicasting”，請求注解(Requestfor Comments)1112，因特網(wǎng)工程任務(wù)組，1989年8月。
Fenner，“Internet Group Management Protocol，Version 2”，請求注解2236，因特網(wǎng)工程任務(wù)組，1997年11月。
Cain等人，“Internet Group Management Protocol，Version 3”，請求注解3376，因特網(wǎng)工程任務(wù)組，2002年10月。
Bates等人，“Multiprotocol Extensions for BGP-4”，請求注解2283，因特網(wǎng)工程任務(wù)組，1998年2月。
Estrin等人，“Protocol Independent Multicast-Sparse Mode(PIM-SM)Protocol Specification”，請求注解2362，因特網(wǎng)工程任務(wù)組，1998年6月。
Handley等人，“Bi-directional Protocol Independent Multicast(BIDIR-PIM)”，因特網(wǎng)工程任務(wù)組因特網(wǎng)草案，2002年6月。
Fenner等人，“Protocol Independent Multicast-Sparse Mode(PIM-SM)Protocol Specification(revised)”，因特網(wǎng)工程任務(wù)組因特網(wǎng)草案，2002年3月。
Adams等人，“Protocol Independent Multicast-Dense Mode(PIM-DM)Protocol Specification”，因特網(wǎng)工程任務(wù)組因特網(wǎng)草案，2002年10月。
Holbrook等人，“Source Specific Multicast for IP”，因特網(wǎng)工程任務(wù)組因特網(wǎng)草案，2002年11月。
以上協(xié)議文獻(xiàn)中的很多都涉及被稱為協(xié)議無關(guān)多播(PIM)的多播協(xié)議族。本發(fā)明將參考PIM的實(shí)現(xiàn)方式來描述，但是并不局限于這種特定的多播協(xié)議族。例如，本發(fā)明可以被應(yīng)用于距離向量多播路由協(xié)議(DMVPRP)、多播擴(kuò)展OSPF(MOSPF)和其他多播協(xié)議。
IP多播將單個(gè)信息流同時(shí)傳遞到多個(gè)受者。多播分組在網(wǎng)絡(luò)中路徑分散的點(diǎn)處被復(fù)制以實(shí)現(xiàn)到多個(gè)接收者的有效數(shù)據(jù)傳遞。PIM被用于動(dòng)態(tài)創(chuàng)建多播分配樹，以在限制分配的同時(shí)確保到預(yù)期接收者的分配，從而使不在源和接收者之間的路徑上的網(wǎng)段不會(huì)負(fù)擔(dān)不必要的流量。
多播操作基于組的概念。多播組是表示出有興趣接收特定數(shù)據(jù)流的一組任意的接收者。這樣的組沒有物理或地理上的邊界。有興趣接收流到特定組的數(shù)據(jù)的主機(jī)使用因特網(wǎng)組管理協(xié)議(IGMP)加入該組。
IP多播地址或其一部分指定特定組。例如在IPv4和IPv6中，預(yù)留特定地址范圍以用于指定多播組。
具有多播能力的路由器創(chuàng)建分配樹，該分配樹控制IP多播流量通過網(wǎng)絡(luò)所采取的路徑，以便將流量傳遞到所有接收者。兩種基本類型的多播分配樹是源樹和共享樹。
在源樹中，多播流量源是根，并且分枝構(gòu)成通過網(wǎng)絡(luò)去往接收者的生成樹。這還被稱為最短路徑樹(SPT)，因?yàn)樵摌渫ǔＪ褂猛ㄟ^網(wǎng)絡(luò)在源和接收者之間的最短路徑。特定的SPT用(S，G)地址來指代，其中S是源的IP地址，而G是受者組的組地址。
與其根位于源的源樹不同，共享樹使用單個(gè)公共根，這個(gè)根位于網(wǎng)絡(luò)中某個(gè)選定點(diǎn)上。該共享根被稱為集合點(diǎn)(RP)。由于定向到特定多播組的所有流量源都使用公共的共享樹，因此共享樹用寫為(*，G)形式的地址來標(biāo)識(shí)。在這種通配符的符號(hào)中，*指代所有源，而G代表多播組。
源樹和共享樹都是自由環(huán)路的。消息優(yōu)選地只在樹的分枝處被復(fù)制。多播組的成員可以在任意時(shí)刻加入或離開；因此分配樹被動(dòng)態(tài)更新。當(dāng)在特定分枝中的所有活動(dòng)的接收者都停止請求特定多播組的流量時(shí)，路由器從分配樹中剪掉這個(gè)分枝，并停止沿這個(gè)分枝向下轉(zhuǎn)發(fā)流量。
在單播路由中，流量根據(jù)預(yù)先計(jì)算的路由而沿著從源到目的地主機(jī)的單個(gè)路徑通過網(wǎng)絡(luò)被轉(zhuǎn)發(fā)。單播路由器通常不考慮源地址；它只考慮目的地地址，以及它將如何朝著目的地的方向轉(zhuǎn)發(fā)流量。路由器通過其路由表掃描以找到對目的地地址的匹配(在很多情況下，實(shí)際上是對目的地地址的前綴構(gòu)成部分的匹配)，然后在去往目的地的方向上將單播分組的單個(gè)拷貝從正確的接口轉(zhuǎn)發(fā)出去。
相比之下，在多播轉(zhuǎn)發(fā)中，源將流量發(fā)送到由多播組地址代表的一組任意的主機(jī)。多播路由器必須確定哪個(gè)方向是上游方向(朝著樹的根的方向)，以及哪個(gè)是下游方向(或多個(gè)下游方向)。如果存在多條下游路徑，路由器則復(fù)制分組，并基于接收者的需求沿著適當(dāng)?shù)南掠温窂较蛳罗D(zhuǎn)發(fā)分組。轉(zhuǎn)發(fā)多播流量遠(yuǎn)離根(而不是去往接收者)被稱為反向路徑轉(zhuǎn)發(fā)(RPF)。
“RPF故障”是多播路由操作中的一個(gè)重要概念。單播路由技術(shù)被用于確定來自接收者的路徑，或返回樹根的中間節(jié)點(diǎn)。經(jīng)由來自樹根的路徑接收到的分組適合于進(jìn)一步向下游轉(zhuǎn)發(fā)。在其他未連接到該路徑的接口上接收到的分組將不會(huì)被轉(zhuǎn)發(fā)，并且它們的接受被稱為RPF故障。以這種方式區(qū)分上游和下游流量被稱為RPF檢查，并且有助于確保分配樹保持自由環(huán)路。
為了識(shí)別正確的反向路徑，PIM可以采用多種單播路由協(xié)議，包括增強(qiáng)型內(nèi)部網(wǎng)關(guān)路由協(xié)議(EIGRP)、開放最短路徑優(yōu)先(OSPF)、邊界網(wǎng)關(guān)協(xié)議(BGP)等等。PIM通常使用由這種單播路由協(xié)議開發(fā)的單播路由表來執(zhí)行RPF功能，而不是構(gòu)建獨(dú)立的多播路由表。
存在各種PIM轉(zhuǎn)發(fā)模式，包括PIM密集模式、PIM稀疏模式和雙向PIM?，F(xiàn)在將論述這些示例性的PIM轉(zhuǎn)發(fā)模式。源特定多播(SSM)也被本發(fā)明的實(shí)施例所包含。
PIM密集模式最初使用推模型(push model)將多播流量覆蓋(flood)到網(wǎng)絡(luò)中的每個(gè)角落。不具有下游鄰居(接收者)的邊緣路由器修剪返回分配樹。該覆蓋修剪過程例如每三分鐘重復(fù)一次。路由器通過經(jīng)由覆蓋和修剪機(jī)制接收數(shù)據(jù)流來積累關(guān)于分配樹形狀的狀態(tài)信息。這些數(shù)據(jù)流包含源和組信息，以使下游路由器能夠建立它們的多播轉(zhuǎn)發(fā)表。PIM密集模式只支持源樹，不支持共享樹。
PIM稀疏模式使用拉模型(pull model)來傳遞多播流量。只有具有已經(jīng)明確請求數(shù)據(jù)的活動(dòng)接收者的網(wǎng)段將接收流量。PIM稀疏模式使用共享樹，最初還建立源樹以提高效率。源首先注冊到RP，然后將數(shù)據(jù)從源轉(zhuǎn)發(fā)到RP，并向下轉(zhuǎn)發(fā)到接收者。
更具體而言，源的直接鄰居(也被稱為共享介質(zhì)的指定路由器或DR)得知源的傳輸，并封裝源流量以用于轉(zhuǎn)發(fā)到RP。最后一跳路由器(即在共享樹上直接連接到一個(gè)或多個(gè)接收者的路由器)在接收到共享樹上通過RP來自特定源的數(shù)據(jù)分組時(shí)，得知該特定源。最后一跳路由器隨后在朝著源的方向上發(fā)送PIM加入消息。
當(dāng)接收者想要加入共享樹時(shí)，它將IGMP消息發(fā)送到其直接鄰居。在這些直接鄰居中的DR通過通知該接收者有興趣接收沿該共享樹向下流動(dòng)的多播分組，并在需要時(shí)向RP發(fā)送加入消息而作出反應(yīng)。DR也可以代表接收者進(jìn)行切換以經(jīng)由SPT加入該源。PIM加入消息然后將在朝著源的方向上被發(fā)送。
雙向PIM是對已開發(fā)出的PIM協(xié)議的增強(qiáng)以協(xié)助有效的多對多通信。使用雙向模式，多播組可以僅僅利用最少量的附加開銷適應(yīng)任意的源數(shù)目。
在PIM稀疏模式中創(chuàng)建的共享樹是單向的。源樹必須被創(chuàng)建為將數(shù)據(jù)流帶入RP(共享樹的根)，然后它可以沿著分枝被向下轉(zhuǎn)發(fā)到接收者。源數(shù)據(jù)無法朝著RP沿共享樹向上流動(dòng)。相比之下，在雙向模式中，流量只沿著以RP為根的雙向共享樹被路由。來自源的數(shù)據(jù)可以朝著RP沿共享樹向上流動(dòng)，然后沿著共享樹的其他分枝向下流動(dòng)到接收者。
多播路由體系結(jié)構(gòu)圖1示出了可以應(yīng)用本發(fā)明的實(shí)施例的網(wǎng)絡(luò)設(shè)備100。線路卡102包括用于耦合到物理介質(zhì)的網(wǎng)絡(luò)接口。如下所述，在線路卡102內(nèi)還會(huì)發(fā)現(xiàn)轉(zhuǎn)發(fā)智能。這里只示出了兩個(gè)線路卡102，但是應(yīng)當(dāng)理解，實(shí)際上在同一網(wǎng)絡(luò)設(shè)備100中可能存在非常大量的線路卡。線路卡102通過用于傳輸分組的高速背板104而互連。路由處理器106負(fù)責(zé)控制平面功能。路由處理器106具有到高速背板104的相對低速連接。
路由處理器106的部分功能可以由包括存儲(chǔ)在程序存儲(chǔ)器108中的指令的軟件來實(shí)現(xiàn)。但是，程序存儲(chǔ)器108只是可以存儲(chǔ)在實(shí)現(xiàn)本發(fā)明的實(shí)施例時(shí)所使用的軟件的計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)的一個(gè)示例。其他示例例如包括硬盤驅(qū)動(dòng)器、CD-ROM、閃存等等。計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)的另一示例是在網(wǎng)絡(luò)上運(yùn)載軟件的信號(hào)。
圖2示出了根據(jù)本發(fā)明一個(gè)實(shí)施例的線路卡102的內(nèi)部結(jié)構(gòu)。內(nèi)部接口202耦合到背板104以提供到網(wǎng)絡(luò)設(shè)備100的剩余部分的連接。外部接口204提供到各種物理網(wǎng)絡(luò)介質(zhì)的訪問。外部接口204可以是以太網(wǎng)接口、SONET接口、撥號(hào)接口、電纜數(shù)據(jù)接口、DSL接口等。雖然只示出了兩個(gè)外部接口204，但是可以存在任意數(shù)目N個(gè)外部接口。
轉(zhuǎn)發(fā)引擎206對單個(gè)分組執(zhí)行轉(zhuǎn)發(fā)判決，即，轉(zhuǎn)發(fā)引擎206選擇接收到的分組將被轉(zhuǎn)發(fā)到的下一節(jié)點(diǎn)，以及為了轉(zhuǎn)發(fā)到該選出的下一節(jié)點(diǎn)，分組將被傳輸?shù)降木W(wǎng)絡(luò)設(shè)備100的線路卡/接口。在采用分布式體系結(jié)構(gòu)的某些實(shí)現(xiàn)方式中，轉(zhuǎn)發(fā)引擎操作可以被劃分到接收分組的線路卡(“入口線路卡”)和在朝著分組目的地的方向上中繼分組的線路卡(“出口線路卡”)中。
分組存儲(chǔ)器208提供對分組的中間存儲(chǔ)。程序存儲(chǔ)器210可以被用于存儲(chǔ)在實(shí)現(xiàn)轉(zhuǎn)發(fā)引擎206中有用的軟件指令。用于實(shí)現(xiàn)轉(zhuǎn)發(fā)引擎206的任意部分的指令可以被存儲(chǔ)在任意計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)中，如以上參考圖1中的程序存儲(chǔ)器108所論述的。在執(zhí)行轉(zhuǎn)發(fā)判決時(shí)，轉(zhuǎn)發(fā)引擎206參考多播轉(zhuǎn)發(fā)表MFIB 212。
根據(jù)本發(fā)明的實(shí)施例，用于網(wǎng)絡(luò)設(shè)備100的多播路由操作的控制和轉(zhuǎn)發(fā)平面保持分離。路由處理器106操作控制平面，并且無需處理將被轉(zhuǎn)發(fā)的數(shù)據(jù)分組就能夠維護(hù)對多播協(xié)議上下文的感知能力。為了支持多播路由操作，路由處理器106維護(hù)多播路由協(xié)議拓?fù)浔?MRPTT)。當(dāng)需要協(xié)議操作時(shí)，轉(zhuǎn)發(fā)引擎206(在所有線路卡中被復(fù)制)通過識(shí)別特定的MFIB條目以及路由處理器106應(yīng)該得知的相關(guān)接口，來以信號(hào)通知路由處理器106適當(dāng)?shù)馗缕鋮f(xié)議上下文。信令機(jī)制優(yōu)選地使去往路由處理器106的信令最小化。轉(zhuǎn)發(fā)引擎206將轉(zhuǎn)發(fā)信息丟失或不完全的分組保存在MFIB中，直到這些轉(zhuǎn)發(fā)信息在MFIB中變?yōu)榭捎?。為了達(dá)到MFIB信令的要求并且實(shí)現(xiàn)正確的多播路由協(xié)議操作，路由處理器106適當(dāng)?shù)刈⒔釳FIB 212的內(nèi)容。路由處理器106和轉(zhuǎn)發(fā)引擎206在模塊上彼此不同，經(jīng)由修改和對MFIB 212的內(nèi)容的監(jiān)控進(jìn)行交互。
轉(zhuǎn)發(fā)引擎206采用多播路由協(xié)議無關(guān)狀態(tài)轉(zhuǎn)換方案來確定每個(gè)接收到的多播分組的處理。給定的多播分組可以按照需要被轉(zhuǎn)發(fā)、丟棄、保存或復(fù)制到主機(jī)應(yīng)用。轉(zhuǎn)發(fā)引擎206在不知道協(xié)議上下文的情況下進(jìn)行操作，基于由路由處理器106控制的MFIB條目對各個(gè)分組執(zhí)行判決。轉(zhuǎn)發(fā)邏輯被相信包含所有已知的未經(jīng)修改的多播路由協(xié)議。
這樣，多播轉(zhuǎn)發(fā)引擎的實(shí)現(xiàn)方式可以獨(dú)立于多播路由協(xié)議中的變化而被移植、定制、優(yōu)化、分布和發(fā)展。此外，多播路由協(xié)議本身可以通過改變路由處理器的操作而被改變，并且無需跟隨這里所述的狀態(tài)轉(zhuǎn)換而對轉(zhuǎn)發(fā)引擎的操作進(jìn)行任何改變。
轉(zhuǎn)發(fā)引擎的操作在繼續(xù)論述之前，有必要理解MFIB 212的結(jié)構(gòu)。圖3示出了根據(jù)本發(fā)明一個(gè)實(shí)施例的MFIB 212的結(jié)構(gòu)。MFIB具有樹結(jié)構(gòu)，以協(xié)助找到對組和多播分組的源地址的最好匹配。在單播路由表中，用于匹配目的的條目通常是地址前綴。每個(gè)前綴由地址和掩碼表示，所述掩碼指示地址中的多少個(gè)最高有效位構(gòu)成用于匹配目的的前綴。當(dāng)單播分組將被轉(zhuǎn)發(fā)時(shí)，將目的地地址與轉(zhuǎn)發(fā)表中的前綴條目相比較，以找到具有最長前綴的條目，所述最長前綴仍舊匹配目的地地址的相應(yīng)最高有效位。為了執(zhí)行這種匹配，目的地地址和在表中將被匹配的地址值都與在最低有效位(未構(gòu)成前綴的一部分)上包括“1”值的掩碼進(jìn)行AND操作。
圖3中的MFIB以類似方式工作。但是，這里匹配是用于組前綴(如由組地址和掩碼所指示的)和源地址的組合。為了匹配的目的，源地址可以被視為組地址的擴(kuò)展。對組合組和源條目的匹配被看作比對不需要源匹配的(*，G/M)條目的匹配更長(因此“更好的”)的匹配。
圖3示出了從根據(jù)本發(fā)明一個(gè)實(shí)施例的MFIB中選出的條目。為了協(xié)助最長前綴匹配，最長匹配將是樹中最深的匹配條目。第一條目302對應(yīng)于組地址224.1.0.0，其中前面16位是用于匹配目的的前綴。源地址對于匹配目的是“無關(guān)緊要的”。在樹中更深的一層上發(fā)現(xiàn)了兩個(gè)從條目302懸掛的條目304和306。條目304具有組地址224.1.1.1，而條目306具有組地址224.1.1.2。對于條目304和306兩者，條目的全部32位都被用于匹配目的，同時(shí)源地址保持“無關(guān)緊要”。從條目306懸掛著兩個(gè)其他條目308和310。條目308和310共享與306相同的組地址，但是條目308指定源地址10.1.1.3，而條目310指定源地址20.1.3.5。對于條目308和310，級聯(lián)的源和組地址的全部64位被用于匹配目的。當(dāng)然應(yīng)當(dāng)理解，大多數(shù)MFIB實(shí)現(xiàn)方式包括非常多的條目，圖3中示出的有限數(shù)目的條目僅僅出于使說明清晰的目的。
根據(jù)本發(fā)明的實(shí)施例，在MFIB中的每個(gè)條目可以有被設(shè)置或清零的各種標(biāo)志。這些標(biāo)志中的一些應(yīng)用于全部條目。其他標(biāo)志專用于條目和網(wǎng)絡(luò)設(shè)備100的指定接口之一。圖4示出了特定條目的細(xì)節(jié)?？梢詾槿織l目設(shè)置或清零指定為IA、DS、DSS、C和X的標(biāo)志。為特定接口設(shè)置和清零被指定為SP、A、F、NS、NSS和IC的標(biāo)志。接口可以包括物理接口、IP層接口或任意到軟件創(chuàng)建的隧道的接口。
現(xiàn)在將簡要論述標(biāo)志的意思。這后面將跟隨在各種多播路由情形中轉(zhuǎn)發(fā)引擎狀態(tài)機(jī)的操作示例。
AA標(biāo)志指示與條目匹配的多播分組是否將在特定接口上被接受。
FF標(biāo)志指示與條目匹配的已被接受的多播分組是否將在特定接口上被轉(zhuǎn)發(fā)。但是，如果分組在該接口到達(dá)，F(xiàn)標(biāo)志則將被忽略。
SPSP標(biāo)志被用于以信號(hào)通知路由處理器數(shù)據(jù)分組已到達(dá)。然后路由處理器也將得知該數(shù)據(jù)分組的源、組和接收接口。路由處理器可以基于數(shù)據(jù)分組到達(dá)的通知和當(dāng)前協(xié)議上下文的知識(shí)的組合來確定它應(yīng)該更新多播協(xié)議狀態(tài)、更新MFIB等。會(huì)在路由處理器的一部分上導(dǎo)致這種行為的數(shù)據(jù)分組到達(dá)事件的示例例如包括在PIM密集模式的接口上來自新的源的多播分組的到達(dá)、RPF故障等等。轉(zhuǎn)發(fā)引擎本身無法得知協(xié)議狀態(tài)，但是知道它應(yīng)該在何時(shí)通過使用SP標(biāo)志以信號(hào)通知路由處理器。
當(dāng)另一數(shù)據(jù)分組到達(dá)時(shí)(這通常會(huì)導(dǎo)致一個(gè)信號(hào))，SP標(biāo)志已被發(fā)送的事實(shí)避免其他信號(hào)被發(fā)送到路由處理器。因此，用于該(*，G/M)或源、組和接口的組合(S，G，I)的信號(hào)被過濾，直到路由處理器在適當(dāng)條目的特定接口上清零SP標(biāo)志。路由處理器將選擇它在何時(shí)清零SP標(biāo)志。在所述實(shí)現(xiàn)方式中，SP標(biāo)志是唯一一個(gè)由轉(zhuǎn)發(fā)引擎設(shè)置并由路由協(xié)議清零的標(biāo)志。所有其他所述標(biāo)志都由路由協(xié)議來設(shè)置和清零。
DS和NS這些標(biāo)志被路由處理器所設(shè)置和清零，以在設(shè)置SP標(biāo)志的過程中控制轉(zhuǎn)發(fā)引擎的行為。DS標(biāo)志被設(shè)置和清零，以從總體上控制用于條目的信令。NS標(biāo)志被用于使特定接口上的DS值無效。如果DS(用于匹配條目)異或NS(用于在匹配條目上的接收接口)被設(shè)置，則信令被制止。如果DS和NS兩者被設(shè)置或兩者都不被設(shè)置，則信令可以出現(xiàn)。
DSS和NSS路由處理器使用這些標(biāo)志來有選擇地強(qiáng)制信令在新創(chuàng)建的源條目上發(fā)生，而不是在匹配(*，G/M)條目上發(fā)生。這可以發(fā)現(xiàn)新源并且適當(dāng)?shù)貏?chuàng)建源專用的狀態(tài)信息。然后分組應(yīng)該被保存，以使其能夠由轉(zhuǎn)發(fā)引擎基于對新條目的匹配而被重新處理。對于全部條目，DSS標(biāo)志被設(shè)置和清零。NSS標(biāo)志被設(shè)置為使用于特定接口的DSS值無效。
C路由處理器將在它想要轉(zhuǎn)發(fā)引擎檢查分組源是否處于直接連接中的某些情況下設(shè)置該標(biāo)志。這與某些多播路由情況相關(guān)，例如當(dāng)該網(wǎng)絡(luò)設(shè)備是在共享介質(zhì)上用于檢測PIM稀疏模式分布網(wǎng)絡(luò)中的新源的指定路由器(DR)時(shí)。
IC在某些情況下，對于在網(wǎng)絡(luò)設(shè)備100上運(yùn)行的主機(jī)應(yīng)用，應(yīng)該執(zhí)行分組復(fù)制。IC標(biāo)志用于輔助確定應(yīng)該在何時(shí)執(zhí)行這種復(fù)制，并應(yīng)該在何時(shí)經(jīng)由棧將其發(fā)送到應(yīng)用。例如，網(wǎng)絡(luò)設(shè)備100工作在某些情況下，以用于轉(zhuǎn)發(fā)分組并在應(yīng)用層上處理分組的內(nèi)容。一個(gè)示例是RP發(fā)現(xiàn)協(xié)議的操作以自動(dòng)發(fā)現(xiàn)RP。
IAIA標(biāo)志在PIM雙向模式中非常有用。IA標(biāo)志提示轉(zhuǎn)發(fā)引擎查找父條目，以判斷即使對于特定接口的A標(biāo)志未被設(shè)置，也是否在該接口上接受多播分組。
XX標(biāo)志出于創(chuàng)建條目的目的而被單獨(dú)設(shè)置。例如，在配置時(shí)，路由處理器將對標(biāo)識(shí)出在PIM密集模式下工作的組的所有條目設(shè)置X標(biāo)志。
圖5示出了根據(jù)本發(fā)明的一個(gè)實(shí)施例，用于多播轉(zhuǎn)發(fā)引擎的狀態(tài)轉(zhuǎn)換圖。圖5描述了對單個(gè)接收到的多播分組的處理。多播分組的可能處理包括丟棄該分組、轉(zhuǎn)發(fā)該分組、保存該分組以使路由處理器能夠在轉(zhuǎn)發(fā)之前調(diào)整控制狀態(tài)，或者執(zhí)行分組復(fù)制以待本地主機(jī)應(yīng)用所使用。下面將參考若干示例性的多播路由情形來描述操作。
由于狀態(tài)轉(zhuǎn)換圖是交叉的，因此在MFIB標(biāo)志設(shè)置和轉(zhuǎn)發(fā)條目的創(chuàng)建和刪除之間存在復(fù)雜的交互關(guān)系。當(dāng)存在需要被保存在條目上的信息(標(biāo)志)時(shí)，則條目存在。如果不存在標(biāo)志，則條目被刪除。如果在之前沒有設(shè)置標(biāo)志的情況下，一個(gè)標(biāo)志被設(shè)置，則一個(gè)條目或條目上的接口被創(chuàng)建。
PIM密集模式路由創(chuàng)建第一示例將集中于接收來自新源的PIM密集模式多播分組的路由器。在狀態(tài)502處，轉(zhuǎn)發(fā)引擎測試接收到的分組實(shí)際上是否是IGMP控制分組。由于該分組實(shí)際上是來自新的PIM密集模式源的多播分組，因此測試結(jié)果為否，并且處理前進(jìn)至狀態(tài)504。狀態(tài)504在MFIB中查找接收到的多播分組的(S，G)地址以找到匹配。由于這是接收自該源的第一個(gè)多播分組，因此不存在(S，G)條目，并且匹配過程前進(jìn)至狀態(tài)506。
狀態(tài)506嘗試在MFIB中找到對(*，G/M)條目的最長匹配。實(shí)際上存在對在多播路由協(xié)議被配置時(shí)已創(chuàng)建(通過在其上設(shè)置X標(biāo)志)的條目的匹配。該條目標(biāo)識(shí)出工作在PIM密集模式下并具有類似行為的所有組或組的范圍。如果不存在條目，則在狀態(tài)508處丟棄分組。由于實(shí)際上存在匹配(*，G/M)條目，因此處理前進(jìn)至狀態(tài)510。狀態(tài)510測試對于接收到該多播分組的接口是否在匹配的條目上設(shè)置了IC標(biāo)志。該匹配條目不具有接口信息，并且所有接口標(biāo)志被清零，因此處理前進(jìn)至狀態(tài)512以測試C標(biāo)志。C標(biāo)志也被清零，因此處理前進(jìn)至狀態(tài)514。
狀態(tài)514測試DS和NS標(biāo)志，它們控制是否可以發(fā)生SP信令。由于這兩個(gè)標(biāo)志都被清零，因此到達(dá)狀態(tài)516。狀態(tài)516測試DSS和NSS標(biāo)志。這些標(biāo)志控制SP標(biāo)志是否應(yīng)該設(shè)置在匹配條目上，或被設(shè)置在出于信令目的而可能需要被創(chuàng)建的(S，G)條目上。在匹配條目上的信令將不會(huì)傳輸在接收到的多播分組中固有的全部(S，G，I)信息。在這種情況下，DSS和NSS標(biāo)志都被清零，因此處理前進(jìn)至狀態(tài)518，該狀態(tài)檢查SP標(biāo)志是否被設(shè)置在接收該多播分組的接口上。由于這是來自該源的第一個(gè)分組，因此不存在在前信號(hào)，從而SP標(biāo)志被清零。實(shí)際上，(S，G)條目完全不存在就意味著其所有標(biāo)志都被暗中清零。
這導(dǎo)致了狀態(tài)520，該狀態(tài)在對應(yīng)于接收到的分組的(S，G)地址的條目上為接收接口設(shè)置SP。由于這是在從未存在的條目上的從未存在的接口，因此條目和接口被創(chuàng)建，作為設(shè)置標(biāo)志的一部分。路由處理器因此被告知數(shù)據(jù)到達(dá)事件以及接收到的分組的全部(S，G，I)信息。然后在狀態(tài)522處，分組被保存。接收到的分組被轉(zhuǎn)發(fā)引擎所保存，并與(S，G)條目和接口相關(guān)聯(lián)。保存的原因在于路由處理器還未以關(guān)于如何轉(zhuǎn)發(fā)分組的信息填充MFIB條目。還不存在具有設(shè)置在新條目上的A和F標(biāo)志的任何接口。分組被保存，以給路由處理器提供進(jìn)一步填充新的MFIB條目的機(jī)會(huì)。一旦路由處理器已經(jīng)清零SP標(biāo)志，則將指示它已經(jīng)調(diào)整了MFIB的內(nèi)容，并以信號(hào)通知轉(zhuǎn)發(fā)引擎是時(shí)候基于新信息(下面將描述)來轉(zhuǎn)發(fā)分組了。
具有相同(S，G)地址并到達(dá)相同接口的后續(xù)分組將在狀態(tài)504處匹配，并將以相同方式前進(jìn)通過狀態(tài)510、512、514和516，但是將在狀態(tài)518處肯定地測試，從而跳過信令狀態(tài)，直接進(jìn)入狀態(tài)522處分組的保存。這是關(guān)于轉(zhuǎn)發(fā)引擎如何從到達(dá)路由處理器中過濾不必要的信令的一個(gè)很好的示例。路由處理器已經(jīng)得知新的源并且不需要被重新通知。
現(xiàn)在，讓我們考慮路由處理器對SP標(biāo)志的設(shè)置的反應(yīng)細(xì)節(jié)。路由處理器現(xiàn)在得知數(shù)據(jù)分組已經(jīng)從源S到達(dá)，分組要去往組G，并且它到達(dá)接口I。已知G在對應(yīng)于PIM密集模式的范圍中。注意，轉(zhuǎn)發(fā)引擎不知道這是密集模式的分組，或者G對應(yīng)于密集模式的組。路由處理器檢查分組到達(dá)的接口是否處于朝著源的反向路徑上。假設(shè)該接口處于去往源的反向路徑上，并且RPF檢查已經(jīng)通過，路由器則確定該分組應(yīng)該被轉(zhuǎn)發(fā)到下游。為了實(shí)現(xiàn)這種下游轉(zhuǎn)發(fā)，路由處理器在網(wǎng)絡(luò)設(shè)備中的所有MFIB上填充新的(S，G)條目。在接收接口上A標(biāo)志被設(shè)置。F標(biāo)志在已知被配置為用于多播路由的所有接口上被設(shè)置。設(shè)置F標(biāo)志將涉及創(chuàng)建新接口，這是因?yàn)橹俺鲇谠O(shè)置SP標(biāo)志的目的而僅僅創(chuàng)建了接收接口。
為該(S，G)條目指定缺省的信令行為，從而DS標(biāo)志被保持清零。由于路由處理器將想要知道分組何時(shí)到達(dá)我們通常執(zhí)行轉(zhuǎn)發(fā)的接口，因此該行為適合于密集模式的轉(zhuǎn)發(fā)接口。但是，路由處理器不想要被以信號(hào)告知到達(dá)接受接口的所有新分組。因此在接受接口上，路由處理器設(shè)置NS標(biāo)志。NS標(biāo)志改變了在接受接口上的缺省條目行為，并防止轉(zhuǎn)發(fā)引擎以信號(hào)通知接收到的分組。這是過濾不必要的信令的另一示例。
而且，為條目設(shè)置DSS標(biāo)志。這實(shí)質(zhì)上表示到達(dá)轉(zhuǎn)發(fā)接口的分組將在匹配條目上被發(fā)送。但是，它們將不被保存。在DSS/NSS標(biāo)志后面的基本原理在于，如果目標(biāo)條目已經(jīng)存在，那么路由處理器已經(jīng)對其填充了轉(zhuǎn)發(fā)信息。從而，將不會(huì)對到達(dá)錯(cuò)誤接口的分組感到驚奇，并將不需要保存這些分組。
在以用于控制轉(zhuǎn)發(fā)和信令所需的所有標(biāo)志填充了條目之后，路由處理器以信號(hào)通知轉(zhuǎn)發(fā)引擎這種情況。它是通過清零由轉(zhuǎn)發(fā)引擎在接收到初始分組時(shí)設(shè)置的SP標(biāo)志來完成的。最后的條目(假設(shè)三個(gè)多播接口)是(S，G)設(shè)置標(biāo)志DSSIF1設(shè)置標(biāo)志A、F、NSIF2設(shè)置標(biāo)志FIF3設(shè)置標(biāo)志F當(dāng)轉(zhuǎn)發(fā)引擎發(fā)現(xiàn)SP標(biāo)志已被清零時(shí)，它將釋放在設(shè)置了SP標(biāo)志的接口上排隊(duì)的所有保存的分組。這些分組將再次穿過圖5的狀態(tài)轉(zhuǎn)換圖的簡化版本。該簡化版本只執(zhí)行對(S，G)條目的匹配的查找，檢查在接收接口上是否設(shè)置了A標(biāo)志，如果設(shè)置則轉(zhuǎn)發(fā)分組。A標(biāo)志在狀態(tài)524處被測試，并且轉(zhuǎn)發(fā)發(fā)生在狀態(tài)526處。轉(zhuǎn)發(fā)行為意味著轉(zhuǎn)發(fā)引擎在除了接收接口之外的每個(gè)在匹配條目上設(shè)置了F標(biāo)志的接口上輸出分組的拷貝。
到達(dá)這個(gè)接受接口(也被稱為RPF接口)并匹配已經(jīng)建立的(S，G)條目的后續(xù)分組將穿過狀態(tài)502、504、510、512和514。但是，由于NS標(biāo)志在RPF接口上被設(shè)置，因此處理在狀態(tài)514之后前進(jìn)至狀態(tài)524。狀態(tài)524確定A標(biāo)志實(shí)際上被設(shè)置在接受接口上，然后分組在狀態(tài)526處在適當(dāng)?shù)慕涌谏媳晦D(zhuǎn)發(fā)。
密集模式的RPF故障如上所述，RPF故障表示分組到達(dá)來自該源和組的分組不想要到達(dá)的接口。在這種情況下，路由處理器應(yīng)該被以信號(hào)通知采取適當(dāng)?shù)膮f(xié)議行為，以可能停止轉(zhuǎn)發(fā)錯(cuò)誤分組的節(jié)點(diǎn)。讓我們假設(shè)分組到達(dá)在以上示例中創(chuàng)建的條目的錯(cuò)誤接口。
在狀態(tài)504處，(S，G)條目被匹配。IC和C標(biāo)志在狀態(tài)510和512處被確定清零。狀態(tài)514確定DS在條目上被清零，而NS在該接口上被清零。但是，對于該條目DSS被設(shè)置，并且對于該接收接口NSS被清零。因此，在狀態(tài)516之后，處理前進(jìn)至狀態(tài)528，該狀態(tài)測試SP標(biāo)志是否在接收接口上被設(shè)置。由于SP標(biāo)志實(shí)際上在該接口上被清零，因此處理前進(jìn)至狀態(tài)530，該狀態(tài)設(shè)置SP標(biāo)志。然后，到達(dá)A標(biāo)志被測試的狀態(tài)524。由于A標(biāo)志被清零(這不是接受接口)，因此分組在狀態(tài)532處被丟棄。
由于SP標(biāo)志已被設(shè)置，因此路由處理器現(xiàn)在知道對于特定接口和特定(S，G)地址的分組到達(dá)事件。結(jié)合當(dāng)前多播協(xié)議上下文，路由處理器確定分組不應(yīng)該已被發(fā)送。響應(yīng)于這種情況，路由處理器采取行動(dòng)，發(fā)送適當(dāng)?shù)腜IM控制消息以停止錯(cuò)誤的傳輸，然后清零SP標(biāo)志。如果在SP標(biāo)志被清零之前，在同一接口上到達(dá)更多RPF故障分組，那么由于狀態(tài)524將在不穿過狀態(tài)530的情況下跟隨狀態(tài)528，因此這些分組將在不進(jìn)一步以信令通知的情況下以被丟棄告終。這是信號(hào)過濾的另一示例。
雙向PIM轉(zhuǎn)發(fā)雙向PIM不具有數(shù)據(jù)驅(qū)動(dòng)的協(xié)議事件。路由處理器以A、F和IA標(biāo)志填充MFIB，以使路由器在雙向共享樹內(nèi)適當(dāng)?shù)毓ぷ鳌?br> 雙向PIM操作的一個(gè)方面在于指定轉(zhuǎn)發(fā)器(DF)選擇機(jī)制的使用，該機(jī)制用于在每條鏈路上選擇用于特定責(zé)任的單個(gè)路由器。選出的路由器被稱為DF。該DF負(fù)責(zé)從鏈路上拾取分組，并將它們在朝著集合點(diǎn)(RP)的方向上向上游轉(zhuǎn)發(fā)。而且，如果對于已尋址到分組的組已接收到合適的加入消息，則DF負(fù)責(zé)將來自RP的行進(jìn)分組向下游轉(zhuǎn)發(fā)到同一鏈路。
對于可能的雙向模式組的特定范圍，在網(wǎng)絡(luò)中每條鏈路的所有DF選擇均已完成之后，并在任意源開始發(fā)送或任意接收者加入組之前，DF選擇結(jié)果被反映在MFIB中。因此，所有路由器都具有一個(gè)(*，G/M)條目，該條目在路由器已經(jīng)贏得DF選擇以朝著RP轉(zhuǎn)發(fā)分組的所有接口上都設(shè)置了A。F標(biāo)志被設(shè)置在指向RP的接口上。該接口的A標(biāo)志也被設(shè)置以適應(yīng)于來自RP的下游流量。
當(dāng)源開始發(fā)送時(shí)，數(shù)據(jù)分組將在每個(gè)路由器上匹配(*，G/M)條目，并在去往RP的所有通路上被轉(zhuǎn)發(fā)。沒有信號(hào)產(chǎn)生，因此不需要涉及路由處理器。參考圖5，轉(zhuǎn)發(fā)引擎在到達(dá)狀態(tài)526之前穿過狀態(tài)502、504、506、510、512、514和524，以在集合點(diǎn)的方向上轉(zhuǎn)發(fā)分組。當(dāng)一個(gè)接收者加入該組時(shí)，它將IGMP加入消息(Join)發(fā)送到該接收者附近的最后一跳路由器。在該第一跳路由器內(nèi)，IGMP加入消息被傳輸?shù)铰酚商幚砥?，該路由處理器通過創(chuàng)建(*，G)條目來做出反應(yīng)，該條目在面向接收者的接口上設(shè)置了F標(biāo)志。由于用于該組的分組仍舊需要在朝著RP的方向上被轉(zhuǎn)發(fā)，因此F標(biāo)志也被設(shè)置在面向RP的接口上。
新的(*，G)條目是之前論述的(*，G/M)條目的“子條目”。該新條目不具有任何已經(jīng)設(shè)置了A標(biāo)志的接口。相反，對于該條目設(shè)置了IA標(biāo)志。這指示轉(zhuǎn)發(fā)引擎繼承接受來自父條目的信息。因此，當(dāng)在狀態(tài)524處遇到匹配數(shù)據(jù)分組時(shí)，由于出現(xiàn)被設(shè)置的IA標(biāo)志，因此將參考(*，G/M)條目以判斷分組是否應(yīng)該被接受以用于轉(zhuǎn)發(fā)或丟棄。而且，該路由器沿著樹在朝著集合點(diǎn)的方向上向下一跳路由器中繼加入消息。該下一跳路由器也創(chuàng)建類似的(*，G)條目。
PIM稀疏模式源到集合點(diǎn)的注冊當(dāng)源開始向共享介質(zhì)進(jìn)行發(fā)送時(shí)，在共享介質(zhì)上的路由器之一被指定為封裝源的流量，并將其傳輸?shù)郊宵c(diǎn)以用于在稀疏模式的共享樹上執(zhí)行分配。為了適合這種類型的操作，這樣指定的路由器的路由處理器將在已為其配置了稀疏模式操作的(*，G/M)條目上設(shè)置C標(biāo)志。當(dāng)源的第一個(gè)稀疏模式多播分組被接收時(shí)，轉(zhuǎn)發(fā)引擎穿過狀態(tài)502，在狀態(tài)504處發(fā)現(xiàn)沒有(S，G)匹配，在狀態(tài)506處發(fā)現(xiàn)(*，G/M)匹配，在步驟510處未發(fā)現(xiàn)IC標(biāo)志被設(shè)置，但是在512處發(fā)現(xiàn)C標(biāo)志被設(shè)置。然后在狀態(tài)534處，轉(zhuǎn)發(fā)引擎判斷該分組是否已通過直接連接被接收，該直接連接指示該路由器實(shí)際上將負(fù)責(zé)封裝和隧道操作。如果它還未經(jīng)由直接連接被接收，處理則前進(jìn)至狀態(tài)514。
如果它是直接連接，SP標(biāo)志則在用于接收接口的(S，G)條目上被測試。當(dāng)然，由于該條目還未存在，因此認(rèn)為SP標(biāo)志未被設(shè)置，并且處理前進(jìn)至狀態(tài)520，在該狀態(tài)中，轉(zhuǎn)發(fā)引擎在新創(chuàng)建的(S，G)條目上設(shè)置用于接收接口的SP。然后該分組在狀態(tài)522處被保存。
路由處理器現(xiàn)已得知一事件已在對應(yīng)于稀疏模式操作的組地址上以信號(hào)被告知，該路由處理器通過在新的(S，G)條目上添加虛擬接口來做出反應(yīng)。該虛擬接口將被用于以隧道將分組發(fā)送到集合點(diǎn)，從而A標(biāo)志被設(shè)置在該接口上。NS標(biāo)志也可以被設(shè)置以進(jìn)一步過濾信號(hào)。然后SP標(biāo)志被清零，并且轉(zhuǎn)發(fā)引擎通過使保存的分組穿過狀態(tài)轉(zhuǎn)換圖來進(jìn)行響應(yīng)。A標(biāo)志將已被設(shè)置在接收接口上，并且F和NS標(biāo)志將已被設(shè)置在實(shí)現(xiàn)隧道的虛擬接口上，因此分組將通過隧道而到達(dá)集合點(diǎn)。在該(S，G)條目的接口上接收到的后續(xù)分組也將以這種方式來通過隧道發(fā)送。
各種情形接收到的IGMP消息退出狀態(tài)502以到達(dá)狀態(tài)536。狀態(tài)536測試這些消息是否來源于內(nèi)部。如果它們來源于內(nèi)部，則在狀態(tài)508處丟棄它們，因?yàn)樗鼈儾恍枰M(jìn)一步的處理。如果它們不是來源于內(nèi)部，則狀態(tài)540將它們發(fā)送到工作在路由處理器上的適當(dāng)?shù)闹鳈C(jī)應(yīng)用，以用于處理。
在網(wǎng)絡(luò)設(shè)備動(dòng)作以轉(zhuǎn)發(fā)數(shù)據(jù)并在應(yīng)用層上處理同樣數(shù)據(jù)的某些情形中，轉(zhuǎn)發(fā)引擎將做出分組的內(nèi)部拷貝，并將其發(fā)送到主機(jī)應(yīng)用。路由處理器對于該行為所需條目設(shè)置IC標(biāo)志。這樣，如果在狀態(tài)510處確定IC標(biāo)志被設(shè)置，則狀態(tài)542判斷分組是否來源于內(nèi)部。如果分組來源于內(nèi)部，則常規(guī)操作繼續(xù)轉(zhuǎn)換到狀態(tài)512。如果分組還未來源于內(nèi)部，則狀態(tài)544在繼續(xù)狀態(tài)512處的常規(guī)操作之前，將分組發(fā)送到主機(jī)應(yīng)用。
應(yīng)該理解，這里所描述的示例和實(shí)施例僅僅出于示例性目的，并且本領(lǐng)域技術(shù)人員將想到根據(jù)本發(fā)明的各種修改和改變，并且這些修改和改變將被包括在本申請的精神和范圍內(nèi)以及所附權(quán)利要求及其等同物的全部范圍內(nèi)。例如，本發(fā)明不僅涉及多播協(xié)議的處理，還可被用于簡化其他數(shù)據(jù)驅(qū)動(dòng)的協(xié)議(例如ARP解析和NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換))的實(shí)現(xiàn)方式。
權(quán)利要求
1.在網(wǎng)絡(luò)設(shè)備中，一種用于操作轉(zhuǎn)發(fā)引擎以處理多播分組的方法，所述方法包括提供所述轉(zhuǎn)發(fā)引擎可訪問的多播轉(zhuǎn)發(fā)表；在所述多播轉(zhuǎn)發(fā)表的條目中提供多播操作標(biāo)志；在接收到多播分組之后，基于所述多播分組的地址，在所述多播轉(zhuǎn)發(fā)表中識(shí)別匹配條目；以及在不知道多播協(xié)議狀態(tài)的情況下，基于對所述識(shí)別出的條目中的一個(gè)或多個(gè)所述多播操作標(biāo)志的檢查，來選擇對所述多播分組的處理。
2.如權(quán)利要求1所述的方法，其中所述選出的處理屬于包括以下操作的組轉(zhuǎn)發(fā)所述分組、保存所述分組以及丟棄所述分組。
3.如權(quán)利要求1所述的方法，其中所述多播分組的所述地址包括(S，G)或(*，G)地址。
4.如權(quán)利要求1所述的方法，還包括基于對一個(gè)或多個(gè)所述多播操作標(biāo)志的檢查，向在模塊上不同于接收到所述多播分組的所述轉(zhuǎn)發(fā)引擎的路由處理器發(fā)信號(hào)。
5.如權(quán)利要求4所述的方法，其中以信號(hào)通知的步驟包括設(shè)置所述匹配條目的信號(hào)出現(xiàn)標(biāo)志。
6.如權(quán)利要求4所述的方法，其中以信號(hào)通知的步驟包括創(chuàng)建對應(yīng)于所述多播分組的(S，G)地址的條目；以及設(shè)置所述被創(chuàng)建條目的信號(hào)出現(xiàn)標(biāo)志。
7.如權(quán)利要求1所述的方法，其中提供多播操作標(biāo)志的步驟包括提供對所述多播轉(zhuǎn)發(fā)表的被選條目專用，但對所述網(wǎng)絡(luò)設(shè)備的接口通用的第一多播操作標(biāo)志；以及提供對所述被選條目專用，并且對所述網(wǎng)絡(luò)設(shè)備的被選接口專用的第二多播操作標(biāo)志。
8.如權(quán)利要求1所述的方法，其中在模塊上不同于所述轉(zhuǎn)發(fā)引擎的路由處理器設(shè)置和清零所述多播操作標(biāo)志中被選的多播操作標(biāo)志，以實(shí)現(xiàn)多播路由協(xié)議。
9.如權(quán)利要求1所述的方法，其中在模塊上不同于所述轉(zhuǎn)發(fā)引擎的路由處理器設(shè)置和清零所述多播操作標(biāo)志中被選的多播操作標(biāo)志，以過濾從所述轉(zhuǎn)發(fā)引擎去往所述路由處理器的信令。
10.如權(quán)利要求1所述的方法，其中所述多播路由協(xié)議包括PIM。
11.一種操作網(wǎng)絡(luò)設(shè)備以轉(zhuǎn)發(fā)信息的方法，所述方法包括提供數(shù)據(jù)驅(qū)動(dòng)的數(shù)據(jù)路由協(xié)議；采用轉(zhuǎn)發(fā)引擎來基于由所述轉(zhuǎn)發(fā)引擎維護(hù)的至少一個(gè)標(biāo)志，選擇對接收到的分組的處理，其中所述轉(zhuǎn)發(fā)引擎不知道所述數(shù)據(jù)路由協(xié)議的協(xié)議狀態(tài)；以及從所述轉(zhuǎn)發(fā)引擎向控制平面處理器發(fā)信號(hào)，以協(xié)助在所述控制平面處理器處維護(hù)所述數(shù)據(jù)路由協(xié)議的協(xié)議狀態(tài)。
12.如權(quán)利要求11所述的方法，其中所述數(shù)據(jù)路由協(xié)議包括多播路由協(xié)議。
13.如權(quán)利要求11所述的方法，其中采用所述轉(zhuǎn)發(fā)協(xié)議的步驟包括查詢轉(zhuǎn)發(fā)表。
14.如權(quán)利要求11所述的方法，還包括使用所述控制平面處理器而基于協(xié)議上下文來填充所述轉(zhuǎn)發(fā)表。
15.在網(wǎng)絡(luò)設(shè)備中，一種用于操作轉(zhuǎn)發(fā)引擎以處理多播分組的計(jì)算機(jī)程序產(chǎn)品，所述計(jì)算機(jī)程序產(chǎn)品包括提供所述轉(zhuǎn)發(fā)引擎可訪問的多播轉(zhuǎn)發(fā)表的代碼；在所述多播轉(zhuǎn)發(fā)表的條目中提供多播操作標(biāo)志的代碼；在接收到多播分組之后，基于所述多播分組的地址，在所述多播轉(zhuǎn)發(fā)表中識(shí)別匹配條目的代碼；在不知道多播協(xié)議狀態(tài)的情況下，基于對所述識(shí)別出的條目中的一個(gè)或多個(gè)所述多播操作標(biāo)志的檢查，來選擇對所述多播分組的處理的代碼；以及存儲(chǔ)所述代碼的計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)。
16.如權(quán)利要求15所述的計(jì)算機(jī)程序產(chǎn)品，其中所述選出的處理屬于包括以下操作的組轉(zhuǎn)發(fā)所述分組、保存所述分組以及丟棄所述分組。
17.如權(quán)利要求15所述的計(jì)算機(jī)程序產(chǎn)品，其中所述多播分組的所述地址包括(S，G)或(*，G)地址。
18.如權(quán)利要求15所述的計(jì)算機(jī)程序產(chǎn)品，還包括基于對一個(gè)或多個(gè)所述多播操作標(biāo)志的檢查，向在模塊上不同于接收到所述多播分組的所述轉(zhuǎn)發(fā)引擎的路由處理器發(fā)信號(hào)的代碼。
18.如權(quán)利要求18所述的計(jì)算機(jī)程序產(chǎn)品，其中發(fā)信號(hào)的所述代碼包括設(shè)置所述匹配條目的信號(hào)出現(xiàn)標(biāo)志的代碼。
19.如權(quán)利要求18所述的計(jì)算機(jī)程序產(chǎn)品，其中發(fā)信號(hào)的所述代碼包括創(chuàng)建對應(yīng)于所述多播分組的(S，G)地址的條目的代碼；以及設(shè)置所述被創(chuàng)建條目的信號(hào)出現(xiàn)標(biāo)志的代碼。
20.如權(quán)利要求15所述的計(jì)算機(jī)程序產(chǎn)品，其中提供多播操作標(biāo)志的所述代碼包括提供對所述多播轉(zhuǎn)發(fā)表的被選條目專用，但對所述網(wǎng)絡(luò)設(shè)備的接口通用的第一多播操作標(biāo)志的代碼；以及提供對所述被選條目專用，并且對所述網(wǎng)絡(luò)設(shè)備的被選接口專用的第二多播操作標(biāo)志的代碼。
21.如權(quán)利要求15所述的計(jì)算機(jī)程序產(chǎn)品，其中在模塊上不同于所述轉(zhuǎn)發(fā)引擎的路由處理器設(shè)置和清零所述多播操作標(biāo)志中被選的多播操作標(biāo)志，以實(shí)現(xiàn)多播路由協(xié)議。
22.如權(quán)利要求15所述的計(jì)算機(jī)程序產(chǎn)品，其中在模塊上不同于所述轉(zhuǎn)發(fā)引擎的路由處理器設(shè)置和清零所述多播操作標(biāo)志中被選的多播操作標(biāo)志，以過濾從所述轉(zhuǎn)發(fā)引擎去往所述路由處理器的信令。
23.如權(quán)利要求15所述的計(jì)算機(jī)程序產(chǎn)品，其中所述多播路由協(xié)議包括PIM。
24.一種用于操作網(wǎng)絡(luò)設(shè)備以轉(zhuǎn)發(fā)信息的計(jì)算機(jī)程序產(chǎn)品，所述計(jì)算機(jī)程序產(chǎn)品包括提供數(shù)據(jù)驅(qū)動(dòng)的數(shù)據(jù)路由協(xié)議的代碼；采用轉(zhuǎn)發(fā)引擎來基于由所述轉(zhuǎn)發(fā)引擎維護(hù)的至少一個(gè)標(biāo)志，選擇對接收到的分組的處理的代碼，其中所述轉(zhuǎn)發(fā)引擎不知道所述數(shù)據(jù)路由協(xié)議的協(xié)議狀態(tài)；從所述轉(zhuǎn)發(fā)引擎向控制平面處理器發(fā)信號(hào)，以協(xié)助在所述控制平面處理器處維護(hù)所述數(shù)據(jù)路由協(xié)議的協(xié)議狀態(tài)的代碼；以及存儲(chǔ)所述代碼的計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)。
25.如權(quán)利要求24所述的計(jì)算機(jī)程序產(chǎn)品，其中所述數(shù)據(jù)路由協(xié)議包括多播路由協(xié)議。
26.如權(quán)利要求24所述的計(jì)算機(jī)程序產(chǎn)品，其中采用所述轉(zhuǎn)發(fā)協(xié)議的所述代碼包括查詢轉(zhuǎn)發(fā)表的代碼。
27.如權(quán)利要求24所述的計(jì)算機(jī)程序產(chǎn)品，還包括使用所述控制平面處理器而基于協(xié)議上下文來填充所述轉(zhuǎn)發(fā)表的代碼。
28.用于處理多播分組的裝置，所述裝置包括轉(zhuǎn)發(fā)引擎，其1)存儲(chǔ)具有保存著多播操作標(biāo)志的條目的多播轉(zhuǎn)發(fā)表，2)在接收到多播分組時(shí)，基于所述分組的地址在所述多播轉(zhuǎn)發(fā)表中識(shí)別匹配條目，以及3)在不知道多播路由協(xié)議狀態(tài)的情況下，選擇對所述多播分組的處理；以及路由處理器，該路由處理器在模塊上不同于維護(hù)所述協(xié)議狀態(tài)的所述轉(zhuǎn)發(fā)引擎。
29.如權(quán)利要求28所述的裝置，其中所述選出的處理屬于包括以下操作的組轉(zhuǎn)發(fā)所述分組、保存所述分組以及丟棄所述分組。
30.如權(quán)利要求28所述的裝置，其中所述多播分組的所述地址包括(S，G)或(*，G)地址。
31.如權(quán)利要求28所述的裝置，還包括其中所述轉(zhuǎn)發(fā)引擎向接收到所述多播分組的所述路由處理器發(fā)信號(hào)。
32.如權(quán)利要求28所述的裝置，其中所述轉(zhuǎn)發(fā)引擎通過設(shè)置所述匹配條目的信號(hào)出現(xiàn)標(biāo)志來發(fā)信號(hào)。
33.如權(quán)利要求33所述的裝置，其中所述轉(zhuǎn)發(fā)引擎通過以下方式來發(fā)信號(hào)創(chuàng)建對應(yīng)于所述多播分組的(S，G)地址的條目，并且設(shè)置所述被創(chuàng)建條目的信號(hào)出現(xiàn)標(biāo)志。
34.如權(quán)利要求28所述的裝置，其中所述多播操作標(biāo)志包括對所述多播轉(zhuǎn)發(fā)表的被選條目專用，但對所述網(wǎng)絡(luò)設(shè)備的接口通用的第一多播操作標(biāo)志，以及對所述被選條目專用，并且對所述網(wǎng)絡(luò)設(shè)備的被選接口專用的第二多播操作標(biāo)志。
35.如權(quán)利要求28所述的裝置，其中所述路由處理器設(shè)置和清零所述多播操作標(biāo)志中被選出的多播操作標(biāo)志，以實(shí)現(xiàn)多播路由協(xié)議。
36.如權(quán)利要求28所述的裝置，其中在模塊上不同于所述轉(zhuǎn)發(fā)引擎的所述路由處理器設(shè)置和清零所述多播操作標(biāo)志中被選的多播操作標(biāo)志，以過濾從所述轉(zhuǎn)發(fā)引擎去往所述路由處理器的信令。
37.如權(quán)利要求28所述的裝置，其中所述多播路由協(xié)議包括PIM。
38.在網(wǎng)絡(luò)設(shè)備中，用于操作轉(zhuǎn)發(fā)引擎以處理多播分組的裝置，所述裝置包括用于提供所述轉(zhuǎn)發(fā)引擎可訪問的多播轉(zhuǎn)發(fā)表的裝置；用于在所述多播轉(zhuǎn)發(fā)表的條目中提供多播操作標(biāo)志的裝置；用于在接收到多播分組之后，基于所述多播分組的地址，在所述多播轉(zhuǎn)發(fā)表中識(shí)別匹配條目的裝置；以及用于在不知道多播協(xié)議狀態(tài)的情況下，基于對所述識(shí)別出的條目中的一個(gè)或多個(gè)所述多播操作標(biāo)志的檢查，來選擇對所述多播分組的處理的裝置。
39.用于操作網(wǎng)絡(luò)設(shè)備以轉(zhuǎn)發(fā)信息的裝置，所述裝置包括用于提供數(shù)據(jù)驅(qū)動(dòng)的數(shù)據(jù)路由協(xié)議的裝置；用于采用轉(zhuǎn)發(fā)引擎來基于由所述轉(zhuǎn)發(fā)引擎維護(hù)的至少一個(gè)標(biāo)志選擇對接收到的分組的處理的裝置，其中所述轉(zhuǎn)發(fā)引擎不知道所述數(shù)據(jù)路由協(xié)議的協(xié)議狀態(tài)；以及用于從所述轉(zhuǎn)發(fā)引擎向控制平面處理器發(fā)信號(hào)，以協(xié)助在所述控制平面處理器處維護(hù)所述數(shù)據(jù)路由協(xié)議的協(xié)議狀態(tài)的裝置。
全文摘要
本發(fā)明提供了用于實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)協(xié)議的系統(tǒng)和方法。在一個(gè)實(shí)施例中，提供了多播路由協(xié)議的實(shí)現(xiàn)方式。通過將功能強(qiáng)大而簡單的應(yīng)用程序接口(API)用于模塊間通信，從而提供多播轉(zhuǎn)發(fā)和控制元件之間的分離。API是多播路由協(xié)議無關(guān)的，并且可以被用于表示任意現(xiàn)有多播協(xié)議的轉(zhuǎn)發(fā)狀態(tài)。從而使有效的平臺(tái)專用實(shí)現(xiàn)方式更便利。
文檔編號(hào)H04L12/18GK1754353SQ200480005028
公開日2006年3月29日 申請日期2004年1月23日 優(yōu)先權(quán)日2003年2月28日
發(fā)明者艾斯德爾·庫韋拉斯, 洛倫佐·維西薩諾, 托尼·斯佩克曼 申請人:思科技術(shù)公司