專利名稱：一種基于多鏈接透明互聯網絡的鄰居維護方法和設備的制作方法
技術領域：
本發(fā)明涉及多鏈接透明互聯(TRILL)網絡技術，特別是一種基于TRILL網絡的鄰居維護方法和設備。
背景技術：
TRILL 是因特網工程任務組(IETF，Internet Engineering Task Force)推薦的二層(U)網絡標準。目前，大型數據中心開始利用以太網光纖通道(FCoE，Fibre Channel over Ethernet)等新技術將存儲傳輸的IP傳輸融合到以太網連接上。但傳統的生成樹協議(STP，Spanning Tree Protocol)不適合融合網絡或超大型數據中心的擴展，而TRILL卻非常適合，這就使得TRILL網絡越來越重要。隨著時間的推移，TRILL網絡有代替在L2網絡上被普遍使用的STP協議。下面簡單介紹一下TRILL網絡。在TRILL網絡中，網絡設備被稱為路由橋(RB)，每個RB利用Hello報文與直連的另一 RB設備進行交互。另外，在同一鏈路中，還需要選舉指定路由橋(DRB)，由DRB為每個虛擬局域網(VLAN, Virtual Local Area Network)分配報文轉發(fā)端口(AVF)。這樣，RB將本地網絡中的數據報文通過AVF上送到TRILL網絡時，先進行TRILL封裝，再通過TRILL網絡傳遞到遠端目的的RB。遠端目的的RB再將該數據報文解封裝后通過自身的AVF端口傳送給遠端本地網絡。TRILL網絡中的鄰居維護非常重要，因為鄰居關系的建立可以使RB設備清楚網絡中正確的拓撲結構，并以此為基礎進行DRB選舉、AVF的指定等其它操作。對同一個鏈路而言，現有的TRILL網絡中的鄰居維護方法只能應對單端口的RB設備，對于多端口的RB設備則無法準確識別，容易造成識別錯誤、網絡震蕩等不良影響。

發(fā)明內容
本發(fā)明提供了一種基于多鏈接透明互聯(TRILL)網絡的鄰居維護方法和設備，對同一個鏈路也能準確識別多端口的RB，從而避免識別錯誤、防止網絡震蕩等缺陷。針對第一個發(fā)明目的，本發(fā)明提出的技術方案是一種基于多鏈接透明互聯TRILL網絡的鄰居維護方法，該方法包括為路由橋RB的每一個端口分別建立鄰居列表，所述鄰居列表包括鄰居端口的媒體接入控制MAC地址和端口 ID ；RB從一端口接到Hello報文時利用該Hello報文中的源MAC地址和端口 ID查找本端口的鄰居列表；如果沒找到相應表項，且該HelIo報文不包括本端口的MAC地址和端口 ID，則將所述Hello報文中的源MAC地址和端口 ID記錄在本端口的鄰居列表中，且標記為單向鄰居關系；如果沒找到相應表項，且該Hello報文包括本端口的MAC地址和端口 ID，則將所述Hello報文中的源MAC地址和端口 ID記錄在本端口的鄰居列表中，且標記為雙向鄰居關系；如果找到相應表項，且該HelIo報文包括本端口的MAC地址和端口 ID，則將相應表項中為單向鄰居關系的標記修改為雙向鄰居關系；RB從一端口發(fā)送Hello報文時將本端口鄰居列表中所有鄰居端口的MAC地址和端口 ID，以及本端口的源MAC地址和端口 ID攜帶于該Hello報文中發(fā)送出去。針對第二個發(fā)明目的，本發(fā)明提出的技術方案是一種路由橋RB，該設備包括收發(fā)單元，用于接收和發(fā)送Hello報文；存儲單元，用于分別保存各端口的鄰居列表，所述鄰居列表包括鄰居端口的媒體接入控制MAC地址和端口 ID ；處理單元，用于RB從一端口接到Hello報文時利用該Hello報文中的源MAC地址和端口 ID查找本端口的鄰居列表；如果沒找到相應表項，且該Hello報文不包括本端口的MAC地址和端口 ID，則將所述Hello報文中的源MAC地址和端口 ID記錄在本端口的鄰居列表中，且標記為單向鄰居關系；如果沒找到相應表項，且該Hello報文包括本端口的MAC 地址和端口 ID，則將所述Hello報文中的源MAC地址和端口 ID記錄在本端口的鄰居列表中，且標記為雙向鄰居關系；如果找到相應表項，且該Hello報文包括本端口的MAC地址和端口 ID，則將相應表項中為單向鄰居關系的標記修改為雙向鄰居關系；還用于RB從一端口發(fā)送Hello報文時將本端口鄰居列表中所有鄰居端口的MAC地址和端口 ID，以及本端口的源MAC地址和端口 ID攜帶于該Hello報文中發(fā)送出去。綜上，由于本發(fā)明為RB的每個端口單獨維護鄰居列表，用MAC地址+端口 ID唯一標識端口，并利用MAC地址和端口 ID來表示鄰居端口，使得RB可以準確識別鄰居端口，避免識別錯誤和網絡震蕩等問題。


