有第三方支持的变种移动SCTP，江大鹏，马跃，地址管理和切换管理是IP移动性的两个关键问题。移动流控制传输协议（mSCTP）提供了无缝切换管理；但是mSCTP的主要问题是地址管理——山国利技记文在线http://www.paper.edu.cn显然,从WLAN到 cellular的垂直切换多数为被动ⅤHO。移动和移动移动P和移动IP6都需要在网络实体HA上注册[19][20]。移动节点在本地冈络申请个长期的IP地址,这个本地地止( Home address,HoA)和本地网络上的固定主机的地止样,当移动节点还在家乡网络时,可以用家乡地址直接通信[4]。移动IP需要FA支持,当移动节点切换到外地时,向木地代理注册其HoA和CoA的绑定关系;CN发给它的数据分组由HA通过隧道转发到FA,再转交给移动节点。移动节点发往CN的数据包无需隊道技术,直接通过标准IP路由发给CN。移动IPV6不再需要HA,当节点发生移动时,MN从外地网络获得一个临时地址(CcoA),并通过当前的网关路由器把绑定更新发送到HA和CN。在更新了绑定关系之后,MN和CN间的通信使用直接路由,不需要隧道,但是这些数据包要包含“源路由”和“家乡地址”的选项;那些之前发往MN家乡地址的包将被HA通过隧道转发给MN通过使用MIP4√v6,节点的移动对传输层及其他上层是透明的;在MIPV4情况下,节点在切换前后都使用HoA通信,但是需要考虑三角路由的影响;MIPv6米用一种相对较好的策略,但是还需要较多的完善[16]。移动移动SCTP( mSCTP)是一种有效的传输层移动性解决方案,是SCTP扩展的移动功能,直接建立在 ADDIP基础卜[8I[16]。 mSCtP的这种能力在一定程度上解决了移动IP切换的问题,但是在偶联建立的过稈中可能会需要移动I的地址管理机制:而一旦偶联建立完成,MN与CN之间的数据传输通过 SctP over lp来进行,不使用MIP的隧道机制[10][11]lAreal[l]定义的 mSCTP可以很好的解决主动VHO。其木质是,在一条激活的SCTP偶联上,atRIArco?MN动态添加、朋除IP地址以及更改主路径的端到Internet端的软切换如图2所示,在区域1,MN使用地址A1Arca-习CN通信。当MN移到交叠区域2时,检测到新接入点的信号,获得新地址A2并配置路图2 SCTP示意图山;这一地址变化通过 ASCONE通知CN;此时,MN有两个可达地址A1、A2。当MN移到区域3时,MN失去了与原接入点的连接,节点撤除A1对应的网络接口,并把这一变化通过 ASCONF通知CN。这一切都发生在有交叠区域存在的前提下,如果没有交叠区, mSCTP就无法工作;这一问题或许可以通过在ASCONF数据块中添加额外的参数来解决[8],但是这不是木文讨论范围。山国武技文在线http://www.paper.edu.cn两端同时切换移动SCTP可以很好的处理通信双方只有一端移动并发牛切换的情况[1]l如果两端同时发生切换,如图3所示,无论是软切换还是硬切换,都必然导致SCTP偶联中断,双方无法继续通信,移动SCTP也就无法起作用。有了 mSctP和移动IP的支持,即使通信两DNSI端同时发生切换,移动节点能够通知对端自己地址变化情况[18]:任何 ASCONF数据包都发往相则sB33应节点的家乡地址,由HA通过隧道转发到移动Routera节点;前提是通信双方之间的偶联必须是以各自BS2BS4的家乡地址HoA建立的,当前的转交地址CcoA是后来添加的。在这种情况下, ASCONE信令包图3通信双方同时切换是用各自IlA交互的,数据包是用各自的CCoA交互这一策略需要网络层和传输层协同运作,操作过程较复杂,而且其要求的前提条件时常难以满足。我们设计了一套方案 TPS-mSCTP处理通信两端同时切换的情况,将在下一节具体描述。协议描述如图3所示, TPS-MSCTP协议除了INSI有通信双方两个实体外,还要有第三方DNS的支持:SCTP偶联建立之前,通信双方分别在各自的DNS上注册;终端既要倮存自己的域名,也要保存通信对端的urR厚ks+Tegistration Re-sponse一 stration R时域名;当终端发生切换时,为了恢复通信,I Registration epns它首先更新自凵的域名和主IP地址的对4Connection establishment l应关系,接着向对端所属DNS服务器查Application询对端当前的主IP地址。Comunication/TPS- mSCTP协议的概要操作步骤如图4所示。假定通信双方CN和MN各自Handover的域名服务器分别为DNS1和DNS2,Handover且都已成功注册。 TPS-mSCTP采用和标准SCTP一样的四次握手方式建立偶联。ReglsTattoiortIy-estragon ouer如2.1节所述:当HL发生时,其他丢包(ε.g,EL)的影响都可以忽略。我们采用HeTY eNtREResponse I如卜的优化策略来减少HL,以达到减少urnectior establish切换丢包的目的:当源端检测到切换发生时(源端发生Application、Communication切换,或收到CN发过来的 NOTIFY),暂停数据发送和相关定时器(cg,T3),等图4 V-MStp协议不意图山国武技文在线http://www.paper.edu.cn到偶联重建后再恢复发送数据和启动相关定吋,当切换发生时,通信两端采用不对称的处理方式,分为源端和目的端:MN为源端,CN为目的端。源端:1)MN发现自己将要发生切换,立刻更新所属DNS上域名和地址的对应关系。同时做三个操作:a)向目的端CN发 NOTIFY-ACK切换通知(如果双方同时发生切换此通知消息必然到不了对端),其中包含QoS选项:带宽、时延等:b)冋日的端CN的DNS发查询消息( QUERY);c)暂停数据发送和相关定时器。2)DNS收到 QUERY消息,回复 QUERY-ANW消息,包含被查询域名当前对应的IP地址3)MN根据收到的 QUERY-ANW消息,判断CN是否发生切换:若CN发生切换,其P地址必然会改变,则以其新地址为目的地址,再发一次 NOTIFY-ACK切换道知反之,不发4)CN收到 NOTIFY-ACK后,判断能否满足其QoS要求,并回复 NOTIFY-BACK,包含对相应QoS选项的答复。5)MN收到 NOTIFY-BACK,表明该SCTP偶联已经重现建立;源端首先恢复切换开始时被暂停的相关定时器,丙根据 NOTIFY-BACK对其QoS的限定,恢复通信。日的端:1)CN发现自己将要发生切换,立刻史新所属DNS上域名和IP地址的对应关系。同吋做两个操作:a)向源端MN发 NOTIFY切换通知(如果双方同时发生切换,此通知消息必然到不了对端),不包含QoS选项;b)向溟端DNS发查询消息( QUERY)。2)DNS操作同源端。3)CN根据收到的 QUERY-ANW消息,判断MN是否发生切换:若MN发生切换,其IP地址必然会改变,则以其新地址为目的地址,再发一次 NOTIFY切换通知;反之,不发。4)MN收到 NOTIFY后,回复 NOTIFY-ACK,其中包含QoS选项:带宽、时延等;暂停数据发送和相关定时器。5)CN收到 NOTIFY-ACK后,判断能否满足其QoS要求,并回复 NOTIFY-BACK包含对相应QoS选项的答复6)MN收到 NOTIFY-BACK,表明该SCTP偶联已经重现建立,源端恢复被暂停的相关定吋器,并根据 NOTIFY-BACK对其QoS的限定,恢复通信。源端和目的端对切换的处理流程是相对独立的,任何一条流程先处理完,表明切换完戊,双方已经恢复通信,则落斤流程的余下步骤不必再进行下去。仿真试验我们在NS-2.29[15]上实现了 mSCTP模块,并仿真了TPS- mSCtP协议。仿真拓扑如图所示山国武技文在线http://www.paper.edu.cnANIB:mBps 2.0ms10.OMbps 2.mdeN31100.0Mbps1010mBps 2. gmsdela图5仿真拓扑图中SCTP发送端是N0,接收端是N7,双方都支持多穴主机,节点N3和N4都有路由器和DNS服务器的功能,N1、N2、N5、N6分别是无线区域A、B、C、D的基站BS。相应的有线部分链路参数在图5中给出;无线部分采用802.11协议,带宽2Mbps。模拟时间150s,发送端从100s开始发送数据。在115.0s时,NO、N7同时发生切换:N0从A区切换到B区,N7从C区切换到D区。假定新的小区都能满足各自的QoS要求,因此,通信双方都可以按正常流程进行切换。40化TPS- mSCTP未优化TPS-mS标准 SCTP10'/s佟6三种协议的发送窗口比较10优化未少化0100120140tine/s图7两种协议的发包序列号的比较山国利技记文在线http://www.paper.edu.cn120(00C80O伏化60未优化40021O1151161113119120121122 Time(图8两种协议在切换过程中的吞吐量比较图6显示了三种协议在试验过程中的发送窗口变化折线图。标准 mSCTP在通信双方发生切换之后通信中断。未采用优化策略的TPS- mSCtP在切换过程中窗口先减小为1,然后在连接重新建立之后通过慢启动恢复到切换前的状态。用了优化策略的TPS- mSCTP在切换过程中窗∏不变;因为在切换过程中,源端暂停了数据发送和相关定吋器,也无法收到对端得SACK,所以发送窗∏保持不变。图7显示了未优化的IPS- mSCtP和优化的TPS- mSCT两种协议在试验过程中发包序列号的斜率比较。从图上易知,在切换之前,两者相同;切换之后,优化的TPS- mSCTP明显要比未优化的斜率要大。也就是说,未优化的TPS- mSCTP协议的发包效率受切换影响较图8显示了未优化的TPS- mSCTP和优化的TPS- mSctP两种协议在切换过程中(从检测到切换发生开始到发送窗口回复到切换前的状态为止)的吞吐量情况的比较。在连接未重新建立之前,两者的吞吐量都为苓:但是在切换信令交互完成,连接重新建立之后,采用优化策略的TPS- mSCTP的吞吐量明显比未优化的增长速率要快的多结论与未来的工作本文首先介绍了标准 mSCtP在切换过程中采取的簧略;接着介绍了无线网络环境下的3种丢包形式:CL、EL、HL:其中,EL和HL是导致垂直切换(VHO)过程中低吞吐率的主要原因,也会对SCTP流和拥塞控訇产生严重影响。并且比较了移动IP和移动Iⅴ6以及移动SCTP。标准 mSCTP可以很好的解决主动ⅤHO,其木质是,在一条激活的SCTP偶联上,动态添加、圳除ⅠP地址以及更改主嵱径的端到端的软切换;但是它无法解决被动VHO(硬切换),更无法解决通信刈方同时切换。因此,本文提出了·种由第三方支持的变种mSCTP,TPS-mSC'IP协议,该协议除了有通信双方两个实体外,还要有第三方DNS的支持。经过仿真试验验证,它能够很好的解决通信双方同时切换情况。当然,TPS- mSCTP协议未对通信双方在切換过程中重新建立连接的安全认证策略进行详细定义,可以采用 IPSCC或其他安全策略来实现。今后,会在网终安全性和协议的健壮性上做进一步的研究和完善。山国武技文在线http://www.paper.edu.cn参考文献[1R. Stewart, et al. Stream Control Transmission Protocol S IETF RFC 2960, 2000[2R. Stewart, et aL. Stream Control Transmission Protocol Implementer's guide[r. IETf Internet Draft, Work inProgress, 20053] Stream Control Transmission Protocol(SCTP)Partial Reliability Extension[S]. IETF RFC 3758, 2004[4] Perkins C IETF RFC 2004. Minimal Encapsulation within IP. 1996[5]R. Stewart, et al. Stream Control Transmission Protocol Dynamic Address Reconfiguration[R]. IETF InternetDraft, Work in Progress, 2005[6 L Ong et al. An Introduction to the Stream Control Transmission Protocol (SCTPIS IETF RFC 3286, 2002[71 Coene Stream Control Transmission Protocol Applicability Statement[S]. IETF RFC 3257, 2002.[8 Riegel M, Tuexen M, Mobile SCTPIS] IETF Internet Draft, Work in Progress, 2003[9 Amando L, Caro Jr, et al. SCTP: A Proposed Standard for Rebust Internet Data Transport. IEEE CoInputer2003,(11):56-63[10 Amando L, Caro Jr Using SCTP Multihoming for Fault Tolerance and Load Balancing[J]. ACM SIGCOMMComputer Communication Rcvicw 2002,32(3),2[ll] Fu ShaoJian, Mohammed Atiquzzaman Improving End-to-End Throughput of Mobile IP Using SCTP [C]Iligh Performance Switching and Routing, 2003, 171-176[12] Van Jacobson. Michael J. Karels Congestion Avoidance and Control. SIGCOMM Computer CommunicationReview. 1988.1113 Li Ma, ct al. A ncw mcthod to support UMTS/ WLAN vcrtical handover using SCTP In IEEE WirelessCommun, vol. ll, no, 4, pp 44-51, Aug 2004.[14]Li Ma, ct aL. SMART-FRX: A Novcl Error-Rccovcry Schcmc to Improvc Pcrformancc of Mobilc SCTP duringWlaN to Cellular Forced Vertical Handover. IEEE Communication Society/WCNC 2005.05. 1377-1382115www.isi.edu/nsnam/ns[16 Wang Li, Xu Ming-wei, Xu Ke, Zhang Rui-ning. A Multicast-linked Lightweight Solution For MobileSCTP-Based IP Mobility. IEEE 2004.04 60-63[17 Samir Chcbbinc, ct al. Framework Architccturc and Mathcmatical Optimization of Vcrtical HandoverDecision on 4G Networks using mSCTP. IEEE 2005.05 235-241[18 Dreibholz, T. Jungmaier, A. Tuxen, M. A New Scheme for IP-based Internet-Mobility. Local ComputerNetworks. 2003. LCN '03. Proceedings. 28th Annual IEEE International Conference on 99-108[19]Perkins, C IP Mobility Support for IPv4, RFC3344, August 2002[20] Perkins, C. IP Mobility Support, RFC2002, October 1996[21]周贤伟等《移动IP与安全》2005Jiang Dapeng, Ma YucComputer Network Research Center, Beijing University of Posts and telecommunicationsBeijing(100876)Location Management and Handover Management are two key issues of Ip mobility. The mobileMobile Stream Control Transmission Protocol(mSCTP) provides seamless handover management; butthe main issue of the mSCTP-based ip mobility is location management--mobile Sctp is alwaysable to keep the association established when only one of two communicating nodes handovers at thesame time, but it will be down if both nodes move to new networks simultaneously. In this paper, wepresents a new type of mobility management(TPS-mSCTP, Third Part Support-mSCTP) for IP-basednetworks that, contrary to conventional approaches, does not focus on the network layer, but on thetransport layer. At the heart of this new mobility concept is the reliable transport protocol SCTP, withan enhanced dynamic address reconfiguration, which supported by the third part--NS(Name Server)Name Server provides a translation service between the Ip address and its unique name. we presentsthe results of the simulation, which prove the strategy is effectiveMobile, mSCTP(Mobile Stream Control Transmission Protacpl), Third Part Support, Wireless