Fast-handoff Scheme for Application Layer Mobility Management

Transcription

1 Fast-handoff Scheme for Application Layer Mobility Management Ashutosh Dutta, Sunil Madhani, Wai Chen Telcordia Technologies Inc., 445 South Street, Morristown, NJ Onur Altintas, Toyota InfoTechnology Center, 4009 Miranda Avenue, Palo Alto, CA Henning Schulzrinne Computer Science Department, Columbia University, New York, NY Abstract In order to ensure proper quality of service for real-time communication in a mobile wireless Internet environment it is essential to minimize the transient packet loss when the mobile is moving between different cells(subnets) within a domain. There are variety of network layer mobility management scheme proposed to provide optimized fast-handoff for multimedia streams during a client s frequent handoff within a domain. This paper introduces few application layer techniques to achieve fast-handoff for real-time RTP/UDP based multimedia traffic in a based signaling environment. These techniques are based on standard based components such as user agent and proxy which usually participate to set up and tear down the multimedia sessions between the mobiles. Unlike network layer based techniques, these do not have to depend upon any additional components such as home agent, foreign agent in the middle of the network, thus provide a network independent solution suitable for application service providers. I. INTRODUCTION In order to provide seamless mobility support to the clients in a Mobile Wireless Internet environment several variations of Mobile IP [14] such as [7], [6], [11], [5] have been proposed. Mobile Wireless Internet Telephony uses [2] signaling to establish and tear down Multimedia sessions. These multimedia sessions are mostly RTP/UDP based and have different delay, error characteristics than standard TCP/IP based application. Application layer mobility management scheme [1], [3] uses based mechanism to provide an alternative mobility solution for RTP/UDP based real-time traffic in the Mobile Wireless Internet. This scheme does not depend upon any components such as home agent or foreign agent in the middle of the network and can be deployed by any third party application service provider easily without much dependence upon the ISP providing network connectivity. During an active session when the mobile moves between cells(subnets) within a domain transient data is lost due to the time taken to complete the Mobile IP registration or. In order to help reduce the transient data loss when the communicating mobiles are far apart or the mobile is far away from the home agent, it is necessary to limit the signaling traversal within the domain itself when the mobile moves within a domain only. There are several layer 3 based Intra-domain mobility management solutions [8], [9], [10] to help reduce the transient data loss when a mobile host moves between the subnets within a domain. In most of the cases there are variations of hierarchical mobility agents installed within a domain, so that when the mobile host moves within a domain, the update request does not go all the way to the correspondent host, but rather is limited to the mobility agent within that domain. Since provides an application layer mobility management solution by itself, it is helpful to augment this approach with fast-handoff techniques for intra-domain mobility management.this can be achieved by limiting the updates due to Intra-domain mobility to the domain itself. Several methods based on signaling have been proposed in this paper. In a typical scenario when the mobile host moves from one subnet to another it obtains a new IP address and sends a new to the (Correspondent Host). During a consecutive move if the happens to be far away from (Mobile Host), then it would take a long time before the data from gets re-directed to the new address, thus resulting in transient data loss. Some of the methods that can be applied to help take care of the transient data loss can be achieved by intercepting and forwarding the transient traffic or by multicasting these packets pro-actively for a short period of time. These proposed methods would help alleviate transient data loss related to continuous hand-offs within a domain. It is assumed that, a router on the media path between and, proxy and B2BUA (Back-to-Back UA) can all co-exist in the same host. This paper is organized as follows. Section II describes the related work in the area of fast-hand-off for Intra-domain mobility. Section III provides several alternatives for based fast-handoff. Implementation details of one these techniques is described in section IV. Section V points out some of the issues that need to be taken care of for a wide scale deployment. We finally conclude the paper in section VI. II. RELATED WORK Once the mobile moves to a new domain, most of the movement is limited to the new domain until the mobile moves out again to new domain. In order to take care of the transient data loss associated with frequent fast-handoff during an Intra-domain mobility several techniques have been proposed. [15] provides an approach of optimized fast handoff based on Mobile IP. HMIP [8], DMA [12], and [9] are some of