圖1是本發(fā)明實施例中的組網示意圖。圖2是本發(fā)明實施例中RB接收Hello報文時的流程圖。圖3是本發(fā)明實施例中RB發(fā)送Hello報文時的流程圖。圖4是本發(fā)明實施例中Neighbor TLV格式的示意圖。圖5是本發(fā)明實施例Neighbor TLV中Neighbor RECORDS的格式示意圖。圖6是本發(fā)明實施例中RB的內部結構示意圖。
具體實施例方式圖1是本實施例的一個簡單的多鏈接透明互聯(TRILL)網絡的組網圖，包括若干路由橋(RB)，并用直線表示這些RB之間的連接關系。在圖中，RB可能有多個端口(未畫出)，每個端口利用MAC地址+端口 ID來唯一標識。其中，所述的MAC地址就是該端口所在的RB的MAC地址，而端口 ID就是該端口自身的ID號。本實施例為RB的每一個端口單獨建立鄰居列表，用于記錄該端口的鄰居端口的相關信息，至少包括鄰居端口的MAC地址和端口 ID。實際應用中，鄰居列表還可以包括鄰居端口的其他信息，比如鄰居關系標記、虛擬局域網(VLAN)、指定路由橋(DRB)優(yōu)先級等信息等。組網之后，對于同一個鏈路來說，各個RB按照協議規(guī)定發(fā)送Hello報文，并接收來自其它RB的Hello報文。各RB在發(fā)送和接收Hello報文的過程中獲悉并維護鄰居關系， 從而明確整個網絡的拓撲結構，為后續(xù)選舉DBR、分配報文轉發(fā)端口(AVF)等做好準備。為了更好地描述本實施例方案，下面利用RB接收Hello報文和發(fā)送Hello報文兩部分分別進行說明。圖2是本實施例接收Hello報文的流程圖，如圖2所示，該方法包括步驟201 =RB從一端口接到Hello報文時，利用該Hello報文中的源MAC地址和端口 ID查找本端口的鄰居列表，如果沒找到相應表項，則執(zhí)行步驟202 ；如果找到相應表項， 則執(zhí)行步驟203。這里所指Hello報文中的源MAC地址是發(fā)送該Hello報文的RB的MAC地址，端口 ID是發(fā)送該Hello報文的RB中的某個端口的ID號。這里的源MAC地址和端口 ID可以按照現有協議的規(guī)定攜帶于Hello報文，比如=Hello報文VLAN-Flags-sub-TLV中將攜帶發(fā)送該報文的端口 ID。由于鄰居列表是記錄鄰居端口的，如果沒有從列表中查找到，則表示發(fā)送該Hello 報文的端口是一個新鄰居，將利用以下的步驟202記錄在鄰居列表中。如果從列表中查找到，則利用以下步驟203操作。實際應用中，RB接到Hello報文時，還可以將Hello報文中的源MAC地址和端口 ID與自身的比較，如果相同，則表示該Hello報文是自身之前發(fā)出的Hello報文，無需處理， 丟棄即可。步驟202 如果該Hello報文不包括本端口的MAC地址和端口 ID，則將該Hello報文中的源MAC地址和端口 ID記錄在本端口的鄰居列表中，且標記為單向鄰居關系；如果該 Hello報文包括本端口的MAC地址和端口 ID，則將該Hello報文中的源MAC地址和端口 ID 記錄在本端口的鄰居列表中，且標記為雙向鄰居關系；這里所述的“本端口”就是步驟201中接收Hello報文的端口，其對應的鄰居列表如表一所示
權利要求
1.一種基于多鏈接透明互聯TRILL網絡的鄰居維護方法，其特征在于，該方法包括 為路由橋RB的每一個端口分別建立鄰居列表，所述鄰居列表包括鄰居端口的媒體接入控制MAC地址和端口 ID ；RB從一端口接到Hello報文時利用該Hello報文中的源MAC地址和端口 ID查找本端口的鄰居列表； 如果沒找到相應表項，且該Hello報文不包括本端口的MAC地址和端口 ID，則將所述 Hello報文中的源MAC地址和端口 ID記錄在本端口的鄰居列表中，且標記為單向鄰居關系；如果沒找到相應表項，且該Hello報文包括本端口的MAC地址和端口 ID，則將所述 Hello報文中的源MAC地址和端口 ID記錄在本端口的鄰居列表中，且標記為雙向鄰居關系；如果找到相應表項，且該HelIo報文包括本端口的MAC地址和端口 ID，則將相應表項中為單向鄰居關系的標記修改為雙向鄰居關系； RB從一端口發(fā)送HelIo報文時將本端口鄰居列表中所有鄰居端口的MAC地址和端口 ID，以及本端口的源MAC地址和端口 ID攜帶于該Hello報文中發(fā)送出去。
2.根據權利要求1所述的方法，其特征在于，RB從一端口接到Hello報文時，所述本端口的MAC地址和端口 ID是攜帶于接到的 Hello報文的鄰居類型長度值Neighbor TLV中；RB從一端口發(fā)送HelIo報文時，所述本端口的源MAC地址和端口 ID是攜帶于要發(fā)送的 Hello報文中。
3.根據權利要求1或2所述的方法，其特征在于，所述RB從一端口接到Hello報文時， 該方法進一步包括如果Hello報文中的源MAC地址和端口 ID與本端口的一樣，則丟棄該Hello報文。
4.一種路由橋RB，其特征在于，該設備包括 收發(fā)單元，用于接收和發(fā)送Hello報文；存儲單元，用于分別保存各端口的鄰居列表，所述鄰居列表包括鄰居端口的媒體接入控制MAC地址和端口 ID ；處理單元，用于RB從一端口接到HelIo報文時利用該HelIo報文中的源MAC地址和端口 ID查找本端口的鄰居列表；如果沒找到相應表項，且該Hello報文不包括本端口的MAC 地址和端口 ID，則將所述Hello報文中的源MAC地址和端口 ID記錄在本端口的鄰居列表中，且標記為單向鄰居關系；如果沒找到相應表項，且該Hello報文包括本端口的MAC地址和端口 ID，則將所述Hello報文中的源MAC地址和端口 ID記錄在本端口的鄰居列表中，且標記為雙向鄰居關系；如果找到相應表項，且該Hello報文包括本端口的MAC地址和端口 ID，則將相應表項中為單向鄰居關系的標記修改為雙向鄰居關系；還用于RB從一端口發(fā)送 Hello報文時將本端口鄰居列表中所有鄰居端口的MAC地址和端口 ID，以及本端口的源 MAC地址和端口 ID攜帶于該Hello報文發(fā)送出去。
5.根據權利要求4所述的路由橋，其特征在于，RB接到Hello報文時，所述本端口的MAC地址和端口 ID是攜帶于接到的Hello報文的鄰居類型長度值Neighbor TLV中；RB從一端口發(fā)送Hello報文時，所述本端口的源MAC地址和端口 ID是攜帶于要發(fā)送的 Hello報文中。
6.根據權利要求4或5所述的路由橋，其特征在于，所述處理單元進一步用于RB從一端口接到Hello報文時，如果Hello報文中的源MAC 地址和端口 ID與本端口的一樣，則丟棄該Hello報文。
全文摘要
本發(fā)明提供一種基于多鏈接透明互聯網絡的鄰居維護方法和設備，為路由橋(RB)的每個端口建立鄰居列表，接到Hello報文時查找鄰居列表，如無，則在不含本端口時將其記錄并標為單向鄰居關系，在包含本端口時將其記錄并標為雙向鄰居關系；如有，則將相應表項修改為雙向鄰居關系。發(fā)送Hello報文時，將所有鄰居端口的MAC地址和端口ID攜帶于Hello報文中發(fā)送出去。應用本發(fā)明方案，由于為RB的每個端口維護鄰居列表，利用MAC地址和端口ID來表示鄰居端口，使得RB可以準確識別鄰居端口，避免識別錯誤和網絡震蕩等問題。
文檔編號H04L12/56GK102333000SQ20111033787
公開日2012年1月25日 申請日期2011年10月31日 優(yōu)先權日2011年10月31日
發(fā)明者曲進, 曹輝, 鄒文宇 申請人:杭州華三通信技術有限公司