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