Internet DRAFT - draft-harsha-sip
draft-harsha-sip
Internet Engineering Task Force ShreHarsha Koti Anand Rao
Document: draft-harsha-sip-00.txt University Of Texas at Arlington
INTERNET DRAFT
Date : July 10th 2001
Expires : Jan 2002
Effective Mobility Support Extension to the Session Initiation Protocol (SIP)
<draft-harsha-sip-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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 material or to cite them
other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract:
The Session Initiation Protocol (SIP) provides advanced signaling and control
functionality for a wide variety of multimedia services over the Internet. Host
Mobility is also becoming important due to the blossoming of laptop computers and
the desire to have continuous network access anywhere the host happens to be.
The current version of SIP however does not support host mobility. In order to
enable SIP to handle real time Mobile Multimedia interactive services, handoff
latency should be very low. This paper presents an architecture to effectively
perform Complete Registration of a mobile terminal in the visited network by
extending the SIP REGISTER request, which also enables the Mobile Terminal to roam
among different administrative domains. The main subject of interest in this paper
is domain hand-off (mobile moves between different administrative domains). For
the mobile user to have undeterred service mobility across administrative domains,
the domain handoff latency should be low. An upper bound for the worst-case domain
hand off delay is enumerated in this paper and an architecture, which performs
effectively with these delay constraints, is also outlined.
2. Conventions used in this document
Effective Mobility Support Extension to the Session Initiation Protocol (SIP)
Expires Jan 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC-2119[4].
3. Introduction
Since SIP [1] is gaining acceptance as the signaling protocol of multimedia and
Internet telephony, it is essential to develop a mechanism for supporting
multimedia mobile applications in a SIP signaling and control environment. In
order to extend SIP to support mobile multimedia interactive services, the handoff
latency has to be minimized. The different mobility management functions to be
performed during a hand-off are Configuration, Registration, Dynamic Address
Binding, Location Management [2]. An efficient way of reducing Hand-Off latency is
to reduce the Registration Latency. The registration latency will be considerable
if the mobile roams to another administrative domain, because the mobile has to be
authenticated and authorized before it can access services. This requires that the
Mobile Terminal information has to travel the wide area Internet to reach the home
network which alone can authenticate and authorize it.
This draft introduces a new architectural model and certain solutions that are
proposed to support efficient complete registration for a mobile terminal in a
Visited network.
4. Architecture of the future Mobile Internet [2,3]
The architecture discussed in drafts [2] and [3] is taken as the basic
architectural model of the future mobile Internet scenario.
5. Complete Registration
5.1 Efficient Architecture to Perform Complete Registration
The signaling flow for complete registration with a visited network is depicted
in Figure 3. This is the method used in [3]
MS VR AAA(v) AAA(h) HR
| REGISTER F1 | | | |
|------------->| Query F2 | | |
| |------------>| Request F3 | |
| | |------------>| Query F4 |
| | | |-------------->|
| | | | |
| | | |<--------------|
| | |<------------| Response F5 |
| |<------------| Answer F6 | |
|<-------------| Response F7 | | |
| 200 OK F8 | | | |
AAA(h): AAA entity of the home network
AAA(v): AAA entity of the visited network.
Figure 3. Complete registration with the visited network
The rationale for registration with a visited network is to reduce the delay of
complete registration and improve hand-off performance, particularly for real-time
interactive services. However, Figure 3 shows no such improvement. The
registration delay is still a round trip delay. In order to reduce the
registration delay, one has to ensure that the whole registration process takes
place in the visited network, and minimize the direct interaction with the home
AAA entity during the registration process.
5.2 Architectural Model for Complete Registration in the Visited Network
The following diagram shows a model that achieves
a) Efficient complete Registration
b) Scalability
c) Reduced handoff latency by reducing Registration latency
d) Roaming of Mobiles between different administrative domains.
In this architecture the cloud Domain is meant to include the components
shown in the following figure.
+---------------+
| MAAAQ |
|---------------|
| SIP Server |
+---------------+
|
|
|
___|___
/ \
/ \
/Regional IP\ ----- Equivalent to ---- +----------+
\ Network / | Domain |
\ / +----------+
---\_______/---
| |
+-----+ +-----+
| ERC | | ERC |
+-----+ +-----+
| |
| |
| |
__|__ __|__
/ \ / \
/ Radio \ / Radio \
/ Access \ / Access \
\ Network / \ Network /
\ / \ /
\_____/ \_____/
| |
| |
+----+ +----+
| MS1| | MS2|
+----+ +----+
D C
Assuming that the MS is moving from Domain1 to Domain2 having same AAAP
CO LOCATED AAAL AND DHCP
+----------+ +-------+ +------------------+ ---------|
| Domain1 |-------| HR |-------| AAAL | DHCP | | |
+----------+ +-------+ | | Server |--| |
+------------------+ | |
| AAAP1 |
----------+ +-------+ +------------------+ | |
| Domain2 |-------| HR |-------| AAAL | DHCP |--| |
+----------+ +-------+ | | Server | | |
+------------------+ |---|----|
|
|
+-----------|-----+
| |
| INTERNET |
+-----------|-----+
|
|
+----------+ +-------+ +------------------+ ----|----|
| Domain3 |-------| HR |-------| AAAL | DHCP | | |
+----------+ +-------+ | | Server |--| |
+------------------+ | |
| AAAP2 |
+----------+ +-------+ +------------------+ | |
| Domain4 |-------| HR |-------| AAAL | DHCP | | |
+----------+ +-------+ | | Server |--| |
+------------------+ |--------|
Figure (6) û Architectural Model showing various components for complete
Registration in the Visited Network
5.3 Signaling Details
The signaling details for the following cases are considered in this draft.
Case I : The MS moves from one administrative domain to another which have
a SA (Security Association)
Case II: The MS moves from one administrative domain to another which DO NOT
have a SA (Security Association)
Sub Case I : The client specifies the AAAP entity as part of the
REGISTRATION request.
Sub case (Ia): The client specifies the AAAP entity in the Registration
Request and the home and visited domains have a security
association with AAAP.
Sub case (Ib): The client specifies the AAAP entity in the Registration
Request and the home and visited domains DO NOT have a
security association with AAAP.
Sub Case II : The client DOES NOT specify the AAAP entity as part of the
REGISTRATION request
Case (I): The MS moves from one administrative domain to another
which have a SA (Security Association)
(This is a slightly modified approach used in [3])
In the case that the home and visitor domain have identical private keys (they
trust each other), they are said to have a security association.
1) The MS that has entered domain 2 acquires the address of the local SIP proxy
from DHCP upon its reconfiguration in the visited network. It then uses this
temporary IP address as the CONTACT field in the Header of the REGISTER request.
The Body of the REGISTER request contains the following
a) Encrypted and signed copy of the user's registration with the home
network.
b) Home Network Information
c) AAAP Information, (optional, TBD)
+------------------------------------------------------------------------+
|IP address |MS's profile|Home AAAL| Home AAAP | Encrypted copy of user's|
|(SIP proxy)| | Info | Info | Registration (optional) |
+------------------------------------------------------------------------+
Figure 7. REGISTER request
2) This REGISTER request is first forwarded to the VR in the visited network. The
VR forwards this information to the AAA visitor entity AAAL2 (F2). Since AAAL2
shares the same private key with AAAL1, it can use this encrypted data to complete
the registration by itself in the visited network. Note that AAAL2 updates the
registration results as necessary, and sends an encrypted signed copy of it to VR
in the Response (F3) for forwarding to the MS in the body of 200 OK (F4).
MS VR2 AAAL2
| REGISTER F1 | |
|---------------->| Query F2 |
| |--------------->|
| | |
| | |
| | |
| | |
| | |
| |<---------------|
|<----------------| Response F3 |
| 200 OK F4 | |
AAAL2: AAA entity of the visited network.
Figure 8. Fast complete registration process with the visited network
Case (II) : The two domains DO NOT have a Security Association (SA)
A public AAA may play the role of a proxy between two administrative domains that
have security associations with the AAAP, and relay AAA messages back and forth
securely. Alternatively, a public AAA may also enable the two domains with which
it has associations, but the domains themselves do not have a direct association,
in establishing a security association, thereby bypassing the public AAA for
carrying the messages between the domains. This may be established by virtue of
having the public AAA relay a shared secret key to both the domains that are
trying to establish secure communication and then have the domains use the keys
supplied by the broker in setting up a security association.
Sub case (I): The client specifies the AAAP entity in the Registration Request
Sub case (Ia): The client specifies the AAAP entity in the Registration Request
and the home and visited domains have a
security association with AAAP.
a) The client can include the optional AAAP info in the body of the
registration request to the VR. This AAAP address is of the form
AAAPname@AAAPdomain.com . This enables the SIP redirect servers to locate
the AAAP server. (All the proxies traversed to reach the AAAP is inserted in
the Record-Route Header)
b) The SIP Redirect Sever in the visited domain (VR) appends the address of the
AAAL visitor entity in the SIP REGISTER method header and sends it across to
the AAAP that is specified as part of the client's request.
c) The AAAP checks whether it has a security association (one of its trusted
AAAL's) with the AAAL in the trusted domain. If it does then it relays a
shared secret key to the AAAL's for both the home and visited domains and
the two AAAL's use this key to perform AAA.
d) The AAAL in the visited domain then decrypts the registration info using the
shared secret key and performs the registration in the visited domain. It
also updates the registration results to the HR.
e) Once this is over, DHCP server will be notified about the successful
negotiation and the server can provide the requested resources to the
client. If it is not authorized, server will be informed to terminate the
service to the client.
Sub case (Ib): The client specifies the AAAP entity in the Registration Request
and the home and visited domains DO NOT have a security association with AAAP.
a) If the AAAP that the client has specified does not have a SA with the AAAL
of the visited domain, the AAAL of the visited domain forwards the REGISTER
request to the AAAP that it has SA.
b) This AAAP then forwards this request to the AAAP that the client has
specified and REGISTRATION has to take place in the home domain.
The details of AAAP discovery are explained in the next section
Sub case (II): The client does not specify the AAAP entity in the Registration
Request.
The challenge here is that the AAAL2 (visited AAAL) has to find the AAAP, which
can provide AAA services to the mobile terminal.
1) The AAAL2 can send the home network's information to the AAAP entity that it
has Security Association with.The Visited AAAL info is appended the REGISTER request
body as shown in the figure(9)
+-----------------------------------------------------------------------------+
|IP address |MS's |Home AAAL| Home AAAP | Encrypted copy of user's|Visited |
|(SIP proxy)|profile| Info | Info | Registration (optional) |AAAL Info|
+-----------------------------------------------------------------------------+
Figure 9. SIP REGISTER request for Inter AAAL hand off
2) The AAAP entity checks this info and checks whether (TBD, how this is
accomplished) it has the private key necessary to provide AAA services. If
it does, DHCP server will be notified about the successful negotiation and
the server can provide the requested resources to the client. If it is not
authorized, server will be informed to terminate the service to the client.
3) If the trusted AAAP is not able to provide AAA services, it does the
following
a) Appends the AAAP visitor information (address information) to the SIP
REGISTER request body as shown on figure (10)
+---------------------------------------------------------------------------+
|IP address |MS's |Home | Home| Encrypted copy |Visited |Visited |
|(SIP proxy)|profile| AAAL| AAAP| of user's |AAAL |AAAP |
| | | Info| Info| Registration (optional)|INFO |info |
+---------------------------------------------------------------------------+
Figure 10. SIP REGISTER request for Inter AAAP hand off
b) Multicasts a AAAP discover message to the selected multicast group of
all AAAP's with the home network info as part of the message.
c) The trusted AAAP of the home network provides the AAA services to the
client. DHCP server will be notified about the successful negotiation
and the server can provide the requested resources to the client. If
it is not authorized, server will be informed to terminate the service
to the client.
The details of AAAP discovery are explained in the section 6.2
6. Domain hand-off latency
6.1 Different delays
According to specifications in [2] the upper bound for domain hand off latency is
set to around 1 sec. Thus any mobility management scheme which supports domain
handoff has to meet this upper bound.
The domain handoff latency can be broken up into
1. RE INVITATION DELAY [4 X round trip delay of MS-CH_MS] = 200ms
[Assuming a round trip delay in the continental US as 50ms]
a) One round trip for resource reservation.
b) Two round trip delays for COMET's and their acknowledgements. COMET
messages make sure that end-to-end communication takes place only if
adequate resources are reserved. (More details about COMET can be
found in [24])
c) One Round trip delay for Re-invitation and its acknowledgement.
2. RECONFIGURATION DELAY û 100ms max
3. REGISTRATION DELAY (Will be discussed next)
4. OLD BEARER PATH RELEASE DELAY (50ms)
Thus we are left with around 600ms worst case delay to perform complete
registration in the visited network to satisfy the real time constraints for
domain hand off.
6.2 To find the Worst case Complete Registration delay in the Visited Network.
The worst-case delay occurs when the mobile moves from one administrative domain
to another, which are managed by different AAAP entities. Thus the mobile is
moving across the AAAP boundaries. This is known as inter-AAAP handoff.
Lets consider a situation where in the mobile moves from home Domain belonging to
one AAAPH (HD) to another administrative domain (VD) managed by a different AAAP.
+----------+ +-------+ +------------------+ ---------|
| Domain1 |-------| HR |-------| AAAL | DHCP | | |
+----------+ +-------+ | | Server |--| |
+------------------+ | |
| AAAPH |
+----------+ +-------+ +------------------+ | |
| HD |-------| HR |-------| AAAL | DHCP |--| |
+----------+ +-------+ | | Server | | |
| +------------------+ |---|----|
| |
| |
| +-----------|-----+
| | |
| | INTERNET |
| +-----------|-----+
| |
| |
+----------+ +-------+ +------------------+ ----|----|
| VD |-------| HR |-------| AAAL | DHCP | | |
+----------+ +-------+ | | Server |--| |
+------------------+ | |
| AAAPV |
+----------+ +-------+ +------------------+ | |
| Domain4 |-------| HR |-------| AAAL | DHCP | | |
+----------+ +-------+ | | Server |--| |
+------------------+ |--------|
Figure 11. Illustrating Inter AAAP handoff.
Since the AAAL entities are configured with the address of its AAAP entity,
without much routing and latency it can forward the mobile's registration info in
the form of SIP REGISTER message to the AAAP entity.
Since the AAAPV does not share does not share a Security Association with AAAL
entity of the home domain (AAALH), it cannot provide registration services the
mobile in the visited domain.
So it is necessary for us to find the AAAP that can provide registration services
to the mobile. This is termed as AAAP discovery. All AAAP's maintain a select
multicast address where it can forward the mobile's home AAAL (as part of the SIP
REGISTER request) info to other AAAP's. Since its is not feasible to maintain a
multicast address to all existing AAAP's due to scalability issues, hierarchical
addressing has to be used. It's to be studied further how this hierarchical
addressing is provided.
|----Reply that home AAAP was found (7)-----------------------
| |
| |
+---|---+ +|-----+
| AAAPV |------- | AAAPH|
+--|----+ | +-------+ |----+--|---+
| | +-------+ | AAAP3|-|--- +------+ | WAN |LINK(8)
WAN| LINK(2) |--| AAAP1 ||-----+-------+ | | AAAP7|---| |
+--|----+ | +-------+| | +------+ +--|---+
| AAALV | | | +-------+ | |AAALH |
+-------+ | |-----| AAAP4 | | +------+ +------|
| DHCP | | +-------+ |---| AAAP8| |DHCP |
| Server| | +------+ |Server|
+---|---+ | +-------+ +-------+ +--|---+
| |--| AAAP2 ||---- | AAAP5 | LAN | LINK(9)
LAN | LINK(1) +-------+| +-------+ |
+-------+ | +--|---+
| VR | | +-------+ | HR |
+----|--+ |-----| AAAP6 | +--|---+
| +-------+ |
| Updating Registration results
+----|---+ to the Home Domain
| Visited| |
| | +--|-----+
| Domain | | Home |
+---|----+ | Domain |
| +--|-----+
| |
|----------Updating Registration Results to MS-----------------|
Figure 12. AAAP discovery stage
The various links and their purposes are illustrated as below
Link #1 Lan Link Between VR and AAALV
Link #2 Wan Link Between AAALV and AAAPV
Link #3 Wan Link Between AAAPV and AAAP1
Link #4 Wan Link Between AAAP1 and AAAP3
Link #5 Wan Link Between AAAP3 and AAAP7
Link #6 Wan Link Between AAAP7 and AAAPH
Link #7 Wan Link Between AAAPH and AAAPV
Link #8 Wan Link Between AAAPH and AAALH
Link #9 Lan Link Between AAALH and HR
Figure (12) illustrates how the AAAP discovery takes place during an inter AAAP
handoff. The SIP REGISTER message as explained earlier is relayed between various
AAAP entities. Thus it is assumed that all AAAP and AAAL entities are SIP User
Agent enabled. Since AAAP's are assumed to be geographically distributed they are
assumed to be WAN links. The SIP Registrar Servers (HR, VR) and the AAAL's are
part of one administrative domain and hence considered as a LAN link. (This does
not preclude them to be geographically distributed, but they are assumed to have a
strong Security Association with each other)
The SIP REGISTER request contains the home AAAL info as part of the body of the
message. The AAAP that has the Security association with that home AAAL responds
to the visited AAAP entity saying that it can provide registration services to the
client. The home AAAL and home AAAP combination is cached in the visited AAAP
database so that any further requests from the home AAAL can directly be routed to
the corresponding home AAAP.
In the figure shown, since AAAPH has security association with AAALH, it responds.
It takes 4 WAN hops to reach the AAAPH in this case. The AAAPH can then reach the
AAAPV in one hop since the REGISTER request contains the visited AAAP info. The
latency is thus one WAN hop instead of 4.The AAAPH then has to update the REGISTRATION
results to the HR and also to the MS.
Assuming
a) End-end propagation delay in the continental United States as 25 ms,
b) "N" is the number of WAN hops required to reach the AAAP.
We can arrive at the following upper bound delay estimate
--------------------------------------------------------
Process Delay (mS)
--------------------------------------------------------
VR-AAALV LAN LINK
Visited AAAL to Visited AAAP 25
AAAP DISCOVERY N*25
Reply from the home AAAP 25
Home AAAP to Home AAAL 25
Updating Registration results 25
to the MS through the SIP
server in the visited domain
Updating registration results LAN LINK
in the home domain
--------------------------------------------------------------
Total Delay 25 * (N+4) + LAN links
-------------------------------------------------------------
For simplicity purposes assuming the LAN links delay to be 25ms, the total worst
case Registration delay is 25*(N+5) MILLISECONDS.
Thus in order to satisfy the upper bound of 600ms set aside for complete
registration number of WAN hops during AAAP discovery should ideally be less than
15. Since multicasting and hierarchical addressing is used, AAAP discovery can be
comfortably done in 15 WAN hops.
7. Summary and Open Issues
A new architectural model for complete registration of the Mobile in the
visited network has been outlined in this paper. The exact descriptions of
Security Associations between various AAA entities, between AAAL2 and AAAP are
assumed to be out of the scope of this paper. I have also identified some open
issues for further study and further work. The key open issues are
a) The parameters to be used to send AAAP information as part of the body of
the REGISTER request message from the Mobile terminal.
b) Messages exchanged between the AAAL entity and the AAAP entity can either
be SIP based messages or AAA messages. This topic needs to be researched
further.
c) It is to be determined how the AAAP uses the home network information to
provide services to the mobile client.
8. Acknowledgements
I would like to acknowledge the numerous technical inputs given by Dr Sajal Das,
Professor,Dept Of Computer Science & Engineering, University of Texas at Arlington
during the course of this research work.
9. 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, Y. Shobatake, N. Nakajima, and H.
Schulzrinne, "Mobility Management in a SIP Environment, Requirements, Functions,
and Issues", <draft-itsumo-sip-mobility -req-02.txt>, work in progress, December
2000.
[3]. F. Vakil, A. Dutta, J-C. Chen, S. Baba, Y. Shobatake, N. Nakajima, and H.
Schulzrinne, "Supporting Mobility for Multimedia with SIP", <draft-itsumo-sip-
mobility-multimedia-00.txt>, work in progress, December 2000.
[4]. F. Vakil, A. Dutta, J-C. Chen, M. Tauil, S. Baba, Y. Shobatake, N. Nakajima,
and H. Schulzrinne, "Supporting Mobility for TCP with SIP", <draft- itsumo-sip-
mobility-tcp-00.txt>, work in progress, December 2000.
[5]. F. Vakil, A. Dutta, S. Baba, N. Nakajima, and H. Schulzrinne, "Service
Mobility with SIP", <draft-itsumo-sip-mobility- service-00.txt>, work in progress,
December 2000.
[6]. McAuley, S. Das, S. Baba, and Y. Shobatake, "Dynamic Registration and
Configuration Protocol for Mobile Hosts", Internet Draft, <draft-itsumo-drcp-
01.txt>, work in progress, July 2000.
[7]. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP", ACM Multimedia
Workshop, Seattle, August 1999.
[8]. H Schulzrinne, "SIP Registration", <draft-schulzrinne-sip- register-00.txt>,
work in progress, October 2000.
[9]. F. Vakil, A. Dutta, J-C. Chen, S. Baba, and Y. Shobatake, "Host Mobility
Management Protocol: Extending SIP to 3G-IP Networks", Internet Draft, <draft-
itsumo-hmmp-00.txt>, work in progress,
[10]. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Authentication,
Authorization, and Accounting Requirements for Roaming Nodes using DHCP",
Internet Draft, <draft-ietf-dhc-aaa-requirements- 00.txt>, work in progress,
March 2000.
[11] S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn,
C. de Laat, M. Holdrege and D. Spence, "AAA Authorization Requirements," RFC
2906, August 2000.
[12] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization,
and Accounting requirements," RFC 2977, October, 2000.
[13] S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C.
de Laat, M. Holdrege and D. Spence " AAA Authorization Framework" RFC 2904,
August 2000
[14] A. McAuley, S. Das, S. Baba, Y. Shobatake, "Dynamic Registration and
Configuration Protocol (DRCP)," <draft-itsumo-drcp-00.txt>, October, 1999.
[15]. ITSUMO Group, "Benchmarking of ITSUMO's All IP Wireless Architecture",
mwif2000.028, January 28, 2000.
[16]. ITSUMO Group, "Evolution of Wireless Telephony towards Voice over 3G-IP",
3GPP2- P00-19990824-010, August 23, 1999.
[17]. E. Gustafson, A.Johnson, E. Hubbard, J. Malmkvist, and A. Roos,"Requirements
on Mobile IP from a Cellular Perspective", <draft- ietf-mobileip-cellular-
requirements-02.txt>, work in progress, June 1999.
[18] C. Perkins, "IP Mobility Support", RFC 2002, October 1996.
[19]. C. Perkins, and D. B. Johnson, "Route Optimization in Mobile IP",Internet
Draft, <draft-ietf- obileip-optim-09.txt>, February 15, 2000.
[20] S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C.
de Laat, M. Holdrege and D. Spence " AAA Authorization Application Examples"
RFC 2905, August 2000
[21] R. Droms, "Dynamic Host Configuration Protocol," Request for Comments 2131,
March, 1997.
[22]. J. Kempf, P. McCann, and P. Roberts, "IP Mobility and CDMA Radio Access
Networks: Applicability Statement for Soft Hand-off", <draft-kempf-cdma-appl-
01.txt>, July 2000.
[23]. F. Vakil, D. Famolari, S. Baba, and T. Maeda, "Virtual Soft Hand-off in IP-
Centric Wireless CDMA Networks", work in progress, Submitted for publication.
[24] W. Marshall, K. Ramakrishnan, E. Miller, G. Russel, B. Beser,M. Mannette, K.
Steinbrenner, D. Oran, F. Andreasen, J. Pickens,P. Lalwaney, J. Fellows, E. Evans,
K. Kelly, A. Roach, J. Rosenberg, H. Schulzrinne, and S. Donovan, "Integration of
Resource Management and SIP for IP Telephony", <draft-manyfolks-sip-resource-
00.txt>, work in progress,
March 2000.
<draft-ietf-harsha-sip-00.txt> Expires Jan 2002
10. Authors' Address
ShreHarsha Koti Anand Rao
University Of Texas at Arlington,
416 Yates Street, Nedderman hall, Room 254B
Box 19016, Arlington, TX 76019-0016, USA
sree.harsha@usa.net
sxk6490@exchange.uta.edu
