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) 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", , 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", , 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", , work in progress, December 2000. [5]. F. Vakil, A. Dutta, S. Baba, N. Nakajima, and H. Schulzrinne, "Service Mobility with SIP", , work in progress, December 2000. [6]. McAuley, S. Das, S. Baba, and Y. Shobatake, "Dynamic Registration and Configuration Protocol for Mobile Hosts", Internet Draft, , 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", , 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, , 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, , 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)," , 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", , 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, , 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", , 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", , work in progress, March 2000. 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