• / 50
  • 下載費用:30 金幣  

通道中傳輸數據包的方法、存儲裝置和通道端點.pdf

摘要
申請專利號:

CN200810131178.4

申請日:

2008.07.30

公開號:

CN101360045B

公開日:

2015.01.07

當前法律狀態:

終止

有效性:

無權

法律詳情: 未繳年費專利權終止IPC(主分類):H04L 12/70申請日:20080730授權公告日:20150107終止日期:20160730|||授權|||實質審查的生效|||公開
IPC分類號: H04L12/70(2013.01)I; H04L1/00; H04L1/18; H04L29/06 主分類號: H04L12/70
申請人: 佳能株式會社
發明人: S·巴龍; P·盧梭
地址: 日本東京
優先權: 2007.07.30 FR 07/56817
專利代理機構: 中國國際貿易促進委員會專利商標事務所 11038 代理人: 楊國權
PDF完整版下載: PDF下載
法律狀態
申請(專利)號:

CN200810131178.4

授權公告號:

|||101360045B||||||

法律狀態公告日:

2017.09.15|||2015.01.07|||2009.04.01|||2009.02.04

法律狀態類型:

專利權的終止|||授權|||實質審查的生效|||公開

摘要

公開了通道中傳輸數據包的方法、相應計算機程序產品、存儲裝置和通道端點。提出了在將兩個子網絡互連以形成總通信網絡的通道中傳輸數據包的方法,通道在兩個通道端點之間實現,每個子網絡包括通道端點中的獨特通道端點,通道實現至少兩個傳輸信道,該方法由通道端點中稱為通道進入端點的端點實現。對每個數據包,該方法包括:接收來自與通道進入端點屬于相同的子網絡的源裝置的數據包;根據與包含在接收的包中的凈荷數據相關的協議以及關于與傳輸信道中當前傳輸條件相關聯的傳輸質量的信息,從傳輸信道中選擇有效信道;根據與有效信道相關的傳輸協議,封裝接收的包,用于獲得將被發送的包;和在選擇的有效信道上,傳輸將在通道中發送的包。

權利要求書

1: 一種用于在將兩個子網絡(103,104)互連以便形成總的通 信網絡的通道中(100)進行數據包的傳輸的方法,所述通道在兩個通 道端點(101,102)之間實現,所述子網絡中的每一個包括所述通道 端點之中的獨特通道端點,所述通道實現至少兩個傳輸信道,所述方 法由所述通道端點中稱為通道進入端點的端點來實現,其特征在于, 所述方法包括用于每個數據包的以下步驟: a)接收(1)來自源裝置的所述數據包,該源裝置與通道進入端 點屬于相同的子網絡; b)根據與包含在所述接收的包中的凈荷數據相關的協議以及關 于與所述傳輸信道中當前傳輸條件相關聯的傳輸質量的信息,從傳輸 信道中選擇(3)有效信道; c)根據與有效信道相關的傳輸協議,封裝(5)所述接收的包, 用于獲得將被發送的包;以及 d)在所選擇的有效信道上,傳輸(6)將在通道中發送的包。
2: 如權利要求1所述的方法,其特征在于,所述關于與當前傳 輸條件有關的傳輸質量的信息屬于包括以下項的組: -關于所述傳輸信道的擁塞ECN的信息; -關于所述傳輸信道的誤包率PER的信息;以及 -關于所述傳輸信道的重傳率,即TCP信道重傳率,的信息。
3: 如權利要求1或2所述的方法,其特征在于,所述選擇(3) 有效信道的步驟b)包括以下步驟: i)確定(32)與所述接收的包相關的包類型,每種包類型由與 包含在擁有所述包類型的包中的凈荷數據相關的不同協議來定義; ii)根據關于如下傳輸質量的信息,確定(36)稱為在先優選信 道的優選信道,該在先優選信道對于由通道進入端點發送并具有與所 述接收的包相同類型的先前發送的包實現最佳傳輸,其中,所述傳輸 質量與對于所述先前發送的包獲得的所述傳輸信道上的傳輸條件有 關; iii)獲得(34)所述關于與所述傳輸信道上的當前傳輸條件相關 聯的傳輸質量的信息; iv)根據與所接收的包相關的包類型以及所述至少一條關于與當 前傳輸條件相關聯的傳輸質量的信息,選擇(35)實現所述接收的包 的最佳傳輸的、稱為新的優選信道的信道;以及 v)根據在先優選信道、新的優選信道以及與所述接收的包相關 的包類型,選擇(38)所述有效信道。
4: 如權利要求3所述的方法,其特征在于,如果對于與所述接 收的包相關的數據類型,在先優選信道不同于新的優選信道,則通過 對于與所述接收的包相關的包類型從所述在先優選信道平滑切換 (363,364)到所述新的優選信道的機制而得到對有效信道的選擇。
5: 如權利要求1到4中的任何一個所述的方法,其特征在于, 通過下面的兩個信道來實現所述選擇有效信道的步驟: -稱為TCP信道的第一信道,其相關的傳輸協議是TCP協議; 以及 -稱為UDP信道的第二信道,其相關的傳輸協議是UDP協議。
6: 如權利要求3和5所述的方法,其特征在于,假設所接收的 包是UDP類型的包,如果關于與當前傳輸條件相關聯的傳輸質量的所 述信息指示所述傳輸信道的擁塞,則用于所述接收的包的新的優選信 道是UDP信道(359),以及如果關于與當前傳輸條件相關聯的傳輸 質量的所述信息沒有指示所述傳輸信道的任何擁塞,則用于所述接收 的包的新的優選信道是TCP信道(358)。
7: 如權利要求3和5所述的方法,其特征在于,假設所接收的 包是UDP類型的包,如果關于與當前傳輸條件相關聯的傳輸質量的所 述信息指示所述傳輸信道的擁塞,則所述接收的包的新的優選信道是 UDP信道(359),以及如果關于與當前傳輸條件相關聯的傳輸質量 的所述信息指示誤包率在確定的閾值以下,則用于所述接收的包的新 的優選信道是TCP信道(358),以及如果關于與當前傳輸條件相關 聯的傳輸質量的所述信息指示所述傳輸信道的誤包率大于或等于所述 確定的閾值,則用于所述接收的包的新的優選信道是UDP信道(359)。
8: 如權利要求3和5所述的方法,其特征在于,假設所接收的 包是TCP類型的包,如果關于與當前傳輸條件相關聯的傳輸質量的所 述信息指示所述傳輸信道的重傳率在確定的閾值之上,則用于所述所 接收的包的新的優選信道是UDP信道(359),以及如果關于與當前 傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的傳輸速率 低于或等于所述確定的閾值,則用于所述接收的包的新的優選信道是 TCP信道(358)。
9: 一種可從通信網絡下載和/或記錄在計算機可讀載體上和/或可 由處理器執行的計算機程序產品,其特征在于,所述計算機程序產品 包括程序代碼指令,當所述程序在計算機上執行時,所述程序代碼指 令用于實現根據權利要求1到8中的至少一個的方法。
10: 一種能總體或局部分離的存儲裝置,其可由計算機讀取以及 存儲一組指令,所述指令能由所述計算機執行,以實現根據權利要求 1到8中的至少一個的方法。
11: 一種通道進入端點,其能夠在將兩個子網絡互連以便形成總 的通信網絡的通道中實現數據包的傳輸,所述通道在所述通道進入端 點與通道離開端點之間被實現,所述子網絡中的每一個包括所述通道 端點中的一個獨特通道端點,所述通道實現至少兩個傳輸信道, 其特征在于,所述通道進入端點包括: -用于接收來自源裝置的數據包的裝置,該源裝置與通道進入端 點屬于相同的子網絡; -用于根據與包含在所述接收的包中的凈荷數據相關的協議以 及關于與所述傳輸信道中當前傳輸條件相關聯的傳輸質量的信息從傳 輸信道中選擇有效信道的裝置; -用于根據與有效信道相關的傳輸協議來封裝所述接收的包以 用于獲得將被發送的包的裝置;以及 -用于在所選擇的有效信道上傳輸將在通道中發送的包的裝置。
12: 如權利要求11所述的通道進入端點,其特征在于,所述關 于與當前傳輸條件有關的傳輸質量的信息屬于包括以下項的組: -關于所述傳輸信道的擁塞的信息; -關于所述傳輸信道的誤包率的信息;以及 -關于所述傳輸信道的重傳率的信息。
13: 如權利要求11和12中的任何一個所述的通道進入端點,其 特征在于,所述選擇有效信道的裝置包括: -用于確定與所述接收的包相關的包類型的裝置,每種包類型由 與包含在擁有所述包類型的包中的凈荷數據相關的不同協議來定義; -用于根據關于如下傳輸質量的信息確定稱為在先優選信道的 優選信道的裝置,該在先優選信道對于由通道進入端點發送并具有與 所述接收的包相同類型的先前發送的包實現最佳傳輸,其中,所述傳 輸質量與對于所述先前發送的包獲得的所述傳輸信道上的傳輸條件有 關; -用于獲得所述關于與所述傳輸信道上的當前傳輸條件相關聯 的傳輸質量的信息的裝置; -用于根據與所接收的包相關的包類型以及所述至少一條關于 與當前傳輸條件相關聯的傳輸質量的信息來選擇實現所述接收的包的 最佳傳輸的、稱為新的優選信道的信道的裝置;以及 -用于根據在先優選信道、新的優選信道以及與所述接收的包相 關的包類型來選擇所述有效信道的裝置。
14: 如權利要求11到12中的任何一個所述的通道進入端點,其 特征在于,通過與每個信道相關的傳輸協議以及所述傳輸協議的輸入 和輸出端口來唯一地標識每個信道。
15: 如權利要求11到14中的任何一個所述的通道進入端點,其 特征在于,從中選擇有效信道的所述傳輸信道是下面的兩個信道: -稱為TCP信道的第一信道,其相關的傳輸協議是TCP協議; 以及 -稱為UDP信道的第二信道,其相關的傳輸協議是UDP協議。
16: 如權利要求13和15所述的通道進入端點,其特征在于,所 述選擇有效信道的裝置是這樣的,即:假設所接收的包是UDP類型的 包,如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述 傳輸信道的擁塞,則用于所述接收的包的新的優選信道是UDP信道, 以及如果關于與當前傳輸條件相關聯的傳輸質量的所述信息沒有指示 所述傳輸信道的任何擁塞,則用于所接收的包的新的優選信道是TCP 信道。
17: 如權利要求13和15所述的通道進入端點,其特征在于,所 述選擇有效信道的裝置是這樣的,即:假設所接收的包是UDP類型的 包,如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述 傳輸信道的擁塞,則所述接收的包的新的優選信道是UDP信道,以及 如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示誤包率在 確定的閾值以下,則用于所述接收的包的新的優選信道是TCP信道, 以及如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述 傳輸信道的誤包率大于或等于所述確定的閾值,則用于所述接收的包 的新的優選信道是UDP信道。