2 these approaches that use layer 3 mobility management techniques to take care of the transient data loss. [19] provides a virtual soft-handoff approach for CDMA based wireless IP networks. But it does not provide a generalized solution suitable for any type of network. Thus it is important to design an architecture that can provide fast-handoff of real-time sessions based on based signaling without changing any software on the mobiles or adding any additional components. III. FAST-HANDOFF TENIQUES user agents and servers are the integral parts of a based architecture. Every user in the wireless Internet has a home server, that provides the authentication for the roaming user by interacting with AAA servers and other servers in the visited domain. It is natural to assume that each visited domain has a proxy where a visiting mobile can register during its movement [4]. In some cases however it may be desirable to institute multiple servers to ensure redundancy and proper load balancing. Each visited domain may consist of several subnets. Every move to a new subnet causes the to send a re-invite to the containing its new care-of address. If the re-invite request gets delayed due to path length or congestion, media packets will continue to be directed to the old address. We assume that the visited network has an outbound proxy. We enhance this proxy with the ability to temporarily register visitors [4]. The visitor obtains a temporary, random identity from the visited network and uses it as its address-ofrecord to register with the registrar in the visited network. The informs the home registrar of this temporary address. It then only updates that registration with its current local IP address. This speeds up registrations, but does not address the delayed binding update issue. In this section, we describe several ways to achieve fast handoff using, namely, using a registrar and RTP translator or NAT, using the outbound proxy and B2BUA as a mobility agent. In-transit packets can be redirected to a unicast or multicast address based on the movement pattern of the mobiles and usage scenario. Following subsections describes some possible ways of achieving fast-handoff using based mechanism. Each of these techniques will help reduce the transient data loss associated with the frequent handoffs within a domain. A. registrar and RTP translator or NAT When the correspondent host and mobile hosts are quite far apart in terms of number of hops in between, for every move the mobile makes within a domain while obtaining a new IP address, it sends a to the correspondent host so that the new traffic gets forwarded to the new destination of the mobile. Because of the distance between and and congestion associated with the routing in the network, may get delayed. Thus during this time transient traffic still gets redirected to the old destination, and thus not being received by the mobile. In order to take care of this transient data an application layer approach that combines both Mapping Database -> IPR1 IP3 -> IPR2... IP3 IPR3 RT3 Server Register 2 Intra- Domain fast-handoff Domain -D1 RT1,RT2,RT3 - RTP Translators R IPR2 RT2 3 4 (Transient media) Delay Simulator 1 () IPR1 2 (Re-invite) ( in flight) :p1 RT1 :p1 Fig. 1. RTPTrans based fast-handoff and RTP translator has been designed. This approach provides a complete application layer technique. Each subnet within a domain is equipped with an RTP translator [20] that provides application-layer forwarding of RTP packets for a given addres and UDP port to a given network destination. (RTP applications generally do not care about the source IP address of RTP packets, using just the synchronization source identifier (SSRC) to identify the source.) Figure 1 shows a sequence of operations when a mobile host moves from one network to another. server here can like a registrar or proxy (to be used in the next tecnique). The visited-network registrar described earlier receives the registration update from the that has just moved, and immediately sends a request to the RTP translator in the network that the just left. The request causes the RTP translator to bind to the old IP address used by the and forward any incoming packets to the new address of the. After a set interval or after no media packets have been received by the RTP translator, the RTP translator relinquishes this old address and removes the forwarding table entry, assuming that the re-invite has reached the. This time period should be no longer than a few seconds at most.in the laboratory testbed the distance has been simulated by using a delay simulator between and however. As shown in figure 1, RT1, RT2 and RT3 are RTP translators in the respective subnets. These RTP translators forward the traffic associated with one IP address/port number to another IP address/port number. This RTP translator in each of these subnets would intercept the traffic meant for the mobile host and would send it to the new address of the mobile host after capturing it. As the mobile host moves from one location to another and obtains a new address say, it would send a re-register message to the registrar. The server in turn would look up in its database and would send a message to the appropriate RTP translator to forward the transient traffic to the mobile s new address. This message can be via - CGI [17] or any other UDP based signaling. If the distance between and is large enough, then it would take some 4

