專利名稱：用于實(shí)現(xiàn)輕量級、可靠的、基于分組的傳輸協(xié)議的裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)據(jù)網(wǎng)絡(luò)，并且更具體而言，涉及快速、輕量級、可靠的基于分組的傳輸協(xié)議，該傳輸協(xié)議獨(dú)立于網(wǎng)絡(luò)所使用的下層協(xié)議類型進(jìn)行操作。
背景技術(shù)：
目前使用的最流行的傳輸協(xié)議是在因特網(wǎng)協(xié)議(IP)簇(InternetProtocol suite)的框架中定義的傳輸控制協(xié)議(Transmission ControlProtocol，TCP)。TCP協(xié)議為較高協(xié)議層和/或應(yīng)用提供了可靠的、面向連接的、嚴(yán)格按順序傳遞的、字節(jié)流傳輸服務(wù)。TCP利用確認(rèn)和重傳機(jī)制來實(shí)現(xiàn)可靠性。一般來講，接收TCP實(shí)體對其從發(fā)送TCP實(shí)體接收到的每個分組進(jìn)行確認(rèn)。當(dāng)在一定時間段(被稱為“重傳超時(RetransmissionTimeout)”)內(nèi)沒有接收到一個這樣的確認(rèn)時，發(fā)送TCP實(shí)體假定相應(yīng)的分組已在網(wǎng)絡(luò)中丟失，并且重傳該分組。這種重傳機(jī)制多年來已經(jīng)過改良，以便使其更加有效。例如，被稱為“快速重傳(Fast Retransmit)”的算法己被添加到TCP中，以在重傳超時出現(xiàn)之前觸發(fā)丟失分組的重傳。而且，通過添加對往返時間(即，TCP分組到達(dá)其目的地所花費(fèi)的時間加上其確認(rèn)返回所需的時間)的估計(jì)器，已經(jīng)使得重傳超時適應(yīng)于網(wǎng)絡(luò)尺寸和負(fù)載。
TCP協(xié)議還提供流控制功能，該流控制功能被定義為接收節(jié)點(diǎn)控制向其發(fā)送分組的速率以防止其輸入緩沖區(qū)溢出的能力。為此，TCP采用被稱為“滑動窗(sliding window)”的機(jī)制。接收TCP實(shí)體連續(xù)告知發(fā)送TCP實(shí)體關(guān)于空閑輸入緩沖區(qū)(所謂的“供應(yīng)窗(offered window)”)的量。當(dāng)該量降到零時，發(fā)送TCP實(shí)體制止向接收實(shí)體發(fā)送任何另外的數(shù)據(jù)，直到在輸入緩沖區(qū)中出現(xiàn)新的可用空間。
在TCP中構(gòu)建的另一重要能力是擁塞控制功能。已經(jīng)注意到，當(dāng)發(fā)送TCP實(shí)體沒有接收到確認(rèn)時，它假定分組已被網(wǎng)絡(luò)丟棄。出于很多原因，網(wǎng)絡(luò)可能丟棄分組，例如數(shù)據(jù)損壞、鏈路和/或網(wǎng)絡(luò)故障、緩沖區(qū)擁塞等等。在所有這些原因中，擁塞到目前為止是最常見的，尤其是在諸如因特網(wǎng)的大網(wǎng)絡(luò)中。因此，當(dāng)確認(rèn)丟失時，TCP不僅假定分組被丟棄，還假定分組丟棄的原因是網(wǎng)絡(luò)擁塞。在TCP中已經(jīng)嵌入了諸如“慢啟動(SlowStart)”和“快恢復(fù)(Fast Recovery)”之類的許多算法，以便處理擁塞。這些算法的目的是依賴于在網(wǎng)絡(luò)中檢測到的擁塞的嚴(yán)重性而以不同方式降低傳輸速率。
TCP的一個問題在于，上述三種功能，即可靠傳遞、流控制和擁塞控制，以及其他功能，使得其從實(shí)現(xiàn)方式的角度來講是非常復(fù)雜的協(xié)議。結(jié)果，大多數(shù)網(wǎng)絡(luò)節(jié)點(diǎn)通常將TCP實(shí)現(xiàn)為嵌入到操作系統(tǒng)中的軟件模塊。很明顯，這種解決方案不是特別快速，并且還消耗可以用來運(yùn)行用戶應(yīng)用的CPU周期。還存在一些TCP實(shí)現(xiàn)方式，它們依賴于微控制器芯片和專用軟件(微代碼)來使系統(tǒng)CPU不用承擔(dān)運(yùn)行TCP的任務(wù)。這種解決方案比前面提到的解決方案更快速并且更有效，但是它仍然不適用于高速(即每秒幾千兆位)網(wǎng)絡(luò)。
因此，需要快速、輕量級、可靠的、基于分組的協(xié)議，其獨(dú)立于下層協(xié)議的類型而進(jìn)行操作。

