TWI743860B - 通訊裝置以及網路管理方法 - Google Patents

Abstract

一種通訊裝置經配置以接收一資料流。通訊裝置包括監控端口以及封包處理器。監控端口經配置以接收一資料流的封包。封包處理器耦接於監控端口，其中封包處理器經配置以計算封包的文摘值，以及根據封包的文摘值計算出封包的識別碼，於查找表中查找關聯識別碼之狀態值，以判斷是否已記錄該資料流的丟棄事件。

Description

通訊裝置以及網路管理方法

本案是有關於一種電子裝置及管理方法，且特別是有關於一種通訊裝置及網路管理方法。

乙太交換機(Ethernet switch)在傳遞封包過程，會因為服務品質原則(QoS policy)或是轉發機制的配置，導致封包被丟棄。在此情況下，網管人員需要根據網路拓撲，在每個交換機的管理信息庫(Management Information Base)所記錄的計數器分析以得到封包被丟棄的原因。然而，當管理信息庫被傳輸給中央網路管理層時，由於網路傳輸量龐大，網管人員查看到的問題及其發生時間點不一定即時，並且管理信息庫也可能於網路中被丟失，導致無法追朔封包被丟棄的時間和原因。

網路遙測技術(Network Telemetry)是另一種實現網管的方法。然而，網路遙測技術僅能查看原始封包的內容，沒有封包的經歷路徑和服務品質狀態。若欲得到封包的經歷路徑和服務品質狀態，則需要額外設置硬體以將需要的資料放入原始封包。然而，這樣的方法花費額外的硬體成本及網路頻寬，並且在原始封包嵌入資料的檔頭格式並沒有統一標準。

據此，如何得到封包被丟棄時的時間和原因以及具體的封包內容，是本領域技術人員所欲解決的技術問題。

發明內容旨在提供本揭示內容的簡化摘要，以使閱讀者對本案內容具備基本的理解。此發明內容並非本揭示內容的完整概述，且其用意並非在指出本案實施例的重要/關鍵元件或界定本案的範圍。

根據本案之一實施例，揭示一種通訊裝置，經配置以接收一資料流，該通訊裝置包括一監控端口以及一封包處理器。監控端口經配置以接收該資料流的封包。封包處理器耦接於該監控端口，其中該封包處理器經配置以計算該封包的一文摘值，以及該封包處理器根據該封包的該文摘值計算出該封包的一識別碼，於一查找表中查找關聯該識別碼之一狀態值，以判斷是否已記錄關聯該資料流的該丟棄事件。

根據另一實施例，揭示一種網路管理方法，經配置以分析一資料流，該網路管理方法包括以下步驟：接收該資料流的一封包；計算該封包的一文摘值；以及根據該封包的該文摘值計算出該封包的一識別碼，於一查找表中查找關聯該識別碼之一狀態值，以判斷是否已記錄關聯該資料流的丟棄事件。

以下揭示內容提供許多不同實施例，以便實施本案之不同特徵。下文描述元件及排列之實施例以簡化本案。當然，該些實施例僅為示例性且並不欲為限制性。舉例而言，本案中使用「第一」、「第二」等用語描述元件，僅是用以區別以相同或相似的元件或操作，該用語並非用以限定本案的技術元件，亦非用以限定操作的次序或順位。另外，本案可在各實施例中重複元件符號及/或字母，並且相同的技術用語可使用相同及/或相應的元件符號於各實施例。此重複係出於簡明性及清晰之目的，且本身並不指示所論述之各實施例及/或配置之間的關係。

第1圖繪示根據本案一些實施例中通訊裝置的配置示意圖。通訊裝置PE1中儲存目的端口轉發表TB。如第1圖所示，客戶端c1欲傳送資料流DF至客戶端c2。於正常情況下，通訊裝置PE1應該透過端口P1將資料流轉送至客戶端c2。轉發路經應為通訊裝置CE1、PE1、PE3、PE4、CE2。然而，通訊裝置PE1可能設定錯誤或其他原因而將資料流的封包丟棄，例如輸出端口的虛擬區域網路過濾器(Egress VLAN filter)的設定錯誤，使得封包被誤判為不符合通過端口P1而被丟棄。

為了監控這些封包被丟棄的原因，通訊裝置PE1上可開啟事件監控程序。

