SIPPING Working Group S. Niccolini Internet-Draft NEC Intended status: Informational S. Salsano Expires: April 16, 2007 Univ. of Rome Tor Vergata L. Veltri Univ. or Parma October 13, 2006 Requirements for vertical handover of multimedia sessions using SIP draft-niccolini-sipping-siphandover-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Niccolini, et al. Expires April 16, 2007 [Page 1] Internet-Draft SIP-based vertical handover October 2006 Abstract This document analyses the issue of handling vertical handovers among different network technologies using SIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenario for vertical handover . . . . . . . . . . . . . . . . 4 3. Requirements for Vertical Handovers . . . . . . . . . . . . . 5 4. Taxonomy of possible approaches . . . . . . . . . . . . . . . 7 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Niccolini, et al. Expires April 16, 2007 [Page 2] Internet-Draft SIP-based vertical handover October 2006 1. Introduction Let us consider a terminal (hereafter named "Mobile Host" or MH), possibly equipped with different network interfaces (i.e. a subset of WiFi, Bluetooth, GPRS, 3G, fixed Ethernet, WiMax). Each interface will receive an IP address from the corresponding Access Network (AN). Therefore the mobile host will have a set of different IP addresses and will have to select which one to use when running multimedia sessions with correspondent terminals. While the mobile host moves, the "selected" interface may become not available due to loss of signal, or could suffer high packet loss or packet delay. Under these circumstances, the MH would like to switch to another interface (using a different IP address) keeping the running sessions active. Even with a single interface the connected access network can become not available anymore and the terminal could connect to another Access Network (in this case on the same technology), which provides a different IP address. If the switch to the new AN is fast enough, the MH could also be interested in keeping the running session active. This problem has been addressed with different approaches. One approach is based on "network level" mobility solutions like Mobile IP or MobileIPv6. Another approach is based on "application level" mobility solution. The main advantage of application level mobility solutions is that they do not require any support at the network level from the different access networks, which only needs to provide plain IP connectivity. We are interested in this second approach, in particular considering the solutions that exploits the SIP protocol. The aim of SIP based application level mobility is to keep active a multimedia session that has been established with SIP, while the terminal switches from one network interface to another or it changes IP address on the same interface. Niccolini, et al. Expires April 16, 2007 [Page 3] Internet-Draft SIP-based vertical handover October 2006 2. Scenario for vertical handover The figure below shows a Mobile Host that wants to communicate with a "Correspondent Host". The Mobile Host can connect to different access Networks (AN1, AN2, AN3 are represented in the figure). The different ANs could have different wireless or wired techologies and the Mobile Host could be connected to more than one access network at the same time if it has more than one physical network interface. Note that the Access networks can provide public or private addresses to the mobile host (in most typical scenarios the Access Networks are likely to provide private IP addresses). For example In the figure AN 1 and AN 3 provide a private address (as shown by the NAT box), while AN2 provides a public address. Similarly, the Correspondent Host can have a public address (like CH 1 in the figure) or a private IP address (like CH 2 in the figure). +-------+ | AN1 |-----+ ----| | NAT | +--------+ / +-------+-----+ |Corresp.| +-------+ __________ | Host 1 | | Mobile| +-------+ / \ +--------+ | Host | | AN2 | / \ +-------+ ----| | | INTERNET | + - - - + \ / \__________/ \ +-------+ +--------+ ----| AN3 |-----+ +-----|Corresp.| | | NAT | | NAT | Host 2 | +-------+-----+ +-----+--------+ The goal of the handover mechanism is to let the MH roam among different Access Network in a seamless way. The mobility management mechanism should consider the roaming of the MH both "off call" and during an active call . The MH should be able to dinamically choose among the available ANs the one that better suits its needs (e.g. perceived quality of media flows and cost) in a given moment. NB We are not interested in the criteria and tools for selection of the "best" access network, we are only concerned in the mobility management and handover execution mechanims. Niccolini, et al. Expires April 16, 2007 [Page 4] Internet-Draft SIP-based vertical handover October 2006 3. Requirements for Vertical Handovers In this session we discuss a set of requirements that a mobility management solution based on SIP should have. o The solution should be as fast as possible. The goal is to provide a "seamless" handover with no perception from the user point of view. If it is not possible to provide a truly seamless solution, the impairment should be minimized. o The solution should support a "forward handover" (i.e. in which all the procedure is performed on the new target Access Network). This is important if the connection on the old Access Network is suddenly broken. If possible (i.e. if the connection with the old access network does not break suddenly) the solution could exploit the communication on the old access network in order to better control the handover procedure. Soft handovers (i.e. where the two active connections can be exploited in the same moment to send the session data) could be exploited. o The handover solution should be compatible with NATted networks, i.e. it should interoperate gracefully with NAT traversal mechanisms for SIP signaling and for session media flows. o The handover solution should not require a support in the different access network. The access networks are only required to provide IP connectivity (either with public or private addresses) for the forwarding of signalling SIP packets and media RTP packets. o The mobility management solution should allow the decoupling of "user level" registration and mobility and "terminal level" mobility. As an example a user with AOR "sip:user@domain.com" should be allowed to use different terminals (i.e. Mobile Hosts supporting the handover solutions as well as normal SIP terminals). These terminals can be used in sequence or at the same time depending on the capability of his own "home" registrar/ proxy server, and this is independent of the vertical handover solution which takes care of the mobility of only one Mobile Host among the set of the terminals on which the user can be registered. A concrete example for this requirement is that the user "sip:user@domain.com" owns three Mobile Hosts (one could be his phone, one his PDA, one his laptop) and two fixed terminals (his desktop and his home VoIP phone). The vertical handover solution takes care of the mobility of the phone, PDA and laptop as three separate Mobile Hosts (which can also be switched on in parallel). Niccolini, et al. Expires April 16, 2007 [Page 5] Internet-Draft SIP-based vertical handover October 2006 o The switch of the "active" interface during a SIP transaction should be supported. As an example the terminal should be able to send (receive) an INVITE on the currenlty active interface, switch to another interface and receive (send) the 200 OK on the other interface. o An optional desirable requirement is to provide privacy with respect to user location and user movements. o Another desirable feature is that existing user agent should inter-work with the handover procedure without the need to be updated. This requirement applies especially to the "Correspondent Hosts" (which in general are not moving, but they are communication with a moving terminal). If this requirement is not fulfilled there is the need to change all SIP terminals to support the handovers of Mobile Host. To a lesser extent this requirements also applies to the Mobile Host itself: it would be desirable to reuse existing SIP clients (User Agents) without updating them to support the terminal mobility. Niccolini, et al. Expires April 16, 2007 [Page 6] Internet-Draft SIP-based vertical handover October 2006 4. Taxonomy of possible approaches The application level mobility solutions based on SIP can be classified in "Correspondent host based" or "Intermediate Element based". o Correspondent Host based solutions TO BE PROVIDED o Intermediate Element based solutions TO BE PROVIDED Niccolini, et al. Expires April 16, 2007 [Page 7] Internet-Draft SIP-based vertical handover October 2006 5. Conclusions To be provided Niccolini, et al. Expires April 16, 2007 [Page 8] Internet-Draft SIP-based vertical handover October 2006 6. Security considerations To be provided Niccolini, et al. Expires April 16, 2007 [Page 9] Internet-Draft SIP-based vertical handover October 2006 Appendix A. Acknowledgments The authors would like to thank Chiara Mingardi (Univ. of Padova/NEC) and Andrea Polidoro (Univ. of Rome Tor Vergata) for their support in the identification of the requirements and the fruitful discussions about possible solutions. Niccolini, et al. Expires April 16, 2007 [Page 10] Internet-Draft SIP-based vertical handover October 2006 Authors' Addresses Saverio Niccolini Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 43 42 118 Email: saverio.niccolini@netlab.nec.de URI: http://www.netlab.nec.de Stefano Salsano DIE, University of Rome "TorVergata" Via Politecnico, 1 Rome 00156 Italy Phone: +39 06 7259 7770 Email: stefano.salsano@uniroma2.it URI: http://netgroup.uniroma2.it/Stefano_Salsano Luca Veltri DII, University of Parma Parco Area delle Scienze 181/A Parma 43100 Italy Phone: +39 0521 90 5768 Email: luca.veltri@unipr.it URI: http://www.tlc.unipr.it/veltri Niccolini, et al. Expires April 16, 2007 [Page 11] Internet-Draft SIP-based vertical handover October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Niccolini, et al. Expires April 16, 2007 [Page 12]