專利名稱：Ip通信裝置及其所組成的ip通信系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及使用IP包來執(zhí)行通信的IP通信裝置及其所組成的IP通信系統(tǒng)。
本申請要求日本專利申請No.2005-270626的優(yōu)先權(quán)，其內(nèi)容以引用的方式并入本文。
背景技術(shù)：
題為“RFC 791”的文獻(xiàn)(可通過互聯(lián)網(wǎng)使用URL為http://www.ietf.org/rfc/rfc791.txt來在線檢索到)指出在為第三層(即，網(wǎng)絡(luò)層)安排的網(wǎng)際協(xié)議(IP)中，引入了MTU(即，最大傳輸單元)的概念來根據(jù)諸如為第二層(即，數(shù)據(jù)鏈路層)安排的以太網(wǎng)(即，注冊商標(biāo))之類的各種協(xié)議以實現(xiàn)信息和數(shù)據(jù)的存儲。MTU指出了通過為第二層安排的協(xié)議而可被存儲的最大數(shù)據(jù)長度。
一個IP包(或一個IP數(shù)據(jù)報)的最大數(shù)據(jù)長度被定義為65535個八位字節(jié)。為了通過MAC幀存儲IP包，例如應(yīng)將其分成1500個八位字節(jié)的單元，每一個單元與以太網(wǎng)的最大幀大小(即，MTU)相對應(yīng)。
為第二層安排了除以太網(wǎng)之外的各種協(xié)議；因此存在各種MTU，從而可以根據(jù)互聯(lián)網(wǎng)環(huán)境中的多個第二層協(xié)議來存儲IP包。當(dāng)把IP包從某一具有相對較大MTU的第二層協(xié)議傳輸?shù)搅硪痪哂邢鄬^小MTU的第二層協(xié)議時，必須將IP包分為多個片段。當(dāng)產(chǎn)生片段時，因為每個IP包都附上了包頭，所以應(yīng)相應(yīng)地增加IP包的總數(shù)，從而增加傳輸數(shù)據(jù)的總量；這減少了總通信效率。由于這個原因，使用節(jié)點(diǎn)到節(jié)點(diǎn)通信(或主機(jī)到主機(jī)通信)，其中借助兩個節(jié)點(diǎn)和(存在于該兩個節(jié)點(diǎn)之間路徑中的)另一節(jié)點(diǎn)中具有最小MTU的一個來分割I(lǐng)P包，從而增加通信效率。最初，由路由器來執(zhí)行包的分割；近年來，由發(fā)送源主機(jī)來執(zhí)行包的分割以減小路由器的過載。為了實現(xiàn)這種程序，引入了路徑MTU發(fā)現(xiàn)方法來發(fā)現(xiàn)通信路徑中的最短MTU；這在題為“RFC 1191”的文獻(xiàn)(可通過互聯(lián)網(wǎng)使用URL為http://www.ietf.org/rfc/rfc1191.txt來在線檢索到)中有介紹。
圖1示出了路徑MTU發(fā)現(xiàn)算法，其通過以下步驟實現(xiàn)。
(1)首先，源主機(jī)(H1)在IP頭設(shè)置一個不分段標(biāo)志。
(2)一個IP包被發(fā)送。在圖1的情況下，被發(fā)送的IP包的包長度為1500。
(3)當(dāng)發(fā)送數(shù)據(jù)長度超過MTU的IP包時，路由器不會將發(fā)送來的IP包分段，而是將其丟棄。
(4)在未能到達(dá)目的地的情況下，根據(jù)ICMP(網(wǎng)際控制報文協(xié)議)向源主機(jī)通知錯誤。在圖1的情況下，例如在路由器R1和R2之間鋪設(shè)電話線，其中MTU＝576(八位字節(jié))。由于這個原因，路由器R1把從源主機(jī)H1發(fā)送來的包長度為1500八位字節(jié)的IP包丟棄；之后，其把類型＝3(未能到達(dá)目的地)且代碼＝4(所需的分段和設(shè)置的DF)的ICMP消息或ICMP錯誤通知到源主機(jī)H1。ICMP錯誤包括了指示從路由器R1延伸的路徑以MTU＝576(八位字節(jié))設(shè)置的信息。
(5)此后，每一個都與被通知的MTU相匹配的包被重新發(fā)送。在此情況下，源主機(jī)H1將其MTU變?yōu)?76八位字節(jié)，以便將包長度為576八位字節(jié)的IP包重新發(fā)送到目的地主機(jī)H2。由于源主機(jī)H1和目的地主機(jī)H2之間所鋪設(shè)的路徑具有576或更多八位字節(jié)的MTU，所以重新發(fā)送的IP包完整地到達(dá)目的地主機(jī)H2。
在上述例子中，一接收到單個ICMP錯誤就可進(jìn)行路徑MTU發(fā)現(xiàn)過程。然而，通常重復(fù)上述步驟(2)到(5)，直到IP包完整地到達(dá)目的地主機(jī)H2(換句話說，直到不再發(fā)生ICMP通知)。
圖2示出了在完成上述路徑MTU發(fā)現(xiàn)過程后對在源主機(jī)H1和目的地主機(jī)H2之間發(fā)送的IP包進(jìn)行分割和重組的過程。如上所述，為鋪設(shè)在源主機(jī)H1和目的地主機(jī)H2之間的路徑設(shè)置576八位字節(jié)的最小MTU。源主機(jī)H1將包長度為1500八位字節(jié)的IP包分割為三個包，即，兩個包長度均為576八位字節(jié)的包和一個包長度為348八位字節(jié)的包；因此，源主機(jī)H1向目的地主機(jī)H2發(fā)送三次包。目的地主機(jī)H2將這三個包重組(恢復(fù))為原始IP包。
為了提高通信效率，已將最大幀大小超過了(由前述標(biāo)準(zhǔn)定義的)1500八位字節(jié)的MAC幀(稱為“巨型幀”)用在以太網(wǎng)中。
巨型幀的最大幀大小比以太網(wǎng)的原始MTU(即，1500八位字節(jié))大；換句話說，它們可擴(kuò)展以太網(wǎng)的原始MTU。不存在清楚地描述巨型幀的最大幀大小的標(biāo)準(zhǔn)；實際上，MTU取決于制造商和產(chǎn)品。
由于上述原因，網(wǎng)絡(luò)管理者必須檢查裝置的MTU，裝置相互連接在一起以使用各種幀大小來執(zhí)行通信；因此，網(wǎng)絡(luò)管理者必須手動設(shè)置相互連接的裝置以實現(xiàn)在通信路徑中所使用的最小MTU。這種手動設(shè)置操作是很繁瑣的，并且可能會引起設(shè)置錯誤而使通信下降。
例如，當(dāng)接收端裝置接收到比其自身定義的指定幀大小還大的幀時，其僅將在第二層(即，數(shù)據(jù)鏈路層)中的那些幀丟棄。這會引起“黑洞”，即發(fā)送端裝置無法接收到關(guān)于發(fā)送該幀的回復(fù)。題為“RFC2923”的文獻(xiàn)(可通過互聯(lián)網(wǎng)使用URL為http://www.ietf.org/rfc/rfc2923.txt來在線檢索到)介紹了一種方法，其中一旦發(fā)生黑洞，則使用上述路徑MTU發(fā)現(xiàn)算法來重新發(fā)送減小了MTU的MAC幀。
在發(fā)生了黑洞時的路徑MTU發(fā)現(xiàn)過程中，發(fā)送端裝置在等待到關(guān)于沒有來自接收端裝置的回復(fù)的檢測超時之后啟動路徑MTU發(fā)現(xiàn)過程；因此與正常程序相比，在啟動路徑MTU發(fā)現(xiàn)過程之前花了相對較長的時間。
在正常的路徑MTU發(fā)現(xiàn)過程中，一個發(fā)送ICMP錯誤的節(jié)點(diǎn)(或接收端裝置)描述了關(guān)于ICMP錯誤中基準(zhǔn)MTU的信息；因此，這使得發(fā)送端裝置可以根據(jù)該信息來檢驗通信路徑中的MTU。在發(fā)生黑洞時的路徑MTU發(fā)現(xiàn)過程中，沒有將信息送回到發(fā)送端裝置；因此，例如發(fā)送端裝置必須使用另一方法來搜索將一步步減小的MTU。
假設(shè)，如圖3所示，將包從具有MTU＝9000(八位字節(jié))的源主機(jī)H1發(fā)送到具有MTU＝7000(八位字節(jié))的目的地主機(jī)H2。當(dāng)源主機(jī)H1將幀大小為9000八位字節(jié)的包發(fā)送到目的地主機(jī)H2時，布置在它們之間的交換集線器SH僅將幀大小為9000八位字節(jié)的相應(yīng)MAC幀傳輸?shù)侥康牡刂鳈C(jī)H2。然而，該MAC幀在目的地主機(jī)H2中過大，所以目的地主機(jī)H2直接將其丟棄。
在上述情況下，源主機(jī)H1并未在指定時間段內(nèi)從主機(jī)H2接收到回復(fù)，所以源主機(jī)H1將該9000八位字節(jié)的MAC幀分割為兩個各具有一半MTU(即，4500八位字節(jié))的MAC幀，之后，其重新發(fā)送各具有MTU＝4500(八位字節(jié))的已分割的MAC幀，其中該MTU＝4500(八位字節(jié))小于目的地主機(jī)H2的MTU＝7000(八位字節(jié))；因此，目的地主機(jī)H2可以將它們可靠地接收并進(jìn)行處理。
在上述情況下，因為對于可以接收每一個具有MTU＝7000(八位字節(jié))的包的目的地主機(jī)H2，使用了各具有MTU＝4500(八位字節(jié))的包來執(zhí)行通信，所以勢必會降低通信效率。在這種情況下，可以嘗試通過改變應(yīng)用于原始MAC包的減小率來多次執(zhí)行包的分割，從而計算出一個適當(dāng)?shù)膸笮　Ｈ欢?，這增加了嘗試執(zhí)行包的分割的次數(shù)并且最終減小了通信效率。

