專利名稱：利用周期重復序列壓縮通過udp傳輸snmp消息的方法和裝置的制作方法
技術領域：
本發(fā)明涉及使用UDP(用戶數(shù)據(jù)報協(xié)議的簡稱)傳輸消息的方法，例如傳輸 SNMP (簡單網(wǎng)絡管理協(xié)議)消息。這些消息是在數(shù)據(jù)通信網(wǎng)絡，例如互聯(lián)網(wǎng)中產(chǎn)生并傳輸?shù)?。互?lián)網(wǎng)協(xié)議的結構基 于四個邏輯層，即應用層、傳輸層、網(wǎng)絡層和連接層。SNMP消息在網(wǎng)絡管理系統(tǒng)(匪S)和被管理的節(jié)點之間執(zhí)行一種簡單的通信機制。 這使得分別位于稱作“網(wǎng)絡管理器”的匪S上的以及位于稱作“代理”的節(jié)點上的特定應用 成為可能。因此SNMP消息能在UDP級上發(fā)生，并為該目的使用UDP來傳輸。
背景技術：
對SNMP消息具有獨立的網(wǎng)絡管理器的稱作“代理”的應用(以下均為代理)和 當前稱作“管理信息庫”或簡稱為MIB的數(shù)據(jù)庫相結合。在這個數(shù)據(jù)庫中，根據(jù)相應節(jié)點或 網(wǎng)絡單元的管理和監(jiān)控，進行相應的信息收集。這種信息特別包括下列部分一MIB變量，可由網(wǎng)絡管理器讀取，并獲得關于網(wǎng)絡單元的信息；一可由網(wǎng)絡管理器寫入的MIB變量，能引起網(wǎng)絡單元上的動作；以及一同一代理根據(jù)特定的情況對網(wǎng)絡管理器(管理器)引起的事件(陷阱)。因此SNMP級上的通信主要包括一請求讀 / 寫上述變量的消息(GetRequest，GetNextRequest, SetRequest, GetBulk)，由網(wǎng)絡管理器發(fā)送出去，以及一響應消息(GetResponse)和陷阱消息，由代理發(fā)送。一個代理管理的所有變量/陷阱的集合與網(wǎng)絡單元有關，并明確地表示了相應的 MIB，即它們能向網(wǎng)絡管理器展示網(wǎng)絡單元的操作模式和固有特性。每個變量或陷阱分別由ASN. 1表示法(第一抽象語法表示法)中的一個字符串進 行標識，稱作對象標識符或0ID。該字符串的框架結構表明ASN. 1表示法根據(jù)等級樹結構允許對對象進行描述，例 如 “1. 3. 6. 1. 2. 1. 4. 21” 類型。MIB的一部分定義為一個標準，支持任何代理，但是其他變量和一些陷阱對每個制 造商都是特定的，在一些情況下還成為特定裝置類型的獨有特征。1988年誕生的SNMP協(xié)議這些年來經(jīng)過了幾次發(fā)展。特別是定義了代理必須能夠 理解的新的消息類型。每個代理必須支持的MIB標準也被擴充了。在本發(fā)明的申請日，使 用的版本是第一版和第二版，而第三版標準正在進行中。MIB的大小根據(jù)裝置類型而不同，對于相應的幾百個0ID，甚至可達到幾百K字節(jié)
3大小。附圖的圖1中的示意圖顯示了一個SNMP消息的典型組成部分。每個組成部分的 內(nèi)容是用ASCII字符寫成，且它的最大允許尺寸和UDP消息的最大尺寸是相等的，數(shù)據(jù)體傳 送消息的組成部分，等于65，507字節(jié)或八位位組(需傳送的信息被設計為大約64K字節(jié))。在圖1中的同一個示意圖中，特別要注意到存在一個消息頭和一個PDU(協(xié)議數(shù)據(jù) 單元)部分，其中數(shù)字1表示的部分收集如GetRequest，GetNextRequest，SetRequest以及 GetResponse等消息，數(shù)字2表示的部分收集GetBulk消息，而數(shù)字3表示的部分一般涉及 到陷阱類型消息。更特別的是，在SNMP消息頭中有下列信息一版本號用于消息合成的SNMP版本號(VI，V2, V3，...)以及一共用名稱一種密碼，能允許對MIB模塊中包含的對象通過讀和寫進行訪問。下列信息是PDU內(nèi)可用的—PDU類型消息類型，在版本1中包括的指令例如為GetRequest， GetNextRequest, SetRequest以及Request，而在版本2還可包含的指令例如為 GetBulkRequest 禾口 InformRequest ；一請求標識符管理器分配的消息的個人標識符，并在應答時被代理使用，目的在 于管理器能夠把請求的響應和適當?shù)膮⒖蓟鶞式Y合起來；一錯誤狀態(tài)除了響應消息之外所有的消息類型都設成0，其中如果設成1，意味
著存在錯誤；—錯誤索引它能夠指示出被請求的變量(0ID)中發(fā)生錯誤的變量，以及一變量結這些變量結是0ID/數(shù)值對；在請求的情況下數(shù)值為“空”，在消息響應 的情況下進行編譯。圖1中左邊部分特別顯示了收集上述變量結部分的典型結構。本發(fā)明中以及一些附圖的標題中，對于需考慮的不同元件，可根據(jù)英語中提及的 相應的首字母縮寫/名稱/首字母來進行選擇。這樣做的目的是為了得到清晰和直觀的描述。上述首字母縮寫詞、名稱和首字母 現(xiàn)在被本領域技術人員在國際間運用，因為這些年來沒有開發(fā)翻譯成不同國家的語言。通過UDP可能實現(xiàn)的SNMP消息的傳送，允許在連接到網(wǎng)絡上的兩臺計算機之間進 行數(shù)據(jù)包的交換。UDP消息格式即包含了一個消息頭，它的主要數(shù)據(jù)是發(fā)送消息的計算機的 IP地址、目標計算機的IP地址以及被傳送的PDU的大小。接下來，PDU格式由一個頭部分 和一個數(shù)據(jù)部分構成，現(xiàn)在稱為“有效載荷”或“八位數(shù)據(jù)”。因此消息頭包含下列數(shù)據(jù)源 端口、目標端口、傳送單元的大小、數(shù)據(jù)單元的完整性檢驗(CHECKSUM)?，F(xiàn)在通過UDP (從管理器至代理，以及相反路徑)傳送SNMP消息采用的方法實質(zhì) 上是基于整個SNMP消息是使用BER(基本編碼規(guī)則)方法進行編碼的事實。這種操作方法 能夠把構成SNMP消息的字節(jié)轉(zhuǎn)換成UDP消息的有效載荷適用的十六進制結構。這樣獲得的數(shù)據(jù)UDP傳送服務基本上設想為一在發(fā)送階段為了通過UDP發(fā)送消息，先讀取SNMP消息，隨后對該消息進行十六 進制編碼(BER編碼)，以及一在接收階段通過UDP接收消息之后，對PDU進行十六進制解碼(BER解碼)，隨
4后對消息進行重建。目前的應用實踐證明了在數(shù)據(jù)通信網(wǎng)絡如互聯(lián)網(wǎng)中產(chǎn)生了這樣的需求即要以 SNMP消息的格式傳送大量的請求/響應信息。由于信息的總體大小決定了相應的傳輸和網(wǎng)絡業(yè)務量所需的時間，以標準格式傳 輸SNMP消息的常規(guī)解決方案一般效率相當?shù)汀Ｒ驗檫@個原因已經(jīng)提出了三個IEFT標準(處在草案階段)來解決該難點。第一個建議(稱為SNMP對象標識符壓縮，2001年4月修訂版，draft-ietf-eos-oidcompression-00. txt)基于的概念是MIB中包含的大部分信息通過0ID來索引，相當大 部分是常數(shù)格式，而很小部分是變量格式。根據(jù)這個原則出發(fā)，該建議的目標是根據(jù)一種算 法通過一個較短的編號方式對0ID的常數(shù)部分進行編碼。這種方案只能部分地優(yōu)化需傳送 的信息量，而沒有大量減少信息的大小。第二個建議(稱為“大量SNMP數(shù)據(jù)的有效傳輸，2001年4月修訂版， draft-ietf-eos-snmpbulk-00. txt”)面對的問題是GetBulk指令管理可允許對給定信息 集的同步收集。SNMP版本2中引入的指令不能優(yōu)化信息收集，因為管理器必須聲明所需收 集的單元數(shù)量，而不知道被請求的信息集由多少單元構成。UDP協(xié)議的修正曾建議改進消 息的編碼算法(從BER改為PER，它支持分組編碼規(guī)則)或采取FTP (文件傳輸協(xié)議的首字 母縮寫)類型的傳送模式。上面引用的文件中描述的方案在代理端引入了新的指令，叫做 GetColsRequest，還在管理器端引入了相關消息，能夠識別需傳送的單元的數(shù)量，能識別出 被請求的信息集的結束，從而優(yōu)化了請求和網(wǎng)絡業(yè)務量。但是，這個方案也不能優(yōu)化對需發(fā) 送的消息的大小和數(shù)量的管理。第三個考慮的方案(稱為“SNMP有效荷載壓縮，2001年4月修訂版，draft-irtf -nmrg-snmp-compression-01. txt”)在原理上和第一個建議相似，因為它提出了一種差分 編碼算法，叫做“0ID Delta Compression”或簡稱為0DC。這種方案從一個0ID根出發(fā)，設 想能夠存儲隨后的0ID，并把和0ID根相關的代碼分配給該0ID，隨后是0ID的變化的部分。 實質(zhì)上，這些變化以與根單元相比較的差分增量形式被存儲起來。該方案的缺點是和以前 的協(xié)議版本不兼容。另外，它特別對求遞歸0ID值(即數(shù)據(jù)陣列)時估計能夠節(jié)省30%，而 它在遞歸項數(shù)目很少的情況下效率是很低的。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種和以前實行的解決方案相比的另一種可選擇的替代方 案，且能夠通過UDP對如SNMP的消息進行優(yōu)化傳輸，而不會影響協(xié)議以及代理端和管理器 端的執(zhí)行性能。根據(jù)本發(fā)明，實現(xiàn)這個目的的方法具有權利要求中特定的技術特征。本發(fā)明還以 獨立的方式，涉及到相關系統(tǒng)和數(shù)據(jù)處理產(chǎn)品，當上述數(shù)據(jù)處理產(chǎn)品在計算機上運行時，能 夠直接載入到計算機的內(nèi)部存儲器中，并包括執(zhí)行本發(fā)明所述方法的軟件代碼部分。本質(zhì)上，本發(fā)明的方案是基于整個消息(消息頭和PDU)的壓縮。特別能夠預見兩種不同的傳送模式。第一個模式把SNMP消息封裝成一種新的特 有類型的SNMP消息，并使用UDP以一種標準模式發(fā)送該消息。第二個模式直接通過驅(qū)動器來驅(qū)動UDP，得到的結果是把SNMP消息壓縮為八位數(shù)據(jù)。所述壓縮技術實質(zhì)上基于對消息中周期性出現(xiàn)的序列進行識別。特別地，在本發(fā)明的優(yōu)選實施例中，使用的壓縮技術是已知的LZ77技術的 ^ ( JAL Ziv. J. , Lempel A.白勺胃 # “A Universal Algorithm forSequential Data Compression，，，IEEE Transactions on InformationTheory, Vol. 23, No. 3, PP. 337-343), 在UNIX環(huán)境中是很有名的，叫做gzip(gzip格式一RFC 1952)，也被更流行的PKZIP所使 用。這種技術規(guī)范是眾所周知的，同時還可使用源庫，用于不同的開發(fā)環(huán)境和操作系統(tǒng)來執(zhí) 行和使用這個方案，如 HP-UX，Digital, Beos, Linux, OS/2, Java, Win32, WinCE。特別在Win32上可通過使用“zLib”庫來使用該算法的接口。作為參考，可以參見 站點httD://www. info-zip. org/pub/infozip/zlib/0這個庫的主要特征是可以對二進制 數(shù)據(jù)結構和字符串進行實時和聯(lián)機存儲器壓縮，這成為和系統(tǒng)性能相關的一個重要因素。


現(xiàn)在通過一個不受限的實例，參照附圖對本發(fā)明進行描述，其中一圖1和背景技術有關，前面已作了描述；一圖2是根據(jù)本發(fā)明的方案的一個典型應用結構的一般結構框圖的形式；一圖3至圖5，每個圖再分成兩部分，分別是發(fā)送(a部分)和接收(b部分)，以流 程圖的形式闡釋了本發(fā)明的方案的不同類型的實施例；一圖6是一個補充的流程圖，闡釋了本發(fā)明的方案的一般特性；以及一圖7和圖8根據(jù)基本上類似于圖1中采用的特征，通過兩種可行的變型，描述了 本發(fā)明的方案的實施例標準。
具體實施例方式圖2的一般框圖中，符號N表示了根據(jù)本發(fā)明的方案的一個規(guī)定了典型應用環(huán)境 的數(shù)據(jù)通信網(wǎng)絡(可以考慮互聯(lián)網(wǎng)作為一個直接的例子)。符號A表示了現(xiàn)在稱作“代理”的模塊，它實現(xiàn)的功能是對網(wǎng)絡N的相應單元進行 控制和監(jiān)視，并與相應的管理器M以一種雙向?qū)υ捘Ｊ竭M行操作。后者和一個更高等級水平上的附加代理A’ 一起確定了一個端口或網(wǎng)關G，它隨即 和另一個更高等級水平上的附加管理器M’相對接。后者和一個相應應用一起確定了一個觀測模塊或觀測器0。符號C1和C2表示兩個雙向通信信道，一個信道在代理A和網(wǎng)關G之間在較低等 級水平上執(zhí)行通信，另一個信道在網(wǎng)關G和觀測器0之間在較高等級水平上執(zhí)行通信。在上面提到的信道CI、C2上進行SNMP消息傳輸。圖3中的流程圖描述了 SNMP消息壓縮(圖3a)和解壓縮(圖3b)的特征。圖4中的流程圖(仍然參照圖4a中的發(fā)送和圖4b中的接收)闡釋了第一個方案， 其中設想通過對SNMP進行封裝，然后發(fā)送壓縮后的SNMP消息。圖5中的流程圖是另一種通過UDP封裝的傳輸方案。這個圖仍然參照發(fā)傳(圖 5a)和接收(圖5b)。圖7和圖8中的結構圖描述了和圖1中相同格式的0ID表示形式，并且參照壓縮和傳輸操作集，分別舉例說明圖3和4(圖7)中的a)部分以及圖3和5(圖8)中的a)部 分。首先來看圖3中的流程圖，在符號100表示的步驟中，整個SNMP消息(消息頭 +PDU)被讀出，用于在隨后由102表示的步驟中轉(zhuǎn)換或編碼成十六進制格式。這是采用一種 BER編碼類型的代碼來實現(xiàn)的。這樣編碼后的消息再通過一種基于對遞歸序列進行識別的壓縮技術進行壓縮，例 如前面已經(jīng)提及的zLib庫中提到的技術。這是在104表示的步驟中發(fā)生的，目的是在106表示的步驟中獲得準備用于發(fā)送 的壓縮后的數(shù)據(jù)單元。以一種完全對稱的方式，圖3的b部分的流程圖也包括四個步驟，即206，204，202 和200 (根據(jù)示出的順序來執(zhí)行)，其中接收到的壓縮數(shù)據(jù)單元(步驟206)被解壓縮(步驟 204)，隨后進行十六進制解碼(步驟202)，其后對整個SNMP消息進行重建(步驟200)。圖3中b部分的流程圖的數(shù)字符號順序和它們的執(zhí)行順序是相反的，這樣做的唯 一目的是強調(diào)這個過程和步驟100到106的壓縮過程的對稱性。圖4和圖5的流程圖中也 選擇了同樣的方式。如圖所示，圖4和圖7涉及到一種發(fā)送方案，設想將壓縮后的數(shù)據(jù)單元封裝成一個 標準SNMP消息，其特征在于專有的或特殊的“變量結”，以及通過UDP的標準發(fā)送性質(zhì)。壓縮數(shù)據(jù)單元的封裝形式在步驟106處獲得，還包括一個用108表示的初始化步 驟，在該步驟中壓縮后的數(shù)據(jù)單元按字節(jié)讀出，然后再隨后用110表示的編碼步驟中轉(zhuǎn)換 成相應的ASCII字符集。在下面一個步驟112中(可能在此之前加上輔助功能，例如ACKTAB+NULL-見圖 7中模塊110a)，第一個0ID和專有的或特殊的編號方式(例如1. 3. 6. 1. 4. 666. 1)構成的 消息生成了“變量結”，其包含的數(shù)值是字符串_zip_XXXX，其中XXXX表示原文件的大小。 上面引用的例子中，特定代碼666. 1表示此時還沒有在IANA(Internet AssignedNumbers Authority)注冊，但其他任何沒有注冊過的代碼都可以使用。其后適時地轉(zhuǎn)換成ASCII字符的包含有壓縮數(shù)據(jù)單元的變量結單元由0ID/數(shù)值 對構成。其數(shù)值包括壓縮數(shù)據(jù)單元轉(zhuǎn)換成ASCII字符的部分，最大為255個字符。然后SNMP消息的消息頭進行重建。這都發(fā)生在步驟112中，其后是步驟114，執(zhí)行 一個根據(jù)BER方法的額外的編碼，用于生成數(shù)據(jù)發(fā)送(步驟116)中所需的UDP消息的PDU 載荷(PDU-UDP的有效載荷)。還是在這種情況下，圖4的b)部分中重復出現(xiàn)的步驟216，214，212，210和208被 設計為根據(jù)前面所引用的順序來執(zhí)行，這些步驟表示出接收端實現(xiàn)的涉及到發(fā)送操作的步 驟108到116的雙重功能。采用圖4和圖7中提及的方案，壓縮后的SNMP消息具有一個標準的邏輯SNMP格 式，但是內(nèi)容是專有的或特殊的。因此，它需要代理管理器的功能擴充，盡管很小，從而能夠 進識別和編碼/解碼。申請人:進行的實驗證明這種方案是完全可行的，不會影響網(wǎng)絡結構。圖5和圖8提到的另一種方案，設想根據(jù)圖3所示的性質(zhì)，準備來自SNMP消息的 壓縮數(shù)據(jù)單元，然后把上述數(shù)據(jù)單元直接封裝PDU-UDP的有效載荷中。
7
很明顯對于正確的操作，這個方案需要使用專用的發(fā)送器和接收器，例如前提條 件是要確保UDP端口的可用性和標準端口不同。因此發(fā)送器必須能識別接收器使用的UDP 端口，反過來也是一樣。使用的端口信息可根據(jù)下文中將要詳細解釋的標準，通過一種標準 SNMP格式的同步消息在更高層上進行交換。采用圖5和圖8中描述的另一個替代方案時，在步驟108處得到的用于替代消息 的BER的壓縮數(shù)據(jù)單元成為PDU-UDP消息的有效載荷。圖5和圖8中相關的操作用標號為118、120的步驟表示，上述步驟在發(fā)送步驟122 之前，用于接收器的各個專用端口( 一般稱作端口 X)。還是在這種情況下，其余操作包括三個步驟，分別是222 (該時刻用作接收器的模 塊的端口 Y的接收)、220 (PDU-UDP有效載荷的提取)、218 (接收到壓縮數(shù)據(jù)單元，用于傳送 至圖3中b)部分流程圖的步驟206處)。同樣在這種情況下，步驟222、220、218按照上面已經(jīng)提及的順序來執(zhí)行。前面提到的同步消息由管理器按照“應用到應用”的基本原則發(fā)至SNMP代理，使 用了含有專用或特殊的“變量結”的標準SNMP格式。被傳送的信息可能的類型為0ID數(shù)值 管理器向SNMP管理器發(fā)送一個專用消息，把用于UDP傳輸?shù)亩丝谔?例如1024) 編譯成<UDP_TX_P0RT>值，并且把用于UDP接收的端口號(例如1224)編譯成<UDPR_X_ PORT〉值。代理向管理器答復一個類似的包含自身信息的消息。這種方法增加了技術方案的 效率，從而減少了處理時間。圖6中的框圖還顯示了對上面描述的方案的推廣，以適用于任何使用UDP作為傳 輸端口的消息類型(例如SNMP、PING等等)。這種推廣使得能夠?qū)崿F(xiàn)一種取代目前正在使 用的UDP驅(qū)動器。這種方案能夠估計要傳送的有效載荷的大小，并使用此處提到的方法進一步處理 (假定大小是足夠大的(例如大于20字節(jié)))。為了表明發(fā)送至接收端的UDP消息的簡潔 性，例如一或多個比特時，可以把UDP消息頭中(目前這些比特沒有使用，缺省設置為0)第 62個比特到第69個比特之間的8個比特置為1。特別是圖6的框圖中，符號300表示出現(xiàn)發(fā)送能夠通過UDP傳輸?shù)南⒌男枨蟮?任何步驟，隨后是對有效載荷進行壓縮的步驟302，根據(jù)圖3中描述的特性來實現(xiàn)。接下來的步驟304中設想了根據(jù)上面提到的原則生成UDP消息頭，同時下面的步 驟306對應了整個UDP消息的創(chuàng)建，考慮了 IP傳輸，在步驟308中實現(xiàn)。提及的方法能夠?qū)崿F(xiàn)一種一般用途的解決方案，能夠支持任何一種使用UDP-IP 協(xié)議棧的應用類型。上述方案特別適用于硬件實現(xiàn)或“on-chip ”方案。上述方案的一個功能性延伸能夠獨立于用于數(shù)據(jù)傳輸?shù)姆椒▉韺崿F(xiàn)，以及消息的
8編碼或等效的BER或八位數(shù)據(jù)UDP。對此考慮采用了一種安全有效的方法，現(xiàn)在稱為“block cipher Ri jndael ”，也叫做 “AES，，。這里描述的方案的優(yōu)點在于允許對SNMP消息進行壓縮，以一種組合的方式，既參 考了一種靈活的壓縮技術，又參考了其他壓縮技術(如MPEG)克服了說明書中提到的缺點。 這種技術及其算法可在多個操作系統(tǒng)下使用，使該方案成為一個可以再次使用和重復實現(xiàn) 的方案。另外，上述方案對管理器和代理端的影響都是最小的，因為它需要建立消息壓縮和 解壓縮的一個簡單的上層結構。該方案證明是高效率的，因為它能夠?qū)W(wǎng)絡業(yè)務量進行優(yōu)化，時間間隔相等時，能 夠通過較小的消息數(shù)量來傳送相同數(shù)量或更大量的信息。它也是個安全的解決方案，因為 信息被壓縮和編碼之后，在網(wǎng)絡中以明文進行傳輸。顯然，在本發(fā)明的原理不改變的情況下，考慮到此處描述和闡釋的方面，具體實施 方式以及實施例可能會不同，這并沒有偏離權利要求所限定的本發(fā)明的主旨和范圍。
權利要求
傳輸用戶數(shù)據(jù)報協(xié)議(UDP)消息的方法，包括對來自第一UDP消息的數(shù)據(jù)單元進行壓縮；將壓縮后的數(shù)據(jù)單元配置為第二UDP消息的協(xié)議數(shù)據(jù)單元有效載荷；并且根據(jù)UDP發(fā)送第二UDP消息，其中第二UDP消息包括對壓縮的指示。
2.如權利要求1中所述的方法，其中所述壓縮是gzip壓縮。
3.如權利要求1中所述的方法，還包括使用第二UDP消息的UDP包頭的一個比特字段 來指示壓縮步驟的執(zhí)行。
4.如權利要求3中所述的方法，其中來自第二UDP消息的UDP包頭的比特62到比特 69的比特被用作指示壓縮步驟的執(zhí)行的比特字段。
5.如權利要求3中所述的方法，還包括將第二UDP消息的UDP包頭的一個壓縮指示比 特設置為值1，其中該壓縮指示比特是來自UDP包頭的比特62至比特69的比特之一。
6.如權利要求1中所述的方法，還包括將第二UDP消息從發(fā)送器的所識別的發(fā)送端口 發(fā)送到接收器的所識別的接收端口。
7.如權利要求6中所述的方法，還包括在所述接收端口處接收所述第二UDP消息； 從所述第二 UDP消息提取所述協(xié)議數(shù)據(jù)單元有效載荷；以及對所述協(xié)議數(shù)據(jù)單元有效載荷進行解壓，以得到原始消息的數(shù)據(jù)單元。
全文摘要
本發(fā)明涉及使用UDP傳輸來傳送信息。一個典型的例子是SNMP消息，用于在管理數(shù)據(jù)通信網(wǎng)絡，如互聯(lián)網(wǎng)的系統(tǒng)內(nèi)的管理器單元(M，M’)和代理單元(A，A’)之間進行通信(C1，C2)。消息的有效荷載，最好是作為一個整體的消息，基于在消息中周期性出現(xiàn)的序列的識別，進行壓縮操作。
文檔編號H04L29/06GK101854252SQ20101013438
公開日2010年10月6日 申請日期2002年8月9日 優(yōu)先權日2001年8月13日
發(fā)明者毛利茲奧·齊拉迪 申請人:意大利電信股份公司