於一些實施例中，如第1圖所示，通訊裝置PE1被設置一監控端口P2。例如，當封包被輸出端口的虛擬區域網路過濾器所丟棄時，封包會被重新導向至監控端口P2。此時，封包的檔頭被擴增修改後，會被傳送至監控中心M1，使得網路管理者可統籌這些被丟棄的封包資訊，以進行丟棄封包事件的監控。

於另一些實施例中，通訊裝置PE1可設定一監控端口(如第1圖中目的端口轉發表TB的CPU port)，於封包被判定為應該被丟棄時，用以接收被丟棄封包，以進行後續的診斷(diagnostic)。

請參照第2圖，其繪示根據本案一些實施例中一種通訊裝置200的方塊示意圖。如第2圖所示，通訊裝置200包含封包處理器210、資料端口220、監控端口230以及記憶體240。封包處理器210耦接於資料端口220、監控端口230以及記憶體240。資料端口220經配置以執行一般的資料封包接收/轉送。通訊裝置200可以有多個資料端口220，為簡潔說明書內容，於此以一個資料端口220作為範例。舉例而言，通訊裝置200透過資料端口220接收一資料流的封包。若通訊裝置200判斷此封包應該被丟棄，則會被重新導向至監控端口230。監控端口230可以是第1圖的監控端口P2或是監控端口CPU port。

為進一步說明本案的通訊裝置200，請一併參照第3圖。第3圖繪示根據本案一些實施例中一種網路管理方法的流程示意圖。

於步驟S305，透過資料端口220接收一資料流之封包。於一些實施例中，同一個資料流的封包，具有相同的特徵。因此，通訊裝置200可藉由封包的特徵來取得封包所屬的資料流。

於步驟S310，判斷該封包是否符合一丟棄事件。丟棄事件可以為但不限於封包攜帶不匹配或錯誤的資訊導致無法找到正確的目的端口、非法或疑似入侵封包、因為通訊裝置200的記憶容量不足而導致封包無法被執行儲存轉發(store and forward)、查找表未命中(lookup table miss)等事件，而導致封包被判定應被丟棄。

於一些實施例中，若封包被判斷不符合一丟棄事件，則於步驟S355，執行後續的資料轉發，此封包將被傳送至目的地位置。

於當封包被判斷符合丟棄事件，則於步驟S315，封包會被重新導向至監控端口230。於一些實施例中，封包會透過監控端口230被儲存於記憶體240。記憶體240包含複數個佇列，各佇列具有不同的優先權。根據封包的性質及其優先程度，當封包被封包重新導向後，此些封包會被分配到不同優先權的佇列。封包處理器210會依據優先權來讀取佇列中的封包，以執行後續的診斷程序(例如高優先權的佇列中的封包會被優先診斷)。

於一些情況下，若突發的大量監控封包被重新導向至監控端口230，即相同類型的資料流的多個封包被儲存於記憶體240，將使得通訊裝置200需要大量處理相同類型的封包診斷，這會造成浪費運算資源的問題。為避免此問題，於一些實施例中，通訊裝置200會執行抑制過濾(suppression filter)程序。於抑制過濾程序中，僅同一個資料流中被通訊裝置200收到的第一個封包會被重新導向至監控端口230。若同一個資料流已有封包被完成診斷，則後續若此資料流的封包發生丟棄事件，此封包也不會被重新導向至監控端口230。如此，封包處理器210僅需要處理同一個資料流的一個封包即可，而不需要浪費時間及儲存空間在相同資料流的丟棄事件上。抑制過濾流程說明如下。

首先，通訊裝置200對資料流進行分類。於步驟S320，透過封包處理器210使用封包的特徵值及丟棄事件來計算封包的文摘值(digest value)。封包的特徵值可以為但不限於封包中記錄的目的媒體存取控制位址、來源媒體存取控制位址、目的網際網路協定位址、來源網際網路協定位址、乙太網路類型、虛擬區域網路識別符、第四層目的埠、第四層來源埠、穿隧標頭、封包流識別符。

於一些實施例中，文摘值是根據雜湊演算法、封包的特徵值及丟棄事件被計算得到。舉例而言，封包內容為長度32位元的二進位數值。第4A-4D圖繪示根據本案一些實施例中的雜湊演算法之示意圖。