3 Fast-handoff Flow diagram (1) Server RT1 RT2 RT3 fast-handoff with B2B UA approach 1 First move Second move IP3 (2) New traffic Re-register 2 Transient Traffic during the move Re-register Transient Traffic during the move -CGI (3) -CGI Forward traffic (:p1 ---> :p1) Forward traffic (:p1 ---> IP3:p1) IP3 Router MA (B2B) UAC UAS UAS UAC Move B2B SDP Delay Simulator (Initial position before move) IPch Fig. 2. RTPTrans based fast-handoff Flow time for re-invite to reach before the new media gets redirected to the proper address. Thus installation of the RTP translators would help take care of the transient data which are in the flight when the node moves. It is noteworthy to mention that, these RTP translators can also forward the transient traffic to a duration limited multicast address until the new data comes from the. There is also a need to make sure that RTP translation and associated aging is taken care of in the previous subnet as the mobile moves to a new one. In the absence of aging not being done properly, there is a likelihood that some other client may like to use this address. Thus it is absolutely essential that there should be a mechanism to age this address out of the virtual interface of the RTP-translator as soon as the traffic redirection stops from the previous RTP translator. It is important to trigger the de-activation as soon as the mobile host stops sending the packets to mobile s previous network. This deactivation is also needed when the mobile goes back to its original subnet. Figure 2 shows a flow diagram for the fast-handoff operation that is done during the intra-domain mobility. B. outbound proxy requests typically traverse a proxy in the visited network, the outbound proxy. This outbound proxy can also support fast handoff, by using the data in the -to- re- INVITE to configure the RTP translator or NAT. The advantage of this approach is that the outbound proxy usually has access to the Session Description Protocol (SDP) information containing the media address and port, thus simplifying the configuration of the translator or NAT. On the other hand, this outbound proxy has to remember the INVITE information for an unbounded amount of time and become call stateful, since it needs the old information when a new re-invite is issued by the. C. B2BUA approach Another way of providing fast-handoff is by using a backto-back user agent (B2BUA). A B2BUA consists of two Fig. 3. B2BUA based fast-handoff approach user agents where one user agent receives a request, possibly transforms it and then has the other part of the B2BUA re-issue the request. A B2BUA in each domain needs to be addressed by the in the visited domain. The B2BUA issues a new request to the containing its own address as the media destination and then forwards the packets, via RTP translation or NAT, to the. This approach has the disadvantage that it requires some cooperation from the. As noted, the INVITE request needs to be addressed explicitly to the B2BUA, as otherwise end-to-end encryption of the body may prevent the B2BUA from inspecting it. Figures 3 and 4 describe one approach of providing fasthandoff by using back-to-back User Agent. Here the B2B UA is co-located with the intra-domain router. In the above picture Mobility Agent acts like B2BUA In this case the mobile host sets up the communication in the beginning via B2B UA. B2BUA in addition to setting up a call between and, it also sets up a call between itself and. As the mobile moves to a new subnet, it sends a Reinvite message and also an message to the B2BUA. A time bound transient session is established between B2BUA and the where a transient data is delivered until the new media arrives from. Figure 5 illustrates the call flow associated with the second approach where B2BUA acts a like third party call controller. D. Fast-handoff using Multicast Agent and B2BUA Locally Scoped multicast may help to avoid packet losses if the can predict that it will be moving to a new subnet shortly. In that case, it informs the visited registrar or B2BUA of a temporary multicast address as its contact or media address. Once the has arrived in its new subnet, it updates the registrar or B2BUA with its new unicast address, while continuing to listen to multicast address. Using scoped multicast is only effective if the can quickly acquire a multicast address. Multicast agent may co-locate with the first-hop router or can co-exist with the B2BUA or proxy. Figures 6 and 7 provide the framework and associated flow using