發(fā)明內(nèi)容
本發(fā)明的一個目的是提供一種IP通信裝置，其可以使用巨型幀來執(zhí)行高效率通信并可消除由網(wǎng)絡(luò)管理器執(zhí)行設(shè)定的必要。
在本發(fā)明的第一方面中，IP通信裝置包括發(fā)送器、接收器、以及用于檢驗接收到的數(shù)據(jù)的幀大小是否超過預(yù)先確定的最大幀大小的幀大小檢驗器。該IP通信裝置還產(chǎn)生ICMP錯誤，該ICMP錯誤包括從接收到的數(shù)據(jù)提取的用來表示源地址的信息和作為MTU的最大幀大小，從而通過發(fā)送器將該ICMP錯誤送回到源地址。這里，在接收到ICMP錯誤時執(zhí)行路徑MTU發(fā)現(xiàn)。
在本發(fā)明的第二方面中，IP通信系統(tǒng)是由多個IP通信裝置組成的，該IP通信裝置的每一個都包括發(fā)送器、接收器、以及用于檢驗接收到的數(shù)據(jù)的幀大小是否超過預(yù)先確定的最大幀大小的幀大小檢驗器。另外，該IP通信裝置還產(chǎn)生ICMP錯誤，該ICMP錯誤包括從接收到的數(shù)據(jù)提取的用來表示源地址的信息和作為MTU的最大幀大小。而且，在接收到ICMP錯誤時至少有一個IP通信裝置執(zhí)行路徑MTU發(fā)現(xiàn)。
如上所述，當(dāng)接收到的數(shù)據(jù)的幀大小超過了最大幀大小時，該IP通信裝置將ICMP錯誤送回到由接收到的數(shù)據(jù)包含的信息所指定的源地址，其中，該ICMP錯誤還包括作為MTU的最大幀大小。因此，具有該源地址的源裝置可在第二層(即，數(shù)據(jù)鏈路層)中檢測到作為關(guān)于到達(dá)該網(wǎng)絡(luò)層的IP包的錯誤的超過幀大小錯誤。另外，該源裝置還可檢測一個適合于鋪設(shè)在該源裝置和該目的地裝置之間的通信路徑的適當(dāng)?shù)腗TU。
在接收到ICMP錯誤時執(zhí)行路徑MTU發(fā)現(xiàn)，從而調(diào)整發(fā)送幀大小來與送回該ICMP錯誤的IP通信裝置的MTU匹配。這樣迅速地確定了滿足該通信路徑的適當(dāng)MTU，而不會在通信中引起黑洞；因此，可以提高通信效率。