於一些實施例中，如第4A圖所示，雜湊演算法可以為對原始封包400進行反轉，將原始封包400的最高有效位元(most significant bit)反轉為最低有效位元(least significant bit)，以得到封包401。接著，對原始封包400及封包401進行互斥或運算，運算結果為封包400的第一文摘值。

於一些實施例中，如第4B圖所示，雜湊演算法可以為反轉原始封包400，而得到兩個經過反轉的封包403及封包404。接著，對封包403及封包404進行互斥或運算，運算結果為封包400的第二文摘值。

於一些實施例中，如第4C圖所示，雜湊演算法可以為將原始封包400分割為兩段並對調此兩段的次序後，得到封包405。接著，對封包405與原始封包400進行互斥或運算，運算結果為封包400的第三文摘值。

於一些實施例中，如第4D圖所示，雜湊演算法可以為取兩個封包405進行互斥或運算，運算結果為封包400的第四文摘值。值得一提的是，第4A圖至第4D圖為實施例說明，本案不限制此些雜湊演算法。

於步驟S325，根據封包的文摘值來計算出封包的識別碼。舉例而言，文摘值的長度為32位元。通訊裝置200可分配2 ³²的大小之查找表來記錄此文摘值是否已被記錄過。然而，為節省記憶體空間，本案於步驟S325中，會壓縮文摘值的長度，以縮小查找表的大小。查找表是用於記錄關聯於文摘值之狀態值。

於一些實施例中，識別碼的長度小於文摘值的長度。舉例而言，文摘值的長度，例如32位元，被壓縮為例如14位元，被壓縮長度的文摘值稱為識別碼。舉例而言，32位元長度的文摘值被分割成三段長度為14位元的資料(其中最後一段僅4位元有資料，其餘欄位補零)。透過對此三段資料例如互斥或運算而得到長度14位元的識別碼。此識別碼對應至查找表的位址(例如位址0至位址2 ¹⁴-1)。查找表的位址所指向的內容為狀態值，代表文摘值對應的封包是否已經被接收過(詳述於後)。因此，只需要配置2 ¹⁴的大小的查找表即可記錄長度為32位元的文摘值之狀態值。於另一些實施例中，識別碼的長度亦可以等於文摘值的長度，本案不限制文摘值被壓縮之後的長度。

於步驟S330，於一查找表中查找關聯於識別碼的狀態值。於一些實施例中，由於使用雜湊演算法來計算雜湊值，存在一些機率可能會使得資料流雖不同但卻會計算得到相同的文摘值(雜湊值)，而發生碰撞(collision)。因此，本案計算同一個封包的多個雜湊值，以避免碰撞問題。本案的實施例中以四個雜湊演算法及四個查找表來分別記錄對應於各資料流的文摘值之狀態值。惟，本案不限制查找表的個數，使用兩個以上的查找表來記錄狀態值均屬本案的範疇。

請參照第5A-5C圖，其繪示根據本案一些實施例中的查找表之示意圖。文摘值被壓縮後產生的識別碼，其分別透過第一雜湊演算法501、第二雜湊演算法502、第三雜湊演算法503及第四雜湊演算法504被計算，而產生第一雜湊值、第二雜湊值、第三雜湊值及第四雜湊值。另一方面，第一查找表511對應於第一雜湊演算法501，用以於第一雜湊值之位址所指向的內容記錄第一狀態值。相似地，第二查找表512對應於第二雜湊演算法502，用以於第二雜湊值之位址所指向的內容記錄第二狀態值。第三查找表513對應於第三雜湊演算法503，用以於第三雜湊值之位址所指向的內容記錄第三狀態值。第四查找表514對應於第四雜湊演算法504，用以於第四雜湊值之位址所指向的內容記錄第四狀態值。封包處理器210可根據此四個狀態值來判斷是否有接收過此資料流。舉例而言，狀態值為0，代表通訊裝置200沒有處理過此資料流的丟棄事件。狀態值為1，則代表此資料流的丟棄事件有被處理過。