4 Flow diagram B2B approach 1 (Limits Re-invite to B2B UA within a domain) B2BUA- fast-handoff approach 3 multicast agent IP0 ok ack RTP1 UA1 B2BUA Translator UA2 ok ack RTP2 (SDP with maddr) B2B UA Multicast Agent M1 - local scoped multicast address (duration limited multicast) Internet /Delay Box Re-invite Existing media RTP1 after the move RTP2 Subnet 1 Subnet 0 Fig. 4. B2BUA based fast-handoff Flow Fig. 6. Fasthandoff with Multicast Agent Fast handoff with B2B UA approach 2 flow diagram Re-invite from activates the interceptor at B2BUA IP0 (no SDP) OK ( SDP) UA1 B2BUA UA2 Approach 3 multicast agent -flow B2BUA IP0 UA1 UA2 (no SDP) OK ( SDP) SDP SDP ACK SDP OK ACK ACK SDP OK ACK RTP RTP RTP1 (Interceptor) RTP1 with Maddr Transient data at M addr RTP Fig. 5. B2BUA Third Party Call Control Flow multicast agent and B2BUA. IV. IMPLEMENTATION DETAILS based fast-handoff architecture as described in Figure 1 has been implemented in the multimedia test-bed. The basic components are registrar, UA, RTPtrans. Modified version of Columbia University C 1.51 was used in the experimental test-bed. All the network elements, and proxy are Linux based with kernel version , so that iptables NAT functionality can be used to change the source and destination address of the media packets for different application. In this particular demonstration both RTP translator and proxy do co-exist. Etherape measurement tool was modified so that GUI can show all the packet redirection including media and signaling traffic between different entities on the screen. Tcpdump tool was used to capture the RTP packets with time-stamp on, proxy and mobile host that provides a time scale of how much time it took to forward the packet and packet loss associated. Signal re-invite was delayed to simulate the network Fig. 7. Fasthandoff flow with Multicast Agent congestion or distance between and. Important feature of this experiment was to capture the transient packets as the mobile moves from one subnet while takes a long time to reach the correspondent host. It is the assumption that the common network router is not too far from the subnet routers in each adjacent cell, thus the registration message will not take that much time to reach the server compared to the re-invite signal. Both VIC and RAT tools were used to measure the performance of audio and video streaming traffic. Two methods (e.g., rtptrans and NAT iptables) were used to direct the transient traffic from the previous subnet to the new one. Output of both the approaches are noted below. As can be seen rtptrans tool actually changes the IP address of the outgoing traffic to be that of the RTPtranslator ( server in this case since they co-exist), but iptables with NAT functionality does not change the source IP address rather maintains it to be that of. VIC and RAT application behaved bit differently with rtptrans because of VIC s BIND(). VIC application does not accept the packets if they come with a different source address than what it used to receive before the subnet change.