發(fā)明內(nèi)容
為了實(shí)現(xiàn)上述目的，并且根據(jù)本發(fā)明的目的，公開了一種快速、輕量級、可靠的、基于分組的協(xié)議，該協(xié)議獨(dú)立于下層協(xié)議的類型而操作。更具體而言，該協(xié)議(在下文中被稱為ABC協(xié)議)可以由例如但不局限于IEEE 802.3、以太網(wǎng)、以太網(wǎng)II、HARD和IP之類的協(xié)議所承載。該ABC協(xié)議定義至少三種不同類型的幀，包括信息幀(Information frame)、監(jiān)控幀(Supervisory frame)和無序號幀(Unnumbered frame)。在本發(fā)明的各種實(shí)施例中，信息幀、監(jiān)控幀和無序號幀包括目的地服務(wù)接入點(diǎn)(Destination Service Access Point，DSAP)和源服務(wù)接入點(diǎn)(SourceService Address Point，SSAP)字段，這兩個字段足夠大以支持可以在網(wǎng)絡(luò)上使用的各種應(yīng)用。信息幀、監(jiān)控幀和無序號幀還具有支持緊急數(shù)據(jù)傳遞和某些存儲器管理功能的能力。ABC協(xié)議還能夠支持上層協(xié)議的復(fù)用，使得多個上層的應(yīng)用能夠共享相同連接。最后，本發(fā)明的ABC協(xié)議支持流控制和擁塞控制兩者，從而有助于減少在接收節(jié)點(diǎn)或網(wǎng)絡(luò)上丟失或丟棄分組的發(fā)生率。


