CN1933486A - Ip通信装置及其所组成的ip通信系统 - Google Patents

Ip通信装置及其所组成的ip通信系统 Download PDF

Info

Publication number
CN1933486A
CN1933486A CNA2006101274555A CN200610127455A CN1933486A CN 1933486 A CN1933486 A CN 1933486A CN A2006101274555 A CNA2006101274555 A CN A2006101274555A CN 200610127455 A CN200610127455 A CN 200610127455A CN 1933486 A CN1933486 A CN 1933486A
Authority
CN
China
Prior art keywords
mtu
icmp
communication
bag
mistake
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
CNA2006101274555A
Other languages
English (en)
Other versions
CN1933486B (zh
Inventor
广濑良太
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.)
Yamaha Corp
Original Assignee
Yamaha Corp
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 Yamaha Corp filed Critical Yamaha Corp
Publication of CN1933486A publication Critical patent/CN1933486A/zh
Application granted granted Critical
Publication of CN1933486B publication Critical patent/CN1933486B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/36Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H04L47/365Dynamic adaptation of the packet size

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

一对IP通信装置(称为源装置和目的地装置)在铺设在它们之间的通信路径上使用IP包(如,MAC帧或巨型帧)来执行通信。该IP通信装置检验MAC帧的大小是否超过了预先确定的最大帧大小;之后,将ICMP错误发回到具有包含在MAC帧的规定部分中的IP地址的源装置。源装置还执行路径MTU发现来确定适当的MTU,从而提高通信效率而不会在通信中引起黑洞。

Description