於步驟S335，判斷狀態值是否等於一操作值。於一些實施例中，狀態值用來判斷資料流的封包是否被分析過。值得一提的是，狀態值可以是一或多個位元，本案不限制狀態值的位元數，可依實際的狀態數量來設計相應的位元數，例如狀態值可以是2個位元的數值，以用來表示四種不同的狀態。於此實施例中，狀態值是1個位元。當狀態值是1時，代表通訊裝置200已分析過此資料流的封包，反之，當狀態值是0時，代表通訊裝置200尚未分析此資料流的封包。為簡化本案說明書的說明，以操作值為1之實施例來說明封包是否被分析過，通常知識者可依據實際應用來設計不同情況的狀態及其數值。

如第5A圖所示，此四個位址所指向的內容，即狀態值，分別為0、0、0、0。換言之，通訊裝置200沒有分析過此資料流的封包。因此，於步驟S340，於監控事件中記錄該封包的內容。舉例而言，封包會被進行診斷，診斷結果被記錄於監控事件，以供網路管理人員參考。於一些實施例中，封包的內容包含封包被接收時的時間戳、關聯於封包的丟棄事件、封包的輸入端口及輸出端口。

於步驟S345，狀態值被修改為操作值(例如，1)。如第5B圖所示，第一查找表至第四查找表中該識別碼對應的狀態值均被修改為1，代表此資料流發生過丟棄封包的情況已被記錄過。

於一些實施例中，執行步驟S305~步驟S330，監控端口230接收到一資料流的封包，並且，此封包對應的狀態值被對應地計算。於步驟S335中，若判斷第一查找表至第四查找表中狀態值均為1，如第5B圖所示，代表此資料流發生過丟棄封包的情況已被記錄過，則丟棄此封包。此封包將不會被執行診斷流程(例如被轉發至監控中心或被記錄於監控事件)。

值得一提的是，若於步驟S335中判斷只有部分的查找表的狀態值為1(例如第一查找表的狀態值為1，其第二至第四查找表的狀態值為0)，如第5C圖所示，則代表有碰撞發生，通訊裝置200仍會處理資料流的丟棄事件。舉例而言，第一個資料流的第一封包於第一雜湊演算法計算出雜湊值3173，並且位址3173的內容已在先前的丟棄事件中被修改為1。然而，第二個資料流的第二封包於第一雜湊演算法也計算出雜湊值3173。由第二個資料流的第二雜湊演算法至第四雜湊演算法計算出的雜湊值對應的狀態值均為0的情況來看，第一封包與第二封包的雜湊值發生碰撞。實際上，通訊裝置200沒有處理過第二資料流。此時，通訊裝置200仍會處理第二資料流的丟棄事件。如此一來，多個雜湊演算法可以減少誤判資料流是否被處理過的機率。

於一些實施例中，通訊裝置200對資料流的文摘值設定一時效值(aging)。舉例而言，若資料流的文摘值的時效值超過一門檻值(例如時效值遞增計數至門檻值255)或者低於一門檻值(例如時效值遞減計數至門檻值0)，則清除查找表中的狀態值。如此，記憶體空間可被空出來記錄新的資料流的狀態值。舉另一例而言，通訊裝置200會週期地清除查找表中的所有狀態值(例如每天)。如此，查找表可隨著資料流的週期性來記錄狀態值，提升使用效能。

綜上所述，本案的通訊裝置及網路管理方法不需要設置額外的硬體成本來對封包嵌入需要的管理資訊(降低晶片成本)，網路管理人員只需要在通訊裝置上修改設定，將封包轉發至處理器或特定端口，即可監控被丟棄的封包。此外，在封包發生丟棄事件的當下，通訊裝置在記錄管理信息庫和統計計數器的同時，也會儲存這些發生問題的封包、原因及時間戳，並且只需要記錄一次(降低處理器的負擔)，以產生分析報告供網管人員進一步查測，以減少除錯流程的時間。

上述內容概述若干實施例之特徵，使得熟習此項技術者可更好地理解本案之態樣。熟習此項技術者應瞭解，在不脫離本案的精神和範圍的情況下，可輕易使用上述內容作為設計或修改為其他變化的基礎，以便實施本文所介紹之實施例的相同目的及/或實現相同優勢。上述內容應當被理解為本案的舉例，其保護範圍應以申請專利範圍為準。