圖1A是本發(fā)明的ABC協(xié)議所使用的信息幀的頭部。
圖1B是根據(jù)本發(fā)明的圖1A的信息幀頭部的控制字段的格式。
圖1C是根據(jù)本發(fā)明的圖1A中的信息幀頭部的標(biāo)志字段(Flagsfield)的格式。
圖2A示出了本發(fā)明的ABC協(xié)議的監(jiān)控幀的頭部。
圖2B是根據(jù)本發(fā)明的圖2A的監(jiān)控幀頭部的控制字段的格式。
圖3示出了本發(fā)明的ABC協(xié)議所使用的無序號幀的頭部。
圖3B是根據(jù)本發(fā)明的圖3A的無序號幀頭部的控制字段的格式。
圖3C是根據(jù)本發(fā)明的ABC協(xié)議所使用的XID幀的頭部。
圖4示出了根據(jù)本發(fā)明的各種實(shí)施例，置于HARD層的IP層、MAC層之上的本發(fā)明的ABC協(xié)議。
圖5A示出了以太網(wǎng)II幀的格式。
圖5B示出了根據(jù)本發(fā)明在以太網(wǎng)II幀內(nèi)的ABC分組的封裝。
圖5C示出了根據(jù)本發(fā)明，在HARD分組內(nèi)，進(jìn)而在以太網(wǎng)II幀內(nèi)的ABC分組的封裝。
圖6A示出了根據(jù)本發(fā)明在IP數(shù)據(jù)報內(nèi)的ABC分組的封裝。
圖6B示出了根據(jù)本發(fā)明，在HARD分組內(nèi)，進(jìn)而在IP數(shù)據(jù)報內(nèi)的ABC分組的封裝。
圖7是示出了本發(fā)明的ABC協(xié)議所使用的停和走(stop and go)流控制的周期的圖。
圖8是示出了根據(jù)本發(fā)明，ABC協(xié)議擁塞窗(congestion window)隨時間變化的圖。
具體實(shí)施例方式
本發(fā)明的快速、輕量級、可靠的、基于分組的傳輸協(xié)議(在下文中被稱為ABC協(xié)議)是Logical Link Control-Part 2(LLC-Type 2)(邏輯鏈路控制第2部分(LLC-Type 2))協(xié)議的修改。更具體而言，如這里所述，本發(fā)明的ABC協(xié)議在不執(zhí)行實(shí)質(zhì)改動的情況下使用LLC-Type 2協(xié)議的狀態(tài)機(jī)，同時修改和擴(kuò)展LLC-Type 2的某些方面。對于LLC-Type 2的更多信息，參見第2部分(logic Link Control(邏輯鏈路控制)，ANSI/IEEEStd.802.2，1998版)這里為所有目將其全部內(nèi)容結(jié)合于此。
對LLC-Type 2的修改本發(fā)明的ABC協(xié)議在以下三個基本方面修改LLC-Type 2協(xié)議尋址、流和擁塞控制以及帶外信令。
每個LLC-Type 2協(xié)議數(shù)據(jù)單元(LLC-Type 2 Protocol Data Unit，PDU)包含兩個地址字段目的地服務(wù)接入點(diǎn)(DSAP)和源服務(wù)接入點(diǎn)(SSAP)。這些字段中的每一個都具有八位寬度，并且包括七位的實(shí)際地址信息。DSAP字段中的最低有效位(LSB)用于將DSAP地址標(biāo)識為個人或組地址。SSAP字段中的最低有效第八位用于將LLC PDU標(biāo)識為命令或響應(yīng)，并且因此有時被稱為命令/響應(yīng)標(biāo)識符位。本發(fā)明的ABC協(xié)議通過具有16位寬度的DSAP和SSAP字段而擴(kuò)展LLC-Type 2的尋址能力。這兩個字段的LSB的語義保持與LLC-Type 2相同。但是，其余15位現(xiàn)在被分別用于DSAP和SSAP字段的尋址目的。
LLC-Type 2依賴于LLC-Type 2頭部中的DSAP和SSAP字段和MAC源和目的地地址來標(biāo)識連接。由于本發(fā)明的ABC協(xié)議獨(dú)立于下層物理層進(jìn)行操作，并且可以被用于幾乎任何類型的聯(lián)網(wǎng)媒體，因此DSAP和SSAP字段的語義以如下方式稍作修改連接只由DSAP和SSAP地址來唯一地標(biāo)識。本發(fā)明不需要媒體訪問控制或MAC地址。這種修改使本發(fā)明的ABC協(xié)議能夠非常靈活，并且允許其運(yùn)行在諸如IP或以太網(wǎng)之類的任意下層上而無需任何大的修改。
LLC-Type 2流控制主要用于點(diǎn)對點(diǎn)鏈路，而在ABC中對流控制進(jìn)行了修改，以便對一對ABC節(jié)點(diǎn)之間的任意數(shù)量鏈路起作用。對于所涉及的擁塞控制，最近可獲得的LLC-Type 2規(guī)范包括一個附件(即附件C)，該附件為橋接的LAN定義了可選的擁塞控制技術(shù)。這里所描述的擁塞控制技術(shù)似乎不適合于應(yīng)對嚴(yán)重?fù)砣?，并且從帶寬角度來講實(shí)質(zhì)上不利于連接，尤其是在網(wǎng)絡(luò)很大并且往返時間(Round Trip Time，RTT)相當(dāng)大的情況下。ABC用與TCP協(xié)議所采用的擁塞控制機(jī)制非常類似的擁塞控制機(jī)制來替代附件C的技術(shù)，TCP協(xié)議所采用的擁塞控制機(jī)制被廣泛認(rèn)為是有效且高效的。在本申請中，后面詳細(xì)描述了流控制和擁塞控制。
最后，如LLC-Type 2規(guī)范中所指定的，ABC需要強(qiáng)制實(shí)現(xiàn)用于帶外信令的XID和測試(TEST)幀。
對LLC-Type 2的擴(kuò)展ABC協(xié)議通過在以下方面中添加一些額外功能來擴(kuò)展LLC-Type 2協(xié)議存儲器管理和分割、對緊急數(shù)據(jù)的支持，以及上層/應(yīng)用復(fù)用。
對于所涉及的存儲器管理，ABC允許發(fā)送實(shí)體通過NEW_BUFFER位以信號通知接收實(shí)體它需要為數(shù)據(jù)分配新的緩沖區(qū)，或者通過END_OF_DATA位以信號通知接收實(shí)體數(shù)據(jù)單元已經(jīng)發(fā)完，并且可以將其傳遞到上層。
ABC支持緊急數(shù)據(jù)到目的地ABC實(shí)體的傳遞。當(dāng)這樣的實(shí)體接收到被標(biāo)記為緊急的信息幀時，包含在該幀中的數(shù)據(jù)不被緩沖，而是立即將其傳遞到上層協(xié)議。
最后，ABC允許多個應(yīng)用共享同一連接(即，使用同一DSAP/SSAP對來發(fā)送它們的分組)。應(yīng)用復(fù)用是以與TCP(Transmission ControlProtocol，傳輸控制協(xié)議)或UDP(User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議)類似的方式被實(shí)現(xiàn)的，即利用被稱為源端口(Source Port)和目的地端口(Destination Port)的兩個16位字段。
ABC幀類型類似于LLC-Type 2，本發(fā)明的ABC協(xié)議使用三種不同類型的幀。這三種類型包括信息幀、監(jiān)控幀和無序號幀。
參考圖1A，示出了本發(fā)明的ABC協(xié)議所使用的信息幀的頭部。信息幀頭部10總共包括6個字段，每個字段具有16位寬度。這6個字段分別包括DSAP字段、SSAP字段、控制字段12、標(biāo)志字段14以及源和目的地端口字段。DSAP字段標(biāo)識在目的地節(jié)點(diǎn)處的ABC協(xié)議連接。最低有效位是如LLC-Type 2規(guī)范所定義的個人/組(Individual/Group)位。其余的15個位被用于標(biāo)識在目的地節(jié)點(diǎn)上的連接。SSAP字段標(biāo)識在源節(jié)點(diǎn)上的ABC協(xié)議連接。最低有效位是如LLC-Type 2規(guī)范所定義的命令/響應(yīng)(Command/Response)位。其余的15個位被用于定義在源節(jié)點(diǎn)上的連接。由于在DSAP或SSAP字段中的15個位被用作連接標(biāo)識符，因此在ABC節(jié)點(diǎn)處最多可以有215＝32768個連接是活動的。在本發(fā)明的另一實(shí)施例中，如果需要，可以將DSAP的較高15位和SSAP的較高15位的級聯(lián)用作連接標(biāo)識符，以增大活動連接的最大數(shù)目。DSAP和SSAP字段除了是16位寬度而不是8位寬度之外，基本上與LLC-Type 2規(guī)范所定義的相同。源端口字段標(biāo)識源應(yīng)用，而目的地端口字段標(biāo)識目的地應(yīng)用。
如圖1B所示，信息幀的控制字段被用于保存序列號和控制信息。根據(jù)優(yōu)選實(shí)施例，控制字段12的最高有效位總是被設(shè)置為零(0)。后面7位代表發(fā)送者的發(fā)送序列號N(S)。第二字節(jié)中的第一位是輪詢/終止(Poll/Final)位，如LLC-Type 2規(guī)范所定義的。其余7位代表發(fā)送者的接收序列號N(R)。
在圖1C中，示出了標(biāo)志字段14中的各個標(biāo)志。這些標(biāo)志從最高有效位到最低有效位包括用于指示協(xié)議版本號的兩個位(VERS)、三個存儲器管理標(biāo)志(HM、NB和EOD)以及緊急數(shù)據(jù)標(biāo)志(URG)。HM標(biāo)志指示是否支持硬件存儲器管理(Hardware Memory management)。如果設(shè)置該標(biāo)志，則認(rèn)為NB和EOD標(biāo)志有效。新緩沖區(qū)(New Buffer，NB)標(biāo)志指示在接收機(jī)處必須分配新緩沖區(qū)，以保存當(dāng)前和后續(xù)的信息幀。數(shù)據(jù)終止(End of Data，EOD)標(biāo)志指示該幀承載了上層數(shù)據(jù)單元的最后片斷，并且因此該數(shù)據(jù)單元可以被傳遞，并且緩沖區(qū)返回空閑池。最后，緊急數(shù)據(jù)標(biāo)志(URG)當(dāng)被設(shè)置時，通知接收ABC實(shí)體該幀所包含的數(shù)據(jù)是緊急的，并且必須不經(jīng)緩沖就傳遞到上層。其余的“保留(Reserved)”位可用于按需添加新的標(biāo)志。
參考圖2A，示出了本發(fā)明的AMC協(xié)議的監(jiān)控幀的頭部的格式。監(jiān)控幀頭部20包括三個字段DSAP、SSAP和控制字段22。監(jiān)控幀頭部的格式除了DSAP和SSAP字段是16位寬度而不是8位寬度之外，基本上與LLC-Type 2協(xié)議的監(jiān)控幀相同。
在圖2B中，示出了控制字段22。根據(jù)一個實(shí)施例，對于每個監(jiān)控幀頭部20，控制字段22的兩個最高有效位被設(shè)置為“10”。隨后的兩個位(SS)標(biāo)識監(jiān)控幀的類型。監(jiān)控幀類型包括接收機(jī)就緒(ReceiverReady，RR)[SS＝00]、接收機(jī)未就緒(Receiver Not Ready，RNR)[SS＝10]以及拒絕(Reject，RJT)[SS＝01]。隨后的四位未被使用，而輪詢/終止位處于與信息幀相同的位置。7個最低有效位被用于代表發(fā)送者的接收序列號N(R)。
參考圖3A，示出了本發(fā)明的ABC協(xié)議所使用的無序號幀的頭部。無序號幀頭部30除了控制字段32只有8位寬度之外，與監(jiān)控幀頭部20類似。如圖3B所示，根據(jù)一個實(shí)施例，前兩個最高有效位總是被設(shè)置為“11”，第15位是輪詢/終止(P/F)位，并且所有其余位(M)都指定無序號幀的類型。下面的表I定義了利用本發(fā)明的ABC協(xié)議所實(shí)現(xiàn)的無序號幀。
表I


