CN101094240B - 流控制传输协议多归属功能的实现方法 - Google Patents
流控制传输协议多归属功能的实现方法 Download PDFInfo
- Publication number
- CN101094240B CN101094240B CN2007101432445A CN200710143244A CN101094240B CN 101094240 B CN101094240 B CN 101094240B CN 2007101432445 A CN2007101432445 A CN 2007101432445A CN 200710143244 A CN200710143244 A CN 200710143244A CN 101094240 B CN101094240 B CN 101094240B
- Authority
- CN
- China
- Prior art keywords
- address
- path
- communication path
- destination address
- coupling
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种SCTP多归属功能实现方法,包括以下处理:在流控制传输协议即SCTP偶联的各条通信路径的数据结构中维护预设参数;确定SCTP偶联的通信路径的数量,并确定各条通信路径的源地址和目的地址的地址对应关系,以及确定主用通路;在需要进行主用通路的切换时,轮询SCTP偶联除主用通路之外的其他通信路径,选择合适的通信路径作为新的主用通路。通过本发明,可以为偶联的各条通信路径建立一种地址对应关系,为偶联主用通路的切换做好准备。
Description
技术领域
本发明涉及第三代移动通信技术领域,并且具体地,涉及WCDMA(Wideband Code Division Multiple Address,宽带码分多址)系统中的SCTP(Stream Control Transmission Protocol,流控制传输协议)多归属功能的实现方法。
背景技术
SCTP为用于IP网络的流控制传输协议,是由IETF(InternetEngineering Task Force,互联网工程任务组)在原TCP(ControlTransmission Protocol,控制传输协议)基础上改进而来的专为信令消息在IP网络上传输的一种协议,SCTP是在IP网络上建立下一代高质量通信和电子商务应用的关键部分。
SCTP较TCP和UDP(User Datagram Protocol,用户数据报协议)主要有两大扩展,分别是:SCTP支持多归属功能和单个SCTP偶联,具有多条输入和输出流。SCTP多归属功能是指一条SCTP偶联可以跨越多条通信路径,减少路径冗余。
SCTP位于3G(第三代)核心网设备的传输网络层,主要用于在IP网络中传送PSTN(Public Switched Telephone Network,公共交换电话网)的信令消息和IP网内的信令消息,与其上层用户ULP(上层协议)(M3UA、M2UA、M2PA、SUA等)构成IP信令网的节点。
信令能否可靠、快速地传输是移动通讯系统性能的关键,3G移动通讯系统也不例外,IP信令是WCDMA(Wideband Code DivisionMultiple Access,宽带码分多址接入)的可选信令之一,SCTP是IP信令的承载,如何将信令快速可靠地传输到目的信令点是SCTP需要完成的主要任务,所以如何充分发挥SCTP的协议功能,如何实现SCTP多归属功能,如何检测偶联的各条通信路径,如何感知偶联主用通路出现的故障,并尽快地切换偶联主用通路,关系到SCTP能否在WCDMA系统中快速可靠的传输信令数据,关系到3G移动通讯系统的稳定性和可靠性。
在实际的应用中,两个通信端点(A和B)之间可能会存在多条可用通路,端点A和B之间的偶联如何充分利用这些可用的通路,避免其中一条通路故障而造成的偶联中断,是SCTP多归属功能当初设计的初衷。假定端点A和B之间存在多条可用通路,那么对于每一个端点来说,可能存在多个源地址和目的地址,当偶联需要切换主用通路的时候,如果只是改变偶联主用通路的目的地址,显然是不够的,但是对于如何改变偶联主用通路的源地址,IETF的标准中并没有提供详细的解决方法。
发明内容
考虑到现有技术中存在的上述问题而提出本发明。为此,本发明旨在提供一种SCTP多归属功能的实现方法,其能够通过预先设置每条通讯路径的源地址与目的地址之间的对应关系,从而更方便的实现主用通路的切换。
根据本发明的SCTP多归属功能实现方法包括以下处理:在流控制传输协议即SCTP偶联的各条通信路径的数据结构中维护预设参数;确定SCTP偶联的通信路径的数量,并确定各条通信路径的源地址和目的地址的地址对应关系,以及确定主用通路;在需要进行主用通路的切换时,轮询SCTP偶联除主用通路之外的其他通信路径,选择合适的通信路径作为新的主用通路。
其中,上述的预设参数包括:当前通信路径的源地址、当前通信路径的目的地址、当前通信路径的状态、当前通信路径的错误次数、当前通信路径的错误次数门限值、已经由当前通信路径发送但尚未收到对端确认的数据块的字节数之和、已经由当前通信路径发送但尚未收到对端确认的数据块的个数、当前通信路径的数据重传定时器、以及当前通信路径的心跳定时器。
对于地址关系的确定,可以包括以下两种情况:在第一端点与第二端点的IP地址数相同的情况下,将地址对应关系确定为各条通信路径的源地址与目的地址的一一对应关系;在第一端点与第二端点的IP地址个数不同的情况下,通过预定处理确定各条通信路径的地址对应关系。
具体地,在第一端点的本地地址列表中的IP地址个数小于第二端点的目的地址列表中的IP地址个数的情况下,预定处理包括:步骤一,判断已经确定地址对应关系的通信路径的数量n与SCTP偶联的通信路径数量m的大小关系,在n小于m的情况下,进行到步骤二;步骤二,将n+1赋值给n;步骤三,选择第n条通信路径的目的地址;步骤四,从本地地址列表中选择一个未被前n-1条通信路径使用的源地址,在不存在该源地址的情况下,通过遍历本地地址列表选择一个源地址作为第n条通信路径的临时源地址,并且保证最近k次选择的临时源地址各不相同,其中,k为本地地址列表中的有效IP地址个数;步骤五,用在步骤五中选择的临时源地址和步骤三中选择的目的地址来建立第n条通信路径的临时地址对应关系,发送一个心跳报文,使用步骤四中选择的临时源地址和步骤三中选择的目的地址作为心跳报文的源地址和目的地址,并启动时长为第n条路径重传超时的定时器,如果在定时器超时之前收到SCTP偶联对端回应的心跳应答,则将步骤四中选择的临时源地址作为第n条通信路径的源地址,确定第n条路径地址对应关系,否则,返回步骤四。
在第一端点的本地地址列表中的IP地址个数大于第二端点的目的地址列表中的IP地址个数的情况下,预定处理包括:步骤一,判断已经确定地址对应关系的通信路径的数量n与SCTP偶联的通信路径数量m的大小关系,在n小于m的情况下,进行到步骤二;步骤二,将n+1赋值给n;步骤三,选择第n条通信路径的源地址;步骤四,从目的地址列表中选择一个未被前n-1条通信路径使用的目的地址,在不存在该目的地址的情况下,通过遍历目的地址列表选择一个目的地址作为第n条通信路径的临时目的地址,并且保证最近k次选择的临时目的地址各不相同,其中,k为目的地址列表中的有效IP地址个数;步骤五,用在步骤四中选择的临时目的地址和步骤三中选择的源地址来建立第n条通信路径的临时地址对应关系,发送一个心跳报文,使用步骤四中选择的临时目的地址和步骤三中选择的源地址作为心跳报文的目的地址和源地址,并启动时长为第n条路径RTO的定时器,如果在定时器超时之前收到SCTP偶联对端回应的心跳应答,则将步骤四中选择的临时目的地址作为第n条通信路径的目的地址,确定第n条路径的地址对应关系,否则,返回步骤四。
在上述处理中,n可以等于1。
在确定了第n条路径的地址对应关系后,启动第n条通路的心跳定时器,使用心跳机制来保活第n条通信路径。
在上述处理中,由上层协议通过SET PRIMARY原语将确定的地址对应关系传递给SCTP。
对于主用通路的切换,可以包括以下几个方面:当主用通路的错误次数大于或等于主用通路的错误次数门限值时,选择SCTP偶联的其他通信路径中错误次数最小的通信路径作为新的主用通路。在主用通路发送数据块超时的情况下,选择重传路径重传数据块,如果SCTP偶联在重传路径的定时器超时之前收到对重传的数据块的确认,且确认的源地址和目的地址分别是重传路径的源地址和目的地址,则选择重传路径作为新的主用通路。如果在SCTP偶联建立时,上层协议使用SET PRIMARY原语指定了主用通路,且SCTP偶联当前使用的主用通路与指定的主用通路不一致,则在指定的主用通路恢复通信后,将其作为新的主用通路。
通过本发明,可以为偶联的各条通信路径建立一种地址对应关系,建立这种地址对应关系的目的是降低通信路径之间的关联程度,尽量做到通信路径之间彼此互不影响,偶联的每一条通信路径都使用心跳机制来进行链路检测,为偶联主用通路的切换做好准备。此外,本发明提供的技术方案便于实现,且可靠性高,同时对本端IP网络层的实现方式以及对端的SCTP处理方式没有特殊要求,通用性强,效率高。
本发明的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本发明的进一步理解,并且构成说明书的一部分,与本发明的实施例一起用于解释本发明,并不构成对本发明的限制。在附图中:
图1是根据本发明实施例的SCTP多归属功能实现方法的流程图;
图2-1和图2-2是根据本发明实施例的处理方式一的示意图;
图3是根据本发明实施例的处理方式二的示意图;
图4是根据本发明实施例的重传路径选择处理的流程图;以及
图5是根据本发明实施例的主用通路切换过程中的偶联示意图。
具体实施方式
以下结合附图对本发明的优选实施例进行说明,应当理解,此处所描述的优选实施例仅用于说明和解释本发明,并不用于限定本发明。
根据本发明实施例,提供了一种SCTP多归属功能实现方法。
如图1所示,根据本发明的SCTP多归属功能实现方法包括以下处理(步骤S102-步骤S106):
步骤S102,在SCTP偶联的各条通信路径的数据结构中维护预设参数;
步骤S104,确定SCTP偶联的通信路径的数量,并确定各条通信路径的源地址和目的地址的地址对应关系,以及确定主用通路;此外,还需要检测偶联的各条通路;
步骤S106,在需要进行主用通路的切换时,轮询SCTP偶联除主用通路之外的其他通信路径,选择合适的通信路径作为新的主用通路。
以下将详细描述上述的各个步骤。
(一)在步骤S104中提到的需要维护的预设参数,包括:
SIPaddr:当前通信路径的源地址;
DIPaddr:当前通信路径的目的地址;
State:当前通信路径的状态,例如,1表示可用,0表示不可用;
ErrCount:当前通信路径的错误次数,始值为零,当T3-rtx(数据重传)定时器超时,或者发送HeartBeat(心跳)没有应答,都会使该值加1,当收到对端发送过来的HeartBeat Ack(心跳应答),或者SACK(选择确认)后,会将ErrCount清零;
ErrThresh:当前通信路径的错误次数门限值,当ErrCount大于等于ErrThresh值时,就将当前通路置为不可用(State=0);否则当前通路是可用的(State=1);
OutStandingSize:已经由当前通信路径发送但尚未收到对端确认SACK的数据块(Data Chunk)的字节数之和;
PendingChkNum:已经由当前通信路径发送但尚未收到对端确认的数据块的个数;
T3-rtx:当前通信路径的数据重传定时器;
HBTimer:当前通信路径的心跳定时器。
除了上述参数外,偶联的每一条通信路径还要维护HeartBeat(心跳)的相关参数、RTO(重传超时时长)的相关参数、PMTU(通路最大传输单元)值、Cwnd(拥塞窗口)、Ssthresh(慢启动门限),等等。另外,无论偶联拥有多少条通信路径,这些通信路径都将共同维护一个Rwnd(发送窗口)参数,这是因为,一条偶联只拥有一个目的端点。
(二)步骤S104中提到的地址对应关系的确定
所谓建立偶联各条通路上源地址和目的地址的对应关系,就是要确定偶联的每一条通路中SIPaddr值和DIPaddr值,其目的是尽最大努力降低通信路径之间的关联程度,不要因为某一条通信路径出现故障,而影响到其它通信路径。
处理方式1——对SET PRIMARY原语进行扩展(两个端点的IP地址数相同,将地址对应关系确定为各条通信路径的源地址与目的地址的一一对应关系)
在SCTP的标准中,有一个SET PRIMARY原语,可以用在偶联的客户端和服务器端上,当SCTP偶联建立成功后,ULP可以使用这个原语来设置SCTP偶联的主用通路。通过对SET PRIMARY原语的扩展,ULP可以在收到COMMUNICATION UP通知原语后,把偶联通信路径上源地址和目的地址的对应关系表传递给SCTP。SETPRIMARY原语原型:
SETPRIMARY(偶联ID,目的地传送地址,[起源传送地址])
扩展后的SETPRIMARY原语:
SETPRIMARY(偶联ID,目的地传送地址,[起源传送地址],[地址对应关系表])
在SET PRIMARY原语中加入一个名为地址对应关系表的属性,这是一个可选的属性。我们通过一个例子来说明地址对应关系表的作用。
图2-1示出了端点A和端点B之间的偶联还未建立的情况。如图2-1所示,已知端点A和B将要建立SCTP偶联,端点A拥有A1、A2、A3三个有效的IP地址,端点B拥有B1、B2、B3三个有效的IP地址,已知A1和B1是相互可达的,A2和B2是相互可达的,A3和B3是相互可达的,可以确定A1←→B1,A2←→B2,A3←→B3为三条可用通信路径。
根据SCTP标准的描述,偶联的两个端点成功完成INIT/INITACK/COOKIE ECHO/COOKIE ACK四次握手之后,偶联各条通信路径的参数会得到相应的初始化,这些参数包括SIPaddr值和DIPaddr值,也就是说,在偶联成功建立后,偶联各条通信路径上会形成了一个初步的地址对应关系,但是这种初步的地址对应关系有可能不是我们希望的那样。先介绍可能出现的两种情况:
第一种情况:对端点A来说,有可能形成下面这种地址对应关系:
通路1:A1←→B1
通路2:A1←→B2
通路3:A1←→B3
如果IP地址A1所在子网瘫痪,或者IP地址A1所在的网口出现故障,那么这三条通路将同时中断。通路1、通路2、和通路3彼此关联比较大。
第二种情况:对端点A来说,还有可能形成下面这种地址对应关系:
通路1:A1←→B1
通路2:A2←→B3
通路3:A3←→B2
从图2-1中我们可以知道:A2和B2是相互可达的,A3和B3是相互可达的。如果A2和B3是互不可达的,那么通路2将是不可用的;同理,如果A3和B2是互不可达的,那么通路3也是不可用的。
上述两种情况中提到的问题,是在实现SCTP多归属功能的过程中,必须要面对,而且一定要解决的问题。在这个例子中,我们希望建立下面这种地址对应关系:
通路1:A1←→B1
通路2:A2←→B2
通路3:A3←→B3
图2-2示出了端点A和端点B之间的偶联成功建立之后的相关处理。如图2-2所示,端点A和B的SCTP模块成功完成四次握手之后,会使用COMMUNICATION UP原语通知各自的ULP,随后ULP会使用扩展后的SET PRIMARY原语把偶联通信路径的地址对应关系表传递给SCTP,地址对应关系表的结构如下所示:
SCTP偶联会利用这张地址对应关系表来矫正偶联各条通路上源地址和目的地址的对应关系,形成我们所希望的地址对应关系,接下来,我们会启动偶联各条通信路径的心跳定时器HBTimer,每条通信路径都会定期向偶联的对端发送HeartBeat,并期待收到HeartBeat Ack;当收到一个合法HeartBeat的时候,会立刻向偶联的对端发送一个HeartBeat Ack,以此来保活偶联的各条通信路径,为将在下文中描述的主用通信路径切换做好准备。
采用上述这种方式来确定偶联各条通信路径的地址对应关系是最简单的,但是需要具备一定的前提条件,前提条件就是我们需要对偶联两端IP地址的支持情况和通信路径的有效情况有一个预先的了解,并限制了偶联两端所支持的有效IP地址个数必须相等。客观的说,这种方式具有很大局限性。
处理方式2——同样对SET PRIMARY原语进行扩展,同时对工作方式1的改进(两个端点的IP地址数不同)
如果偶联两端所支持的有效IP地址个数不相等,那么如何确定一条偶联所拥有的可用通路的条数,以及每一条可用通路中源地址和目的地址的对应关系呢?我们还是通过一个例子来说明。
如图3所示,已知端点A和B将要建立SCTP偶联,端点A拥有A1、A2、A3三个有效的IP地址,端点B拥有B1、B2、B3,B4四个有效的IP地址,已知A1和B1是相互可达的,A2和B2是相互可达的,其余IP地址的互通情况不详,可以确定A1←→B1,A2←→B2为两条可用通路。
1、关于如何确定偶联所拥有的可用通信路径的条数
端点A和B的SCTP模块成功完成四次握手之后,端点A的偶联会知道目的地址列表中有四个可用IP地址(B1,B2,B3,B4),本地地址列表中有三个可用IP地址(A1,A2,A3);端点B的偶联会知道目的地址列表中有三个可用IP地址(A1,A2,A3),本地地址列表中有四个可用IP地址(B1,B2,B3,B4),那么这条偶联所拥有的可用通信路径的条数是三条还是四条呢?通过下面这个公式来计算:
偶联可用通信路径的条数=
MAX(本地地址列表中有效IP地址的个数,目的地址列表中有效IP地址的个数)
注:MAX函数的返回值为MAX函数两个参数的最大值
从上述公式我们可以知道,在图3中,端点A和B的偶联建立成功后,该偶联可用通信路径的条数为四条。
对端点A来说,这四条通信路径的目的地址分别为B1、B2、B3、B4,源地址从本地地址列表(A1,A2,A3)中选取,也就是说,对端点A来说,这四条通信路径中,至少有一对通信路径的源地址是相同的。
对端点B来说,这四条通信路径的本地地址分别为B1、B2、B3、B4,目的地址从目的地址列表(A1,A2,A3)中选取,也就是说,对端点B来说,这四条通信路径中,至少有一对通信路径的目的地址是相同的。
在这个例子中,偶联的各条通路有可能形成如下地址对应关系:
通路1:A1←→B1
通路2:A2←→B2
通路3:A3←→B3
通路4:A1←→B4
2、关于如何确定偶联各条通信路径中地址对应关系
当端点A和B之间的偶联成功建立后,各自的SCTP模块会使用COMMUNICATION UP原语通知各自的ULP,随后ULP会使用扩展后的SET PRIMARY原语把偶联通信路径的地址对应关系表传递给SCTP。由于在偶联建立之前仅仅知道A1←→B1,A2←→B2两条可用通信路径,所以地址对应关系表只有两条记录,如下表所示:
端点A和B会分别利用各自的地址对应关系表来矫正偶联两条通路上源地址和目的地址的对应关系,形成通路1和通路2上的地址对应关系,如下所示:
通路1:A1←→B1
通路2:A2←→B2
同时,SET PRIMARY原语还会指定该偶联的主用通路,一般地,ULP会选取地址对应关系表中的一条记录作为该偶联的主用通路。例如,选取通路1(A1←→B1)作为偶联的主用通路。对于已经确定地址对应关系的偶联通路,会马上启动该通路的心跳定时器HBTimer,该通路会定期的使用HeartBeat机制来保活该通路。
由于该偶联拥有四条可用通信路径,所以必须确定通路3和通路4的地址对应关系,端点A和B分别代表了两种不同的处理情况:
第1种情况:偶联本地地址列表中有效IP地址个数小于目的地址列表中有效IP地址个数
对于端点A来说,偶联本地地址列表中有效IP地址个数小于目的地址列表中有效IP地址个数,那么偶联可用通信路径的条数即为目的地址列表中有效IP地址的个数。在这种情况下,偶联各条通信路径的目的地址就可以确定下来,通路3的目的地址为B3,通路4的目的地址为B4,通过如下的处理可以确定通路3和通路4的源地址,从而可以确定通路3和通路4的地址对应关系。
在以下的描述中,n代表已经确定地址对应关系的通信路径的条数;m代表偶联可用通信路径的条数。
步骤1:判断n与m的大小关系,如果n小于m,那么将进行到步骤2,否则处理结束;
步骤2:把n+1赋值给n;
步骤3:选取第n条通信路径的目的地址DIPaddr[n-1];
步骤4:从本地地址列表中选取一个未被前n-1条通信路径所使用的源地址,如果不存在这样的源地址,那么将采用遍历本地地址列表的方式来选取一个源地址SIPTemp作为第n条通信路径的临时源地址,同时还要保证最近k次(包括本次)选择的SIPTemp各不相同;
步骤5:用源地址SIPTemp和目的地址DIPaddr[n-1]来建立第n条通信路径的临时地址对应关系,发送一个心跳报文,用SIPTemp和DIPaddr[n-1]作为心跳报文的源地址和目的地址,并启动一个时长为当前路径(第n条通信路径)RTO的定时器,如果在定时器超时之前收到偶联对端回应的HeartBeat Ack,那就认定SIPTemp为第n条通信路径的源地址,继续执行步骤6;否则跳到步骤4;
步骤6:确定了第n条通信路径的地址对应关系,启动该通路的心跳定时器,使用HeartBeat机制来保活第n条通信路径,为主用通信路径切换做好准备;
步骤7:跳转到步骤2;之后,处理结束。
当端点A开始执行步骤1的时候,n等于2,m等于4,DIPaddr[0]等于B1,DIPaddr[1]等于B2,DIPaddr[2]等于B3,DIPaddr[3]等于B4。
当端点A执行到步骤4的时候,通路3的地址对应关系可以有下列三种选择:
选择一:A3←→B3
选择二:A1←→B3
选择三:A2←→B3
根据步骤4的描述,“选择一”应该是通路3的首选,如果“选择一”不能满足步骤5的要求,那么重新回到步骤4后,将对上述三种选择进行轮选,直到满足步骤5的要求。因为端点A拥有三个有效的本地IP地址,所以还要保证最近3次(包括本次)选择的SIPTemp各不相同。
当通路3的地址对应关系确定下来后,端点A将从步骤7跳到步骤1,继续为通路4确定地址对应关系。
第2种情况:偶联本地地址列表中有效IP地址个数大于目的地址列表中有效IP地址个数
对于端点B来说,偶联本地地址列表中有效IP地址个数大于目的地址列表中有效IP地址个数,那么偶联可用通信路径的条数即为本地地址列表中有效IP地址的个数。在这种情况下,偶联各条通信路径的本地地址就可以确定下来,通路3的本地地址为B3,通路4的本地地址为B4,通过如下的处理可以确定通路3和通路4的目的地址,从而确定通路3和通路4的地址对应关系。
在以下的描述中,n代表已经确定地址对应关系的通信路径的条数,m代表偶联可用通信路径的条数。
步骤1:判断n与m的大小关系,如果n小于m,那么进行到步骤2,否则处理结束;
步骤2:把n+1赋值给n;
步骤3:选取第n条通信路径的源地址SIPaddr[n-1];
步骤4:从目的地址列表中选取一个未被前n-1条通信路径所使用的目的地址,如果不存在这样的目的地址,那么将采用遍历目的地址列表的方式来选取一个目的地址DIPTemp作为第n条通信路径的临时目的地址,同时还要保证最近k次(包括本次)选择的DIPTemp各不相同;
步骤5:用源地址SIPaddr[n-1]和目的地址DIPTemp来建立第n条通信路径的临时地址对应关系,发送一个心跳报文,用DIPTemp和SIPaddr[n-1]作为心跳报文的目的地址和源地址,并启动一个时长为当前路径(第n条通信路径)RTO的定时器,如果在定时器超时之前收到偶联对端回应的HeartBeat Ack,那就认定DIPTemp为第n条通信路径的目的地址,继续执行步骤6;否则跳到步骤4;
步骤6:确定了第n条通信路径的地址对应关系,启动该通路的心跳定时器,使用HeartBeat机制来保活第n条通信路径,为主用通信路径切换做好准备;
步骤7:跳到步骤1;之后,处理结束。
当端点B开始执行步骤1的时候,n等于2,m等于4,SIPaddr[0]等于B1,SIPaddr[1]等于B2,SIPaddr[2]等于B3,SIPaddr[3]等于B4。
当端点B执行到步骤4的时候,通路3的地址对应关系可以有下列三种选择:
选择一:B3←→A3
选择二:B3←→A1
选择三:B3←→A2
根据步骤4的描述,“选择一”应该是通路3的首选,如果“选择一”不能满足步骤5的要求,那么重新回到步骤5后,将对上述三种选择进行轮选,直到满足步骤5的要求。因为端点B拥有三个有效的目的IP地址,所以还要保证最近3次(包括本次)选择的DIPTemp各不相同。
当通路3的地址对应关系确定下来后,端点B将从步骤7跳到步骤1,继续为通路4确定地址对应关系。
处理方式3-不使用SET PRIMARY原语
前两种处理方式提到了用扩展后的SET PRIMARY原语来指定偶联的主用通路和建立偶联部分通路的地址对应关系,这样对ULP提高了要求,也增加了SCTP对ULP的依赖性。在本发明实施例中,在不使用SET PRIMARY原语的情况下,也可以指定偶联的主用通路以及建立偶联各条通路的地址对应关系,以下将详细描述该情况下的本发明。
1、关于如何确定偶联的主用通信路径
偶联的两个端点通过INIT/INIT ACK/COOKIE ECHO/COOKIE ACK四次握手来完成偶联的建立,成功完成四次握手的源地址和目的地址将作为偶联主用通路的源地址和目的地址。
2、关于如何确定偶联所拥有的可用通信路径的条数
通过处理方式2中给出的公式来计算偶联所拥有的可用通信路径的条数。
3、关于如何确定偶联各条通信路径中地址对应关系
偶联成功建立后,就确定了偶联主用通路的地址对应关系,通过与上述处理方式2中描述的两种情况下的处理类似的处理,就可以确定其余通路的地址对应关系。唯一不同的是,在开始执行步骤1的时候,n是等于1的,因为已经确定了一条通路的地址对应关系,这条通路就是主用通路。
通过上述三种处理方式,偶联可以确定每一条通信路径的地址对应关系,每一条通路发送的报文的源地址为该通路的SIPaddr值,目的地址为该通路的DIPaddr值。每一条通信路径都使用心跳机制来进行链路检测。
(三)步骤S106中提到的SCTP偶联主用通信路径的切换
SCTP偶联首选当前的主用通路来传输数据块(Data Chunk),偶联的非主用通路要使用心跳(HeartBeat)来保活,当偶联的主用通路不发送数据的时候,也要使用心跳来保活主用通路,为偶联主用通路的切换做好准备。
当ULP通过SEND原语要求SCTP偶联发送数据的时候,偶联会将用户数据封装成Data Chunk,然后将Data Chunk从偶联当前主用通路发送出去,并接着执行下面六个步骤:
步骤1:启动当前主用通路的T3-rtx定时器,时长为当前主用通路的RTO;
步骤2:将当前主用通路的标识记录在Data Chunk中;
步骤3:将这个Data Chunk放入偶联等待确认队列中;
步骤4:当前主用通路的OutStandingSize值要加上Data Chunk的字节数;
步骤5:当前主用通路的PendingChkNum值要加一;
步骤6:偶联的Rwnd值要减掉Data Chunk的字节数。
如果在主用通路T3-rtx定时器超时之前收到来自偶联对端对Data Chunk的确认(SACK),要执行下面七个步骤:
步骤1:将主用通路T3-rtx定时器杀掉;
步骤2:将主用通路的ErrCount值清零;
步骤3:重新计算主用通路的RTO;
步骤4:主用通路的OutStandingSize值要减去Data Chunk的字节数;
步骤5:主用通路的PendingChkNum值要减1;
步骤6:根据SCTP标准中描述,用SACK中的a_rwnd值来调整偶联的Rwnd值;
步骤7:从偶联等待确认队列中删除Data Chunk。
如果主用通路T3-rtx定时器超时,那么SCTP偶联将重传DataChunk,在重传数据之前,要执行下面三个步骤:
步骤1:将主用通路的ErrCount值加一;
步骤2:根据SCTP标准中描述,来调整Cwnd和Ssthresh;
步骤3:根据SCTP标准中描述,来调整RTO。
如果该偶联拥有多于一条的可用通路,那么偶联将选择一条可用的、非主用通路的路径来重传Data Chunk,此时并不切换主用通信路径。
1、关于如何选择Data Chunk的重传路径以及重传Data Chunk
图4示出了选择重传路径的流程,其核心思想是选取偶联的一条可用通路,并且在偶联的众多通路中,这条通路的ErrCount值是最小的。
找到重传路径后,按照以下步骤来重传Data Chunk:
步骤1:在重传路径上重传Data Chunk;
步骤2:启动当前重传路径的T3-rtx定时器;时长为当前重传路径的RTO;
步骤3:将当前重传路径的标识记录在Data Chunk中;
步骤4:从当前主用通路的OutStandingSize值中减去DataChunk的字节数;
步骤5:当前重传路径的OutStandingSize值要加上Data Chunk的字节数;
步骤6:从当前主用通路的PendingChkNum值中减1;
步骤7:当前重传路径的PendingChkNum值要加1。
当收到对重传Data Chunk的确认的时候,偶联将不重新计算重传路径的RTO。
如图5所示,偶联当前的主用通路是通路1(A1←→B1),当从通路1发送Data Chunk超时后,我们将选择通路2(A2←→B2)来重传Data Chunk,重传报文的源地址为A2,目的地址为B2。偶联当前的主用通路仍然是通路1。
到此我们可以知道,第一次发送Data Chunk将使用偶联当前的主用通路,如果需要重传Data Chunk,那么将选取一个ErrCount值最小的通路来重传Data Chunk。
2、关于如何切换偶联的主用通信路径
对于这个问题,将分三种不同的情况:
第一种情况:当前主用通路的ErrCount值大于或者等于当前主用通路的ErrThresh值
也要按照如图4所示的流程来寻找新的主用通路,新主用通路必须是一条可用通路,并且新主用通路的ErrCount值在偶联的众多通路中是最小的。
第二种情况:从当前Data Chunk的重传路径上,收到来自偶联对端的确认
如图5所示,偶联当前的主用通路是通路1(A1←→B1),当从通路1发送Data Chunk超时后,将选择通路2(A2←→B2)来重传Data Chunk,并启动通路2的T3-rtx定时器,如果偶联在通路2的T3-rtx定时器超时之前,收到对Data Chunk的确认(SACK),并且这个SACK源地址是B2,目的地址是A2,那么将通路2(A2←→B2)置为偶联的主用通路。
第三种情况:ULP使用SET PRIMARY原语指定的主用通路优先级最高
如果在偶联建立之初,ULP使用SET PRIMARY原语指定通路A为偶联的主用通路,而偶联当前的主用通路是通路B,而不是通路A,那么等通路A的通信恢复后,偶联将主用通路切换回通路A。
当偶联完成主用通信路径的切换之后,如果ULP又通过SEND原语来要求SCTP偶联发送数据,那么数据将直接发送到新的主用通路上。
这样,通过本发明,可以为偶联的各条通信路径建立一种地址对应关系,以降低通信路径之间的关联程度,尽量做到通信路径之间彼此互不影响,偶联的每一条通信路径都使用心跳机制来进行链路检测,为偶联主用通路的切换做好准备。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (12)
1.一种流控制传输协议多归属功能的实现方法,其特征在于,包括:
在流控制传输协议即SCTP偶联的各条通信路径的数据结构中维护预设参数;
确定所述SCTP偶联的通信路径的数量,并确定各条通信路径的源地址和目的地址的地址对应关系,以及确定主用通路;以及
在需要进行所述主用通路的切换时,轮询所述SCTP偶联除所述主用通路之外的其他通信路径,选择合适的通信路径作为新的主用通路。
2.根据权利要求1所述的方法,其特征在于,所述预设参数包括:
当前通信路径的源地址、当前通信路径的目的地址、当前通信路径的状态、当前通信路径的错误次数、当前通信路径的错误次数门限值、已经由当前通信路径发送但尚未收到对端确认的数据块的字节数之和、已经由当前通信路径发送但尚未收到对端确认的数据块的个数、当前通信路径的数据重传定时器、以及当前通信路径的心跳定时器。
3.根据权利要求1所述的方法,其特征在于,在第一端点与第二端点的IP地址数相同的情况下,将所述地址对应关系确定为各条通信路径的源地址与目的地址的一一对应关系。
4.根据权利要求1所述的方法,其特征在于,在第一端点与第二端点的IP地址个数不同的情况下,通过预定处理确定各条通信路径的地址对应关系。
5.根据权利要求4所述的方法,其特征在于,在所述第一端点的本地地址列表中的IP地址个数小于所述第二端点的目的地址列表中的IP地址个数的情况下,所述预定处理包括:
步骤一,判断已经确定地址对应关系的通信路径的数量n与所述SCTP偶联的通信路径数量m的大小关系,在n小于m的情况下,进行到步骤二;
步骤二,将n+1赋值给n;
步骤三,选择第n条通信路径的目的地址;
步骤四,从所述本地地址列表中选择一个未被前n-1条通信路径使用的源地址,在不存在该源地址的情况下,通过遍历所述本地地址列表选择一个源地址作为所述第n条通信路径的临时源地址,并且保证最近k次选择的临时源地址各不相同,其中,k为所述本地地址列表中的有效IP地址个数;以及
步骤五,用在所述步骤四中选择的所述临时源地址和所述步骤三中选择的所述目的地址来建立所述第n条通信路径的临时地址对应关系,发送一个心跳报文,使用所述步骤四中选择的所述临时源地址和所述步骤三中选择的所述目的地址作为所述心跳报文的源地址和目的地址,并启动时长为所述第n条通信路径重传超时的定时器,如果在所述定时器超时之前收到所述SCTP偶联对端回应的心跳应答,则将所述步骤四中选择的所述临时源地址作为所述第n条通信路径的源地址,确定所述第n条通信路径地址对应关系,否则,返回所述步骤四。
6.根据权利要求4所述的方法,其特征在于,在所述第一端点的本地地址列表中的IP地址个数大于所述第二端点的目的地址列表中的IP地址个数的情况下,所述预定处理包括:
步骤一,判断已经确定地址对应关系的通信路径的数量n与所述SCTP偶联的通信路径数量m的大小关系,在n小于m的情况下,进行到步骤二;
步骤二,将n+1赋值给n;
步骤三,选择第n条通信路径的源地址;
步骤四,从所述目的地址列表中选择一个未被前n-1条通信路径使用的目的地址,在不存在该目的地址的情况下,通过遍历所述目的地址列表选择一个目的地址作为所述第n条通信路径的临时目的地址,并且保证最近k次选择的临时目的地址各不相同,其中,k为所述目的地址列表中的有效IP地址个数;以及
步骤五,用在所述步骤四中选择的所述临时目的地址和所述步骤三中选择的所述源地址来建立所述第n条通信路径的临时地址对应关系,发送一个心跳报文,使用所述步骤四中选择的所述临时目的地址和所述步骤三中选择的所述源地址作为所述心跳报文的目的地址和源地址,并启动时长为所述第n条通信路径重传超时RTO的定时器,如果在所述定时器超时之前收到所述SCTP偶联对端回应的心跳应答,则将所述步骤四中选择的所述临时目的地址作为所述第n条通信路径的目的地址,确定所述第n条通信路径的地址对应关系,否则,返回所述步骤四。
7.根据权利要求5或6所述的方法,其特征在于,n=1。
8.根据权利要求5或6所述的方法,其特征在于,在确定了所述第n条通信路径的地址对应关系后,启动所述第n条通信路径的心跳定时器,使用心跳机制来保活所述第n条通信路径。
9.根据权利要求3至6中任一项所述的方法,其特征在于,由上层协议通过SET PRIMARY原语将确定的所述地址对应关系传递给SCTP。
10.根据权利要求1所述的方法,其特征在于,
当所述主用通路的错误次数大于或等于所述主用通路的错误次数门限值时,选择所述SCTP偶联的所述其他通信路径中错误次数最小的通信路径作为所述新的主用通路。
11.根据权利要求1所述的方法,其特征在于,
在所述主用通路发送数据块超时的情况下,选择重传路径重传数据块,如果所述SCTP偶联在所述重传路径的定时器超时之前收到对重传的所述数据块的确认,且所述确认的源地址和目的地址分别是所述重传路径的源地址和目的地址,则选择所述重传路径作为所述新的主用通路。
12.根据权利要求1所述的方法,其特征在于,
如果在所述SCTP偶联建立时,上层协议使用SETPRIMARY原语指定了主用通路,且所述SCTP偶联当前使用的所述主用通路与指定的主用通路不一致,则在指定的所述主用通路恢复通信后,将其作为所述新的主用通路。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101432445A CN101094240B (zh) | 2007-08-07 | 2007-08-07 | 流控制传输协议多归属功能的实现方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101432445A CN101094240B (zh) | 2007-08-07 | 2007-08-07 | 流控制传输协议多归属功能的实现方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101094240A CN101094240A (zh) | 2007-12-26 |
CN101094240B true CN101094240B (zh) | 2013-01-16 |
Family
ID=38992266
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101432445A Expired - Fee Related CN101094240B (zh) | 2007-08-07 | 2007-08-07 | 流控制传输协议多归属功能的实现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101094240B (zh) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101867939A (zh) * | 2009-04-15 | 2010-10-20 | 中兴通讯股份有限公司 | 一种基于ip承载的信令网络规划方法和系统 |
CN101741736B (zh) * | 2009-12-09 | 2012-07-18 | 中兴通讯股份有限公司 | 一种发送报文时可切换路径的确定方法及其系统 |
CN101873259B (zh) * | 2010-06-01 | 2013-01-09 | 华为技术有限公司 | Sctp报文识别方法和装置 |
CN102111330A (zh) * | 2010-12-15 | 2011-06-29 | 北京佳讯飞鸿电气股份有限公司 | 双通道视频监控系统的数据传输方法 |
CN102801606B (zh) * | 2012-02-24 | 2015-09-02 | 华北电力大学 | 一种sctp主路径自动切换方法 |
US8589825B2 (en) | 2012-02-28 | 2013-11-19 | Huawei Technologies Co., Ltd. | Communication application triggering method and electronic device |
CN104243396A (zh) * | 2013-06-07 | 2014-12-24 | 阿尔卡特朗讯公司 | 在第一端点与第二端点之间建立关联的方法及相关端点 |
CN110149220B (zh) | 2014-12-30 | 2022-07-29 | 华为技术有限公司 | 一种管理数据传输通道的方法及装置 |
CN105959170A (zh) * | 2016-07-19 | 2016-09-21 | 浪潮(北京)电子信息产业有限公司 | 一种通信连接创建方法、系统及分布式锁组件 |
CN109429220B (zh) * | 2017-06-20 | 2022-03-22 | 中兴通讯股份有限公司 | 一种多制式共偶联的方法及装置 |
CN109803333B (zh) * | 2017-11-17 | 2022-04-19 | 中兴通讯股份有限公司 | 偶联重定向方法及装置 |
CN107896233B (zh) * | 2017-12-28 | 2021-09-10 | 广州汇智通信技术有限公司 | 一种sctp流数据管理方法、系统及设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1533100A (zh) * | 2003-03-18 | 2004-09-29 | ����ͨѶ�ɷ�����˾ | 对基于流控制传送协议的偶联进行保护的方法 |
CN1534951A (zh) * | 2003-04-02 | 2004-10-06 | 华为技术有限公司 | 基于流控制传输协议的多地址选择方法 |
CN101001217A (zh) * | 2006-06-28 | 2007-07-18 | 华为技术有限公司 | 一种媒体网关注册协商的方法 |
-
2007
- 2007-08-07 CN CN2007101432445A patent/CN101094240B/zh not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1533100A (zh) * | 2003-03-18 | 2004-09-29 | ����ͨѶ�ɷ�����˾ | 对基于流控制传送协议的偶联进行保护的方法 |
CN1534951A (zh) * | 2003-04-02 | 2004-10-06 | 华为技术有限公司 | 基于流控制传输协议的多地址选择方法 |
CN101001217A (zh) * | 2006-06-28 | 2007-07-18 | 华为技术有限公司 | 一种媒体网关注册协商的方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101094240A (zh) | 2007-12-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101094240B (zh) | 流控制传输协议多归属功能的实现方法 | |
US8140927B2 (en) | Method and system for reliable multicast data transmission | |
US7502860B1 (en) | Method and apparatus for client-side flow control in a transport protocol | |
CN101924771B (zh) | 一种用于加速应用代理的核心级tcp连接粘合方法 | |
EP1678909B1 (en) | Method, system and article for dynamic real-time stream aggregation in a network | |
WO2017219557A1 (zh) | 数据传输方法及数据传输装置 | |
US8861393B2 (en) | Protocol link layer | |
CN101027644A (zh) | 透明的tcp连接故障切换 | |
US8788682B2 (en) | Communication device, and method, in an internet protocol network, of controlling a communication device | |
CN101547210A (zh) | 一种tcp连接的处理方法和装置 | |
WO1996022641A2 (en) | Network multicasting method using arq techniques for preventing unnecessary retransmissions | |
WO2012083737A1 (zh) | 丢包检测方法、系统和媒体客户端 | |
CN1463401A (zh) | 文件传送系统,文件传送服务器和接收客户机 | |
CN110011967A (zh) | 一种用于数据传输的方法和系统 | |
US6515994B1 (en) | Method of communication in a communications network and apparatus therefor | |
CN1917512B (zh) | 一种建立对等直连通道的方法 | |
CN102769520A (zh) | 基于sctp协议的无线网络拥塞控制方法 | |
KR100998830B1 (ko) | 무선 네트워크에서의 유디피를 이용한 데이터 전송 시스템및 그 방법 | |
JP2004357307A (ja) | IPv6基盤無線網でモバイルノードのハンドオフ時、バインドアップデートメッセージを用いたパケット伝送制御方法及びそのシステム | |
US6826623B1 (en) | Detecting a dead gateway for subsequent non-TCP transmission by sending a first TCP packet and deleting an ARP entry associated with the gateway | |
JP2000207298A (ja) | ファイル転送方法 | |
JP2003316666A (ja) | スタックのセッション数検証方法、コンピュータに実行させるためのスタックのセッション数検証プログラム、コンピュータに実行させるためのスタックのセッション数検証プログラムを記録したコンピュータ読み取り可能な記録媒体、スタックのセッション数検証システム | |
CN105721454B (zh) | 一种基于udp的可靠传输的连接管理方法 | |
CN112055035B (zh) | 一种ng接口的建立方法及装置 | |
KR100501713B1 (ko) | 헤더가 압축된 패킷을 전송하는 네트워크 시스템 및 그의제어방법 |
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 | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20130116 Termination date: 20170807 |