c1、c2:客戶端 DF:資料流 CE1、CE2:通訊裝置 PE1、PE2、PE3、PE4:通訊裝置 M1:監控中心 TB:目的端口轉發表 P0、P1、P2、CPU port:埠 200:通訊裝置 210:封包處理器 220:資料端口 230:監控端口 240:記憶體 400:原始封包 401~405:封包 501~504:雜湊演算法 511~514:查找表 S305~S355:步驟

以下詳細描述結合隨附圖式閱讀時，將有利於較佳地理解本揭示文件之態樣。應注意，根據說明上實務的需求，圖式中各特徵並不一定按比例繪製。實際上，出於論述清晰之目的，可能任意增加或減小各特徵之尺寸。 第1圖繪示根據本案一些實施例中通訊裝置的配置示意圖。 第2圖繪示根據本案一些實施例中一種通訊裝置的方塊示意圖。 第3圖繪示根據本案一些實施例中一種網路管理方法的流程示意圖。 第4A-4D圖繪示根據本案一些實施例中的雜湊演算法之示意圖。 第5A-5C圖繪示根據本案一些實施例中的查找表之示意圖。

國內寄存資訊(請依寄存機構、日期、號碼順序註記) 無 國外寄存資訊(請依寄存國家、機構、日期、號碼順序註記) 無

200:通訊裝置

210:封包處理器

220:資料端口

230:監控端口

240:記憶體

Claims (10)

1. 一種通訊裝置，經配置以接收一資料流，該通訊裝置包括： 一監控端口，經配置以接收該資料流的一封包；以及 一封包處理器，耦接於該監控端口，其中該封包處理器經配置以計算該封包的一文摘值，以及該封包處理器根據該封包的該文摘值計算出該封包的一識別碼，於一查找表中查找關聯該識別碼之一狀態值，以判斷是否已記錄關聯該資料流的一丟棄事件。
2. 如請求項1所述之通訊裝置，其中該監控端口還經配置以接收符合該丟棄事件之該封包，該封包處理器還經配置以接收自該監控端口之該封包，且於丟棄該封包之前，使用該封包的一特徵值及該丟棄事件，計算該封包的該文摘值。
3. 如請求項2所述之通訊裝置，其中該封包處理器還經配置以壓縮具有一第一長度的該文摘值為具有一第二長度的該識別碼，其中該第二長度小於或等於該第一長度。
4. 如請求項2所述之通訊裝置，其中該封包處理器還經配置以使用一第一雜湊演算法根據該封包的該特徵值及該丟棄事件，計算該封包的一第一文摘值，以及該封包處理器使用一第二雜湊演算法根據該封包的該特徵值及該丟棄事件，計算該封包的一第二文摘值。
5. 如請求項4所述之通訊裝置，其中該封包處理器還經配置以壓縮該第一文摘值為一第一識別碼以及壓縮該第二文摘值為一第二識別碼。
6. 如請求項5所述之通訊裝置，還包含： 一記憶體，耦接於該封包處理器，其中該記憶體經配置以儲存複數個查找表，其中該些查找表包含一第一查找表以及一第二查找表，該第一查找表對應於該第一雜湊演算法以及該第二查找表對應於該第二雜湊演算法。
7. 如請求項6所述之通訊裝置，其中該記憶體還包含複數個佇列，各該佇列經配置以暫存符合該丟棄事件之該資料流的該封包，使該封包處理器根據各該佇列的一優先權讀取各該佇列的該封包。
8. 如請求項6所述之通訊裝置，其中該封包處理器還經配置以於該第一查找表中查詢關聯該第一識別碼的一第一狀態值，以判斷該第一狀態值是否為一操作值，以及於該第二查找表中查詢關聯於該第二識別碼的一第二狀態值，以判斷該第二狀態值是否為該操作值。
9. 如請求項8所述之通訊裝置，其中該封包處理器還經配置以於判定該第一狀態值不是該操作值及/或者該第二狀態值不是該操作值時，則於一監控事件中記錄該封包的內容，並修改該第一查找表的該第一狀態值為該操作值及修改該第二查找表的該第二狀態值為該操作值。
10. 一種網路管理方法，經配置以分析一資料流，該網路管理方法包括： 接收該資料流的一封包； 計算該封包的一文摘值；以及 根據該封包的該文摘值計算出該封包的一識別碼，於一查找表中查找關聯該識別碼之一狀態值，以判斷是否已記錄關聯該資料流的一丟棄事件。

Images