XID命令/響應(yīng)只被本發(fā)明的ABC協(xié)議用于傳輸接收機(jī)的窗尺寸(RW)。因此，它使用比LLC-Type 2版本更簡化的格式。對于LLC-Type 2版本，發(fā)送實(shí)體所支持的每個LLC協(xié)議類都必須被列出。圖3C示出了本發(fā)明的XID幀。在控制字段32之后，存在8位的信息字段34。最高有效位被設(shè)置為零。其余的7個位傳送接收實(shí)體的窗尺寸(RW)。
封裝本發(fā)明的ABC協(xié)議獨(dú)立于下層協(xié)議的類型而操作。ABC協(xié)議可以被用在以太網(wǎng)、以太網(wǎng)II、IP或HARD之上。對于HARD的更詳細(xì)解釋，參見前述2002年12月6日Gai Silvano等遞交的題為“Apparatus andMethod for a High Availability Data Network Using Replicated Delivery”的美國申請序列號10/313,745(代理卷號ANDIP023)。
參考圖4，本發(fā)明的ABC協(xié)議40被示出為運(yùn)用在以太網(wǎng)MAC層或IP層之上，兩種情況都帶有HARD或不帶有HARD。下面描述可選地使用HARD協(xié)議高可用性特征的以太網(wǎng)/以太網(wǎng)II幀和IP數(shù)據(jù)報內(nèi)的本發(fā)明的ABC協(xié)議40的封裝。將ABC協(xié)議封裝在IP數(shù)據(jù)報內(nèi)的主要優(yōu)點(diǎn)在于能夠使ABC協(xié)議可路由。缺點(diǎn)在于用于實(shí)現(xiàn)ABC協(xié)議的硬件可能不得不處理IP碎片。
參考圖5A，示出了以太網(wǎng)(或以太網(wǎng)II)幀格式。幀50包括目的地地址(DA)字段52、源地址(SA)字段54、以太網(wǎng)類型(Etype)字段56、數(shù)據(jù)字段58和幀校驗(yàn)序列(FCS)字段59。為了將ABC幀封裝到以太網(wǎng)幀中，需要一種新的以太網(wǎng)類型，以標(biāo)識作為以太網(wǎng)數(shù)據(jù)字段50被攜帶的ABC協(xié)議數(shù)據(jù)單元。在一個實(shí)施例中，將值0xABC1用作ABC的以太網(wǎng)類型。
參考圖5B，示出了在以太網(wǎng)幀50內(nèi)的ABC幀的封裝。E-type字段56被設(shè)置為OxABC1以指定數(shù)據(jù)字段58是由ABC頭部60和ABC有效載荷(payload)62(如果ABC幀是監(jiān)控或無序號幀，則不會出現(xiàn)有效載荷)構(gòu)成的ABC幀。
參考圖5C，示出了以太網(wǎng)幀50內(nèi)的HARD幀內(nèi)的ABC幀的封裝。E-type 56(a)被設(shè)置為OxABC0以指示以太網(wǎng)數(shù)據(jù)字段58是HARD幀。HARD頭部64包含以太網(wǎng)類型字段56(b)，該字段已經(jīng)被設(shè)置為0xABC1以指示HARD有效載荷66是由ABC頭部60和ABC有效載荷62構(gòu)成的ABC幀。
參考圖6A，示出了IP數(shù)據(jù)報內(nèi)的ABC幀的封裝。數(shù)據(jù)報70包括IP頭部72、ABC協(xié)議頭部74以及在IP和ABC協(xié)議頭部之間的通用路由封裝(Generic Routing Encapsulation，GRE)頭部76。由于無法定義ABC的IP協(xié)議類型，因此GRE頭部76被包括進(jìn)來以指示特定IP數(shù)據(jù)報正在承載ABC幀。GRE頭部76包括以太網(wǎng)協(xié)議類型字段84，用于保存將在IP數(shù)據(jù)報內(nèi)承載的協(xié)議類型。在這種情況下，由于正在承載ABC協(xié)議，因此以太網(wǎng)協(xié)議類型字段84被設(shè)置為0xABC1。
參考圖6B，示出了在IP數(shù)據(jù)報內(nèi)的HARD幀內(nèi)的ABC幀的封裝。IP數(shù)據(jù)報90包括IP頭部72、ABC協(xié)議頭部74、GRE頭部76和HARD頭部92。HARD頭部包括序列號字段94、源ID字段96、協(xié)議類型字段98。在這種情況下，GRE頭部76中的以太網(wǎng)協(xié)議類型字段84被設(shè)置為0xABC0，以指示HARD分組被封裝在IP數(shù)據(jù)報中。接著，HARD頭部92中的協(xié)議類型字段98被設(shè)置為0xABC1，以指示ABC幀74被封裝在HARD分組中。對于HARD的更多信息，參見前述共同待決申請“Apparatus and Method for a High Availability Data Network UsingReplicated Delivery”，其通過引用結(jié)合于此。
ABC協(xié)議操作ABC協(xié)議操作與第2部分(Logic Link Control，ANSI/IEEE Std.802.2，1998版)的XX節(jié)所描述的LLC-Type 2協(xié)議完全相同。
流控制流控制是一種端對端的機(jī)制，其目的在于防止分組在接收節(jié)點(diǎn)處由于快速發(fā)送節(jié)點(diǎn)所導(dǎo)致的緩沖區(qū)溢出狀況而被丟棄。ABC具有兩種內(nèi)置的流控制機(jī)制典型的LLC-2的滑動窗，以及基于接收機(jī)就緒(RR)和接收機(jī)未就緒(RNR)監(jiān)控幀的“停和走”機(jī)制。單單使用滑動窗機(jī)制通常不足以控制發(fā)送節(jié)點(diǎn)的流速率。實(shí)際上，如果一接收到信息幀就產(chǎn)生幀確認(rèn)，則發(fā)射機(jī)被告知在接收機(jī)處可獲得更多緩沖區(qū)空間，但是實(shí)際上并非如此，至少在接收節(jié)點(diǎn)處的應(yīng)用已經(jīng)從緩沖區(qū)中移走數(shù)據(jù)之前并非如此。因?yàn)榘l(fā)送節(jié)點(diǎn)將被允許一接收到確認(rèn)，就發(fā)送更多信息幀，所以這種情況會導(dǎo)致接收節(jié)點(diǎn)的緩沖區(qū)的溢出狀況。
為了避免上述問題，將ABC協(xié)議的滑動窗與停和走機(jī)制結(jié)合起來。參考圖7，示出了圖120，該圖示出了ABC協(xié)議所使用的停和走機(jī)制。圖120沿x軸示出被記作“C”的緩沖區(qū)容量、低水平閾值tL和高水平閾值tH。沿著圖的y軸示出RNR和RR幀。當(dāng)緩沖區(qū)水平低于tL時，許多緩沖區(qū)空間可用，并且不運(yùn)用流控制。隨著用量增加，最終超過tH閾值。當(dāng)超過tH閾值時，RNR監(jiān)控幀被發(fā)射到發(fā)送節(jié)點(diǎn)，以停止其發(fā)送。根據(jù)一個實(shí)施例，tH閾值被設(shè)置為充分低于緩沖區(qū)容量C，以便為在RNR監(jiān)控幀被發(fā)射之后可能在運(yùn)送中的分組保留一些緩沖區(qū)空間。隨著在接收節(jié)點(diǎn)處的消耗應(yīng)用清空緩沖區(qū)，緩沖區(qū)用量的水平最終將低于tL閾值。這時，RR幀被發(fā)射到發(fā)送節(jié)點(diǎn)，并且再繼續(xù)分組的傳輸。圖120從而定義了由閾值tH和tL管理的滯后周期。該周期防止系統(tǒng)在發(fā)送和靜止?fàn)顟B(tài)之間振蕩，這種振蕩將由于RNR和RR監(jiān)控幀的頻繁傳輸而嚴(yán)重增加網(wǎng)絡(luò)的全局開銷。
在另一實(shí)施例中，如果對ABC協(xié)議操作(如LLC-Type 2操作所定義的)進(jìn)行簡單改變，則可以避免上述停和走機(jī)制。所述改變在于僅當(dāng)通過消耗應(yīng)用/上層協(xié)議從接收節(jié)點(diǎn)的緩沖區(qū)中除去相應(yīng)信息幀時，才產(chǎn)生確認(rèn)幀。這樣一來，只有當(dāng)新空間實(shí)際可用時，才向發(fā)射機(jī)通知緩沖區(qū)空間的可用性。
擁塞控制當(dāng)多個流量流共享同一鏈路時，總會有擁塞的可能。擁塞發(fā)生在每個流的帶寬和超過鏈路的容量時。當(dāng)發(fā)生擁塞時，支持鏈路的緩沖區(qū)開始充滿。最終，當(dāng)超出緩沖區(qū)容量時發(fā)生溢出狀況，導(dǎo)致丟棄傳入的分組。利用ABC協(xié)議，將盡可能避免分組丟棄。由于ABC采用退回N(go-back-N)重傳方案(即，在未接收到確認(rèn)的幀之后發(fā)送的所有幀都與丟失的分組一起重傳)，因此每個被丟棄的幀都可能導(dǎo)致完整的數(shù)據(jù)窗被重傳，這樣，使擁塞問題加劇。為了應(yīng)對擁塞，LLC-Type 2協(xié)議已經(jīng)設(shè)置了擁塞控制機(jī)制(參見LLC-Type 2規(guī)范的附件C)，但是這樣的機(jī)制似乎不夠充分和有效。因此，ABC協(xié)議用得自TCP協(xié)議擁塞控制技術(shù)的更有效且高效的機(jī)制來代替LLC-Type 2機(jī)制。
每個ABC發(fā)送節(jié)點(diǎn)為每個連接維護(hù)四個狀態(tài)變量當(dāng)前發(fā)送窗(send_window)“snd_wnd”、擁塞窗“cwnd”、慢啟動閾值“ssthresh”和確認(rèn)幀計(jì)數(shù)“ack_cnt”。發(fā)送窗與上述參考圖7所描述的停和走機(jī)制聯(lián)合用于實(shí)現(xiàn)端對端的流控制機(jī)制。發(fā)送窗的目的是保持跟蹤接收機(jī)在任何給定時刻能夠接受的幀的數(shù)量。而擁塞窗定義了在任何給定時刻，允許發(fā)送者發(fā)送的信息幀的最大數(shù)量。在發(fā)送任何分組之前，ABC發(fā)送節(jié)點(diǎn)檢查兩個窗，并且選擇兩個窗中較小的一個。這個較小的值是在這時可被發(fā)送的信息幀的數(shù)量。
參考圖8，示出了ABC擁塞窗的圖。y軸代表擁塞窗，該擁塞窗在一(1)處初始化。x軸代表以往返時間(RTT)為單位所表示的時間。對于每個接收到的確認(rèn)幀，擁塞窗cwnd遞增1。這意味著在正常情況下，擁塞窗隨時間按2的冪增長。這在圖8中被清楚地示出，其中在每個RTT處，擁塞窗遞增一(1)、二(2)、四(4)、八(8)和十六(16)。被稱為“慢啟動”的這個過程持續(xù)，直到擁塞窗到達(dá)慢啟動閾值ssthresh，ssthresh的值已經(jīng)初始被設(shè)置為發(fā)送窗的值。在慢啟動階段期間，發(fā)送節(jié)點(diǎn)將快速到達(dá)信息幀的傳輸只由端對端流控制管理的狀態(tài)，即通過早先描述的發(fā)送窗或通過停和走機(jī)制管理。
但是，當(dāng)發(fā)送者在接收到指示接收機(jī)丟失一幀的REJ幀時推斷出擁塞狀況時，擁塞窗立即“縮回”其初始值(1)，從而允許發(fā)送者只發(fā)送一個信息幀。慢啟動閾值被設(shè)置為當(dāng)前窗(擁塞窗和發(fā)送窗中的最小值)的一半，但是不小于2(在這種情況下ssthresh2＝8)。隨后，擁塞窗再次根據(jù)慢啟動階段隨著再次接收確認(rèn)幀而遞增。但是，這次慢啟動閾值只有8幀，因此，慢啟動階段只持續(xù)三個RTT。這時，擁塞避免階段開始，在該階段期間，對于每個RTT，擁塞窗遞增1。這意味著在擁塞避免階段期間，擁塞窗隨時間線性增長，如圖8所清楚示出的。為了實(shí)現(xiàn)這一點(diǎn)，在擁塞避免階段期間，接收到的確認(rèn)幀數(shù)由變量ack_cnt計(jì)數(shù)，并且當(dāng)其等于擁塞窗時，則意味著一個RTT已經(jīng)過去。擁塞窗被遞增1，并且ack_cnt被復(fù)位為0，以在下一RTT期間對接收到的確認(rèn)幀進(jìn)行計(jì)數(shù)。該過程持續(xù)，直到擁塞窗等于發(fā)送窗，或者檢測到另一擁塞狀況為止。
為了防止多個發(fā)射機(jī)同步，并且都在同一時刻開始重傳(這種狀況非常可能發(fā)生在存儲系統(tǒng)內(nèi)，例如在題為“A Scalable Network AttachedStorage System”的共同待決申請中所描述的存儲系統(tǒng)，其中所有發(fā)射機(jī)觀察到幾乎相同的RTT)，使用了重傳定時器。一旦檢測到擁塞，就啟動重傳計(jì)時器，并且發(fā)送節(jié)點(diǎn)只在該計(jì)時器超時之后才啟動重傳程序。該計(jì)時器的值是從范圍
中選出的隨機(jī)數(shù)，其中RTT是系統(tǒng)中的幀的典型往返時間，N是信息幀的重傳嘗試次數(shù)。N的初始值為0，并且在每次接收到對相同序列號的REJ監(jiān)控幀時被遞增。在成功的重傳之后，或者在接收到對于另一序列號的REJ幀時，N清零。這是與以太網(wǎng)所使用的重傳機(jī)制類似的一種指數(shù)重傳退避(back-off)機(jī)制，已知該機(jī)制有利于避免多個發(fā)射機(jī)的同步。
上述本發(fā)明的實(shí)施例被看作示例性的而非限制性的。本發(fā)明并不局限于這里所給出的細(xì)節(jié)，而是可以在所附權(quán)利要求的范圍和等同物內(nèi)對本發(fā)明進(jìn)行修改。
權(quán)利要求
1.一種裝置，包括用在數(shù)據(jù)網(wǎng)絡(luò)中的基于分組的傳輸協(xié)議，所述基于分組的傳輸協(xié)議獨(dú)立于所述網(wǎng)絡(luò)使用的下層物理層而操作。
2.根據(jù)權(quán)利要求1所述的裝置，其中，所述協(xié)議定義至少三種不同類型的幀，包括信息幀、監(jiān)控幀和無序號幀。
3.根據(jù)權(quán)利要求1所述的裝置，其中，所述信息幀頭部包含以下字段目的地服務(wù)接入點(diǎn)字段，被配置為標(biāo)識所述網(wǎng)絡(luò)中的目的地節(jié)點(diǎn)的協(xié)議連接；源服務(wù)接入點(diǎn)字段，被配置為標(biāo)識所述網(wǎng)絡(luò)中的源節(jié)點(diǎn)的協(xié)議連接；控制字段，被配置為承載序列號和控制信息；標(biāo)志字段，被配置為維護(hù)一個或多個標(biāo)志；源端口，被配置為標(biāo)識源應(yīng)用；和目的地端口，被配置為標(biāo)識目的地應(yīng)用。
4.根據(jù)權(quán)利要求3所述的裝置，其中，所述目的地服務(wù)接入點(diǎn)和源服務(wù)接入點(diǎn)字段每個是16位長的，其中所述兩個字段中都分別有一個位用于標(biāo)識是個人還是組地址，并且其余15個位用于尋址。
5.根據(jù)權(quán)利要求3所述的裝置，其中，所述信息幀的所述控制字段具有一個位，被設(shè)置為指示該幀是信息幀；第一組位，用于標(biāo)識發(fā)送者的發(fā)送序列號；第二組位，用于標(biāo)識所述發(fā)送者的接收序列號；和輪詢/終止位。
6.根據(jù)權(quán)利要求3所述的裝置，其中，所述標(biāo)志字段包括用于以下字段中的一個或多個字段的標(biāo)志版本字段、存儲器管理字段和緊急字段。
7.根據(jù)權(quán)利要求2所述的裝置，其中，所述監(jiān)控幀包含以下類型字段中的一個或多個目的地服務(wù)接入點(diǎn)字段，被配置為標(biāo)識所述網(wǎng)絡(luò)中的目的地節(jié)點(diǎn)的協(xié)議連接；源服務(wù)接入點(diǎn)字段，被配置為標(biāo)識所述網(wǎng)絡(luò)中的源節(jié)點(diǎn)的協(xié)議連接；和控制字段，被配置為承載序列號和控制信息。
8.根據(jù)權(quán)利要求7所述的裝置，其中，所述目的地服務(wù)接入點(diǎn)和源服務(wù)接入點(diǎn)字段每個是16位長的，其中所述兩個字段中都分別有一個位用于標(biāo)識是個人還是組地址，并且其余15個位用于尋址。
9.根據(jù)權(quán)利要求8所述的裝置，其中，所述監(jiān)控幀的所述控制字段具有兩個位，被設(shè)置為指示該幀是監(jiān)控幀；第一組位，用于標(biāo)識監(jiān)控幀類型；第二組位，用于標(biāo)識發(fā)送者的接收序列號；和輪詢/終止位。
10.根據(jù)權(quán)利要求2所述的裝置，其中，所述無序號幀包含以下類型字段中的一個或多個目的地服務(wù)接入點(diǎn)字段，被配置為標(biāo)識所述網(wǎng)絡(luò)中的目的地節(jié)點(diǎn)的協(xié)議連接；源服務(wù)接入點(diǎn)字段，被配置為標(biāo)識所述網(wǎng)絡(luò)中的源節(jié)點(diǎn)的協(xié)議連接；和控制字段，被配置為承載控制信息。
11.根據(jù)權(quán)利要求10所述的裝置，其中，所述目的地服務(wù)接入點(diǎn)和源服務(wù)接入點(diǎn)字段每個是16位長的，其中所述兩個字段中都分別有一個位用于標(biāo)識是個人還是組地址，并且其余15個位用于尋址。
12.根據(jù)權(quán)利要求10所述的裝置，其中，所述控制字段被配置為承載以下控制命令或響應(yīng)中的一個或多個設(shè)置異步平衡模式擴(kuò)展命令；斷開命令，用于斷開連接；無序號確認(rèn)響應(yīng)，用于應(yīng)答設(shè)置異步平衡模式擴(kuò)展命令或斷開命令；斷開模式響應(yīng)，用于在尚未啟動連接時應(yīng)答非設(shè)置異步平衡模式擴(kuò)展命令；幀拒絕響應(yīng)，用于在錯誤狀況之后恢復(fù)操作；交換/標(biāo)識命令/響應(yīng)，用于協(xié)商所述網(wǎng)絡(luò)中的接收節(jié)點(diǎn)的窗尺寸；和測試命令/響應(yīng)，用于核實(shí)所述網(wǎng)絡(luò)中的遠(yuǎn)程節(jié)點(diǎn)狀態(tài)。
13.根據(jù)權(quán)利要求12所述的裝置，其中，所述交換/標(biāo)識命令/響應(yīng)的格式包括控制字段和用于定義所述接收節(jié)點(diǎn)的窗尺寸的字段。
14.根據(jù)權(quán)利要求1所述的裝置，其中，所述協(xié)議還被配置為直接在以太網(wǎng)或以太網(wǎng)II幀之上進(jìn)行封裝，在所述以太網(wǎng)或以太網(wǎng)II幀上被封裝的協(xié)議幀包括目的地地址字段、源地址字段、數(shù)據(jù)字段、以太網(wǎng)類型字段和協(xié)議頭部字段。
15.根據(jù)權(quán)利要求1所述的裝置，其中，所述協(xié)議還被配置為在以太網(wǎng)或以太網(wǎng)II幀之上的HARD上進(jìn)行封裝，在所述以太網(wǎng)或以太網(wǎng)II幀之上的HARD上被封裝的協(xié)議幀包括目的地地址字段、源地址字段、數(shù)據(jù)字段、以太網(wǎng)類型字段、HARD字段和協(xié)議頭部字段。
16.根據(jù)權(quán)利要求1所述的裝置，其中，所述協(xié)議還被配置為在IP協(xié)議之上的通用路由封裝協(xié)議上進(jìn)行封裝，包括校驗(yàn)和存在字段C、保留字段、版本字段和指示所述被封裝協(xié)議是ABC的以太網(wǎng)協(xié)議類型字段。
17.根據(jù)權(quán)利要求1所述的裝置，其中，所述協(xié)議還被配置為在IP協(xié)議之上的通用路由封裝協(xié)議上的HARD協(xié)議上進(jìn)行封裝，所述HARD協(xié)議包括序列號字段、源ID字段和指示所述被封裝協(xié)議是ABC的協(xié)議類型字段，并且所述通用路由封裝協(xié)議包括校驗(yàn)和存在字段C、保留字段、版本字段和指示所述被封裝協(xié)議是HARD的以太網(wǎng)協(xié)議類型字段。
18.根據(jù)權(quán)利要求1所述的裝置，還包括流控制機(jī)制，所述流控制機(jī)制被配置為控制在所述網(wǎng)絡(luò)中的發(fā)送節(jié)點(diǎn)和接收節(jié)點(diǎn)之間的分組流。
19.根據(jù)權(quán)利要求1所述的裝置，其中，在接收節(jié)點(diǎn)處的流控制機(jī)制當(dāng)用于緩沖在所述接收節(jié)點(diǎn)處接收到的分組的接收緩沖區(qū)超過第一預(yù)定閾值時發(fā)送接收機(jī)未就緒命令，并且當(dāng)被緩沖的分組的數(shù)量落到第二預(yù)定閾值以下時發(fā)送接收機(jī)就緒命令。
20.根據(jù)權(quán)利要求1所述的裝置，還包括擁塞控制機(jī)制，所述擁塞控制機(jī)制被配置為防止所述網(wǎng)絡(luò)中的鏈路上的導(dǎo)致分組可能被丟棄的溢出狀況。
21.根據(jù)權(quán)利要求20所述的裝置，其中，所述擁塞控制機(jī)制被配置為當(dāng)指示出接收節(jié)點(diǎn)未接收消息的拒絕消息被所述接收節(jié)點(diǎn)接收時，減小由發(fā)送節(jié)點(diǎn)發(fā)送的幀的數(shù)量。
22.根據(jù)權(quán)利要求1所述的裝置，其中，所述協(xié)議還被配置為支持比所述協(xié)議更高層的復(fù)用，使得多個應(yīng)用可以共享相同連接。
23.根據(jù)權(quán)利要求1所述的裝置，其中，所述下層物理層包括如下中的一個IEEE 802.3、以太網(wǎng)、以太網(wǎng)II、HARD或IP。
24.根據(jù)權(quán)利要求6所述的裝置，其中，當(dāng)信息幀的所述緊急字段被設(shè)置時，所述協(xié)議支持緊急數(shù)據(jù)到目的地的傳遞。
25.根據(jù)權(quán)利要求6所述的裝置，其中，當(dāng)信息幀的所述存儲器管理標(biāo)志被設(shè)置時，所述協(xié)議支持硬件存儲器管理和分割。
26.根據(jù)權(quán)利要求16所述的裝置，其中，所述協(xié)議可以在IP網(wǎng)絡(luò)上路由。
27.根據(jù)權(quán)利要求21所述的裝置，其中，退避重傳計(jì)時器被使用，以避免多個發(fā)射機(jī)的同步，其中所有發(fā)射機(jī)都觀察到幾乎相同的往返時間。
全文摘要
公開了一種快速、輕量級、可靠的、基于分組的協(xié)議(ABC)，其獨(dú)立于網(wǎng)絡(luò)下層物理層所用聯(lián)網(wǎng)協(xié)議類型而操作。具體地，該基于分組的協(xié)議獨(dú)立于例如但不局限于MAC、以太網(wǎng)、以太網(wǎng)II、HARD或IP的物理層協(xié)議而操作，或能在其上封裝。協(xié)議定義至少三種不同類型的幀，包括信息幀、監(jiān)控幀和無序號幀。本發(fā)明各實(shí)施例中，信息幀、監(jiān)控幀和無序號幀包括有語義的DSAP和SSAP字段，其足夠大以支持可在網(wǎng)絡(luò)上使用的各種物理層協(xié)議。信息幀、監(jiān)控幀和無序號幀還有支持緊急數(shù)據(jù)傳遞和某些存儲器管理功能的能力。該協(xié)議還能夠支持高于該協(xié)議的層復(fù)用，使多個上層應(yīng)用能共享相同連接。最后，本發(fā)明的協(xié)議支持流控制和擁塞控制，以幫助減少在接收節(jié)點(diǎn)或網(wǎng)絡(luò)上丟失或丟棄分組的發(fā)生率。
文檔編號H04L29/06GK1729675SQ200380105301
公開日2006年2月1日 申請日期2003年11月19日 優(yōu)先權(quán)日2002年12月6日
發(fā)明者西爾瓦諾·加伊, 戴維·貝爾加馬斯科, 克勞迪奧·德桑蒂, 丹蒂·瑪拉格里諾, 法彼奧·R·麥諾 申請人:思科技術(shù)公司