Internet DRAFT - draft-itsumo-sip-mobility-tcp
draft-itsumo-sip-mobility-tcp
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
<draft-itsumo-sip-mobility-tcp-00.txt>
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 <draft-
itsumo-sip-mobility-tcp-00.txt>, 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, <draft-itsumo-sip-mobility-multimedia-00.txt>
[2].
Furthermore, in addition to the assumptions set forward in Section 2
of the draft, <draft-itsumo-sip-mobility-multimedia-00.txt> [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, <original MS IP
address, current MS IP address, original CH IP address>, 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 <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
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 <Alice@MS.home.com>
ITSUMO Group [Page 5]
Internet-Draft Supporting Mobility for TCP with SIP December 2000
To: Bob <Bob@CH.wondernet.com>
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",
<draft-itsumo-sip- mobility-multimedia-00.txt>, 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",
<draft-ietf-dhc-dhcp-dns-12.txt>, 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",
<draft-ietf-mobileip-optim-08.txt>, 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]