5 We tried few experiments with re-invite values of 100 ms, 200 ms 500ms, 1 sec, 2 sec and 3 sec delay to show how RTP translator helps delivery of RTP packets and enhances smooth handoff mechanism. A. RTPtrans case Following dump shows some of the results from experiment when used in conjunction with RTPtranslator. When the client is at home : ( ) sends audio packets to ( ). Note that 0:1:2:52:1d:29 is hardware address of (router) and 0:2:2d:d:64:d0 is the hardware address of () Audio session using RAT was established for the fasthandoff using RTP translator. In case of audio session it is (CBR) constant bit rate traffic and in this instance it is 652 UDP bytes. 14:29: :1:2:52:1d:29 0:2:2d:d:64:d : : udp 652 (DF) (ttl 63, 14:29: :1:2:52:1d:29 0:2:2d:d:64:d : The dump above shows the initial packets between and before s move. When the client gets new address after the move. ( ) sends the packet to s original address ( ) which are intercepted by proxy ( ) as evident from the hardware address (0:1:2:51:86:ec) as shown below. The proxy ( ) then forwards it to new address ( ). Note that now the source address is the proxy address, because rtptrans changes the source address. Packets get picked up here 14:30: :1:2:52:1d:29 0:1:2:51:86:ec : : udp 652 (DF) (ttl 63, 14:30: :1:2:52:1d:29 0:1:2:51:86:ec : Packets get forwarded by the proxy to the mobile s new address. 14:30: :1:2:52:1d:29 0:1:2:51:86:ec : : udp 652 (ttl 64, id 9743, len 680) 14:30: :1:2:51:86:ec 0:1:2:52:1d: : : udp 652 (ttl 64, id 9744, len 680) The following data shows when the mobile host is back home. 14:31: :1:2:52:1d:29 0:2:2d:d:64:d : 14:31: :1:2:52:1d:29 0:2:2d:d:64:d : B. Output using Mobility Proxy Video Session using VIC was used alongwith the mobility proxy where iptables NAT functionality was used to mangle the source address before it goes out of the proxy. ( ) has a video session with ( ), following shows data sent from to. at address has a vic session with at address The following shows a tcpdump output. It will be evident later on that source address is not changed after mobility proxy picks up the packet and forwards it to the new address of the mobile. 14:51: :1:2:52:1d:29 0:2:2d:d:64:d : : udp 655 (DF) (ttl 63, id 52226, len 683) 14:51: :1:2:52:1d:29 0:2:2d:d:64:d : : udp 670 (DF) (ttl 63, id 52227, len 698) 14:51: :1:2:52:1d:29 0:2:2d:d:64:d : : udp 645 (DF) (ttl 63, id 52228, len 673) moves and gets new address ( ) sends the packet to s original address ( ) which are intercepted by proxy as evident from the harware addess 0:1:2:51:86:ec of the proxy. Proxy has a virtual address associated with the original address of the mobile, thus is able to pick up the packets. The proxy ( ) then forwards it to new address ( ). Note that when proxy forwards, the source address is still and not (as in the case of using rtptrans) 14:52: :1:2:52:1d:29 0:1:2:51:86:ec : (Packets picked up by ) : udp 241 (DF) (ttl 63, id 54569, len 269) 14:52: :1:2:51:86:ec 0:1:2:52:1d: : (Packets forwarded ) : udp 241 (DF) (ttl 62, id 54569, len 269) 14:52: :1:2:52:1d:29 0:1:2:51:86:ec : : [udp sum ok] udp 128 (DF) (ttl 63, id 54570, len 156) It is to be noted that source address needed to be mangled again at the destination for VIC application when rtptrans mechanism was used, bacause of the type of application associated with VIC. C. Performance Metrics Each of these implementation methods will provide different performance metrics. Number of RTP packets forwarded contributing to smooth handoff will depend upon the type of optimization technique implemented. In case of RTPtrans method the following provides a factor of improvement calculation as an example.

6 Time taken for complete subnet movement including IP address acquisition and layer 2 movement is T. Time taken for to reach is T mostly decided by the distance factor. Time taken to process Re-invite at is T, time taken to register at the proxy is T, time taken for the registrar to forward the packet after capturing is T. Packet generation rate at is P per second. Thus total number of packets lost during a simple with subnet movement is P = (T +T +T )*P Total number of packets lost during using registration and RTPtrans is P = (T +T +T )*P According to [3] a example processing time at the is about 100 msec. Complete registration takes about 150 msec. It takes about 200 msec to complete the subnet movement and IP address acquisition including the layer 2 detection. An audio packet is generated every 20 msec from the source in our experiment. This can be changed by varying the packet size and codec type. We measured the packet delay due to redirection at the registrar is less than 1ms when iptables-based NAT approach was used, where as RTPtrans approach added 4msec. of delay. Thus it will be easy to figure out number of packets that could have been lost. V. DEPLOYMENT ISSUES This section brings out some of the issues that need to be dealt with while dealing with the fast hand-off approaches with based signaling in a real deployment scenario. A. Duplicate packets during handoff There is a likelihood that duplicate packets are received during the mobile s movement between the subnets. RTP packets have their own sequence numbers associated with it, so there can be an agent within the mobile that takes care of making sure that application does not get affected by the duplicate packets and be screened before being sent to the application. B. Scalability Scalability is a big concern when this architecture is deployed in real network, where multiple subnets and DHCP servers are involved. It is important enough to remove the virtual interface address on the RTPtrans server out as soon as the correspondent host starts sending the traffic directly to the mobile after getting a re-invite This virtual interface can timeout after particular time period say a preset expiry time. Another way can be to look for traffic destined to the mobile s old address, if it does not see for a while then it removes the virtual interface from the RTP server thus releasing that IP address to be used by another mobile. But this method may not always work since network congestion may delay the packet delivery properly thus giving an impression that packets are already getting forwarded to the mobile s new address. Another way of de-activating the virtual interface will be to signal the server that packets have started arriving directly from the correspondent host, since the mobility proxy with iptables actually changes the source address to be that of the correspondent host. Another approach will be to send a disrtp signal to the RTPtrans server to disable the virtual interface out from the RTPtranslator. VI. CONCLUSIONS This paper presents several application layer fast-handoff approaches taking advantage of signaling that is used to set up and tear down the multimedia calls. Main motivation behind these techniques has been to reduce the transient loss of the data in flight as the mobile moves from one subnet to another by using application layer signaling. Although several possible architecture for all these possible techniques was presented, implementation approach for one of these techniques was described in details with an analysis of traffic redirection, performance metrics, transient traffic loss during mobile s intra-domain mobility and deployment issues. REFERENCES [1] Henning Schulzrinne, Elin Wedlund, Application Layer Mobility using ACM Mobile Computing and Communications Review, vol. 4, no.3, pp , July 2000 [2] Jonathan Rosenberg, Henning Schulzrinne, Mark Handley, Eve Schooler et al, Session Initiation Protocol, RFC 3261 [3] A.Dutta, F. Vakil, H. Schulzrinne et al., Application Layer Mobility Management Scheme for Wireless Internet in IEEE 3GWireless 01, San Francisco, May 2001 [4] Henning Schulzrinne, registration, draft-schulzrinne-sip-register-02.txt, IETF Draft Work in Progress [5] Alex C. Snoeren and Hari Balakrishnan An End-to-End Approach to Host Mobility. Proceedings of Mobicom 2000 [6] R. Ramjee et al IP Micro-mobility support using HAWAII, draft-ietfmobileip-hawaii-01.txt, IETF, July 2000, work in Progress [7] A. Campbell, J. Gomez et al, Cellular IP draft-valko-cellularip-00.txt, IETF Work in Progress [8] E. Gustafesson, A. Jonsson, and C. Perkins Mobile IP Regional Registration Internet Draft, draft-ietf-mobileip-reg-tunnel-06.txt [9] K. El Malki et al., Low Latency Handoffs in Mobile IPv4, Internet Draft, draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt [10] P. Calhoun et al., Foreign Agent Assisted Hand-off, draft-calhounmobileip-proactive-fa-03.txt. [11] S.Das, A. Mcauley, A. Dutta et al., An Intra-Domain Mobility Management for Next Generation Wireless Networks, IEEE PCS Magazine June 2002 [12] Archan Misra, S.Das, A.Dutta et al., IDMP-based Fast Handoffs and Paging in IP-based 4G Mobile Networks IEEE Communication Magazine March Issue. [13] Archan Misra, S. Das, A.Dutta, Anthony Mcauley, IDMP: An Intradomain Mobility Management Protocol using mobility agents, draftietf-misra-idmp-00.txt, IETF, July 2000 work in progress [14] C. Perkins, IP mobility support, RFC 2002, IETF October 1996 [15] C. Perkins, Kuang-Yeh Wang, Optimized Smooth Handoffs in Mobile IP ISCC 99 [16] Ramon Caceres, Venkat N. Pdamanabhan, Fast and Scalable Wireless Handoffs in support of Mobile Internet Audio, ACM Baltzer Journals [17] J.Lennox, H.Schulzrinne, J.Rosenberg, Common Gateway Interface for, Request for Comments 3050, IETF [18] Pat Calhoun et al, AAA requirements for IP Telephony/Multimedia WG, IETF, Work in Progress [19] F. Vakil, D. Famolari, S. Baba, T. Maeda, Virtual Soft Hand-off in IP- Centric Wireless CDMA Networks, 3G Wireless Conference 2001, San Francisco [20] H.Schulzrinne, S. Casner, R. Fredrick, V. Jacobson, RTP: A trnsport Protocol for Real-Time Application Request for Commenst 1889, IETF.