IP通信装置及其所组成的IP通信系统
技术领域
本发明涉及使用IP包来执行通信的IP通信装置及其所组成的IP通信系统。
本申请要求日本专利申请No.2005-270626的优先权,其内容以引用的方式并入本文。
背景技术
题为“RFC 791”的文献(可通过互联网使用URL为http://www.ietf.org/rfc/rfc791.txt来在线检索到)指出在为第三层(即,网络层)安排的网际协议(IP)中,引入了MTU(即,最大传输单元)的概念来根据诸如为第二层(即,数据链路层)安排的以太网(即,注册商标)之类的各种协议以实现信息和数据的存储。MTU指出了通过为第二层安排的协议而可被存储的最大数据长度。
一个IP包(或一个IP数据报)的最大数据长度被定义为65535个八位字节。为了通过MAC帧存储IP包,例如应将其分成1500个八位字节的单元,每一个单元与以太网的最大帧大小(即,MTU)相对应。
为第二层安排了除以太网之外的各种协议;因此存在各种MTU,从而可以根据互联网环境中的多个第二层协议来存储IP包。当把IP包从某一具有相对较大MTU的第二层协议传输到另一具有相对较小MTU的第二层协议时,必须将IP包分为多个片段。当产生片段时,因为每个IP包都附上了包头,所以应相应地增加IP包的总数,从而增加传输数据的总量;这减少了总通信效率。由于这个原因,使用节点到节点通信(或主机到主机通信),其中借助两个节点和(存在于该两个节点之间路径中的)另一节点中具有最小MTU的一个来分割IP包,从而增加通信效率。最初,由路由器来执行包的分割;近年来,由发送源主机来执行包的分割以减小路由器的过载。为了实现这种程序,引入了路径MTU发现方法来发现通信路径中的最短MTU;这在题为“RFC 1191”的文献(可通过互联网使用URL为http://www.ietf.org/rfc/rfc1191.txt来在线检索到)中有介绍。
图1示出了路径MTU发现算法,其通过以下步骤实现。
(1)首先,源主机(H1)在IP头设置一个不分段标志。
(2)一个IP包被发送。在图1的情况下,被发送的IP包的包长度为1500。
(3)当发送数据长度超过MTU的IP包时,路由器不会将发送来的IP包分段,而是将其丢弃。
(4)在未能到达目的地的情况下,根据ICMP(网际控制报文协议)向源主机通知错误。在图1的情况下,例如在路由器R1和R2之间铺设电话线,其中MTU=576(八位字节)。由于这个原因,路由器R1把从源主机H1发送来的包长度为1500八位字节的IP包丢弃;之后,其把类型=3(未能到达目的地)且代码=4(所需的分段和设置的DF)的ICMP消息或ICMP错误通知到源主机H1。ICMP错误包括了指示从路由器R1延伸的路径以MTU=576(八位字节)设置的信息。
(5)此后,每一个都与被通知的MTU相匹配的包被重新发送。在此情况下,源主机H1将其MTU变为576八位字节,以便将包长度为576八位字节的IP包重新发送到目的地主机H2。由于源主机H1和目的地主机H2之间所铺设的路径具有576或更多八位字节的MTU,所以重新发送的IP包完整地到达目的地主机H2。
在上述例子中,一接收到单个ICMP错误就可进行路径MTU发现过程。然而,通常重复上述步骤(2)到(5),直到IP包完整地到达目的地主机H2(换句话说,直到不再发生ICMP通知)。
图2示出了在完成上述路径MTU发现过程后对在源主机H1和目的地主机H2之间发送的IP包进行分割和重组的过程。如上所述,为铺设在源主机H1和目的地主机H2之间的路径设置576八位字节的最小MTU。源主机H1将包长度为1500八位字节的IP包分割为三个包,即,两个包长度均为576八位字节的包和一个包长度为348八位字节的包;因此,源主机H1向目的地主机H2发送三次包。目的地主机H2将这三个包重组(恢复)为原始IP包。
为了提高通信效率,已将最大帧大小超过了(由前述标准定义的)1500八位字节的MAC帧(称为“巨型帧”)用在以太网中。
巨型帧的最大帧大小比以太网的原始MTU(即,1500八位字节)大;换句话说,它们可扩展以太网的原始MTU。不存在清楚地描述巨型帧的最大帧大小的标准;实际上,MTU取决于制造商和产品。
由于上述原因,网络管理者必须检查装置的MTU,装置相互连接在一起以使用各种帧大小来执行通信;因此,网络管理者必须手动设置相互连接的装置以实现在通信路径中所使用的最小MTU。这种手动设置操作是很繁琐的,并且可能会引起设置错误而使通信下降。
例如,当接收端装置接收到比其自身定义的指定帧大小还大的帧时,其仅将在第二层(即,数据链路层)中的那些帧丢弃。这会引起“黑洞”,即发送端装置无法接收到关于发送该帧的回复。题为“RFC2923”的文献(可通过互联网使用URL为http://www.ietf.org/rfc/rfc2923.txt来在线检索到)介绍了一种方法,其中一旦发生黑洞,则使用上述路径MTU发现算法来重新发送减小了MTU的MAC帧。
在发生了黑洞时的路径MTU发现过程中,发送端装置在等待到关于没有来自接收端装置的回复的检测超时之后启动路径MTU发现过程;因此与正常程序相比,在启动路径MTU发现过程之前花了相对较长的时间。
在正常的路径MTU发现过程中,一个发送ICMP错误的节点(或接收端装置)描述了关于ICMP错误中基准MTU的信息;因此,这使得发送端装置可以根据该信息来检验通信路径中的MTU。在发生黑洞时的路径MTU发现过程中,没有将信息送回到发送端装置;因此,例如发送端装置必须使用另一方法来搜索将一步步减小的MTU。
假设,如图3所示,将包从具有MTU=9000(八位字节)的源主机H1发送到具有MTU=7000(八位字节)的目的地主机H2。当源主机H1将帧大小为9000八位字节的包发送到目的地主机H2时,布置在它们之间的交换集线器SH仅将帧大小为9000八位字节的相应MAC帧传输到目的地主机H2。然而,该MAC帧在目的地主机H2中过大,所以目的地主机H2直接将其丢弃。
在上述情况下,源主机H1并未在指定时间段内从主机H2接收到回复,所以源主机H1将该9000八位字节的MAC帧分割为两个各具有一半MTU(即,4500八位字节)的MAC帧,之后,其重新发送各具有MTU=4500(八位字节)的已分割的MAC帧,其中该MTU=4500(八位字节)小于目的地主机H2的MTU=7000(八位字节);因此,目的地主机H2可以将它们可靠地接收并进行处理。
在上述情况下,因为对于可以接收每一个具有MTU=7000(八位字节)的包的目的地主机H2,使用了各具有MTU=4500(八位字节)的包来执行通信,所以势必会降低通信效率。在这种情况下,可以尝试通过改变应用于原始MAC包的减小率来多次执行包的分割,从而计算出一个适当的帧大小。然而,这增加了尝试执行包的分割的次数并且最终减小了通信效率。
发明内容
本发明的一个目的是提供一种IP通信装置,其可以使用巨型帧来执行高效率通信并可消除由网络管理器执行设定的必要。
在本发明的第一方面中,IP通信装置包括:发送器、接收器、以及用于检验接收到的数据的帧大小是否超过预先确定的最大帧大小的帧大小检验器。该IP通信装置还产生ICMP错误,该ICMP错误包括从接收到的数据提取的用来表示源地址的信息和作为MTU的最大帧大小,从而通过发送器将该ICMP错误送回到源地址。这里,在接收到ICMP错误时执行路径MTU发现。
 在本发明的第二方面中,IP通信系统是由多个IP通信装置组成的,该IP通信装置的每一个都包括:发送器、接收器、以及用于检验接收到的数据的帧大小是否超过预先确定的最大帧大小的帧大小检验器。另外,该IP通信装置还产生ICMP错误,该ICMP错误包括从接收到的数据提取的用来表示源地址的信息和作为MTU的最大帧大小。而且,在接收到ICMP错误时至少有一个IP通信装置执行路径MTU发现。
如上所述,当接收到的数据的帧大小超过了最大帧大小时,该IP通信装置将ICMP错误送回到由接收到的数据包含的信息所指定的源地址,其中,该ICMP错误还包括作为MTU的最大帧大小。因此,具有该源地址的源装置可在第二层(即,数据链路层)中检测到作为关于到达该网络层的IP包的错误的超过帧大小错误。另外,该源装置还可检测一个适合于铺设在该源装置和该目的地装置之间的通信路径的适当的MTU。
在接收到ICMP错误时执行路径MTU发现,从而调整发送帧大小来与送回该ICMP错误的IP通信装置的MTU匹配。这样迅速地确定了满足该通信路径的适当MTU,而不会在通信中引起黑洞;因此,可以提高通信效率。
附图说明
将参考以下附图详细描述本发明的这些及其他目的、方面、和
实施方式,其中:
图1是说明了与铺设在经由路由器的两个主机之间的通信线相关的路径MTU发现处理的顺序图;
图2是说明了在位于经由路由器的两个主机之间的通信线中的包的分段的顺序图;
图3是说明了包分割的顺序图,其中相对于铺设在经由交换集线器的两个主机之间的通信线来改变应用于原始MAC包的减小率;
图4是示出了根据本发明优选实施例的IP通信装置的组成的框图;
图5示出了IP包和MAC帧之间的关系;
图6示出了ICMP包的结构;
图7是示出了IP通信装置接收数据的处理的流程图,其中所述数据的帧大小与最大帧大小相比较而被检验;
图8A是示出在接收到ICMP错误时IP通信装置的处理的流程图;以及
图8B是示出由IP通信装置执行的路径MTU发现的详情的流程图。
具体实施方式
将参考附图通过示例进一步详细描述本发明。
图4是示出了根据本发明优选实施例的IP通信装置的组成的框图。接收器11基于以太网接收信号,从而对其最大帧大小都由规定位数限制的MAC帧执行缓冲。帧大小检验器12检验接收到的MAC帧是否符合缓冲的被限制的最大帧大小,换句话说,它检验接收到的每一个MAC帧的帧大小是否超过了缓冲的被限制的最大帧大小。CPU 13分析经过指定处理的接收和缓冲的MAC帧。例如,在第二层(即,数据链路层)中,CPU 13从MAC帧中提取MAC头、数据部分、和FCS(帧检验序列)部分,从而执行错误检验。在第三层(即,网络层)中,CPU 13从MAC帧中提取数据部分,即IP包的IP头和有效负荷(或数据)。在第四层(即,传输层)中,CPU 13提取IP包的有效负荷,即TCP段的TCP头和数据(其中TCP表示传输控制协议)。对于更高次序的层,CPU 13根据例如使用从TCP段中提取的传输控制协议(TCP)的应用程序的数据来执行指定的处理。
另外,CPU 13把要传输的MAC帧通过以太网输出到发送器14。发送器14通过以太网将它们发送出去。
当帧大小检验器12检测到接收到的MAC帧的帧大小超过了被限制的最大帧大小时,CPU 13产生ICMP错误,该ICMP错误随后将由发送器14进行发送。
图5示出了MAC帧和IP包之间的关系。MAC帧包括MAC头、数据、和FCS。MAC头包括目的地MAC地址、源MAC地址、和帧类型。IP包包括IP头和有效负荷。IP头包括源IP地址、目的地IP地址、和有效负荷长度。
图6示出了与ICMP错误对应的包,其包括IP头和ICMP报文。
ICMP报文通常描述了识别错误的内容(或原因)以及引起错误的IP包的前半部分的信息。然而,在帧大小超过被限制的最大帧大小以至于无法完整提取相应IP包时产生的ICMP错误中,通过从接收到的MAC帧的数据中提取IP包的必要部分来产生ICMP报文。
下面将参考图7和图8A及8B来描述并入图4所示IP通信装置中的CPU 13的处理,其中该IP通信装置作为通信路径中的源装置或目的地装置,或作为通信路径中布置在源装置和目的地装置之间的插入装置。
图7是示出了作为通信路径中的插入装置或目的地装置的IP通信装置的CPU 13的处理的流程图。当图4所示帧大小检验器12产生了表示接收到的帧大小超过“可处理的”最大帧大小的帧大小检验结果“NG”时,CPU 13从在接收器11中累积的缓冲中的MAC帧的前半部分提取关于通信路径的源装置的IP地址,以便将ICMP错误送回到该源装置。这是通过图7所示一系列步骤S1、S2、和S3实现的。使用图6所示ICMP包来实现ICMP错误,其中IP头包括提取的源装置的IP地址以及当前指定装置的IP地址,并且在IPv4(即,互联网协议版本4)的情况下,ICMP报文包括“类型=3”(表示“未能到达目的地”)和“代码=4”(表示分段错误)。在IPv6(即,互联网协议版本6)的情况下,ICMP报文包括“包过大”代码。另外ICMP报文还包括一个适当的MTU,其表示在第二层中可由IP通信装置处理的最大帧大小。
当帧大小检验器12产生了表示接收到的帧大小不大于“可处理的”最大帧大小的帧大小检验结果“OK”时,在步骤S4中,对相应MAC帧执行正常处理。
下面将参考图8A和8B描述在通信路径中作为源装置的IP通信装置的CPU 13的处理详情。如图8A所示,当IP通信装置接收到ICMP错误时,其执行路径MTU发现(见步骤S11和S12)。图8B示出了路径MTU发现的详情。在步骤S21中,MTU被设置为应用于IP通信装置的最大值。在步骤S22中,IP头包含的不分段标志被设为“1”。在步骤S23中,通信路径中的IP通信装置向目的地装置发送IP包。
当作为通信路径中的插入装置或目的地装置的IP通信装置接收到一个其帧大小超过上述MTU的MAC帧时,它把表示了未能到达目的地报文的ICMP错误(见图7所示的步骤S3)送回到通信路径中的源装置;因此,作为源装置的IP通信装置接收到这样的ICMP错误。在这种情况下,IP通信装置读取该ICMP错误中所包含的MTU,以便执行对相应的IP包的分段,该相应的IP包将在随后被分段并重新发送到目的地装置。这是由一系列步骤S24、S25、S22和S23实现的。
重复上述步骤直到IP通信装置未接收到上述表示未能到达目的地报文的ICMP错误。因此,可以在铺设于源装置和目的地装置之间的通信路径中产生适当的MTU。
IP通信系统是由多个在通信路径中作为源装置、插入装置和目的地装置的IP通信装置组成的;因此,将每一IP通信装置设计为解决图7的处理(其中检验接收到的帧大小,并且如果必要的话将ICMP错误送回到源装置)和图8A和8B的处理(其中在接收到ICMP错误时执行路径MTU发现)。具体地说,在接收到ICMP错误时步骤S4的处理(当在步骤S1中接收到的帧大小为“OK”时所执行的处理)包括路径MTU发现(见图8A和8B)。
在图8A和8B中,ICMP错误的接收触发了将要执行的路径MTU发现;因此,在路径MTU发现的处理期间再次将ICMP错误通知到源装置。由于在接收到其帧大小超过指定MTU的MAC帧时被通知到源装置的上述ICMP错误包括了适当的MTU,所以随着ICMP错误的第一次接收,源装置可以将其MTU改变为该适当的MTU,从而减少路径MTU发现。
如前所述,本发明并不需限制在上述例举的非限制性实施例中;因此,可以在所附权利要求定义的本发明的范围内提出进一步的修改。

Claims (4)

1.一种IP通信装置,包括:
用于通过网络发送数据的发送器;
用于通过网络接收数据的接收器;
帧大小检验器,其用于检验接收到的数据的帧大小是否超过预先确定的最大帧大小;和
ICMP错误产生装置,其用于产生ICMP错误,所述ICMP错误包括从接收到的数据中提取的用以表示源地址的信息和作为MTU的最大帧大小,
其中,所述ICMP错误由所述发送器发回到所述源地址。
2.一种根据权利要求1所述的IP通信装置,还包括执行装置,其用于在接收到所述ICMP错误时执行路径MTU发现。
3.一种IP通信系统,其包括多个IP通信装置,所述多个IP通信装置的每一个均包括:发送器;接收器;帧大小检验器,其用于检验接收到的数据的帧大小是否超过预先确定的最大帧大小;和ICMP错误产生装置,其用于产生ICMP错误,所述ICMP错误包括从接收到的数据中提取的用以表示源地址的信息和作为MTU的最大帧大小。
4.一种根据权利要求3所述的IP通信系统,其中,所述IP通信装置中的至少一个还包括用于在接收到所述ICMP错误时执行路径MTU发现的执行装置。
CN2006101274555A 2005-09-16 2006-09-15 Ip通信装置及其所组成的ip通信系统 Expired - Fee Related CN1933486B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2005270626A JP4222353B2 (ja) 2005-09-16 2005-09-16 Ip通信装置およびip通信システム
JP2005270626 2005-09-16
JP2005-270626 2005-09-16

Publications (2)

Publication Number Publication Date
CN1933486A true CN1933486A (zh) 2007-03-21
CN1933486B CN1933486B (zh) 2011-01-26

Family

ID=37879102

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2006101274555A Expired - Fee Related CN1933486B (zh) 2005-09-16 2006-09-15 Ip通信装置及其所组成的ip通信系统

Country Status (3)

Country Link
US (1) US20070076618A1 (zh)
JP (1) JP4222353B2 (zh)
CN (1) CN1933486B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101656984A (zh) * 2008-08-20 2010-02-24 日本电气株式会社 路径连接
CN101383760B (zh) * 2007-09-06 2011-12-14 株式会社日立制作所 包传送装置

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8400942B2 (en) * 2008-11-12 2013-03-19 Emulex Design & Manufacturing Corporation Large frame path MTU discovery and communication for FCoE devices
JP5672836B2 (ja) * 2010-08-09 2015-02-18 日本電気株式会社 通信装置、通信方法、および通信プログラム
JP5573709B2 (ja) 2011-01-31 2014-08-20 ブラザー工業株式会社 通信装置
JP5418530B2 (ja) 2011-03-28 2014-02-19 ブラザー工業株式会社 通信装置
JP5805575B2 (ja) * 2012-04-06 2015-11-04 日本電信電話株式会社 中継装置、中継方法及び中継プログラム
JP2015023329A (ja) * 2013-07-17 2015-02-02 富士通株式会社 通知方法、装置及びプログラム
CN103475596B (zh) * 2013-08-30 2016-08-17 广州市动景计算机科技有限公司 基于mtu值的中间件与移动终端的数据传输方法及系统
US9282171B2 (en) * 2014-03-06 2016-03-08 Qualcomm Incorporated Context establishment in marginal grant conditions
US9948568B2 (en) * 2015-09-30 2018-04-17 Red Hat Israel, Ltd. Packet size control using maximum transmission units for facilitating packet transmission
JP6718739B2 (ja) * 2016-05-19 2020-07-08 アラクサラネットワークス株式会社 通信装置および通信方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100453055B1 (ko) * 2002-03-29 2004-10-15 삼성전자주식회사 Ip 네트워크 상에서의 경로 mtu 탐색 방법 및 그 장치
US7512120B2 (en) * 2002-07-09 2009-03-31 Ntt Docomo, Inc. Node, correspondent node, mobility anchor point, and home agent in packet communication system, packet communication system, and path MTU discovery method
US20080008202A1 (en) * 2002-10-31 2008-01-10 Terrell William C Router with routing processors and methods for virtualization
US7050447B2 (en) * 2003-01-24 2006-05-23 Houston Associates, Inc. Multi-level expedited forwarding per hop behavior
US7991918B2 (en) * 2003-06-05 2011-08-02 Nvidia Corporation Transmitting commands and information between a TCP/IP stack and an offload unit
US7869450B2 (en) * 2004-04-05 2011-01-11 Verizon Business Global Llc Method and apparatus for processing labeled flows in a communication access network
US7502474B2 (en) * 2004-05-06 2009-03-10 Advanced Micro Devices, Inc. Network interface with security association data prefetch for high speed offloaded security processing

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101383760B (zh) * 2007-09-06 2011-12-14 株式会社日立制作所 包传送装置
CN101656984A (zh) * 2008-08-20 2010-02-24 日本电气株式会社 路径连接
CN101656984B (zh) * 2008-08-20 2013-10-30 日本电气株式会社 路径连接

Also Published As

Publication number Publication date
JP4222353B2 (ja) 2009-02-12
US20070076618A1 (en) 2007-04-05
JP2007082126A (ja) 2007-03-29
CN1933486B (zh) 2011-01-26

Similar Documents

Publication Publication Date Title
CN1933486A (zh) Ip通信装置及其所组成的ip通信系统
JP4829896B2 (ja) データ破壊を避けることによる改善されたネットワーク性能のための方法、システム及び物品
JP6025880B2 (ja) データ伝送方法、装置及びシステム
US7742454B2 (en) Network performance by dynamically setting a reassembly timer based on network interface
EP2493104B1 (en) Header compression data packet transmission method and device based on retransmission mechanism
US7502860B1 (en) Method and apparatus for client-side flow control in a transport protocol
US20110317719A1 (en) Data link layer headers
EP1421765B1 (en) Extension header compression
US20080159150A1 (en) Method and Apparatus for Preventing IP Datagram Fragmentation and Reassembly
JP2005509381A (ja) ヘッダ圧縮を行う無線通信装置
JP2005509381A6 (ja) ヘッダ圧縮を行う無線通信装置
WO2008085336A2 (en) Improved header compression in a wireless communication network
Pelletier et al. RObust header compression (ROHC): a profile for TCP/IP (ROHC-TCP)
CN1791106A (zh) 响应选择确认重发时改进传输控制协议性能的方法和系统
KR20030059129A (ko) 멀티프로토콜 레이블 스위칭 네트워크에서 스트림 제어전송 프로토콜의 최적화된 사용 방법
CN110730143B (zh) 一种分片数据包处理方法及装置
CN112511377B (zh) 一种基于arq和udp协议的tcp网络加速方法
US7924710B2 (en) Method for transmitting data including an error control mechanism designed for unreliable networks and error resilience applications
US20060107168A1 (en) Method and apparatus for transmitting/receiving virtual block information for multiple segment recovery in data network using transmission control protocol
Iyengar et al. Making SCTP more robust to changeover
CN1744561A (zh) 报文转换过程中的超长报文的处理方法
Jungmaier et al. On SCTP multi-homing performance
Nordmark et al. Rfc 5533: Shim6: Level 3 multihoming shim protocol for ipv6
CN100466506C (zh) 一种数据传输的方法
EP1733527B1 (en) Technique for handling outdated information units

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1100604

Country of ref document: HK

C14 Grant of patent or utility model
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1100604

Country of ref document: HK

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

Granted publication date: 20110126