專利名稱：拓?fù)涓淖儓笪牡奶幚矸椒ê吞幚硌b置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)傳輸技術(shù)，具體涉及一種在網(wǎng)絡(luò)拓?fù)涓淖兒髮ν負(fù)涓淖?TC，Topology Change)報文的處理方法和處理裝置。
背景技術(shù)：
快速生成樹協(xié)議(RSTP，Rapid Spanning Tree Protocol)和多生成樹協(xié)議(MSTP，Multiple Spanning Tree Protocol)都屬于生成樹協(xié)議的改進(jìn)協(xié)議，其作用是將環(huán)路網(wǎng)絡(luò)修剪成無環(huán)的樹型網(wǎng)絡(luò)，避免報文在環(huán)型網(wǎng)絡(luò)中的增生和無限循環(huán)，同時還提供了數(shù)據(jù)報文轉(zhuǎn)發(fā)的冗余路徑，是目前以太網(wǎng)的通用冗余備份手段。
在RSTP/MSTP的實際應(yīng)用中，當(dāng)網(wǎng)絡(luò)中配置有RSTP/MSTP的交換機(jī)運行RSTP/MSTP后，這些運行有RSTP/MSTP的所有交換機(jī)都將自己作為生成樹的根橋，周期性的向其它交換機(jī)發(fā)送橋協(xié)議數(shù)據(jù)單元(BPDU，BridgeProtocol Data Unit)報文，又稱配置消息。交換機(jī)中接收到配置消息的端口通過對接收的配置消息和本端口的配置消息進(jìn)行比較，以確定該端口的角色，然后轉(zhuǎn)入相應(yīng)的端口角色狀態(tài)。當(dāng)所有交換機(jī)都確定了其端口的角色和狀態(tài)后，就形成了生成樹。
圖1示出了一種網(wǎng)絡(luò)初始化后所形成生成樹中各交換機(jī)端口的角色圖。如圖1所示，該網(wǎng)絡(luò)為6個交換機(jī)組成的環(huán)型拓?fù)?。?jīng)生成樹計算后，形成一棵生成樹。該生成樹的根橋為交換機(jī)1，交換機(jī)2和6為交換機(jī)1的下游橋，交換機(jī)3為交換機(jī)2的下游橋，交換機(jī)4為交換機(jī)3的下游橋，交換機(jī)5為交換機(jī)4的下游橋。下游橋中與上游橋相連的端口角色為根(ROOT)端口，上游橋中與下游橋相連的端口角色為指定(DES，Design)端口，根端口和指定端口在其端口狀態(tài)為轉(zhuǎn)發(fā)(Forwarding)時，可以進(jìn)行數(shù)據(jù)報文的轉(zhuǎn)發(fā)和BPDU報文的接收和發(fā)送。交換機(jī)5與交換機(jī)6相連，但是交換機(jī)5的端口(port)51的端口角色為替換(ALT，Alternate)端口，替換端口的端口狀態(tài)為阻塞(Discarding)，不能轉(zhuǎn)發(fā)數(shù)據(jù)報文，只能接收但不能發(fā)送BPDU報文。可見，交換機(jī)5和6之間的鏈路被阻塞，相當(dāng)于被斷開，因此，經(jīng)RSTP/MSTP計算后，圖1中的物理環(huán)型拓?fù)渥兂闪诉壿嫎湫屯負(fù)洹?br> 在圖1中，PC1與交換機(jī)1相連，PC2與交換機(jī)4相連。PC1與PC2之間的數(shù)據(jù)報文通過交換機(jī)1、2、3、4形成的主鏈路進(jìn)行轉(zhuǎn)發(fā)。在轉(zhuǎn)發(fā)過程中，PC1的媒體接入控制(MAC，Media Access Control)地址0-0-1被學(xué)習(xí)到交換機(jī)4的根端口port41上，交換機(jī)4將port41與PC1的MAC地址0-0-1的對應(yīng)關(guān)系記錄在其MAC表中，PC2的MAC地址0-0-2被學(xué)習(xí)到交換機(jī)1的指定端口port11上，交換機(jī)1將port11與PC2的MAC地址0-0-2的對應(yīng)關(guān)系記錄在其MAC表中。
當(dāng)交換機(jī)2和交換機(jī)3之間的鏈路因物理斷路(Link Down)而發(fā)生故障后，這個Link Down事件被交換機(jī)3檢測到，由于交換機(jī)3的ROOT端口Down，因此交換機(jī)3將自身作為根橋，發(fā)起一輪從交換機(jī)3到交換機(jī)5的快速握手過程，以重新確定各交換機(jī)端口的角色。圖2示出了圖1中的數(shù)據(jù)鏈路發(fā)生故障后，重新確定各交換機(jī)端口角色后的角色圖。如圖2所示，交換機(jī)2和交換機(jī)3相連的一對端口角色為不可用(DISABLE)端口，不可用端口不能處理任何報文。交換機(jī)5中端口port51的新角色為根端口，而且在重新確定角色后除不可用端口之外的所有交換機(jī)端口的狀態(tài)都是轉(zhuǎn)發(fā)狀態(tài)。
此時，由于交換機(jī)1和交換機(jī)4中所保存的MAC表并沒有改變，因此，PC1和PC2之間的數(shù)據(jù)報文無法在正確的路徑上轉(zhuǎn)發(fā)，還需要在交換機(jī)上對MAC地址進(jìn)行更新以恢復(fù)PC1和PC2之間的數(shù)據(jù)流。具體的，交換機(jī)采用發(fā)送TC報文的方法觸發(fā)自身和其它交換機(jī)更新其各自的MAC表以恢復(fù)PC1和PC2之間的數(shù)據(jù)流。其中，TC報文屬于BPDU報文，該TC報文用于通知其它交換機(jī)網(wǎng)絡(luò)拓?fù)涞淖兓?br> 下面以圖2示出的拓?fù)浣Y(jié)構(gòu)為例，對目前發(fā)送TC報文的過程進(jìn)行描述。圖3示出了目前發(fā)送TC報文的方法流程圖，如圖3所示，該方法包括以下步驟步驟301當(dāng)網(wǎng)絡(luò)拓?fù)渲械臄?shù)據(jù)鏈路發(fā)生故障后，經(jīng)重新確定角色后，交換機(jī)5中端口port51的角色由替換端口轉(zhuǎn)換為根端口，且該端口狀態(tài)也轉(zhuǎn)換為轉(zhuǎn)發(fā)狀態(tài)，則交換機(jī)5生成TC報文，刪除其自身保存的MAC表中與交換機(jī)4和交換機(jī)6相連的端口對應(yīng)的MAC地址，并檢查hello-time定時器。
其中，hello-time定時器所設(shè)定的定時時間稱為hello-time時間，是生成樹協(xié)議中發(fā)送BPDU報文的間隔時間，一般hello-time為2秒。因此，交換機(jī)每2秒發(fā)送一次BPDU報文。
步驟302判斷hello-time定時器是否超時；如果是，則執(zhí)行步驟303；否則，繼續(xù)執(zhí)行本步驟302。
步驟303交換機(jī)5向交換機(jī)4和交換機(jī)6發(fā)送其生成的TC報文。
由于TC報文屬于BPDU報文，因此交換機(jī)5執(zhí)行步驟301時生成的TC報文，也需要等待hello-time定時器超時，才能發(fā)送其生成的TC報文。
步驟304接收到TC報文的交換機(jī)生成TC報文，刪除其自身保存的MAC表中要發(fā)送所生成的TC報文的端口對應(yīng)的MAC地址，并檢查hello-time定時器。
步驟305判斷hello-time定時器是否超時；如果是，則執(zhí)行步驟306；否則，繼續(xù)執(zhí)行本步驟305。
步驟306接收到TC報文的交換機(jī)發(fā)送其生成的TC報文。
其它接收到TC報文的交換機(jī)同樣執(zhí)行步驟304～306，直到生成樹中所有交換機(jī)都接收到TC報文并對各自保存的MAC表內(nèi)容進(jìn)行相應(yīng)刪除。經(jīng)各交換機(jī)刷新MAC地址，PC1與PC2之間的數(shù)據(jù)流恢復(fù)。
可見，當(dāng)生成樹中的鏈路發(fā)生故障后，交換機(jī)會重新確定其端口角色，從而使得網(wǎng)絡(luò)拓?fù)浒l(fā)生變化。然而，RSTP/MSTP協(xié)議標(biāo)準(zhǔn)規(guī)定，當(dāng)交換機(jī)檢測到端口角色和狀態(tài)切換到指定角色和狀態(tài)時，或是接收到TC報文時，都會等待hello-time定時器超時后，才將傳遞拓?fù)渥兓畔⒌腡C報文發(fā)送出去，導(dǎo)致TC報文的發(fā)送速度降低。而且生成樹中每個交換機(jī)都要等待hello-time時間，當(dāng)生成樹中交換機(jī)較多時，會導(dǎo)致TC報文在網(wǎng)絡(luò)中的傳播時間較長，數(shù)據(jù)流遲遲不能恢復(fù)，降低了網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗克俣取?br> 另外，如果生成樹中的交換機(jī)在一次網(wǎng)絡(luò)拓?fù)渥兓l(fā)生后，接收到了TC報文，且接收時刻剛好到達(dá)hello-time定時時間，則可以立刻將TC報文發(fā)送出去。而同一交換機(jī)在另一次網(wǎng)絡(luò)拓?fù)渥兓l(fā)生后，接收到了TC報文，但接收時刻還未到達(dá)hello-time定時器超時時刻，甚至需要等待一個完整的hello-time時間，才能將TC報文發(fā)送出去。因此，這兩次網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗繒r間相差很大，導(dǎo)致收斂不穩(wěn)定。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明提供了一種拓?fù)渥兓瘓笪牡奶幚矸椒?，能夠提高網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗克俣?，增加收斂的穩(wěn)定性。
該處理方法包括網(wǎng)絡(luò)交換設(shè)備檢測是否發(fā)生拓?fù)涓淖僒C觸發(fā)事件，如果是，則立刻發(fā)送TC報文。
其中，所述檢測是否發(fā)生TC觸發(fā)事件為網(wǎng)絡(luò)交換設(shè)備檢測其端口是否由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文，如果是，則判定發(fā)生TC觸發(fā)事件；所述發(fā)送TC報文為所述網(wǎng)絡(luò)交換設(shè)備通過所有允許發(fā)送TC報文的端口，向與其相連的其它網(wǎng)絡(luò)交換設(shè)備發(fā)送TC報文。
其中，所述端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文為所述端口的角色由替換端口和備份端口中的任意一種轉(zhuǎn)換為根端口、指定端口和主端口中的任意一種，且端口狀態(tài)轉(zhuǎn)換為轉(zhuǎn)發(fā)狀態(tài)。
其中，所述端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文為所述端口的角色由不可用端口轉(zhuǎn)換為根端口、指定端口或主端口中的任意一種，且端口狀態(tài)轉(zhuǎn)換為轉(zhuǎn)發(fā)狀態(tài)。
其中，所述檢測是否發(fā)生TC觸發(fā)事件為所述網(wǎng)絡(luò)交換設(shè)備檢測是否接收到TC報文，如果是，則判定發(fā)生TC觸發(fā)事件；所述發(fā)送TC報文為所述網(wǎng)絡(luò)交換設(shè)備通過未接收到所述TC報文且允許發(fā)送TC報文的端口，向與其相連的其它網(wǎng)絡(luò)交換設(shè)備發(fā)送TC報文。
當(dāng)所述網(wǎng)絡(luò)交換設(shè)備運行多生成樹協(xié)議MSTP時，所述網(wǎng)絡(luò)交換設(shè)備檢測到發(fā)生TC觸發(fā)事件后，進(jìn)一步包括所述網(wǎng)絡(luò)交換設(shè)備確定所在各生成樹實例中發(fā)生拓?fù)涓淖兊纳蓸鋵嵗凰霭l(fā)送TC報文為所述網(wǎng)絡(luò)交換設(shè)備發(fā)送所述發(fā)生拓?fù)涓淖兊纳蓸鋵嵗腡C報文。
所述在檢測到發(fā)生TC觸發(fā)事件之后進(jìn)一步包括網(wǎng)絡(luò)交換設(shè)備刪除保存的媒體接入控制MAC地址。
本發(fā)明還提供了一種拓?fù)渥兓瘓笪牡奶幚硌b置，能夠提高網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗克俣?，增加收斂的穩(wěn)定性。
該裝置包括檢測模塊和處理模塊，其中，所述檢測模塊，用于檢測TC觸發(fā)事件，在判定檢測到發(fā)生TC觸發(fā)事件后，向處理模塊發(fā)送TC觸發(fā)消息；所述處理模塊，用于接收所述檢測模塊發(fā)送的TC觸發(fā)消息，根據(jù)接收的所述TC觸發(fā)消息，立刻發(fā)送TC報文。
其中，所述檢測模塊，用于檢測端口，在所檢測端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文時，判定檢測到發(fā)生TC觸發(fā)事件，向處理模塊發(fā)送TC觸發(fā)消息，該TC觸發(fā)消息中攜帶端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文的類型信息；所述處理模塊接收到所述TC觸發(fā)消息后，立刻通過所有允許發(fā)送TC報文的端口，向與該處理模塊所在網(wǎng)絡(luò)交換設(shè)備相連的其它網(wǎng)絡(luò)交換設(shè)備發(fā)送TC報文。
其中，所述檢測模塊，用于檢測接收的報文，在所接收的報文為TC報文時，判定檢測到發(fā)生TC觸發(fā)事件，向處理模塊發(fā)送TC觸發(fā)消息，該TC觸發(fā)消息中攜帶接收到TC報文的類型信息；所述處理模塊，接收到所述TC觸發(fā)消息后，立刻通過未接收到所述TC報文且允許發(fā)送TC報文的端口，向與該處理模塊所在網(wǎng)絡(luò)交換設(shè)備相連的其它網(wǎng)絡(luò)交換設(shè)備發(fā)送TC報文。
根據(jù)以上技術(shù)方案可見，應(yīng)用本發(fā)明能夠提高網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗克俣?，增加收斂穩(wěn)定性。具體來說，具有如下有益效果本發(fā)明中，網(wǎng)絡(luò)交換設(shè)備檢測到發(fā)生TC觸發(fā)事件后，立刻發(fā)送TC報文，而不是現(xiàn)有的在等待hello-time定時器超時后，才發(fā)送TC報文。因此，在網(wǎng)絡(luò)拓?fù)浒l(fā)生變化時，網(wǎng)絡(luò)拓?fù)渥兓录軌蛞宰羁斓乃俣葌鞅樵摼W(wǎng)絡(luò)交換設(shè)備所在生成樹，避免了因等待hello-time定時器超時而引起的不良影響，使得變化后的網(wǎng)絡(luò)迅速收斂，從而提高了網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗克俣取?br> 同時，由于不用等待hello-time定時器超時，使得網(wǎng)絡(luò)交換設(shè)備每次都能夠在接收到TC報文后，立刻向其它網(wǎng)絡(luò)交換設(shè)備發(fā)送TC報文，避免了因各次接收TC報文的時刻與hello-time定時器超時時刻之間的時間差相差較多，而造成的網(wǎng)絡(luò)拓?fù)渥兓笫諗繒r間相差很大的缺陷。因此，采用本發(fā)明，每次網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗繒r間相同，從而在提高收斂速度的同時，增加了收斂的穩(wěn)定性。