將參考以下附圖詳細(xì)描述本發(fā)明的這些及其他目的、方面、和
具體實施例方式
將參考附圖通過示例進(jìn)一步詳細(xì)描述本發(fā)明。
圖4是示出了根據(jù)本發(fā)明優(yōu)選實施例的IP通信裝置的組成的框圖。接收器11基于以太網(wǎng)接收信號，從而對其最大幀大小都由規(guī)定位數(shù)限制的MAC幀執(zhí)行緩沖。幀大小檢驗器12檢驗接收到的MAC幀是否符合緩沖的被限制的最大幀大小，換句話說，它檢驗接收到的每一個MAC幀的幀大小是否超過了緩沖的被限制的最大幀大小。CPU 13分析經(jīng)過指定處理的接收和緩沖的MAC幀。例如，在第二層(即，數(shù)據(jù)鏈路層)中，CPU 13從MAC幀中提取MAC頭、數(shù)據(jù)部分、和FCS(幀檢驗序列)部分，從而執(zhí)行錯誤檢驗。在第三層(即，網(wǎng)絡(luò)層)中，CPU 13從MAC幀中提取數(shù)據(jù)部分，即IP包的IP頭和有效負(fù)荷(或數(shù)據(jù))。在第四層(即，傳輸層)中，CPU 13提取IP包的有效負(fù)荷，即TCP段的TCP頭和數(shù)據(jù)(其中TCP表示傳輸控制協(xié)議)。對于更高次序的層，CPU 13根據(jù)例如使用從TCP段中提取的傳輸控制協(xié)議(TCP)的應(yīng)用程序的數(shù)據(jù)來執(zhí)行指定的處理。
另外，CPU 13把要傳輸?shù)腗AC幀通過以太網(wǎng)輸出到發(fā)送器14。發(fā)送器14通過以太網(wǎng)將它們發(fā)送出去。
當(dāng)幀大小檢驗器12檢測到接收到的MAC幀的幀大小超過了被限制的最大幀大小時，CPU 13產(chǎn)生ICMP錯誤，該ICMP錯誤隨后將由發(fā)送器14進(jìn)行發(fā)送。
圖5示出了MAC幀和IP包之間的關(guān)系。MAC幀包括MAC頭、數(shù)據(jù)、和FCS。MAC頭包括目的地MAC地址、源MAC地址、和幀類型。IP包包括IP頭和有效負(fù)荷。IP頭包括源IP地址、目的地IP地址、和有效負(fù)荷長度。
圖6示出了與ICMP錯誤對應(yīng)的包，其包括IP頭和ICMP報文。
ICMP報文通常描述了識別錯誤的內(nèi)容(或原因)以及引起錯誤的IP包的前半部分的信息。然而，在幀大小超過被限制的最大幀大小以至于無法完整提取相應(yīng)IP包時產(chǎn)生的ICMP錯誤中，通過從接收到的MAC幀的數(shù)據(jù)中提取IP包的必要部分來產(chǎn)生ICMP報文。
下面將參考圖7和圖8A及8B來描述并入圖4所示IP通信裝置中的CPU 13的處理，其中該IP通信裝置作為通信路徑中的源裝置或目的地裝置，或作為通信路徑中布置在源裝置和目的地裝置之間的插入裝置。
圖7是示出了作為通信路徑中的插入裝置或目的地裝置的IP通信裝置的CPU 13的處理的流程圖。當(dāng)圖4所示幀大小檢驗器12產(chǎn)生了表示接收到的幀大小超過“可處理的”最大幀大小的幀大小檢驗結(jié)果“NG”時，CPU 13從在接收器11中累積的緩沖中的MAC幀的前半部分提取關(guān)于通信路徑的源裝置的IP地址，以便將ICMP錯誤送回到該源裝置。這是通過圖7所示一系列步驟S1、S2、和S3實現(xiàn)的。使用圖6所示ICMP包來實現(xiàn)ICMP錯誤，其中IP頭包括提取的源裝置的IP地址以及當(dāng)前指定裝置的IP地址，并且在IPv4(即，互聯(lián)網(wǎng)協(xié)議版本4)的情況下，ICMP報文包括“類型＝3”(表示“未能到達(dá)目的地”)和“代碼＝4”(表示分段錯誤)。在IPv6(即，互聯(lián)網(wǎng)協(xié)議版本6)的情況下，ICMP報文包括“包過大”代碼。另外ICMP報文還包括一個適當(dāng)?shù)腗TU，其表示在第二層中可由IP通信裝置處理的最大幀大小。
當(dāng)幀大小檢驗器12產(chǎn)生了表示接收到的幀大小不大于“可處理的”最大幀大小的幀大小檢驗結(jié)果“OK”時，在步驟S4中，對相應(yīng)MAC幀執(zhí)行正常處理。
下面將參考圖8A和8B描述在通信路徑中作為源裝置的IP通信裝置的CPU 13的處理詳情。如圖8A所示，當(dāng)IP通信裝置接收到ICMP錯誤時，其執(zhí)行路徑MTU發(fā)現(xiàn)(見步驟S11和S12)。圖8B示出了路徑MTU發(fā)現(xiàn)的詳情。在步驟S21中，MTU被設(shè)置為應(yīng)用于IP通信裝置的最大值。在步驟S22中，IP頭包含的不分段標(biāo)志被設(shè)為“1”。在步驟S23中，通信路徑中的IP通信裝置向目的地裝置發(fā)送IP包。
當(dāng)作為通信路徑中的插入裝置或目的地裝置的IP通信裝置接收到一個其幀大小超過上述MTU的MAC幀時，它把表示了未能到達(dá)目的地報文的ICMP錯誤(見圖7所示的步驟S3)送回到通信路徑中的源裝置；因此，作為源裝置的IP通信裝置接收到這樣的ICMP錯誤。在這種情況下，IP通信裝置讀取該ICMP錯誤中所包含的MTU，以便執(zhí)行對相應(yīng)的IP包的分段，該相應(yīng)的IP包將在隨后被分段并重新發(fā)送到目的地裝置。這是由一系列步驟S24、S25、S22和S23實現(xiàn)的。
重復(fù)上述步驟直到IP通信裝置未接收到上述表示未能到達(dá)目的地報文的ICMP錯誤。因此，可以在鋪設(shè)于源裝置和目的地裝置之間的通信路徑中產(chǎn)生適當(dāng)?shù)腗TU。
IP通信系統(tǒng)是由多個在通信路徑中作為源裝置、插入裝置和目的地裝置的IP通信裝置組成的；因此，將每一IP通信裝置設(shè)計為解決圖7的處理(其中檢驗接收到的幀大小，并且如果必要的話將ICMP錯誤送回到源裝置)和圖8A和8B的處理(其中在接收到ICMP錯誤時執(zhí)行路徑MTU發(fā)現(xiàn))。具體地說，在接收到ICMP錯誤時步驟S4的處理(當(dāng)在步驟S1中接收到的幀大小為“OK”時所執(zhí)行的處理)包括路徑MTU發(fā)現(xiàn)(見圖8A和8B)。
在圖8A和8B中，ICMP錯誤的接收觸發(fā)了將要執(zhí)行的路徑MTU發(fā)現(xiàn)；因此，在路徑MTU發(fā)現(xiàn)的處理期間再次將ICMP錯誤通知到源裝置。由于在接收到其幀大小超過指定MTU的MAC幀時被通知到源裝置的上述ICMP錯誤包括了適當(dāng)?shù)腗TU，所以隨著ICMP錯誤的第一次接收，源裝置可以將其MTU改變?yōu)樵撨m當(dāng)?shù)腗TU，從而減少路徑MTU發(fā)現(xiàn)。
如前所述，本發(fā)明并不需限制在上述例舉的非限制性實施例中；因此，可以在所附權(quán)利要求定義的本發(fā)明的范圍內(nèi)提出進(jìn)一步的修改。
權(quán)利要求
1.一種IP通信裝置，包括用于通過網(wǎng)絡(luò)發(fā)送數(shù)據(jù)的發(fā)送器；用于通過網(wǎng)絡(luò)接收數(shù)據(jù)的接收器；幀大小檢驗器，其用于檢驗接收到的數(shù)據(jù)的幀大小是否超過預(yù)先確定的最大幀大小；和ICMP錯誤產(chǎn)生裝置，其用于產(chǎn)生ICMP錯誤，所述ICMP錯誤包括從接收到的數(shù)據(jù)中提取的用以表示源地址的信息和作為MTU的最大幀大小，其中，所述ICMP錯誤由所述發(fā)送器發(fā)回到所述源地址。
2.一種根據(jù)權(quán)利要求1所述的IP通信裝置，還包括執(zhí)行裝置，其用于在接收到所述ICMP錯誤時執(zhí)行路徑MTU發(fā)現(xiàn)。
3.一種IP通信系統(tǒng)，其包括多個IP通信裝置，所述多個IP通信裝置的每一個均包括發(fā)送器；接收器；幀大小檢驗器，其用于檢驗接收到的數(shù)據(jù)的幀大小是否超過預(yù)先確定的最大幀大??；和ICMP錯誤產(chǎn)生裝置，其用于產(chǎn)生ICMP錯誤，所述ICMP錯誤包括從接收到的數(shù)據(jù)中提取的用以表示源地址的信息和作為MTU的最大幀大小。
4.一種根據(jù)權(quán)利要求3所述的IP通信系統(tǒng)，其中，所述IP通信裝置中的至少一個還包括用于在接收到所述ICMP錯誤時執(zhí)行路徑MTU發(fā)現(xiàn)的執(zhí)行裝置。
全文摘要
一對IP通信裝置(稱為源裝置和目的地裝置)在鋪設(shè)在它們之間的通信路徑上使用IP包(如，MAC幀或巨型幀)來執(zhí)行通信。該IP通信裝置檢驗MAC幀的大小是否超過了預(yù)先確定的最大幀大小；之后，將ICMP錯誤發(fā)回到具有包含在MAC幀的規(guī)定部分中的IP地址的源裝置。源裝置還執(zhí)行路徑MTU發(fā)現(xiàn)來確定適當(dāng)?shù)腗TU，從而提高通信效率而不會在通信中引起黑洞。
文檔編號H04L12/56GK1933486SQ20061012745
公開日2007年3月21日 申請日期2006年9月15日 優(yōu)先權(quán)日2005年9月16日
發(fā)明者廣瀨良太 申請人:雅馬哈株式會社