MobOpts Working Group Y. Cui Internet-Draft K. Xu Expires: April 20, 2006 J. Wu CERNET H. Deng Hitachi (China) October 17, 2005 Network Controlled Handover Problem Statement draft-cui-mobopts-netctrl-handover-ps-00.txt 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 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes why network controlled handover is necessary to future IPv6 deployment, and also outlines some of its features. Cui, et al. Expires April 20, 2006 [Page 1] Internet-Draft Network Controlled Handover PS October 2005 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network Controlled Handover . . . . . . . . . . . . . . . . . . 4 3.1. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Administrating . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Simplicity . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5. Handover Delay . . . . . . . . . . . . . . . . . . . . . . 4 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.7. IPv4 Compatibility . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Cui, et al. Expires April 20, 2006 [Page 2] Internet-Draft Network Controlled Handover PS October 2005 1. Terminology 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 [RFC2119]. General mobility terminology can be found in [RFC3753]. Security terminology can be found in [RFC2401] 2. Introduction CERNET2 is one of the China Next Generation Internet (CNGI) backbones. The network design schemes of CERNET2, referring to overall architecture, backbone, core nodes, access networks and CNGI peer centers, are presented. CERNET2 connects 25 core nodes distributed in 20 cities at speeds of 2.5-10 Gb/s. The unique features of CERNET2 are: 1. Its backbones are IPv6-only networks (the biggest in the world), not the mixed IPv4/IPv6 infrastructure; 2. It provides a multi-vendor environment for the testing and trial operation of homemade IPv6 core routers in respects of interconnection, interworking and interoperation; 3. It is a testbed for NGI applications. CERNET plans to deploy a nationwide university Wireless LAN based Mobile IPv6 [RFC3775] network deployment to support VoIP, Video Telephony, and other multi-media services. In such a large scale and complicated network environment, it is crucial to guarantee quality of service to meet the requirements from end users. Therefore the network handover process should be in control and the latency need to be minimized. There are variety of factors which will influence handover performance. Thus currently there are several proposals related to improving handover performance which are already under the process of standardization. e.g. Fast-handover [RFC4068], Hierarchical Mobile IPv6 [RFC4140], Detecting Network Attachment (DNA).[RFC4135] But access routers from different vendors are already deployed in CERNET network. In order to support those technologies like Mobile IPv6 fast-handover, or DNA, those access routers must be upgraded. It is not feasible to upgrade all of those equipments. It is necessary to find a both economical and convinient scheme to solve this problem, and network controlled handover is such a potential solution. Cui, et al. Expires April 20, 2006 [Page 3] Internet-Draft Network Controlled Handover PS October 2005 3. Network Controlled Handover This section outlines those problems which need to be considered by a network controlled handover solution. 3.1. OAM As to operation and management, network controlled handover may be able to provider a convenient user management and operating interface to control the box/module which implements the network controlled function. The failure discovery of such a box/module is required in the OAM interface. 3.2. Administrating In order to satisfy the requirements from monitoring and accounting, network controlled handover should provide a proper mechanism for administrating. User differentiation and priority control needs to be supported. 3.3. Scalability Mobile IPv6 network will be deployed in CERNET which scales more than 100 unversities, and each university will serve at least 5000 users. Also the network is growing continuously. Existing solutions will face crucial challenge in scalability. 3.4. Simplicity Current solutions seams complicated to be widely deployed. Simplicity must be taken into consideration. For example, network interaction and signaling must be simplified. 3.5. Handover Delay Since network should be acceptable to typical services such as VoIP, it is preferable that Mobile IPv6 handover latency can be controlled within 500ms or less. 3.6. Security In control plane, network-constrol box/module must support authentication, but an ISP may decide to turn it off in some circumstances. be able to authenticate its user. In data plane, the network and potential sulotion should support procotol can use IPsec procotol and an IPsec profile will have to be Cui, et al. Expires April 20, 2006 [Page 4] Internet-Draft Network Controlled Handover PS October 2005 defined to protect its data. 3.7. IPv4 Compatibility The co-existence of IPv6 and IPv4 is unavoidable. It is expected that mobile IPv6 network should be compatible with IPv4 as much as possible. 4. Security Considerations Under certain circumstances, it is expected that IPsec in Mobile IPv6 protocol [RFC3776] can be disabled by certain user who have no requirement for security. IPsec security association SHOULD be able to transferred among access routers (thus [RFC4067] can be used), and IPsec security association transferring MUST be initiated by the network side, e.g. by router, and MUST not be initiated by the Mobile Node. 5. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Cui, et al. Expires April 20, 2006 [Page 5] Internet-Draft Network Controlled Handover PS October 2005 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. Cui, et al. Expires April 20, 2006 [Page 6] Internet-Draft Network Controlled Handover PS October 2005 Authors' Addresses Yong Cui CERNET Department of Computer Science and Technology Tsinghua University Beijing 100084 China Email: yong@csnet1.cs.tsinghua.edu.cn Ke Xu CERNET Department of Computer Science and Technology Tsinghua University Beijing 100084 China Email: xuke@csnet1.cs.tsinghua.edu.cn Jianping Wu CERNET Department of Computer Science and Technology Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Hui Deng Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.cn Cui, et al. Expires April 20, 2006 [Page 7] Internet-Draft Network Controlled Handover PS October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cui, et al. Expires April 20, 2006 [Page 8]