說明書


通道中傳輸數據包的方法、存儲裝置和通道端點

    【技術領域】

    本發明的技術領域是通信網絡的技術領域。

    更具體地說,本發明涉及一種用于在通過通信網絡的通道中傳輸數據包(也稱為數據報)的技術。

    一方面,高比特率互聯網在民眾中得到普及,另一方面,出現了具有網絡連接性的廣泛傳播的消費者視聽設備,這兩方面將創建對于用戶部分的新的行為方式。這些新的行為方式毫無疑問地涉及屬于具有共同興趣(休閑、家庭等)的人群(我們可將其稱作“持久聯系”的群體)的個人的出現。這些群體將與相同興趣領域的其他個人建立幾乎永久性的聯系,他們建立音頻和/或視頻通信,并共享各種信息(音頻、視頻、圖片、文本等)。

    虛擬專用網絡(VPN)的技術正在提供針對上述預期的有價值的解決方案。VPN能夠在使用可靠性低但并不昂貴的互聯網體系結構時,以安全的方式在共享相同興趣領域的個人之間實現實時的透明通信。

    為了進行透明的通信并克服對不可路由地址的需要,VPN使用稱為隧穿(tunneling)的特定類型的封裝,其創建所謂的通道(tunnel)。該操作在于借助封裝協議C來以B級別協議(傳輸協議)封裝A級別協議(乘客協議,passenger?protocol),其中,在諸如ISO模型(其描述了由各個層中的每一層提供的服務以及它們的互相作用)的分層模型中,B協議的層(級別)高于或等于A協議的層(級別)。

    因此,傳輸協議處理乘客協議,就好像其是凈荷數據一樣。圖2b(以下將詳細描述)呈現了級別2的VPN的示例,即,級別-2通道中的封裝的例子(級別-2通道表示乘客協議是ISO模型的層2的協議)。

    隧穿可用于在不支持網絡協議的網絡上傳輸該網絡協議。隧穿還可用于提供不同類型的VPN功能,諸如作為示例的個人尋址。

    現在,承擔遠程接入的消費者功能以及本地局域網(LAN)正逐漸使用隧穿技術。

    在以下的描述中,作為示例,我們考慮的僅是傳輸層的級別高于或等于4的級別2或級別3(即,至少為傳輸層在ISO模型中的級別)。

    VPN頻繁地用于將兩個LAN互連,以便創建由兩個原始LAN的聯合體形成的虛擬局域網。安全的VPN包括加密技術和認證算法,以確保傳輸的數據的私密性。在圖1a(以下將詳細描述)中示出基于隧穿技術的典型VPN配置。在該示例中,通道端點沒有集成到網關中。在兩個通道端點之間建立通道,由本地通道端點對發送到與遠程LAN連接的設備的每個包(也成為幀)進行封裝,然后,所述每個包被發送到將對其進行解封裝并在遠程LAN上進行發送的遠程通道端點。關于所述設備,它們虛擬地鏈接到相同的LAN。兩個設備之間通過通道進行的通信也稱為點對點通信。

    背景技術

    在決定在兩個通道端點之間建立通道的情況下出現的首要問題之一是要知道所述通道的傳輸協議應該是哪個。

    在現有技術中,主要使用層3IP(互聯網協議)或層4TCP/UDP(傳輸控制協議/用戶數據報協議)。由于基于IP的隧穿技術不能考慮網絡地址翻譯(NAT)機制,并且它們沒有全部與圖1的典型隧穿配置兼容,所以在說明書的剩余部分中,我們考慮(僅作為示例)基于層4(傳輸層)(即,基于TCP或UDP)的解決方案。

    TCP協議是面向連接的可靠協議,其向發送方確保他或她的數據將被有效地接收(確認的管理),并且所有的幀按照給定順序被接收。TCP應用有效的擁塞控制機制。

    UDP協議是一種更簡單并且更快速的協議,它不考慮幀的順序,也不管理確認。

    在這種特定情況下(其作為示例被單獨指出),上述問題變為知曉應該將TCP還是UDP用作通道的傳輸協議的問題。

    問題在于:與乘客協議中使用的數據相應的協議可干擾通道中以傳輸協議實現的機制。例如,如果我們將TCP作為傳輸協議,并將TCP作為與乘客協議的凈荷數據相應的協議(稱為TCP上的TCP(TCP?over?TCP)的組合),我們要面臨兩種TCP擁塞控制機制之間破壞性的相互作用。對于進一步的細節,可具體參考“UnderstandingTCP?over?TCP:effects?of?TCP?tunnelling?on?end-to-end?throughput?andlatency(O?Honda,H?Ohsaki,M.Imase,M.Ishizuka,J.Murayama).(Proceedings?of?the?SPIE,volume?6011,pp?138-146(Oct?2005)”。

    第一反應可能認為TCP上的TCP組合不是一個好的解決方案。然而,即使在特定條件下公知的是:上述類型的隧穿使得點對點的性能下降,但是在其它條件下,同樣的組合改進了點對點的性能(例如,參見上述示例以及以下文獻:“Avoiding?congestion?collapse?on?theInternet?using?TCP?tunnels(B.P.Lee,R.K.Balan,L.Jacob,W.K.G?Seah,A.L?Ananda)(Computer?Networks?39(2002)pages?207-219,Dec2002)”)。同樣的問題伴隨“UDP上的UDP(UDP?over?UDP)”組合(即,當我們將UDP協議作為傳輸協議,并將UDP作為乘客協議時)而出現。

    因此,沒有針對上述問題(即,將在通道中使用的傳輸協議是哪一個)的絕對性應對,因為這必須取決于三個因素:

    -將通過通道發送的數據的類型(與乘客協議的凈荷數據相應的協議)、應用的類型(文件的傳送、音頻和/或視頻流傳輸等);

    -兩個通道端點之間的網絡質量(在幀丟失或損壞、擁塞等方面);以及

    -用戶和/或管理員的偏好(在帶寬、可靠性、抖動等方面)。

    目前,當決定在兩個通道端點之間建立通道時,必須強制性地對傳輸協議進行預定的選擇(即,假設每個信道使用不同的傳輸協議,則對通道中的信道進行預定的選擇),盡管該選擇并不是所有解決方案中的最佳選擇。

    在第6614800號美國專利文獻中描述的已知技術使用兩個虛擬專用網絡(VPN),即,兩個通道:用于控制數據的第一通道(在兩個IP地址之間)、用于凈荷數據的第二通道(在另兩個IP地址之間)。這一技術使得能夠選擇用于控制數據的第一傳輸協議以及用于凈荷數據的第二傳輸協議,所述兩種類型的數據通過兩個不同的通道。因此,可在兩個信道中的每一個上優化對傳輸協議的選擇。

    然而,所述技術具有兩個主要缺點:其要求有兩個通道(兩對IP地址),以及每種類型的數據(控制數據和凈荷數據)總是使用相同的傳輸協議。因此,對于所考慮的數據類型,所述選擇不是在每種解決方案中都是最佳的(下面,我們將會討論)。

    【發明內容】

    本發明在至少一個實施例中的目的特別是克服現有技術的不同缺點。

    更具體地說,在本發明的至少一個實施例中,本發明的目標在于提供一種在通道中進行數據包傳輸的技術,通過該技術可優化傳輸信道的選擇。

    本發明在至少一個實施例中的另一目標在于避免將在通道的信道上發送的數據質量的突發改變,所述突發改變會導致所述信道上進行的傳輸的劣化。

    本發明的至少一個實施例還旨在提供一種實現簡單并且成本低的技術。

    本發明至少一個實施例的另一目的在于提供一種能夠在通道端點中實現并由此對于源設備和目的地設備透明的技術。

    在本發明的特定實施例中,提出一種用于在將兩個子網絡互連以便形成總的通信網絡的通道中進行數據包的傳輸的方法,所述通道在兩個通道端點之間實現,所述子網絡中的每一個包括所述通道端點之中的獨特通道端點,所述通道實現至少兩個傳輸信道,所述方法由所述通道端點之一(稱為通道進入端點)來實現。對于每個數據包,所述方法包括以下步驟:

    a)接收來自源裝置的所述數據包,該源裝置與通道進入端點屬于相同的子網絡;

    b)根據與包含在所述接收的包中的凈荷數據相關的協議以及關于與所述傳輸信道中當前傳輸條件相關聯的傳輸質量的信息,從傳輸信道中選擇有效信道;

    c)根據與有效信道相關的傳輸協議,封裝所述接收的包,用于獲得將被發送的包;以及

    d)在所選擇的有效信道上,傳輸將在通道中發送的包。

    因此,本發明總的原理在于:執行動態的多信道隧穿,即,使用多信道通道(例如由其傳輸協議并在可能的情況下由一對輸入/輸出端口來定義每個信道),以及對于將在通道上發送的每個數據包選擇通道的信道中的一個。

    通過這種方式,所使用的有效信道(以及相應的傳輸協議)總是最佳的。

    必須注意到:選擇有效傳輸信道的步驟是基于來自源裝置的數據包類型(即,包含在所述包中的凈荷數據的協議)以及關于網絡上傳輸質量的返回信息兩者的。

    有利地,所述關于與當前傳輸條件有關的傳輸質量的信息屬于包括以下項的組:

    -關于所述傳輸信道的擁塞的信息(ECN);

    -關于所述傳輸信道的誤包率(PER)的信息;以及

    -關于所述傳輸信道的重傳率(TCP信道重傳率)的信息。

    選擇信道的準則可基于所述列表的一個元素或多個組合的元素。上述列表并不是窮盡的。

    對于關于網絡擁塞的信息,作為示例,我們使用如“RFC?3168-The?Addition?of?Explicit?Congestion?Notification(ECN)to?IP”中特別描述的ECN(明確擁塞通知)。

    誤包率也稱為PER。

    有利地,所述選擇有效信道的步驟b)包括以下步驟:

    i)確定與所述接收的包相關的包類型,每種包類型由與包含在擁有所述包類型的包中的凈荷數據相關的不同協議來定義;

    ii)根據關于如下傳輸質量的信息,確定稱為在先優選信道的優選信道,其對于由通道進入端點發送并具有與所述接收的包相同類型的先前發送的包實現最佳傳輸,其中,所述傳輸質量與對于所述先前發送的包獲得的所述傳輸信道上的傳輸條件有關;

    iii)獲得所述關于與所述傳輸信道上的當前傳輸條件相關聯的傳輸質量的信息;

    iv)根據與所接收的包相關的包類型以及所述至少一條關于與當前傳輸條件相關聯的傳輸質量的信息,選擇實現所述接收的包的最佳傳輸的信道(稱為新的優選信道);以及

    v)根據在先優選信道、新的優選信道以及與所述接收的包相關的包類型,選擇所述有效信道。

    重要的是:有效傳輸信道能夠暫時與新的優選信道不同(例如,在對網絡上的傳輸條件進行修改之后優選信道發生改變的情況下)。

    例如,如果所接收的包是IP數據報,則術語“與包含在包中的凈荷數據相關的協議”被理解為是指與所述IP數據報的凈荷數據相關的ISO模型的傳輸層(級別)協議(諸如TCP或UDP)。不應把所述與凈荷數據相關的ISO模型傳輸層(或級別)協議錯認為是與通道的每個傳輸信道相關的傳輸協議。

    根據有利特征,如果對于與所述接收的包相關的數據類型,在先優選信道不同于新的優選信道,則通過對于與所述接收的包相關的包類型從所述在先優選信道平滑切換到所述新的優選信道的機制而產生對有效信道的選擇。

    平滑切換的機制防止將在信道上發送的數據的量產生突然變化,該變化會導致傳輸的劣化。

    例如,在從UDP信道切換到TCP信道(即,從傳輸協議為TCP協議的信道切換到傳輸協議是UDP協議的信道)期間,如果TCP信道上的所有包被立即切換過去,而不考慮要與TCP信道的TCP(擁塞)窗口的兼容,則不能立即發送的包將被延遲(或緩沖),從而產生這些包的RTT(往返時間)的虛假增長,其結果可能甚至需要重傳特定包,其中,假設乘客協議是TCP協議,則所述特定的重傳包將具有災難性的效果。很清楚,由于引入虛假干擾,所以所有預計的從UDP信道切換到TCP信道的好處將丟失,以及所進行的所有操作將是事情變得更為糟糕。

    類似地,不經過控制地從TCP信道切換到UDP信道將阻礙傳輸媒介,這是因為,不應忘記的是不同的傳輸信道共享對互聯網的相同物理接入。在從TCP信道改變到UDP信道的情況下,由于UDP信道上的吞吐量迅速增長,會高度損害在TCP信道上緩沖并被設計為將在TCP信道上發送的包。因此,有必要建立漸進系統,用于將由TCP信道使用的帶寬轉移到UDP信道。利用這種系統,使得在TCP信道上緩沖的包有時間流動得足夠多,以使得當在新的信道(UDP信道)上發送全體包時,沒有包會受到損害。

    有利地,對于每種類型的包,所述平滑切換機制包括如下步驟:對于所述信道中的每一個管理最大傳輸窗口,其指示在給定的時間間隔期間,可在所述信道上發送的數據的最大數量。

    因此,通道的每個傳輸信道具有這樣的傳輸窗口,其用于定義在給定的時間間隔期間可通過通道端點在所述信道上發送的數據的最大數量。

    根據有利特征,在給定的時間間隔期滿之后,新的優選信道的最大傳輸窗口增加,以及在先優選信道的最大傳輸窗口變小,這表示在新的給定時間間隔期間能夠在所述信道上發送的數據的新的最大數量。

    因此,這確保了能夠在傳輸信道上發送的數據的最大數量隨著時間而改變,從而共同確保從一個信道(在先優選信道)到另一信道(新的優選信道)的平滑切換。

    根據優選特征,有效信道為:

    -在傳輸窗口的限制之內的新的優選信道,所述傳輸窗口與用于與所接收的包相關的包類型的所述新的優選信道相關,或者

    -在超出所述傳輸窗口的情況下為在先優選信道,所述傳輸窗口與用于與所接收的包相關的包類型的所述新的優選信道相關。

    有利地,通過與每個信道相關的傳輸協議來唯一地標識每個信道。

    例如,我們具有分別由TCP和UDP傳輸協議標識的TCP信道和UDP信道。

    在有利的變例中,通過與每個信道相關的傳輸協議以及所述傳輸協議的輸入和輸出端口來唯一地標識每個信道。

    因此,對于經過若干信道中的每一個的包,可使用相同的傳輸協議但是例如不同類型的服務來有區別地管理所述若干信道。

    在示例性實施例中,從下面的兩個信道中進行選擇有效信道的步驟:

    -第一信道,稱為TCP信道,其相關的傳輸協議是TCP協議;以及

    -第二信道,稱為UDP信道,其相關的傳輸協議是UDP協議。

    在第一特定實施例中,假設所接收的包是UDP類型的包,如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的擁塞,則用于所述接收的包的新的優選信道是UDP信道,以及如果關于與當前傳輸條件相關聯的傳輸質量的所述信息沒有指示所述傳輸信道的任何擁塞,則用于所述接收的包的新的優選信道是TCP信道。

    在第二特定實施例中,假設所接收的包是UDP類型的包,如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的擁塞,則所述接收的包的新的優選信道是UDP信道,如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示誤包率(PER)在確定的閾值(Pth)以下,則用于所述接收的包的新的優選信道是TCP信道,以及如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的誤包率(PER)大于或等于所述確定的閾值(Pth),則用于所述接收的包的新的優選信道是UDP信道。

    在第三特定實施例中,假設所接收的包是TCP類型的包,如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的重傳率在確定的閾值(Rth)之上,則用于述所接收的包的新的優選信道是UDP信道,以及如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的傳輸速率低于或等于所述確定的閾值(Rth),則用于所述接收的包的新的優選信道是TCP信道。

    清楚的是,在不脫離本發明的范圍的情況下,可設想選擇新的優選信道的步驟的其它實施例。例如,可使用關于網絡的其它傳輸質量準則和/或在上述第一、第二和第三實施例中使用的準則的其它組合。

    在另一實施例中,本發明涉及可從通信網絡下載和/或記錄在計算機可讀載體上和/或可由處理器執行的計算機程序產品,所述計算機程序產品包括程序代碼指令,當所述程序在計算機上執行時,所述程序代碼指令用于實現上述方法(在其至少一個實施例中)。

    在另一實施例中,本發明涉及一種可總體或局部分離的存儲裝置,其可由計算機讀取,存儲一組指令,當所述程序在計算機上執行時,可由所述計算機執行所述指令以實現上述方法(在其至少一個實施例中)。

    在另一實施例中,本發明涉及一種通道進入端點,其能夠在將兩個子網絡互連以便形成總的通信網絡的通道中實現數據包的傳輸,所述通道在所述通道進入端點與通道離開端點之間被實現,所述子網絡中的每一個包括所述通道端點中的獨特通道端點,所述通道實現至少兩個傳輸信道。所述通道進入端點包括:

    -用于接收來自源裝置的數據包的裝置,該源裝置與通道進入端點屬于相同的子網絡;

    -用于根據與包含在所述接收的包中的凈荷數據相關的協議以及關于與所述傳輸信道中當前傳輸條件相關聯的傳輸質量的信息從傳輸信道中選擇有效信道的裝置;

    -用于根據與有效信道相關的傳輸協議來封裝所述接收的包以用于獲得將被發送的包的裝置;以及

    -用于在所選擇的有效信道上傳輸將在通道中發送的包的裝置。

    有利地,所述關于與當前傳輸條件有關的傳輸質量的信息屬于包括以下項的組:

    -關于所述傳輸信道的擁塞的信息;

    -關于所述傳輸信道的誤包率(PER)的信息;以及

    -關于所述傳輸信道的重傳率的信息。

    有利地,所述選擇有效信道的裝置包括:

    -用于確定與所述接收的包相關的包類型的裝置,每種包類型由與包含在擁有所述包類型的包中的凈荷數據相關的不同協議來定義;

    -用于根據關于如下傳輸質量的信息確定稱為在先優選信道的優選信道的裝置,該在先優選信道對于由通道進入端點發送并具有與所述接收的包相同類型的先前發送的包實現最佳傳輸,其中,所述傳輸質量與對于所述先前發送的包獲得的所述傳輸信道上的傳輸條件有關;

    -用于獲得所述關于與所述傳輸信道上的當前傳輸條件相關聯的傳輸質量的信息的裝置;

    -用于根據與所接收的包相關的包類型以及所述至少一條關于與當前傳輸條件相關聯的傳輸質量的信息來選擇實現所述接收的包的最佳傳輸的信道(稱為新的優選信道)的裝置;以及

    -用于根據在先優選信道、新的優選信道以及與所述接收的包相關的包類型來選擇所述有效信道的裝置。

    根據有利特征,所述選擇有效信道的裝置包括:

    -用于對于與所述接收的包相關的包類型而實現從所述在先優選信道平滑切換到所述新的優選信道的機制的裝置;以及

    -用于如果對于與所述接收的包相關的包類型,在先優選信道不同于新的優選信道,則激活所述實現平滑切換機制的裝置的裝置。

    有利地,對于每種類型的包,所述實現平滑切換機制的裝置包括:對于所述信道中的每一個管理最大傳輸窗口的步驟,最大傳輸窗口指示在給定的時間間隔期間,可在所述信道上發送的數據的最大數量。

    根據有利特征,所述窗口管理裝置是這樣的:在給定的時間間隔期滿之后,新的優選信道的最大傳輸窗口增加,以及在先優選信道的最大傳輸窗口變小,這表示在新的給定時間間隔期間能夠在所述信道上發送的數據的新的最大數量。

    根據優選特征,所述實現平滑切換機制的裝置是這樣的以使得有效信道為:

    -在傳輸窗口的限制之內的新的優選信道,所述傳輸窗口與用于與所接收的包相關的包類型的所述新的優選信道相關,或者

    -在超出所述傳輸窗口的情況下為在先優選信道,所述傳輸窗口與用于與所接收的包相關的包類型的所述新的優選信道相關。

    有利地,通過與每個信道相關的傳輸協議來唯一地標識每個信道。

    根據有利的變例,通過與每個信道相關的傳輸協議以及所述傳輸協議的輸入和輸出端口來唯一地標識每個信道。

    在一示例性實施例中,從中選擇有效信道的所述傳輸信道是下面的兩個信道:

    -第一信道,稱為TCP信道,其相關的傳輸協議是TCP協議;以及

    -第二信道,稱為UDP信道,其相關的傳輸協議是UDP協議。

    在第一特定實施例中,所述選擇有效信道的裝置是這樣的,即:假設所接收的包是UDP類型的包,如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的擁塞,則用于所述接收的包的新的優選信道是UDP信道,以及如果關于與當前傳輸條件相關聯的傳輸質量的所述信息沒有指示所述傳輸信道的任何擁塞,則用于所接收的包的新的優選信道是TCP信道。

    在第二特定實施例中,所述選擇有效信道的裝置是這樣的,即:假設所接收的包是UDP類型的包,如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的擁塞,則所述接收的包的新的優選信道是UDP信道,以及如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示誤包率在確定的閾值以下,則用于所述接收的包的新的優選信道是TCP信道,以及如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的誤包率大于或等于所述確定的閾值,則用于所述接收的包的新的優選信道是UDP信道。

    在第三特定實施例中,所述選擇有效信道的裝置是這樣的,即:假設所接收的包是TCP類型的包,如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的重傳率在確定的閾值之上,則用于所述接收的包的新的優選信道是UDP信道,以及如果關于與當前傳輸條件相關聯的傳輸質量的所述信息指示所述傳輸信道的傳輸速率低于或等于所述確定的閾值,則用于所述接收的包的新的優選信道是TCP信道。

    【附圖說明】

    通過以下作為表示性和非窮盡的示例給出的描述(并不是本發明的所有實施例都被限于以下描述的實施例的特征和優點)以及附圖,本發明實施例的其它特點和優點將而變得清楚,其中:

    圖1a示出使用通道的典型虛擬專用網絡(VPN)配置;

    圖1b示出可實現本發明方法的通道端點的經典分層模型的示例;

    圖2a示出傳送層2通道包的以太網幀的格式的示例;

    圖2b是在根據本發明的方法的特定實施例中,由通過通道進行發送的通道端點執行的出站(outbound)算法的流程圖;

    圖2c是根據依照本發明的方法的特定實施例,由通過通道進行接收的通道端點執行的入站(inbound)算法的流程圖;

    圖3是根據依照本發明的方法的特定實施例,用于選擇有效信道的算法的流程圖(圖2b的步驟3的細節);

    圖4、圖5和圖6是根據依照本發明的方法的特定實施例,用于選擇優選信道的三種不同算法的流程圖(圖3的步驟35的細節);

    圖7a是根據依照本發明的方法的特定實施例,用于管理當前傳輸模式以及用于包類型的傳輸窗口的算法的流程圖(圖3的步驟36的細節);

    圖7b是根據本發明的方法的特定實施例的包類型的表;

    圖8a是根據本發明的特定實施例的用于管理過渡性UDP到TCP模式的算法的流程圖;

    圖8b是根據本發明的特定實施例的用于管理過渡性TCP到UDP模式的算法的流程圖;

    圖8c是根據依照本發明的方法的特定實施例,用于選擇包類型的有效信道的算法的流程圖(圖3的步驟38的細節);以及

    圖9示出根據本發明特定實施例的通信設備(通道端點)的結構。

    【具體實施方式】

    在本發明的所有附圖中,相同的元素和步驟由相同的標號來指定。

    因此,本發明涉及這樣一種技術,其在分別連接到第一和第二LAN的兩個通道端點中實現,以便改善連接到第一LAN的各設備與連接到第二LAN的各設備之間的通信。

    本發明總的原理包括:對于將經由通道發送的每個數據包,選擇將被使用的最優信道(通常由它的傳輸協議表征)。所述選擇是基于將被發送的數據類型(包含在所述包中的凈荷數據的協議、應用的類型等)以及(在兩個通道端點之間)網絡上的傳輸條件的。

    圖1a示出通過通信網絡107(例如,互聯網)在本地通道端點101與遠程通道端點102之間實現通道100的虛擬專用網絡(VPN)的典型配置。所述通道100連接兩個本地網絡:LAN?A?103以及LANB?104。LAN?103和104中的每一個具有高比特率的互聯網接入設備(能夠集成防火墻的歸屬網關(home?gateway))105和106、PC類型設備109和111、用于存儲和分發數字媒體(屬于音頻、視頻和圖片類型)的服務器110和113以及數字媒體恢復(restitution)設備108和112。通道端點可被集成到諸如數字電視機的視聽設備中。通道端點也可以按照執行與PC類型設備相關的功能的程序的形式而設置在PC類型設備中。

    一旦通道100被建立,則連接到LAN?A?103的設備108、109和110能夠與連接到LAN?B?104的設備111、112和113進行通信。例如,連接到LAN?A?103的客戶機108能夠與連接到網絡LAN?B?104的服務器113進行通信。

    附圖1a示出僅具有一個通道的簡單通信網絡,但是應理解,相同的通道端點可能會管理幾個通道(通向等同數量的通道端點)以便將第一LAN與若干其它LAN互連。此外,為了簡便起見,所述附圖沒有示出諸如互聯網路由器的互聯網中的基礎設備。

    參照圖1b,我們將描述來自(連接到LAN?B?103的)設備108、109、110之一并將進入通道100的以太網幀的路由。為此,將使用分層模型。該分層模型描述實現所述通道100所需的協議層。在該模型中,沒有表示對于除了使用通道之外的其它功能所必需的協議元素。例如,沒有顯示當通道端點101被集成到UPN?p設備時與UPnP結構相關的協議元素。

    通道端點101具有以太網物理接口208,其將來自設備108、109、110的以太網幀給予鏈路層207以進行路由:對于去往包括通道端點的設備的以太網幀,向著網絡層206來實現所述路由,而對于其它以太網幀,向著橋接層209來實現所述路由。橋接層209實現經典的以太網橋的操作,諸如過濾以太網幀,并將這些幀中繼到適當的以太網輸出端口。所述橋具有以太網接口207和至少一個虛擬接口210,用于模擬附加到所述橋的以太網控制器。對于由應用200例示的每個信道創建虛擬接口210,所述應用200向所述信道給出必須傳送經過分別例示的通道的以太網幀。通常,由應用200表示的通道的封裝的協議執行實現每個通道所必需的操作,其中,具體是幀的配置、過濾和封裝(形成通道包)以及提取。

    從虛擬接口210接收的幀在通過應用200處理之后,通過應用接口或套接(socket)層201以包的形式被轉移到可靠的TCP傳輸協議203或不可靠的UDP傳輸協議205,它們分別由SSL協議202和DTLS協議204確保其安全。在由傳輸協議處理以形成通道包250(圖2a)之后,其被傳遞到網絡層206。用通道包由此形成的IP數據報現在可以通過鏈路層207和物理層208在LAN上進行發送。

    幀的接收將在通道端點中采取與以上提供的路徑相反的路徑。

    圖2a提供傳送級別2通道包的以太網幀(標為260)的格式的示例。

    所述格式相應于這樣的幀,作為示例,所述幀在圖1a的LAN?A103上在通道端點101與歸屬網關105之間傳送(要在互聯網上發送或從互聯網接收),并包括以太網頭部3261、傳送級別2通道包(標號250)的第一IP數據報本身以及FCS(“幀校驗序列”)字段。

    通道包250具有4個部分:

    -傳輸協議(即,該示例中的TCP?UDP)的頭部字段251,

    -封裝協議(即,該示例中的L2TP或TLS,具體描述在文獻IETFRFC3931,“Layer?two?tunneling?protocol-version?3(L2TPv3)”,J.Lauand?all,March?2005和文獻IETF?RFC2246,“The?TLS?Protocol?Version1.0”中)的頭部字段252,

    -乘客協議(即,該示例中的以太網)的頭部字段253,以及最后

    -用戶數據字段254,其自身包括第二IP數據報,如果在其從源設備行進期間沒有出現分片,則第二IP數據報是完整的。

    現參照圖2b,描述根據本發明的方法的特定實施例由通道端點(例如,圖1a中的標號101所標識的端點)執行的LAN出站算法。該附圖解釋對通過通道100發送到其它通道端點102的數據的一般處理。

    在步驟1,偵聽網絡接口并捕獲要去往連接到LAN?B?104的至少一個設備的IP或以太網數據包。這可以通過使用網橋并利用添加到網橋的若干虛擬網絡裝置(諸如TUN/TAP)來完成。

    在步驟2,判定所述包是否被授權向LAN?B發送。例如,從LANB接收的包將不會向該相同的LAN發送。

    在步驟3,選擇最適合的信道,以用于將數據包發送到LAN?B104。以下,參照其它附圖在此詳細描述該步驟3。

    在步驟4(可選步驟),可對數據執行加密,以確保用戶數據的私密性。例如,可使用公知的加密算法(諸如AES(高級加密標準))來完成所述步驟。

    在步驟5,基于步驟3的結果,利用與在步驟3選擇的信道相關的封裝協議(也稱為隧穿協議)對所接收的包進行封裝。所述封裝協議添加特定信息(頭部(header)),并可選地能夠添加附加數據,以便提供特別針對通道的功能(諸如“保持活動”機制,其使得兩個通道端點均能夠知曉信道是否仍為活動,即,是否可進行傳輸)的特征。這些附加功能可取決于信道。例如,可能值得添加附加數據,以便測量通常沒有給出任何RTT(往返時間)測量機制的UDP信道的RTT。這可以通過在封裝數據中添加對立即響應(包括標識符)的請求來實現。當遠程通道頭部接收到這種請求時,其立即做出響應。當接收到所述響應時,本地通道頭部可隨后確定RTT。這種機制自然不需要在已經實現RTT評估機制的信道中(例如,這是基于TCP的信道的情況)實現(Cf.“TCP/IP?illustrated,Volumes?1,2?and?3”,Stevens,Wright,Addison-Wesley,1994,1995?and?1996)。

    在步驟6,在步驟3中選擇的信道上發送通過封裝產生的包。這可以通過將數據寫到被配置成在通道上發送數據的連接接口(套接字)來完成。在這一步驟之后,所述包將最終具有圖2a的標號250所標識的包的形狀。該步驟還更新信道統計(重傳、發送的數據類型等)。

    參照圖2c,描述根據本發明的方法的特定實施例由通道端點(例如,圖1a中的標號102所標識的端點)在LAN上執行的入站算法。該附圖解釋了來自其它通道端點101并通過通道100接收的數據的整個處理。

    在步驟7,偵聽與每個信道相應的每個特定連接接口(套接字),以接收包。

    在步驟8,更新關于在其上進行接收的信道的網絡質量(重傳、RTT、PER、擁塞等)的信息。

    在步驟9,使用解密算法以及與步驟4所使用的密鑰兼容的相關密鑰來對凈荷數據進行解密(如果已經執行過圖2b的步驟4)。

    在步驟10,將數據包進行解封裝,以取回原始數據包(由通道端點101在LAN?A?103上最初所捕獲的)。在這一步驟中,如果還存在與可選附加機制相關的任何附加數據,則還處理附加數據(參照圖5的描述)。

    在步驟11,判定通過解封裝得到的包是否是被允許的。例如,解密或解封裝沒有給出令人滿意的結果的包將不會被授權在LAN?A上傳輸,從而不會擾亂連接到所述LAN的設備的工作。

    在步驟12,信道統計(關于帶寬、被發送數據的類型等)被更新。

    在步驟13,在LAN?B?104上發送通過解封裝得到的包。這可以通過使用諸如TUN/TAP的虛擬網絡裝置來實現。

    以下在此參照圖3來描述根據本發明的方法的特定實施例來選擇有效信道的算法(圖2b的步驟3的細節)。

    在步驟31分析從步驟2(圖2b)接收的包,以便確定其是否是IP包(因為在該實施例中,只考慮IP包)。這通過分析包的內容來實現(LLC頭部等)。如果其不是IP包,則處理進行到選擇默認信道的步驟37。該默認信道可由用戶來確定,例如,其為TCP信道。如果其是IP包,則操作進行到步驟32。

    在該步驟32中,對包進行分類(提取關于隨后將用于選擇最優信道的包的所有信息)。通常,為了根據包凈荷數據確定包類型(分類的結果),確定凈荷數據傳輸協議(IP上的傳輸協議),該信息在IP頭部的8個保留比特中被編碼。這里,在以下的描述中,將凈荷數據傳輸協議用作包類型(TCP、UDP、SCTP、DCCP等)的標識符。

    在步驟33,確定在步驟32確定的包類型是否由下面的步驟35來管理。如果不是,則操作進行步驟37。如果答案為“是”,則操作進行步驟34。

    例如,在此討論的特定實施例中,TCP和UDP是通過下面的步驟35管理的乘客協議。對于其它乘客協議,在步驟37選擇默認信道。例如,所述協議為:傳輸協議,如DCCP(數據報擁塞控制協議,“Datagram?Congestion?Control?Protocol”)或SCTP(流控制傳輸協議“Stream?Control?Transmission?Protocol”);或資源保留協議,如RSVP(資源保留協議,“Resource?Reservation?Protocol”);以及非層4(在ISO模型中)協議,諸如ICMP(因特網控制消息協議,“InternetControl?Message?Protocol”)或IGMP(因特網群組多播協議,“Internet?Group?Multicast?Protocol”)。因此,利用單個信道在通道中發送所述類型的乘客協議的包。對于非IP包,默認信道可由用戶來設置或可包括預設的默認值;可注意到:將TCP信道定義為用于上述乘客協議(不由步驟35管理)的默認信道允許應用保留策略。

    在步驟34,確定QoE(“試驗質量”)。為此,涉及網絡質量(擁塞、PER、帶寬、RTT、重傳率等)的所有數據被取回。每當包通過通道被發送或接收時,所有上述數據被評估(步驟8、12、384和387)。

    在步驟35,確定優選信道(并因此確定優選傳輸協議),優選信道被用于盡可能有效地將凈荷數據發送到遠程LAN。信道可僅僅由它的傳輸協議來表征,但是可使用其它特征,例如,TOS(服務類型)參數。作為示例,以下給出用于確定優選信道的三種可行策略(分別在圖4、圖5和圖6中的步驟35a、35b和35c)。

    在步驟36,確定用于被處理的包(以下稱為“被處理包”)的類型的傳輸模式。傳輸模式相應于管理給定類型的包的傳輸的方式。該模式可以是穩定的(例如,TCP或UDP)或過渡(例如,TCP到UDP或UDP到TCP)的。

    在圖7a、圖8a和圖8b中示出步驟36的可能實現方式。在該實現方式中,我們考慮由其傳輸協議表征的信道的情況(與圖4、圖5和圖6兼容)。根據優選傳輸協議以及用于被處理包的類型的當前傳輸模式,在步驟36,對于每種包類型(在步驟32確定的類型),傳輸模式的進展被管理(在四種可行能模式中:兩種穩定模式TCP和UDP,兩種過渡模式TCP到UDP以及UDP到TCP)。例如,如果在步驟35確定為UDP類型的包,也稱為UDP包(即,UDP是乘客協議的凈荷數據協議的包),優選傳輸協議是TCP(即,優選信道是TCP信道),但是UDP包的當前傳輸模式是UDP模式,而在步驟36,進入過渡UDP到TCP模式,用于被處理包的有效傳輸信道可以是優選的TCP信道或UDP信道(參見以下對圖7a、圖7b、圖8a、圖8b和圖8c的詳細描述)。

    在步驟38,根據當前傳輸模式的優選信道(參見步驟35)以及被處理包的類型的傳輸窗口參數(見以下的描述)來選擇有效信道。在圖8c中示出所述步驟38的可能實現方式。對于給定類型的包,這是一種用于從一種傳輸模式平滑地傳遞到另一種模式的選擇機制。這種機制對于避免通道的“虛假”擁塞很重要。

    例如,如果一種類型的包的優選傳輸協議從UDP切換到TCP,則不可能直接在TCP信道上發送所有這種類型的包,這是因為:將在該TCP信道上發送的包的數量上的突然增加將逐漸導致TTP擁塞窗口被超出。結果,即使實際可用帶寬足夠大,所述包也會被TCP堆棧延遲或被緩沖。這些緩沖的包將增加測量的點對點通信的RTT,并且會在TCP包的情況下引起不必要的重傳(在TCP情況下,隨著稱為RTO(“重傳時間超時”)的重傳超時期滿)。

    在從TCP傳輸模式切換到UDP傳輸模式的情況下,有必要注意UDP信道大小的突然增加,這可能突然使得TCP傳輸降速,這也會產生問題。

    圖4示出選擇信道(即,選擇優選傳輸協議)的優選算法的第一示例(圖3的步驟35中的細分標號35a)。在該第一示例中,只有ECN通知機制被使用。

    在該第一示例中選擇的策略是這樣一種策略:只有在不存在網絡擁塞的情況下,在UDP信道上發送TCP包(以防止“TCP上的TCP”組合的問題)并在TCP信道上發送UDP包(以提供與LAN上相同的可靠性)。在存在網絡擁塞的情況下,在UDP信道上發送UDP包(以便即使一些包被消除,也保持UDP速度)。

    在步驟352,確定被處理包的類型,即,用于包含在被處理包中的凈荷數據的傳輸協議。

    如果包是TCP包,則執行步驟359。在該步驟中,UDP信道被選擇,作為用于被處理包的優選信道。

    如果包是UDP包,則執行步驟353。在該步驟中,通過ECN通知機制確定是否檢測到網絡擁塞(在步驟8)。

    如果沒有檢測到擁塞,則執行步驟358。在該步驟中,選擇TCP信道作為用于被處理包的優選信道。如果檢測到擁塞,則執行步驟359。在該步驟中,UDP信道被選擇作為用于被處理包的優選信道。

    圖5示出用于選擇優選信道(即,優選傳輸協議)的算法的第二示例(圖3中的步驟35的細分標號35b)。在該第二示例中,聯合地使用ECN通知機制和誤包率(PER)。

    在該第二示例中,在新的步驟354中,將網絡的PER與確定的閾值Pth(例如,由用戶選擇)進行比較。

    在這種情況下,當步驟353沒有檢測到擁塞時,操作進行到步驟354(而不是如圖4所示直接執行步驟358)。

    在步驟354中,如果PER高(大于或等于閾值Pth),但是如果步驟353指示不存在擁塞,則為了增加點對點的可靠性而選擇TCP信道作為用于被處理包的優選信道是有用的。如果不是(如果PER低于閾值Pth),則選擇UDP信道,作為用于被處理包的優選信道。

    圖6示出用于選擇優選信道(即,優選傳輸協議)的算法的第三示例(圖3的步驟35的細分標號35c)。在該第三示例中,聯合地使用ECN通知機制、誤包率(PER)以及TCP信道上的重傳率。

    對于TCP包,已知(參見上述文獻“Understanding?TCP?over?TCP(…)”)通道中的多次重傳能夠在TCP通信中產生從端到端的重傳,從而產生不必要的重傳。為了防止這種情況,以上建議(參見圖4和圖5)在UDP信道上發送TCP包。然而,為了確保通道的可靠性而允許通道重傳包是有用的。為了實現這一目的,該第三示例考慮在TCP信道上進行重傳。如果在TCP信道上的重傳率低于閾值Rth(例如,10%),則值得在TCP信道上發送TCP包。如果TCP信道上的重傳率大于或等于閾值Rth,則在UDP信道上發送TCP包。

    因此,與圖5相比,存在附加步驟357(在步驟352的輸出),其中,進行檢查以檢測在TCP信道上的重傳率是否低于閾值Rth。如果響應為“是”,則操作進行到步驟358,其中,TCP信道被選擇,作為用于被處理包的優選信道。如果答案為“否”,則操作進行到步驟359,其中,UDP信道被選擇,作為用于被處理包的優選信道。

    參照圖7a,我們現在提出根據本發明的方法的特定實施例的用于管理當前傳輸模式以及用于包類型的傳輸窗口的算法(參見圖3中的步驟36的細節)。

    因此,對于每種包類型,我們管理傳輸模式以及兩個傳輸窗口(通道的每個傳輸信道有一個傳輸窗口)。通過一組參數來定義與給定信道相關的傳輸窗口(見圖7b),所述參數用于定義能夠在確定的持續時間期間(相應于RTT)在給定信道上發送的數據的最大數量。對于給定類型的包,根據傳輸的模式,所述兩個窗口將增加或減小,以便平滑地從一個信道切換到另一個信道。

    可回想到的是:在圖3的分類步驟32期間確定正在被處理的包(或被處理包)的類型。

    該示例考慮兩種類型的包:TCP包或UDP包。對于所述兩種類型的包中的每一種,一種傳輸模式以及兩個傳輸窗口被管理。所述傳輸窗口以下稱為“TCP傳輸窗口”和“UDP傳輸窗口”。

    重要的是要注意到:下面針對具有給定類型的包來描述圖7a,因此,每當提到傳輸模式或窗口參數(Wtcp、Stcp、Wtcp_max、Wudp、Sudp、Wudp_max)時,必須理解:這是屬于適合所述給定的包類型的一組變量的傳輸模式或窗口參數(參見圖7b)。這同樣適用于以下描述的圖8a、圖8b和圖8c。

    對于具有給定類型的被處理包,在步驟35(圖3)確定優選傳輸信道之后到達步驟360(例如,根據圖4、圖5和圖6的三種策略之一來實現)。

    在步驟360,根據優選信道來實現切換:如果優選信道是TCP信道(即,如果優選傳輸協議是TCP),則操作進行到步驟361,或者如果優選信道是UDP信道(即,如果優選傳輸協議是UDP),則操作進行到步驟362。

    在步驟362(優選信道是UDP信道的情況),根據當前傳輸模式(對于被處理包的類型),實現切換。

    如果在步驟362,當前模式是穩定TCP模式(與作為TCP信道的在先優選信道相關),則系統必須進入過渡TCP到UDP模式,其在步驟263建立。首先,方法進行到步驟369,其中,對于被處理包的類型初始化窗口參數:

    -將對于被處理包的類型已經在UDP信道上發送的數據的數量(Sudp)設置為0(Sudp=0)

    -將UDP窗口的大小(Wudp)(能夠在UDP信道上發送的數據的最大數量)設置為TCP上的TCP信道連接的最大分段大小(MSS)(Wudp=MSS);

    -將相應于TCP窗口的最大大小的停止條件(Wudp_max)設置為TCP擁塞窗口的當前值(Cwnd)(Wudp_max=Cwnd)。所述停止條件將確定過渡TCP到UDP模式的輸出。

    如果在步驟362,當前模式是過渡UDP到TCP模式(與作為TCP信道的優選在先信道相關),所述系統在這里也必須進入在步驟263建立的過渡TCP到UDP模式。可對于被處理包的類型,保存已經重置的窗口參數(參見圖8a)。

    在步驟362,如果當前模式是穩定UDP模式(與作為UDP信道的在先優選信道相關)或過渡TCP到UDP模式(與作為UDP信道的優選在先信道相關),則不需要動作。

    在步驟363之后,操作進行到步驟366,其中,發起執行用于管理過渡TCP到UDP模式的算法(以下將參照圖8b來描述)。在所述發起操作之后,操作進行到圖3的步驟38。

    在步驟361(優選信道是TCP信道的情況),根據當前傳輸模式(對于被處理包的類型),完成切換。

    在步驟361,如果當前模式是穩定UDP模式(與作為UDP信道的在先優選信道相關),系統必須進入在步驟364建立的過渡UDP到TCP模式。首先,操作進入到步驟268,其中,用于被處理包的類型的窗口參數被初始化:

    -將對于被處理包的類型已經在TCP信道上發送的數據的數量(Stcp)設置為0(Stcp=0);

    -將TCP窗口的大小(Wtcp)(能夠在TCP信道上發送的數據的最大數量)設置為當前TCP擁塞窗口的大小(Cwnd)(Wtcp=Cwnd)。因此,在最初,兩個窗口(Wtcp和Cwnd)具有同樣的大小;

    -將與TCP窗口的最大大小相應的停止條件(Wtcp_max)設置為UDP窗口的當前值(Wudp)。該停止條件將確定過渡UDP到TCP模式的輸出。

    如果在步驟361,當前模式是過渡TCP到UDP模式(與作為UDP信道的在先優選信道相關),則系統在此也必須進入在步驟364建立的過渡UDP到TCP模式。對于被處理包的類型,可保存已經初始化的窗口參數(參見圖8b)。

    如果在步驟361,當前模式是穩定TCP模式(與作為TCP信道的在先優選信道相關)或過渡UDP到TCP模式(與作為TCP信道的在先優選信道相關),則不需要動作。

    在步驟364之后,操作進行到步驟365,以發起執行用于管理過渡UDP到TCP模式的算法(以下將參照圖8a來描述)。在所述發起處理之后,操作進行到圖3的步驟38。

    圖7b提供根據本發明的方法的特定實施例的包類型的表。該表4000指示將對于每種類型的包而考慮的變量集合。

    更具體地說,表4000對于每種包類型(例如,TCP包或UDP包)包含一行。列4002指示用于這種包類型的當前傳輸模式。列4003到4005給出對于這種包類型定義TCP傳輸窗口的變量(分別在以上討論過的Wtcp、Stcp和Wtcp_max)的值。列4006到4008給出定義UDP傳輸窗口的變量(分別在以上討論過的Wudp、Sudp和Wudp_max)的值。

    兩個附加變量Nudp_tcp和Ntcp_udp總是提供關于分別在過渡UDP到TCP模式以及TCP到UDP模式中的包類型的數量的知識。這兩個變量對于確定增加傳輸窗口的步長(step)很重要(參見圖8a和圖8b中的步驟3654和3664)。實際上,在過渡UDP到TCP模式下的傳輸窗口以及在過渡TCP到UDP模式下的傳輸窗口分別為了遵循擁塞窗口的大小(Cwnd)的自然進展而進行的進展必須考慮由被考慮的過渡模式所考慮的所有包類型。如果沒有考慮,如果獨立地考慮所述包類型中的每一種,則在過渡UDP到TCP模式下的傳輸窗口以及在TCP到UDP模式下的傳輸窗口分別進行的進展將不會遵循擁塞窗口的大小(Cwnd)的自然進展,將存在超出在過渡UDP到TCP模式下可由TCP傳輸協議接受的數據量以及在過渡TCP到UDP模式下可由UDP傳輸協議接受的數據量的閾值的風險。

    圖8a提出根據依照本發明的方法的特定實施例的用于管理過渡UDP到TCP模式的算法。

    該附圖描述:對于給定的包,TCP和UDP傳輸窗口(對于所述給定包類型)的參數演變(develop),以實現從穩定UDP傳輸模式到穩定TCP傳輸模式的平滑切換的方式。

    為了避免由于與所述大小(Cwnd)相比在TCP信道上發送過多數量的包而引起的問題,本發明考慮在TCP信道中計劃的機制,以防止擁塞,并且,TCP(虛擬)傳輸窗口的大小(Wtcp)被增加,以匹配擁塞窗口的大小(Cwnd)的自然進展。

    在步驟3659,將UDP到TCP模式下包類型的數量(Nudp_tcp)增加一個單位。

    然后,為了管理TCP傳輸窗口的大小(Wtcp),在步驟3651發起超時(相應于TCP信道的RTT,每當接收到包時被更新,參見步驟12),在步驟3652,等待所述超時的期滿。

    同時(在步驟3651與3652之間),與步驟38相兼容地發送包(對于每個包執行一次步驟38)。

    在超時過期之后,在步驟3653執行測試,以查出傳輸模式是否已經改變(在步驟35對優選信道進行修改之后,可在步驟36判定將傳輸模式從過渡UDP到TCP模式改變到過渡TCP到UDP模式)。

    如果傳輸模式已經改變,則操作在結束之前進行到步驟3657,其中,UDP到TCP模式下的包類型的數量(Nudp_tcp)被減少。

    如果傳輸模式尚未改變,則算法運行,以繼續管理TCP(虛擬)傳輸窗口的進展。操作進行到步驟3654,其中,TCP傳輸窗口的大小(Wtcp)增加MSS/Nudp_tcp。因此,在避免擁塞并考慮包的Nudp_tcp類型同時處于過渡UDP到TCP模式的情況時遵循TCP擁塞窗口的大小(Cwnd)的最大發展。此外,在步驟3654,將在最后的RTT期間,對于被處理包的類型已經在TCP信道上發送的數據的量(Stcp)設置為0(Stcp=0)。

    在步驟3655,確定過渡UDP到TCP模式下的過渡階段是否已經結束。為此,進行檢查,以查看TCP傳輸窗口的大小(Wtcp)是否已經充分地增加(Wtcp>Wtcp_max?),以及對于被處理包的類型,是否不再有在UDP信道上發送的任何數據(Sudp=0?)

    如果過渡階段已經結束,則操作進行到步驟3656,其中,穩定TCP模式被建立。然后,在結束之前,操作進行到步驟3657,其中,在UDP到TCP模式下的包類型的數量(Nudp_tcp)被減少。

    如果過渡階段沒有結束,則操作進行到步驟3658,其中,將對于被處理包的類型已經在UDP信道上發送的數據的量(Sudp=0)設置為0。然后,操作返回步驟3651,并且發起新的超時。

    圖8b示出根據本發明特定實施例的用于管理過渡TCP到UDP模式的算法。

    該附圖描述:對于給定包類型,TCP和UDP傳輸窗口(對于所述給定包類型)的參數如何發展來實現從穩定TCP傳輸模式到穩定UDP傳輸模式的平滑切換。

    管理UDP傳輸窗口的所述機制類似于以上對于TCP傳輸窗口參照圖8a描述的機制。UDP傳輸窗口的大小(Wudp)指示在持續時間RTTu能夠在UDP信道上發送的數據的最大量。所述持續時間RTTu是由系統計算的值,并相應于對于TCP描述的往返時間(該值可通過周期性地將特定控制請求從一個通道端點發送到另一通道端點來計算,所述另一通道端點立即遵照所述請求進行動作)。

    為了避免由于在UDP信道上發送過多數量的包(在TCP信道已經完成對它的緩沖器的清空之前)而引起的擁塞,不可突然從完全的TCP傳輸切換到完全的UDP傳輸。因此,使用圖8B的機制(與圖8a類似)。

    在步驟3669,因此,將TCP到UDP模式下包類型的數量(Ntcp_udp)增加一個單位。

    然后,為了管理UDP傳輸窗口的大小(Wudp),在步驟3661發起超時(相應于上述RTTu),在步驟3662,等待所述超時期滿。

    同時(在步驟3661與3662之間),與步驟38相兼容地發送包(對于每個包執行一次步驟38)。

    在超時過期之后,在步驟3663執行測試,以查出傳輸模式是否已經改變(在步驟35對優選信道進行修改之后,可在步驟36確定將傳輸模式從過渡TCP到UDP模式改變到過渡UDP到TCP模式)。

    如果傳輸模式已經改變,則操作在結束之前進行到步驟3667,其中,TCP到UDP模式下的包類型的數量(Ntcp_udp)被減少。

    如果傳輸模式尚未改變,則算法運行,以繼續管理UDP(虛擬)傳輸窗口的進展。操作進行到步驟3664,其中,UDP傳輸窗口的大小(Wudp)增加MSS/Ntcp_udp。此外,在步驟3654,將在最后的RTT期間對于被處理包的類型已經在UDP信道上發送的數據的量(Sudp)設置為0(Sudp=0)。

    在步驟3665,判定過渡TCP到UDP模式下的過渡階段是否已經結束。為此,進行檢查,以查看UDP傳輸窗口的大小(Wudp)是否已經充分地增加(Wudp>Wudp_max?),以及對于被處理包的類型,是否不再有在TCP信道上發送的數據(Stcp=0?)

    如果過渡階段已經結束,則操作進行到步驟3666,其中,穩定UDP模式被建立。然后,在結束之前,操作進行到步驟3667,其中,在TCP到UDP模式下的包類型的數量(Ntcp_udp)被減少。

    如果過渡階段沒有結束,則操作進行到步驟3668,其中,將對于被處理包的類型已經在TCP信道上發送的數據的量(Stcp=0)設置為0。然后,操作返回步驟3661,并且發起新的超時。

    現在參照圖8c,我們提出根據本發明的方法的特定實施例的用于對于包類型選擇有效信道的算法(圖3的步驟38的細節)。

    在步驟380,根據當前傳輸模式來執行切換(對于被處理包的類型)。

    如果在步驟380,當前模式是穩定TCP模式,則操作進行到步驟383,其中,TCP信道被選擇作為有效傳輸信道,然后進入操作384,其中,TCP信道的參數(例如,平均吞吐量、擁塞窗口等)被評估。

    在步驟380,如果當前模式是穩定UDP模式,則操作進行到步驟386,其中,UDP信道被選擇作為有效傳輸信道,然后進行到步驟387,其中,UDP信道的參數(例如,平均吞吐量、擁塞窗口等)被評估。

    在步驟380,如果當前模式是過渡模式之一(TCP到UDP或UDP到TCP),則操作進行到步驟381,其中,確定會向其發送包的信道。為此,進行檢查,以查看是否已經到達將在優選信道上發送的最大數據數量(在過渡UDP到TCP模式的情況下,確認“Stcp>Wtcp-max”;在TCP到UDP過渡模式的情況下,確認“Sudp>Wudp-max”)。如果尚未達到最大數量,則優選信道用于發送被處理包。否則,在在先優選信道上發送被處理包。

    因此,對于UDP到TCP模式:

    -如果對于被處理包的類型,從步驟3668的最后執行(將Stcp復位為0)起已經在TCP信道上發送的數據數量(Stcp)大于最大授權值(Wtcp_max)(對步驟381的測試的響應為“是”),則即使優選信道為TCP信道,也將在UDP信道上發送被處理包(在步驟385之后,操作進行到步驟386和387)。在步驟385,對于被處理包的類型,從步驟3658的最后執行(Sudp的復位)起已經在UDP信道上發送的數據數量(Sudp)被增加了被處理包的大小(Sudp=Sudp+包的大小);

    -如果對于被處理包的類型,從步驟3668的最后執行(Stcp的復位)起已經在TCP信道上發送的數據數量(Stcp)小于或等于最大授權值(Wtcp-max)(對步驟381的測試的否定響應),則將在TCP信道上發送被處理包(在步驟382已經執行之后,操作進行到步驟383和384)。在步驟382,對于被處理包已經在TCP信道上發送的數據數量(Stcp)被增加了被處理包的大小(Stcp=Stcp+PacketSize(包的大小))。

    對于TCP到UDP模式:

    -如果對于被處理包的類型,從步驟3658的最后執行(將Sudp復位)起已經在UDP信道上發送的數據數量(Sudp)小于或等于最大授權值(Wudp_max)(對步驟381的測試的響應為“是”),則即使優選信道為TCP信道,也將在UDP信道上發送被處理包(在步驟385之后,操作進行到步驟386和387);

    -如果對于被處理包的類型,從步驟3658的最后執行(Sudp的復位)起已經在UDP信道上發送的數據數量(Sudp)大于最大授權值(Wudp-max)(對步驟381的測試的否定響應),則將在TCP信道上發送被處理包(在步驟382已經執行之后,操作進行到步驟383和384)。

    圖9示出被用于實現本發明的技術的通信設備1000(圖1a的通道端點101或102)的示意性配置。它包括:RAM?1002,其作為中央處理單元(CPU)1001的主要存儲器、工作區等。它的存儲容量可通過連接到擴展端口的可選RAM(未示出)來擴展。中央處理單元1001能夠在通信設備被開啟時執行程序1003的來自ROM的指令。在開啟之后,中央處理單元1001能夠在指令例如已經從程序ROM?1003或硬盤驅動器(HDD)1006載之后執行與軟件應用程序有關的來自主存儲器1002的指令。雖然所述軟件應用程序由中央處理單元1001來執行,但是其會促使執行圖2b、圖2c、圖3、圖4、圖5、圖6、圖7a、圖8a、圖8b和圖8c所示的流程圖的全部或部分步驟。

關 鍵 詞:
通道 傳輸 數據包 方法 存儲 裝置 端點
  專利查詢網所有資源均是用戶自行上傳分享,僅供網友學習交流,未經上傳用戶書面授權,請勿作他用。
關于本文
本文標題:通道中傳輸數據包的方法、存儲裝置和通道端點.pdf
鏈接地址:http://www.rgyfuv.icu/p-6420391.html
關于我們 - 網站聲明 - 網站地圖 - 資源地圖 - 友情鏈接 - 網站客服客服 - 聯系我們

[email protected] 2017-2018 zhuanlichaxun.net網站版權所有
經營許可證編號:粵ICP備17046363號-1 
 


收起
展開
山东11选5中奖结果走势图