CN101360045A - 通道中传输数据包的方法、存储装置和通道端点 - Google Patents

通道中传输数据包的方法、存储装置和通道端点 Download PDF

Info

Publication number
CN101360045A
CN101360045A CN200810131178.4A CN200810131178A CN101360045A CN 101360045 A CN101360045 A CN 101360045A CN 200810131178 A CN200810131178 A CN 200810131178A CN 101360045 A CN101360045 A CN 101360045A
Authority
CN
China
Prior art keywords
channel
bag
transmission
udp
tcp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN200810131178.4A
Other languages
English (en)
Other versions
CN101360045B (zh
Inventor
S·巴龙
P·卢梭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Publication of CN101360045A publication Critical patent/CN101360045A/zh
Application granted granted Critical
Publication of CN101360045B publication Critical patent/CN101360045B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/196—Integration of transport layer protocols, e.g. TCP and UDP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

公开了通道中传输数据包的方法、相应计算机程序产品、存储装置和通道端点。提出了在将两个子网络互连以形成总通信网络的通道中传输数据包的方法，通道在两个通道端点之间实现，每个子网络包括通道端点中的独特通道端点，通道实现至少两个传输信道，该方法由通道端点中称为通道进入端点的端点实现。对每个数据包，该方法包括：接收来自与通道进入端点属于相同的子网络的源装置的数据包；根据与包含在接收的包中的净荷数据相关的协议以及关于与传输信道中当前传输条件相关联的传输质量的信息，从传输信道中选择有效信道；根据与有效信道相关的传输协议，封装接收的包，用于获得将被发送的包；和在选择的有效信道上，传输将在通道中发送的包。

Description

通道中传输数据包的方法、存储装置和通道端点
技术领域
本发明的技术领域是通信网络的技术领域。
更具体地说，本发明涉及一种用于在通过通信网络的通道中传输数据包(也称为数据报)的技术。
一方面，高比特率互联网在民众中得到普及，另一方面，出现了具有网络连接性的广泛传播的消费者视听设备，这两方面将创建对于用户部分的新的行为方式。这些新的行为方式毫无疑问地涉及属于具有共同兴趣(休闲、家庭等)的人群(我们可将其称作“持久联系”的群体)的个人的出现。这些群体将与相同兴趣领域的其他个人建立几乎永久性的联系，他们建立音频和/或视频通信，并共享各种信息(音频、视频、图片、文本等)。
虚拟专用网络(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(因特网控制消息协议，“Internet Control 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所示的流程图的全部或部分步骤。

Claims (17)

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信道。
CN200810131178.4A 2007-07-30 2008-07-30 通道中传输数据包的方法、存储装置和通道端点 Expired - Fee Related CN101360045B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR07/56817 2007-07-30
FR0756817A FR2919778A1 (fr) 2007-07-30 2007-07-30 Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants

Publications (2)

Publication Number Publication Date
CN101360045A true CN101360045A (zh) 2009-02-04
CN101360045B CN101360045B (zh) 2015-01-07

Family

ID=39111833

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200810131178.4A Expired - Fee Related CN101360045B (zh) 2007-07-30 2008-07-30 通道中传输数据包的方法、存储装置和通道端点

Country Status (5)

Country Link
US (1) US7894364B2 (zh)
EP (1) EP2020799B1 (zh)
JP (1) JP4669536B2 (zh)
CN (1) CN101360045B (zh)
FR (1) FR2919778A1 (zh)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102045768A (zh) * 2009-10-26 2011-05-04 宏碁股份有限公司 数据传输方法及其用户装置与数据传输系统
CN103107949A (zh) * 2011-11-09 2013-05-15 巴比禄股份有限公司 中继装置、中继装置的控制方法
CN103618704A (zh) * 2013-11-15 2014-03-05 四川长虹电器股份有限公司 界面客户端与服务器的通信方法
CN104094561A (zh) * 2011-12-01 2014-10-08 汤姆逊许可公司 通过根据可用带宽选择传输协议来获得内容的设备
CN104426732A (zh) * 2013-08-19 2015-03-18 华耀(中国)科技有限公司 一种高速传输隧道的实现方法及系统
CN106031096A (zh) * 2014-02-06 2016-10-12 加速系统有限责任公司 用于提供多安全链路架构的系统和方法
CN107342937A (zh) * 2017-06-12 2017-11-10 中国电子科技集团公司第五十四研究所 一种空间dtn网络下的数据可靠传输方法
CN107624233A (zh) * 2016-11-24 2018-01-23 深圳前海达闼云端智能科技有限公司 一种vpn传输隧道调度方法、装置以及vpn客户端服务器
CN108112282A (zh) * 2015-08-19 2018-06-01 谷歌有限责任公司 基于用户移动网络和数据计划对内容进行过滤
CN109792621A (zh) * 2014-07-14 2019-05-21 柏思科技有限公司 用于评估聚合的连接的网络性能的方法和系统
CN112449252A (zh) * 2019-09-04 2021-03-05 杭州海康威视数字技术股份有限公司 视频流系统的维护方法、装置、无线网桥设备及存储介质
CN112995182A (zh) * 2021-03-04 2021-06-18 广州市百果园信息技术有限公司 媒体流传输方法、装置、设备及介质

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2926939A1 (fr) 2008-01-30 2009-07-31 Canon Kk Procede de transmission de donnees avec anticipation des acquittements, dispositif d'entree, produit programme d'ordinateur et moyen de stockage correspondants
FR2933834A1 (fr) * 2008-07-11 2010-01-15 Canon Kk Procede de gestion d'une transmission de flux de donnees sur un canal de transport d'un tunnel, tete de tunnel, produit programme d'ordinateur et moyen de stockage correspondants.
US7940658B2 (en) * 2008-09-04 2011-05-10 Cisco Technology, Inc. ERSPAN dynamic session negotiation
US8743702B2 (en) * 2008-12-08 2014-06-03 Advantest Corporation Test apparatus and test method
FR2939993B1 (fr) * 2008-12-12 2010-12-17 Canon Kk Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes
US8429647B2 (en) * 2009-05-06 2013-04-23 Vmware, Inc. Virtual machine migration across network by publishing routes to the associated virtual networks via virtual router after the start of migration of the virtual machine
GB2471483A (en) * 2009-06-30 2011-01-05 Nokia Corp Data type selection based on channel type
FR2949931B1 (fr) * 2009-09-10 2011-08-26 Canon Kk Procedes et dispositifs de transmission d'un flux de donnees, produit programme d'ordinateur et moyen de stockage correspondants.
CN102026261B (zh) * 2009-09-16 2014-01-01 中兴通讯股份有限公司 一种随机接入信道负荷状态的衡量方法及装置
EP2312804B1 (en) * 2009-10-13 2015-02-25 BlackBerry Limited Methods and apparatus for intelligent selection of a transport protocol for content streaming
GB0921831D0 (en) 2009-12-14 2010-01-27 British Telecomm Graphical data delivery
GB201000738D0 (en) 2010-01-18 2010-03-03 British Telecomm Graphical data processing
FR2960372B1 (fr) * 2010-05-21 2012-06-22 Canon Kk Procede de gestion d'un flux de donnees utiles passager, produit programme d'ordinateur, moyen de stockage et dispositif gestionnaire correspondants
US8520540B1 (en) 2010-07-30 2013-08-27 Cisco Technology, Inc. Remote traffic monitoring through a network
CN102111330A (zh) * 2010-12-15 2011-06-29 北京佳讯飞鸿电气股份有限公司 双通道视频监控系统的数据传输方法
US9231841B2 (en) * 2011-07-08 2016-01-05 Telefonaktiebolaget L M Ericsson (Publ) Bearer control on the basis of probing
US8437302B2 (en) 2011-08-12 2013-05-07 Renesas Mobile Corporation Method and apparatus for transmission protocol uplink channel selection
US20130039237A1 (en) * 2011-08-12 2013-02-14 Keiichi Kubota Method and Apparatus for Transmission Protocol Uplink Channel Selection
JP5818362B2 (ja) * 2012-05-21 2015-11-18 日本電信電話株式会社 ネットワークシステム、ネットワーク管理装置、ネットワーク管理プログラム及びネットワーク管理方法
US9112804B2 (en) 2012-05-31 2015-08-18 International Business Machines Corporation Network congestion notification preservation and modification during transmission of network data between physical network and virtual network
US9054967B1 (en) 2012-09-18 2015-06-09 Cisco Technology, Inc. Timestamping packets in a network
US9077619B2 (en) 2012-09-18 2015-07-07 Cisco Technology, Inc. Exporting real time network traffic latency and buffer occupancy
US9094307B1 (en) 2012-09-18 2015-07-28 Cisco Technology, Inc. Measuring latency within a networking device
JP5893546B2 (ja) * 2012-11-30 2016-03-23 日本電信電話株式会社 ネットワークシステム、通信制御方法、通信制御装置及び通信制御プログラム
CN104038512A (zh) * 2013-03-04 2014-09-10 华为技术有限公司 数据传输方法和装置
US9236935B2 (en) * 2013-04-10 2016-01-12 Quortus Limited System and method for data transmission
JP6232826B2 (ja) * 2013-08-09 2017-11-22 富士通株式会社 仮想ルータ制御方法、仮想ルータ制御プログラムおよび制御装置
CN104469901B (zh) * 2013-09-17 2018-09-07 华为终端（东莞）有限公司 数据处理的方法及装置
CN103546917B (zh) * 2013-11-07 2016-10-05 华为技术有限公司 数据传输方法和装置
CN104660627B (zh) * 2013-11-18 2018-08-24 北京北方华创微电子装备有限公司 一种上位机与下位机的通信方法和系统
KR101472012B1 (ko) * 2013-12-31 2014-12-24 배재대학교 산학협력단 소프트웨어 기반의 네트워크 시뮬레이터
US9210129B2 (en) * 2014-02-06 2015-12-08 Acceleration Systems, LLC Systems and methods for providing a multiple secure link architecture
EP2908491A1 (en) * 2014-02-12 2015-08-19 HOB GmbH & Co. KG A communication system for transmitting data under a tunnel protocol
US10038712B2 (en) * 2014-06-02 2018-07-31 Paypal, Inc. Method and apparatus for dynamic detection of geo-location obfuscation in client-server connections through an IP tunnel
TWI565263B (zh) * 2014-10-07 2017-01-01 鴻海精密工業股份有限公司 網路裝置及其處理封包的方法
US10256992B2 (en) 2014-10-30 2019-04-09 Hewlett Packard Enterprise Development Lp Tunnel encapsulation
US9930116B2 (en) * 2015-06-01 2018-03-27 Oracle International Corporation Method and system for selecting a transport mechanism and a storage process
CN111769968A (zh) * 2016-11-04 2020-10-13 华为技术有限公司 一种混合接入网络中处理报文的方法及网络设备
US20180376516A1 (en) * 2017-06-21 2018-12-27 Aruba Networks, Inc. Establishing a Datagram Transport Layer Security Connection between Nodes in a Cluster
JP7022540B2 (ja) * 2017-09-08 2022-02-18 キヤノン株式会社 情報処理装置およびその制御方法
US11082255B1 (en) * 2020-09-15 2021-08-03 Hong Kong Applied Science and Technology Research Institute Company Limited Method and an apparatus for establishing secure, low latency, optimized paths in a wide area network
CN112585910B (zh) * 2020-09-15 2022-03-08 香港应用科技研究院有限公司 在广域网中建立安全、低延迟、优化路径的方法和装置
WO2023189016A1 (ja) * 2022-03-31 2023-10-05 株式会社エヌエスアイテクス セキュア中継機器及びデータ送受信システム

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6771594B1 (en) * 1997-03-31 2004-08-03 Intel Corporation Reliable/non-reliable transmission of voice using TCP/UDP based on network quality of service
FR2797543B1 (fr) * 1999-08-12 2004-04-09 Cit Alcatel Procede pour faire communiquer un utilisateur avec au moins une base de donnees
US6636242B2 (en) * 1999-08-31 2003-10-21 Accenture Llp View configurer in a presentation services patterns environment
US6614800B1 (en) 1999-09-02 2003-09-02 International Business Machines Corporation Method and system for virtual private network administration channels
JP2001298479A (ja) * 2000-04-12 2001-10-26 Nec Corp インターネット電話装置
US20080005275A1 (en) * 2000-06-02 2008-01-03 Econnectix, Llc Method and apparatus for managing location information in a network separate from the data to which the location information pertains
JP5138847B2 (ja) * 2001-08-31 2013-02-06 富士通株式会社 ネットワークシステム、ネットワーク中継装置、ネットワーク中継監視装置およびネットワーク運用方法
JP2004153778A (ja) * 2002-09-03 2004-05-27 Ntt Docomo Inc 送受信制御装置、送受信制御方法および送受信制御プログラム
CN1169332C (zh) * 2002-09-29 2004-09-29 清华大学 一种基于客户端反馈的传输协议选择方法
EP1714457A1 (en) * 2004-02-12 2006-10-25 Nokia Corporation Transmission of asset information in streaming services
JP2005260594A (ja) * 2004-03-11 2005-09-22 Oki Techno Creation:Kk ネットワークシステム及び通信装置
US7720983B2 (en) * 2004-05-03 2010-05-18 Microsoft Corporation Fast startup for streaming media
DE102005030108A1 (de) * 2005-02-15 2006-08-17 Rohde & Schwarz Gmbh & Co. Kg Funkübertragungssystem und Verfahren für dessen Betrieb
CN101273650B (zh) * 2005-09-30 2012-01-11 艾利森电话股份有限公司 改进集成无线电接入网络的切换特性的装置和方法
EP1932299A4 (en) * 2005-10-04 2010-05-19 Ericsson Telefon Ab L M METHOD FOR PROVIDING MESSAGE TRANSMISSION USING A CORRESPONDING COMMUNICATION PROTOCOL
US7716731B2 (en) * 2005-10-24 2010-05-11 Cisco Technology, Inc. Method for dynamically tunneling over an unreliable protocol or a reliable protocol, based on network conditions
US8306063B2 (en) * 2006-08-29 2012-11-06 EXFO Services Assurance, Inc. Real-time transport protocol stream detection system and method

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102045768A (zh) * 2009-10-26 2011-05-04 宏碁股份有限公司 数据传输方法及其用户装置与数据传输系统
CN103107949A (zh) * 2011-11-09 2013-05-15 巴比禄股份有限公司 中继装置、中继装置的控制方法
CN104094561A (zh) * 2011-12-01 2014-10-08 汤姆逊许可公司 通过根据可用带宽选择传输协议来获得内容的设备
CN104426732A (zh) * 2013-08-19 2015-03-18 华耀(中国)科技有限公司 一种高速传输隧道的实现方法及系统
CN103618704A (zh) * 2013-11-15 2014-03-05 四川长虹电器股份有限公司 界面客户端与服务器的通信方法
CN106031096A (zh) * 2014-02-06 2016-10-12 加速系统有限责任公司 用于提供多安全链路架构的系统和方法
CN106031096B (zh) * 2014-02-06 2019-07-09 加速系统有限责任公司 用于提供多安全链路架构的系统和方法
CN109792621A (zh) * 2014-07-14 2019-05-21 柏思科技有限公司 用于评估聚合的连接的网络性能的方法和系统
CN109792621B (zh) * 2014-07-14 2023-02-28 柏思科技有限公司 用于评估聚合的连接的网络性能的方法和系统
CN108112282A (zh) * 2015-08-19 2018-06-01 谷歌有限责任公司 基于用户移动网络和数据计划对内容进行过滤
US11218390B2 (en) 2015-08-19 2022-01-04 Google Llc Filtering content based on user mobile network and data-plan
CN107624233A (zh) * 2016-11-24 2018-01-23 深圳前海达闼云端智能科技有限公司 一种vpn传输隧道调度方法、装置以及vpn客户端服务器
CN107624233B (zh) * 2016-11-24 2020-05-15 深圳前海达闼云端智能科技有限公司 一种vpn传输隧道调度方法、装置以及vpn客户端服务器
CN107342937B (zh) * 2017-06-12 2019-08-16 中国电子科技集团公司第五十四研究所 一种空间dtn网络下的数据可靠传输方法
CN107342937A (zh) * 2017-06-12 2017-11-10 中国电子科技集团公司第五十四研究所 一种空间dtn网络下的数据可靠传输方法
CN112449252A (zh) * 2019-09-04 2021-03-05 杭州海康威视数字技术股份有限公司 视频流系统的维护方法、装置、无线网桥设备及存储介质
CN112449252B (zh) * 2019-09-04 2022-11-04 杭州海康威视数字技术股份有限公司 视频流系统的维护方法、装置、无线网桥设备及存储介质
CN112995182A (zh) * 2021-03-04 2021-06-18 广州市百果园信息技术有限公司 媒体流传输方法、装置、设备及介质
CN112995182B (zh) * 2021-03-04 2023-04-25 广州市百果园信息技术有限公司 媒体流传输方法、装置、设备及介质

Also Published As

Publication number Publication date
FR2919778A1 (fr) 2009-02-06
US7894364B2 (en) 2011-02-22
CN101360045B (zh) 2015-01-07
EP2020799B1 (en) 2013-04-24
JP2009033751A (ja) 2009-02-12
JP4669536B2 (ja) 2011-04-13
EP2020799A1 (en) 2009-02-04
US20090034416A1 (en) 2009-02-05

Similar Documents

Publication Publication Date Title
CN101360045B (zh) 通道中传输数据包的方法、存储装置和通道端点
AU2013266624B2 (en) Multi-tunnel virtual private network
US8169911B2 (en) Method for transmitting a data stream with anticipation of acknowledgments, correspondence input device and computer-readable storage medium
US7855955B2 (en) Method for managing frames in a global-area communications network, corresponding computer-readable storage medium and tunnel endpoint
US7516216B2 (en) Generating traffic for testing a system under test
CN107682370B (zh) 创建用于嵌入的第二层数据包协议标头的方法和系统
US7730200B2 (en) Synthetic bridging for networks
Black et al. Differentiated services (DiffServ) and real-time communication
US7720073B2 (en) System and/or method for bidding
US8014389B2 (en) Bidding network
US8605730B2 (en) System and method for multimedia communication across disparate networks
US20090316719A1 (en) Method for managing mechanisms to enhance transmission of data streams in a tunnel, corresponding computer program product, storage medium and tunnel end-point
MXPA01010839A (es) Servidor proxy para mejorar el desempeno y metodo para mejorar el desempeno.
Thompson et al. Tunneling multiplexed compressed RTP (TCRTP)
US8755282B2 (en) Provision of path characterization information in networks
Ibrahim et al. Performance analysis of real time media application in OpenFlow network
RTP Network Working Group B. Thompson Request for Comments: 4170 T. Koren BCP: 110 D. Wing Category: Best Current Practice Cisco Systems November 2005
Pérez et al. Geseq: A generic security and qos model for traffic priorization over ipsec site to site virtual private networks
AMEEN HASHIM et al. Comparing of Real-Time Properties in Networks Based On IPv6 and IPv4

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20150107

Termination date: 20160730

CF01 Termination of patent right due to non-payment of annual fee