圖1為一種網(wǎng)絡(luò)初始化后所形成生成樹中各交換機(jī)端口的角色圖。
圖2為圖1中數(shù)據(jù)鏈路發(fā)生故障后，重新確定各交換機(jī)端口角色后的角色圖。
圖3為目前發(fā)送TC報文的方法流程圖。
圖4為本發(fā)明實施例中TC報文處理方法的流程圖。
圖5為本發(fā)明TC報文處理裝置的結(jié)構(gòu)示意圖。
具體實施例方式
下面結(jié)合附圖并舉實施例，對本發(fā)明進(jìn)行詳細(xì)描述。
本發(fā)明為一種TC報文的處理方案，其基本思想為當(dāng)網(wǎng)絡(luò)交換設(shè)備檢測到發(fā)生TC觸發(fā)事件時，立刻發(fā)送TC報文，從而提高了網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗克俣龋黾邮諗糠€(wěn)定性。
這里，TC觸發(fā)事件為表示網(wǎng)絡(luò)拓?fù)浒l(fā)生變化的事件。網(wǎng)絡(luò)拓?fù)涞淖兓w現(xiàn)在網(wǎng)絡(luò)交換設(shè)備端口是否能夠轉(zhuǎn)發(fā)數(shù)據(jù)報文的變化，或者是網(wǎng)絡(luò)交換設(shè)備接收到表示網(wǎng)絡(luò)拓?fù)浒l(fā)生變化的TC報文。
本發(fā)明的技術(shù)方案可以適用于采用發(fā)送TC報文的方式傳遞網(wǎng)絡(luò)拓?fù)渥兓畔⒌木W(wǎng)絡(luò)交換設(shè)備，例如配置并運行RSTP或MSTP的網(wǎng)絡(luò)交換設(shè)備。其中，運行RSTP或MSTP的網(wǎng)絡(luò)交換設(shè)備可以是交換機(jī)或路由器。下面在描述本發(fā)明的技術(shù)方案時均以交換機(jī)為例進(jìn)行描述，且描述中所涉及的交換機(jī)端口都啟動了RSTP或MSTP協(xié)議。
圖4為本發(fā)明實施例中TC報文處理方法的流程圖。如圖4所示，該方法包括以下步驟步驟401交換機(jī)檢測是否發(fā)生TC觸發(fā)事件，如果是，則執(zhí)行步驟402，否則，返回步驟401。
本步驟中，TC觸發(fā)事件的類型主要包括以下兩種TC觸發(fā)事件的第一種類型為交換機(jī)端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文。
交換機(jī)端口是否能轉(zhuǎn)發(fā)數(shù)據(jù)報文與交換機(jī)端口的角色和狀態(tài)相關(guān)。其中，對于端口的角色，包括根端口，指定端口，主(MASTER)端口、替換端口、備份(BACKUP)端口和不可用端口。其中，根端口是負(fù)責(zé)向上游橋轉(zhuǎn)發(fā)數(shù)據(jù)報文的端口；指定端口是負(fù)責(zé)向下游橋交換機(jī)發(fā)送數(shù)據(jù)報文的端口；主端口是連接到總根的端口；替換端口是主端口的備份端口，也是根端口的備份端口；備份(BACKUP)端口是同一臺交換機(jī)的兩個端口相互連接時，被阻塞的端口。端口角色的不同，使得端口對BPDU報文的處理能力也不同，具體地，根端口、指定端口和主端口可以接收和發(fā)送BPDU報文，替換和備份端口可以接收但不能發(fā)送BPDU報文。
對于端口的狀態(tài)，其決定了端口是否能夠轉(zhuǎn)發(fā)數(shù)據(jù)報文，且與端口角色存在聯(lián)系。其中，根端口、指定端口和主端口的狀態(tài)可以為轉(zhuǎn)發(fā)狀態(tài)，處于轉(zhuǎn)發(fā)狀態(tài)的端口可以轉(zhuǎn)發(fā)數(shù)據(jù)報文。替換端口和備份(BACKUP)端口的狀態(tài)為阻塞狀態(tài)，處于阻塞狀態(tài)的端口不是物理的斷路，只是處于阻塞狀態(tài)，不能轉(zhuǎn)發(fā)數(shù)據(jù)報文。不可用端口是物理斷路的端口，不接收和轉(zhuǎn)發(fā)任何報文。
由以上對端口的角色和狀態(tài)的說明可見，交換機(jī)端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文可以具體分為以下兩種情況1)端口角色從替換端口和備份端口中的一種轉(zhuǎn)換為根端口、指定端口和主端口中的任意一種，且端口狀態(tài)轉(zhuǎn)換為轉(zhuǎn)發(fā)狀態(tài)。轉(zhuǎn)換前，替換/備份端口的狀態(tài)為阻塞狀態(tài)，不能轉(zhuǎn)發(fā)數(shù)據(jù)報文，而轉(zhuǎn)換后的端口狀態(tài)為轉(zhuǎn)發(fā)狀態(tài)，可以轉(zhuǎn)發(fā)數(shù)據(jù)報文。
2)端口角色從不可用端口，即物理斷路，轉(zhuǎn)換為根端口、指定端口和主端口中的任意一種，且端口狀態(tài)轉(zhuǎn)換為轉(zhuǎn)發(fā)狀態(tài)。轉(zhuǎn)換前，不可用端口不能接收和轉(zhuǎn)發(fā)任何報文，而轉(zhuǎn)換后的端口狀態(tài)為轉(zhuǎn)發(fā)狀態(tài)，可以轉(zhuǎn)發(fā)數(shù)據(jù)報文。
因此，當(dāng)交換機(jī)檢測到發(fā)生上述兩種情況中的任意一種時，可以確定網(wǎng)絡(luò)拓?fù)浒l(fā)生改變，從而判定為檢測到發(fā)生TC觸發(fā)事件。
這里舉一個具體實例，對上述檢測到第一種類型的TC觸發(fā)事件進(jìn)行說明。由圖1和圖2示出的網(wǎng)絡(luò)拓?fù)渥兓昂妥兓蟮慕粨Q機(jī)端口角色圖可以看出，當(dāng)交換機(jī)2和3之間的鏈路發(fā)生故障后，經(jīng)重新確定各交換機(jī)端口的角色，從而形成新的生成樹。交換機(jī)5中的端口prot51原角色為替換端口，經(jīng)重新確定端口角色后，其新角色為根端口，端口狀態(tài)也由原來的阻塞狀態(tài)轉(zhuǎn)換為轉(zhuǎn)發(fā)狀態(tài)，符合上述第一種類型的TC觸發(fā)事件中，端口角色從替換端口轉(zhuǎn)換為根端口的情況。交換機(jī)5判定檢測到發(fā)生TC觸發(fā)事件。
TC觸發(fā)事件的第二種類型為端口接收到TC報文。
現(xiàn)有的BPDU報文中包括根橋優(yōu)先級、根路徑花費、本橋優(yōu)先級、端口優(yōu)先級等用于進(jìn)行角色選擇的字段，以及1字節(jié)的標(biāo)識(Flag)字段，該標(biāo)識字段中的最低1比特數(shù)據(jù)位為TC標(biāo)志位，將該TC標(biāo)志位設(shè)置為1時，表示該BPDU報文為TC報文。
因此，交換機(jī)檢測是否接收到TC報文的操作為在接收到BPDU報文后，如果判斷該BPDU為TC報文，可以確定網(wǎng)絡(luò)拓?fù)浒l(fā)生改變，從而判定為檢測到發(fā)生TC觸發(fā)事件。
步驟402交換機(jī)判斷檢測出的TC觸發(fā)事件類型，如果該TC觸發(fā)事件的類型為端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文，則執(zhí)行步驟403；如果TC觸發(fā)事件的類型為接收到TC報文，則執(zhí)行步驟404。
本步驟402中，根據(jù)步驟401的檢測結(jié)果判斷TC觸發(fā)事件是端口變化還是接收到TC報文。
步驟403交換機(jī)立刻通過所有允許發(fā)送TC報文的端口，向與其相連的其它交換機(jī)發(fā)送TC報文，并刪除其自身保存的MAC表中，與發(fā)送TC報文的端口對應(yīng)的MAC地址，結(jié)束當(dāng)前流程。
其中，交換機(jī)的端口是否允許發(fā)送TC報文，具體可以根據(jù)MSTP標(biāo)準(zhǔn)-802.1s和RSTP標(biāo)準(zhǔn)-802.1w進(jìn)行判斷，這里就不在贅述。
舉一個具體實例，如圖2示出的交換機(jī)5，經(jīng)過步驟401的檢測，檢測結(jié)果為交換機(jī)5的端口角色由替換端口轉(zhuǎn)換為根端口，且端口狀態(tài)轉(zhuǎn)換為轉(zhuǎn)發(fā)狀態(tài)，則在不等待hello-time定時器超時的情況下，交換機(jī)5立刻向與其相連的交換機(jī)4和6發(fā)送TC報文，同時清空交換機(jī)5保存的MAC表。
步驟404交換機(jī)立刻通過未接收到該TC報文且允許發(fā)送TC報文的端口，向與其相連的其它交換機(jī)發(fā)送TC報文，并刪除其保存的MAC表中，與發(fā)送TC報文的端口對應(yīng)的MAC地址。
這里舉一個具體實例對步驟404進(jìn)行說明。如圖2示出的交換機(jī)6，經(jīng)過步驟401的檢測，檢測結(jié)果為交換機(jī)6的端口port61接收到交換機(jī)5發(fā)來的TC報文，則立刻通過端口port62向交換機(jī)1發(fā)送其生成的TC報文。同時，交換機(jī)6將其保存的MAC表中與port62對應(yīng)的MAC地址刪除。
至此，完成了交換機(jī)對TC報文的處理。
圖2示出的網(wǎng)絡(luò)拓?fù)渲械拿總€交換機(jī)都會執(zhí)行圖4示出的步驟，當(dāng)所有的交換機(jī)均完成了發(fā)送TC報文以及刪除MAC表中相應(yīng)MAC地址的操作后，就恢復(fù)了該網(wǎng)絡(luò)拓?fù)涞臄?shù)據(jù)流量，從而完成了網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗俊?br> 根據(jù)上述流程，采用圖4的處理方法，交換機(jī)能夠在網(wǎng)絡(luò)拓?fù)浒l(fā)生變化時，不用等待hello-time定時器超時，立刻向外發(fā)送TC報文，因此網(wǎng)絡(luò)拓?fù)渥兓录軌蛞宰羁斓乃俣葌鞅樯蓸渖系乃薪粨Q機(jī)，使得變化后的網(wǎng)絡(luò)迅速收斂。同時，由于不用等待hello-time定時器超時，使得每次網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗繒r間相差很小，從而在提高收斂速度的同時，增加了收斂的穩(wěn)定性。
需要說明的是，在上述步驟403和步驟404中，在發(fā)送TC報文時，檢測到TC觸發(fā)事件的交換機(jī)是向與之處于同一生成樹的交換機(jī)發(fā)送TC報文。
具體地，當(dāng)交換機(jī)運行MSTP時，由于同一交換機(jī)可能處于多個不同的實例中，這里所說的實例是指MSTP中的生成樹實例，每一個實例對應(yīng)一棵生成樹。因此，交換機(jī)在檢測到發(fā)生TC觸發(fā)事件后，需要確定其所在各實例中的哪個實例的生成樹發(fā)生拓?fù)涓淖儯缓蟀l(fā)送該發(fā)生拓?fù)涓淖儗嵗腡C報文。例如，交換機(jī)A同時屬于實例1和實例2，那么當(dāng)交換機(jī)A檢測到實例1中發(fā)生TC觸發(fā)事件后，進(jìn)行相應(yīng)處理后，發(fā)送實例1的TC報文。
需要說明的是，在上述實施例中，是以交換機(jī)為例來說明本發(fā)明中如何對TC報文進(jìn)行處理。對于其他的網(wǎng)絡(luò)交換設(shè)備比如路由器，本發(fā)明實現(xiàn)對TC報文進(jìn)行處理的過程與上述實施例的過程相同。
為了實現(xiàn)本發(fā)明TC報文的處理方法，本發(fā)明實施例提供了一種TC報文的處理裝置。圖5為本發(fā)明TC報文處理裝置的結(jié)構(gòu)示意圖，如圖5所示，該TC報文處理裝置500包括檢測模塊510和處理模塊520。
其中，檢測模塊510，用于檢測TC觸發(fā)事件，在判定檢測到發(fā)生TC觸發(fā)事件時，向處理模塊520發(fā)送TC觸發(fā)消息。該TC觸發(fā)消息用于通知處理模塊520檢測到了TC觸發(fā)事件。
處理模塊520，接收檢測模塊510發(fā)送的TC觸發(fā)消息，根據(jù)接收的TC觸發(fā)消息立刻發(fā)送TC報文。
具體來說，圖5所示裝置的第一種具體實現(xiàn)方式為檢測模塊510，用于檢測端口，在所檢測端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文時，判定檢測到發(fā)生TC觸發(fā)事件，向處理模塊520發(fā)送TC觸發(fā)消息。該TC觸發(fā)消息中攜帶有端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文的類型消息，因此該TC觸發(fā)消息不僅通知處理模塊520檢測到了TC觸發(fā)事件，還通知處理模塊520所檢測到的TC觸發(fā)事件的類型。那么，處理模塊520在接收到該TC觸發(fā)消息后，立刻通過所有允許發(fā)送TC報文的端口，向與該處理模塊520所在交換機(jī)相連的其它交換機(jī)發(fā)送TC報文，同時刪除處理模塊520所在交換機(jī)自身保存的MAC表中，與發(fā)送TC報文的端口對應(yīng)的MAC地址。
圖5所示裝置的第二種具體實現(xiàn)方式為檢測模塊510，用于檢測接收的報文，在所接收的報文為TC報文時，判定檢測到發(fā)生TC觸發(fā)事件，向處理模塊520發(fā)送TC觸發(fā)消息。該TC觸發(fā)消息中攜帶接收到TC報文的類型信息，因此可以通知處理模塊520檢測到了TC觸發(fā)事件，且該TC觸發(fā)事件的類型為接收到TC報文。那么，處理模塊520在接收到該TC觸發(fā)消息后，立刻通過未接收到該TC報文且允許發(fā)送TC報文的端口，向與該處理模塊520所在交換機(jī)相連的其它交換機(jī)發(fā)送TC報文，同時刪除處理模塊520所在交換機(jī)自身保存的MAC表中，與發(fā)送TC報文的端口對應(yīng)的MAC地址。
當(dāng)然，上述的兩種具體實現(xiàn)方式可以在本發(fā)明裝置中同時應(yīng)用，即圖5所示裝置中的檢測模塊510和處理模塊520，即可實現(xiàn)本發(fā)明裝置第一種實現(xiàn)方式中的功能，也可以實現(xiàn)本發(fā)明裝置第二種實現(xiàn)方式中的功能。
綜上所述，以上僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護(hù)范圍。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種拓?fù)涓淖儓笪牡奶幚矸椒?，其特征在于，該方法包括網(wǎng)絡(luò)交換設(shè)備檢測是否發(fā)生拓?fù)涓淖僒C觸發(fā)事件，如果是，則立刻發(fā)送TC報文。
2.如權(quán)利要求1所述的方法，其特征在于，所述檢測是否發(fā)生TC觸發(fā)事件為網(wǎng)絡(luò)交換設(shè)備檢測其端口是否由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文，如果是，則判定發(fā)生TC觸發(fā)事件；所述發(fā)送TC報文為所述網(wǎng)絡(luò)交換設(shè)備通過所有允許發(fā)送TC報文的端口，向與其相連的其它網(wǎng)絡(luò)交換設(shè)備發(fā)送TC報文。
3.如權(quán)利要求2所述的方法，其特征在于，所述端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文為所述端口的角色由替換端口和備份端口中的任意一種轉(zhuǎn)換為根端口、指定端口和主端口中的任意一種，且端口狀態(tài)轉(zhuǎn)換為轉(zhuǎn)發(fā)狀態(tài)。
4.如權(quán)利要求2所述的方法，其特征在于，所述端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文為所述端口的角色由不可用端口轉(zhuǎn)換為根端口、指定端口或主端口中的任意一種，且端口狀態(tài)轉(zhuǎn)換為轉(zhuǎn)發(fā)狀態(tài)。
5.如權(quán)利要求1所述的方法，其特征在于，所述檢測是否發(fā)生TC觸發(fā)事件為所述網(wǎng)絡(luò)交換設(shè)備檢測是否接收到TC報文，如果是，則判定發(fā)生TC觸發(fā)事件；所述發(fā)送TC報文為所述網(wǎng)絡(luò)交換設(shè)備通過未接收到所述TC報文且允許發(fā)送TC報文的端口，向與其相連的其它網(wǎng)絡(luò)交換設(shè)備發(fā)送TC報文。
6.如權(quán)利要求1所述的方法，其特征在于，當(dāng)所述網(wǎng)絡(luò)交換設(shè)備運行多生成樹協(xié)議MSTP時，所述網(wǎng)絡(luò)交換設(shè)備檢測到發(fā)生TC觸發(fā)事件后，進(jìn)一步包括所述網(wǎng)絡(luò)交換設(shè)備確定所在各生成樹實例中發(fā)生拓?fù)涓淖兊纳蓸鋵嵗?；所述發(fā)送TC報文為所述網(wǎng)絡(luò)交換設(shè)備發(fā)送所述發(fā)生拓?fù)涓淖兊纳蓸鋵嵗腡C報文。
7.如權(quán)利要求1所述的方法，其特征在于，所述在檢測到發(fā)生TC觸發(fā)事件之后進(jìn)一步包括網(wǎng)絡(luò)交換設(shè)備刪除保存的媒體接入控制MAC地址。
8.一種拓?fù)涓淖儓笪牡奶幚硌b置，其特征在于，該裝置包括檢測模塊和處理模塊，其中，所述檢測模塊，用于檢測TC觸發(fā)事件，在判定檢測到發(fā)生TC觸發(fā)事件后，向處理模塊發(fā)送TC觸發(fā)消息；所述處理模塊，用于接收所述檢測模塊發(fā)送的TC觸發(fā)消息，根據(jù)接收的所述TC觸發(fā)消息，立刻發(fā)送TC報文。
9.如權(quán)利要求8所述的裝置，其特征在于，所述檢測模塊，用于檢測端口，在所檢測端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文時，判定檢測到發(fā)生TC觸發(fā)事件，向處理模塊發(fā)送TC觸發(fā)消息，該TC觸發(fā)消息中攜帶端口由不能轉(zhuǎn)發(fā)數(shù)據(jù)報文轉(zhuǎn)換為可以轉(zhuǎn)發(fā)數(shù)據(jù)報文的類型信息；所述處理模塊接收到所述TC觸發(fā)消息后，立刻通過所有允許發(fā)送TC報文的端口，向與該處理模塊所在網(wǎng)絡(luò)交換設(shè)備相連的其它網(wǎng)絡(luò)交換設(shè)備發(fā)送TC報文。
10.如權(quán)利要求8所述的裝置，其特征在于，所述檢測模塊，用于檢測接收的報文，在所接收的報文為TC報文時，判定檢測到發(fā)生TC觸發(fā)事件，向處理模塊發(fā)送TC觸發(fā)消息，該TC觸發(fā)消息中攜帶接收到TC報文的類型信息；所述處理模塊，接收到所述TC觸發(fā)消息后，立刻通過未接收到所述TC報文且允許發(fā)送TC報文的端口，向與該處理模塊所在網(wǎng)絡(luò)交換設(shè)備相連的其它網(wǎng)絡(luò)交換設(shè)備發(fā)送TC報文。
全文摘要
本發(fā)明公開了一種拓?fù)涓淖儓笪牡奶幚矸椒?，該方法在網(wǎng)絡(luò)交換設(shè)備檢測到拓?fù)涓淖?TC)觸發(fā)事件時立刻發(fā)送TC報文。本發(fā)明還公開了一種拓?fù)涓淖儓笪牡奶幚硌b置，包括檢測模塊和處理模塊。使用本發(fā)明能夠提高網(wǎng)絡(luò)拓?fù)渥兓蟮氖諗克俣?，增加收斂穩(wěn)定性。
文檔編號H04L29/06GK101060485SQ200710097340
公開日2007年10月24日 申請日期2007年5月11日 優(yōu)先權(quán)日2007年5月11日
發(fā)明者趙里遙, 孫凱 申請人:杭州華三通信技術(shù)有限公司