Internet Engineering Task Force F. Vakil INTERNET DRAFT A. Dutta draft-itsumo-sip-mobility-tcp-00.txt J-C. Chen Date: December 2000 M. Tauil Expires: June 2001 Telcordia Technologies S. Baba N. Nakajima Y. Shobatake Toshiba America Research, Inc. H. Schulzrinne Columbia University Supporting Mobility for TCP with SIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference The distribution of this memo is unlimited. It is filed as , and expires June, 2001. Please send comments to farm@research.telcordia.com or sbaba@tari.toshiba.com or schulzrinne@cs.columbia.edu. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. ABSTRACT This document proposes an approach for using SIP to support mobility for TCP-based applications in a mobile Internet. The proposed approach utilizes a TCP tracking agent, dubbed as SIP_EYE, in mobile stations as well as SIP INFO method to spoof constant endpoints for mobile TCP connections and supports mobile TCP applications in a SIP environment without any changes to TCP. ITSUMO Group [Page 1] Internet-Draft Supporting Mobility for TCP with SIP December 2000 1. Purpose and Scope Along with the strong desire for ubiquitous access to integrated services via the Internet everywhere all the time, several wireless technical forums (e.g., 3GPP, 3GPP2, MWIF) have chosen Session Initiation Protocol (SIP) [1] as the basis of the signaling system of the mobile Internet. Furthermore, these forums have proposed using network layer protocols (e.g., Mobile IP) to support terminal mobility. SIP is expected to become an essential element of the mobile Internet protocol architecture, as well as to provide means of terminal mobility for mobile multimedia applications (see Vakil, et al. [2] for details). Thus, it is desirable to devise an approach that uses SIP to provide means of terminal mobility to mobile TCP applications as well. Such an approach ensures that a mobile Internet can uniformly support all applications of mobile and fixed users with SIP. The objective of this document is to propose an approach that uses SIP to provide means of terminal mobility for TCP applications. In the proposed approach ** the mobile station (MS) is equipped with a SIP_EYE agent that maintains a record of its ongoing TCP connections, ** upon hand-off the MS sends INFO messages to the corresponding hosts (CH) requesting binding of the MS's old address to its new one, and ** MS and CH use IP encapsulation to maintain constant endpoints for MS's ongoing TCP connections. The SIP_EYE agent can be either integrated with SIP UA or remain as a separate entity that interacts with SIP UA within the terminal. The strength of the proposed approach is that it supports TCP without any modifications. Its drawbacks are reduced bandwidth efficiency due to IP encapsulation, and the required modification of the IP stack of the CH for implementing SIP_EYE. This document is organized as follows: Our underlying assumptions are summarized in Section 2. Section 3 focuses on how a tracking agent, i.e., SIP_EYE, and the SIP INFO method are used to support mobile TCP applications. The functions of SIP_EYE as well as a pseudo code for its realization are described in Section 4. Finally, Section 5 concludes the document with a summary and couple of open issues for further study. 2. Assumptions ITSUMO Group [Page 2] Internet-Draft Supporting Mobility for TCP with SIP December 2000 Upon attachement or a hand-off, an MS registers with the home or visited network according to one of the algorithms set forward in Section 3 of the draft, [2]. Furthermore, in addition to the assumptions set forward in Section 2 of the draft, [2], we also assume that: a. Upon successful MS reconfigurations, DHCP dynamically updates the domain same server (DNS) so that the address to name mapping for the MS is current and up-to-date [4, 5]. As we will see later, this dynamic updates allows setting up new TCP connections using current address of the MS. As described in Vakil, et al. [2], in detailed messages throughout the rest of this document we assume that ** Alice (sip:Alice@MS.home.com) is the mobile user who is communicating with Bob (sip: Bob@CH.wondernet.com), ** the domain name for a visited subnet within the same administrative domain is still "home.com", and ** the domain name for a visited network within a different administrative domain is denoted as "visited_adm.com". 3. SIP Mobility Support for TCP Internet applications that require a reliable service from the transport mechanism, e.g., file transfer protocol (FTP), primarily use TCP. Thus, it is essential that the proposed approach support mobile TCP applications without requiring any changes to the TCP. The fundamental abstraction of both SIP and TCP is the connection, however, they identify it differently. A call ID identifies a SIP session/connection, while a pair of endpoints identifies a TCP connection. Each TCP endpoint is identified with a pair of integers (host, port) where host is IP address of the endpoint, and port is the TCP port on the host. However, as a MS roams, its IP address, i.e., the host integer of its TCP endpoint changes. In order to support TCP applications properly, the proposed approach should spoof constant TCP endpoints despite changes in their host integers (i.e., IP addresses) due to roaming of the MSs. The spoofing process is akin to mobile IP with route optimization [6, 7], and its underlying idea is that ITSUMO Group [Page 3] Internet-Draft Supporting Mobility for TCP with SIP December 2000 ** the MS informs the corresponding TCP endpoints about its new IP address, ** the CH(CHs) binds(bind) the initial IP address of the MS with its new temporary (i.e., care of address) IP address, and ** the CH(s) uses(use) encapsulation to send the TCP packets bearing the initial source and destination addresses to the current address of the MS. In order to support TCP applications in a SIP environment, without modifying TCP, the MS should have the capability to maintain a record of ongoing TCP connections and their identifiers. Such a capability is similar to the "netsat" facility of UNIX and Windows operating systems and can be built around it. Thus, the terminal should have an agent (referred to as SIP_EYE, hereafter) that keeps the list of ongoing TCP connections as well as their identifiers. The SIP_EYE is either integrated with the SIP UA or kept as a separate agent that interacts with the SIP UA as necessary. SIP_EYE operates as follows: i. It examines headers of TCP packets to monitor the birth and death of TCP connections as well as identify their endpoints, i.e., the source and destination IP addresses and port numbers of these connections. ii. It maintains a current record of the mobile's ongoing TCP connections' identifiers within the MS. iii. SIP_EYE records a state comprising 3 integers, , per TCP connection. The original MS IP address is the IP address of the MS at the beginning of the TCP session, and current MS IP address is the current IP address of the MS. The original CH IP address is the IP address of the CH at the beginning of the TCP session. iv. Upon a MS's successful registration with the visited network, its SIP UA sends a INFO [3] message (messages) to the SIP UA(s) of CH(s) to request binding of the original IP address of the MS with its current one. The list of necessary address bindings are sent within the INFO message body. The definition of an INFO message body for carrying the address binding list is for further study. v. The CH and the MS use IP encapsulation (either within IP [8] or minimal [9]) to forward the TCP information to each other. The signaling flow for supporting mobility for TCP with SIP is shown in Figure 1. ITSUMO Group [Page 4] Internet-Draft Supporting Mobility for TCP with SIP December 2000 MS Proxies CH | | | | +------------------+ | | |----| MS Reconfigures | | | | | (Figure 1, | | | | | Section 2, | | | | | Reference [3]) | | | | +------------------+ | | | | | | +------------------+ | | |----| Exp/Comp Reg. | | | | | (Figures 2/5 | | | | | Section 3, | | | | | Reference [3]) | | | | +------------------+ | | | | | | INFO | F1 | |---------------------------------------------------->| | | | | 200 OK | F2 | |<----------------------------------------------------| | | | Figure 1. Signaling flow for TCP support *** Message Details for Figure 1 F1 INFO MS --> CH INFO sip:Alice@MS.home.com SIP2/0 Via: SIP/2.0/UDP ara.visited_adm.com:5060 From: Alice To: Bob Call-ID: 567987@ara.visited.com Cseq: 1 INFO Contact:Alice@10.15.20.25 Content-Type:Application/binding Content-Length: ... Original-IP-Addr: 9.10.11.12 New-IP-Addr:10.15.20.25 . . F2 200 OK CH --> MS Via: SIP/2.0/UDP ara.visited_adm.com:5060 From: Alice ITSUMO Group [Page 5] Internet-Draft Supporting Mobility for TCP with SIP December 2000 To: Bob Call-ID: 567987@ara.visited.com Cseq: 1 INFO Contact:Alice@10.15.20.25 Content-Length: 0 Although the above example shows only one ongoing TCP connection, the body of the INFO message can contain original endpoints of several TCP connections, and more address bindings. The key advantage of this approach is that TCP stays as is; though the required IP encapsulation reduces the bandwidth efficiency of the channel, and the realization of the SIP_EYE requires modifying the IP stack of the CH. Since the DHCP interacts with DNS to dynamically update the name to address and address to name mappings, new TCP connections will be established using the current address of the MS. Another alternative for name to address mapping and vice-versa is that instead of a dynamic DNS, one develops a new protocol that allows applications to use SIP registrar for name to address and address to name mappings. The need for such an alternative, its specifications, and its comparison with a dynamic DNS scheme require further study, and is beyond the scope of this document. 4. The SIP_EYE Agent The whole premise of the SIP_EYE agent is to ensure that HMMP supports TCP as is without any modifications to TCP. SIP_EYE is a simple TCP tacking/monitoring agent (similar to "netstat") with small footprint residing within the MSs and CHs. SIP_EYE can be either part of the SIP UA or be a separate entity within a MS (or CH) that interacts with its SIP UA as necessary. Its functions are to ** identify and track ongoing TCP connections of a mobile station, and ** maintain a list of ongoing TCP connection identifiers and their respective corresponding hosts so that the SIP user agent of the mobile sends them INFO messages to bind the original IP address of the mobile with its current one. The SIP_EYE agent tracks both the transmitted and received TCP packets concurrently to create and update the list of ongoing TCP connections in the MS. It runs two concurrent monitoring and updating processes, one for tracks the transmitted packets, and the other received ones. The role of SIP_EYE in hand-off of TCP connections has ITSUMO Group [Page 6] Internet-Draft Supporting Mobility for TCP with SIP December 2000 already been discussed in detail. The following pseudo-code describes the basic TCP tracking operation of the SIP_EYE agent for the simplest case. // SA: Source address of a packet. // DA: Destination address of a packet. // SYN: Synchronization code bit // ACKB: Acknowledgment code bit // FIN: Sender end of byte stream code bit // SEQ: Sequence number // ACKN: Acknowledgement number // Auxiliary variables // CL_ID: Connection Label ID // STAT: Connection Status // STATUS takes values, Setup_Req, Setup_Prog, Established, // Release_Req, Release Ack, Release Accept, Disconnect) // // The TX SIP_EYE Entity. for (;;) { Capture the header of transmitted TCP packets; if (SYN = 1 & ACKB = 0) { Add a TCP entry as follows to the temporary list of connections < original mobile IP address = SA; current mobile IP address = SA; original corresponding IP address = DA; CL_ID = SEQ; STAT = Setup_Req; > } else if (ACKB = 1 & SYN =0) { Get the STAT of the TCP entry, < original mobile IP address = SA; current mobile IP address = SA; original corresponding IP address = DA; CL_ID = ACKN-1; STAT = **; > if ( STAT = Setup Prog ) Set STAT = Established; // A TCP connection is added to the table of ongoing connections. if else (STAT = Release_Ack) { Set STAT = Disconnect; Remove the TCP entry from the table of ongoing connections. } else Error!; } ITSUMO Group [Page 7] Internet-Draft Supporting Mobility for TCP with SIP December 2000 else if { ACKB =1 & FIN = 1 ) { Reset the CL_ID and STAT of the ongoing TCP entry, < original mobile IP address = SA; current mobile IP address = current IP address of the mobile; original corresponding IP address = DA; CL_ID = ** ; STAT = Established; > to CL_ID = SEQ; STAT = Release_Req; } } // The RX SIP_EYE Entity. It is similar to TX entity and they // both run concurrently to manage a single TCP connection list. for(;;) { Capture the header of received TCP packets; if (SYN = 1 & ACKB = 1) { Reset the STAT of the TCP entry ; < original mobile IP address = DA; current mobile IP address = DA; original corresponding IP address = SA; CL_ID = ACKN-1; STAT = Setup_Req; > to STAT = Setup_prog; } else if (SYN = 0 & ACKB =1) { Reset the STAT of TCP_entry; < original mobile IP address = DA; current mobile IP address = DA; original corresponding IP address = SA; CL_ID = ACKN-1; STAT = Release_Req; > to STAT = Release_Ack; } else if { ACKB =1 & FIN = 1) { Reset the STAT of TCP entry < original mobile IP address = DA; current mobile IP address = current IP address of the mobile; original corresponding IP address = SA; CL_ID = ACKN-1; STAT = Release_Ack; > to ITSUMO Group [Page 8] Internet-Draft Supporting Mobility for TCP with SIP December 2000 STAT = Release_ACK; } } // Update of ongoing TCP connection list upon hand-off. // new mobile IP address: The new address that has been assigned to the // mobile upon hand-off. if (hand-off) { while (!eof ongoing list) { < original mobile IP address = original mobile IP address; current mobile IP address = new mobile IP address; original corresponding IP address = original corresponding IP address; CL_ID = **; STAT = Established; } The preceding pseudo-code describes the basic operation of SIP_EYE in an environment whose packet error or loss ratio is negligible and no connection set-up message of TCP is lost or corrupted. It shall be refined further so that it becomes robust enough for use in a wireless environment that has relatively (compared to wireline networks) high packet loss and error and TCP set up messages may be lost or corrupted. Furthermore, the interactions of the SIP_EYE agent with the entities of current SIP user agent as well as its integration within the SIP user agent require further study. In practice, the SIP_EYE agent can be built around either the "netstat" utility of the MS operating system or an SNMP agent in the MS. Further study is required to select one of these alternatives for the realization of the SIP_EYE. 5. Summary and Open Issues We have proposed an approach for supporting mobile TCP applications in a SIP environment. The proposed approach uses a SIP_EYE tracking agent as well as the SIP INFO method to spoof constant endpoints for ongoing TCP connections. Further studies are needed to ** define the INFO message body for carrying address binding list, and ** design the SIP_EYE agent using SNMP or "netstat". 6. Acknowledgments ITSUMO Group [Page 9] Internet-Draft Supporting Mobility for TCP with SIP December 2000 The authors wish to acknowledge the contributions of other members of the ITSUMO(TM) team from Telcordia (P. Agrawal, S. Das, D. Famolari, A. McAuley, P. Ramanathan, and R. Wolff) and Toshiba America Research Incorporated (T. Kodama, and Y. Ohba). (TM): ITSUMO (Internet Technology Supporting Universal Mobile Operation) is a trademark of Telcordia. It is a joint research project of Telcordia Technologies and Toshiba America Research Inc. (TARI). It envisions an end-to-end wireless/wireline IP platform for supporting real-time and non-real-time multimedia services in the future. Its goal is to use IP and third generation wireless technologies to design a wireless platform that allows mobile users to access multimedia services on a next generation Internet. In Japanese, ITSUMO means anytime, always. 7. References 1. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 2. F. Vakil, A. Dutta, J-C. Chen, S. Baba, N. Nakajima, Y. Shobatake, and H. Schulzrinne, "Supporting Mobility for Multimedia with SIP", , work in progress, December 2000. 3. S. Donovan, "The SIP INFO Method", RFC 2976, October 2000. 4. P. Vixie, Editor, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. 5. M. Stapp, and Y. Rekhter, "Interaction between DHCP and DNS", , work in progress, March 2000. 6. C. Perkins, "IP Mobility Support", RFC 2002, October 1996. 7. C. Perkins, and D. B. Johnson, "Route Optimization in Mobile IP", , February 25, 1999. 8. C. Perkins, "IP Encapsulation within IP", RFC 2003, October 1996. 9. C. Perkins, "Minimal Encapsulation within IP", RFC 2004, October 1996. 8. Authors' Addresses Faramak Vakil Telcordia Technologies, Rm 1C-135B ITSUMO Group [Page 10] Internet-Draft Supporting Mobility for TCP with SIP December 2000 445 South Street, Morristown, NJ 07960-6438 farm@research.telcordia.com Ashutosh Dutta Telcordia Technologies, Rm 1C-227B 445 South Street, Morristown, NJ 07960-6438 adutta@research.telcordia.com Jyh-Cheng Chen Telcordia Technologies, Rm 1G-236B 445 South Street, Morristown, NJ 07960-6438 jcchen@research.telcordia.com Miriam Tauil Telcordia Technologies, Rm 1E-209R 445 South Street, Morristown, NJ 07960-6438 miriam@research.telcordia.com Shinichi Baba Toshiba America Research Inc. (TARI) P. O. BOX 136 Convent Station, NJ 07961-0136 sbaba@tari.toshiba.com Nobuyasu Nakajima Toshiba America Research Inc. (TARI) P. O. BOX 136 Convent Station, NJ 07961-0136 nobuyasu@tari.research.telcordia.com Yasuro Shobatake Toshiba America Research Inc. (TARI) P. O. BOX 136 Convent Station, NJ 07961-0136 yasuro.shobatake@toshiba.co.jp Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY, 10027 schulzrinne@cs.coumbia.edu ITSUMO Group [Page 11]