idnits 2.17.1 draft-cui-mobopts-netctrl-handover-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 276. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2005) is 6765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 3753 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4067 ** Obsolete normative reference: RFC 4068 (Obsoleted by RFC 5268) ** Downref: Normative reference to an Informational RFC: RFC 4135 ** Obsolete normative reference: RFC 4140 (Obsoleted by RFC 5380) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MobOpts Working Group Y. Cui 3 Internet-Draft K. Xu 4 Expires: April 20, 2006 J. Wu 5 CERNET 6 H. Deng 7 Hitachi (China) 8 October 17, 2005 10 Network Controlled Handover Problem Statement 11 draft-cui-mobopts-netctrl-handover-ps-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 20, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes why network controlled handover is necessary 45 to future IPv6 deployment, and also outlines some of its features. 47 Table of Contents 49 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Network Controlled Handover . . . . . . . . . . . . . . . . . . 4 54 3.1. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Administrating . . . . . . . . . . . . . . . . . . . . . . 4 56 3.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.4. Simplicity . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.5. Handover Delay . . . . . . . . . . . . . . . . . . . . . . 4 59 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.7. IPv4 Compatibility . . . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . . . 8 69 1. Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 General mobility terminology can be found in [RFC3753]. Security 76 terminology can be found in [RFC2401] 78 2. Introduction 80 CERNET2 is one of the China Next Generation Internet (CNGI) 81 backbones. The network design schemes of CERNET2, referring to 82 overall architecture, backbone, core nodes, access networks and CNGI 83 peer centers, are presented. CERNET2 connects 25 core nodes 84 distributed in 20 cities at speeds of 2.5-10 Gb/s. The unique 85 features of CERNET2 are: 86 1. Its backbones are IPv6-only networks (the biggest in the world), 87 not the mixed IPv4/IPv6 infrastructure; 88 2. It provides a multi-vendor environment for the testing and trial 89 operation of homemade IPv6 core routers in respects of 90 interconnection, interworking and interoperation; 91 3. It is a testbed for NGI applications. 93 CERNET plans to deploy a nationwide university Wireless LAN based 94 Mobile IPv6 [RFC3775] network deployment to support VoIP, Video 95 Telephony, and other multi-media services. In such a large scale and 96 complicated network environment, it is crucial to guarantee quality 97 of service to meet the requirements from end users. Therefore the 98 network handover process should be in control and the latency need to 99 be minimized. 101 There are variety of factors which will influence handover 102 performance. Thus currently there are several proposals related to 103 improving handover performance which are already under the process of 104 standardization. e.g. Fast-handover [RFC4068], Hierarchical Mobile 105 IPv6 [RFC4140], Detecting Network Attachment (DNA).[RFC4135] 107 But access routers from different vendors are already deployed in 108 CERNET network. In order to support those technologies like Mobile 109 IPv6 fast-handover, or DNA, those access routers must be upgraded. 110 It is not feasible to upgrade all of those equipments. 112 It is necessary to find a both economical and convinient scheme to 113 solve this problem, and network controlled handover is such a 114 potential solution. 116 3. Network Controlled Handover 118 This section outlines those problems which need to be considered by a 119 network controlled handover solution. 121 3.1. OAM 123 As to operation and management, network controlled handover may be 124 able to provider a convenient user management and operating interface 125 to control the box/module which implements the network controlled 126 function. The failure discovery of such a box/module is required in 127 the OAM interface. 129 3.2. Administrating 131 In order to satisfy the requirements from monitoring and accounting, 132 network controlled handover should provide a proper mechanism for 133 administrating. User differentiation and priority control needs to 134 be supported. 136 3.3. Scalability 138 Mobile IPv6 network will be deployed in CERNET which scales more than 139 100 unversities, and each university will serve at least 5000 users. 140 Also the network is growing continuously. 142 Existing solutions will face crucial challenge in scalability. 144 3.4. Simplicity 146 Current solutions seams complicated to be widely deployed. 147 Simplicity must be taken into consideration. For example, network 148 interaction and signaling must be simplified. 150 3.5. Handover Delay 152 Since network should be acceptable to typical services such as VoIP, 153 it is preferable that Mobile IPv6 handover latency can be controlled 154 within 500ms or less. 156 3.6. Security 158 In control plane, network-constrol box/module must support 159 authentication, but an ISP may decide to turn it off in some 160 circumstances. be able to authenticate its user. 162 In data plane, the network and potential sulotion should support 163 procotol can use IPsec procotol and an IPsec profile will have to be 164 defined to protect its data. 166 3.7. IPv4 Compatibility 168 The co-existence of IPv6 and IPv4 is unavoidable. It is expected 169 that mobile IPv6 network should be compatible with IPv4 as much as 170 possible. 172 4. Security Considerations 174 Under certain circumstances, it is expected that IPsec in Mobile IPv6 175 protocol [RFC3776] can be disabled by certain user who have no 176 requirement for security. 178 IPsec security association SHOULD be able to transferred among access 179 routers (thus [RFC4067] can be used), and IPsec security association 180 transferring MUST be initiated by the network side, e.g. by router, 181 and MUST not be initiated by the Mobile Node. 183 5. References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 189 Internet Protocol", RFC 2401, November 1998. 191 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 192 RFC 3753, June 2004. 194 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 195 in IPv6", RFC 3775, June 2004. 197 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 198 Protect Mobile IPv6 Signaling Between Mobile Nodes and 199 Home Agents", RFC 3776, June 2004. 201 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 202 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 204 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 205 July 2005. 207 [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network 208 Attachment in IPv6", RFC 4135, August 2005. 210 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 212 Bellier, "Hierarchical Mobile IPv6 Mobility Management 213 (HMIPv6)", RFC 4140, August 2005. 215 Authors' Addresses 217 Yong Cui 218 CERNET 219 Department of Computer Science and Technology 220 Tsinghua University 221 Beijing 100084 222 China 224 Email: yong@csnet1.cs.tsinghua.edu.cn 226 Ke Xu 227 CERNET 228 Department of Computer Science and Technology 229 Tsinghua University 230 Beijing 100084 231 China 233 Email: xuke@csnet1.cs.tsinghua.edu.cn 235 Jianping Wu 236 CERNET 237 Department of Computer Science and Technology 238 Tsinghua University 239 Beijing 100084 240 China 242 Email: jianping@cernet.edu.cn 244 Hui Deng 245 Hitachi (China) 246 Beijing Fortune Bldg. 1701 247 5 Dong San Huan Bei-Lu 248 Chao Yang District 249 Beijing 100004 250 China 252 Email: hdeng@hitachi.cn 254 Intellectual Property Statement 256 The IETF takes no position regarding the validity or scope of any 257 Intellectual Property Rights or other rights that might be claimed to 258 pertain to the implementation or use of the technology described in 259 this document or the extent to which any license under such rights 260 might or might not be available; nor does it represent that it has 261 made any independent effort to identify any such rights. Information 262 on the procedures with respect to rights in RFC documents can be 263 found in BCP 78 and BCP 79. 265 Copies of IPR disclosures made to the IETF Secretariat and any 266 assurances of licenses to be made available, or the result of an 267 attempt made to obtain a general license or permission for the use of 268 such proprietary rights by implementers or users of this 269 specification can be obtained from the IETF on-line IPR repository at 270 http://www.ietf.org/ipr. 272 The IETF invites any interested party to bring to its attention any 273 copyrights, patents or patent applications, or other proprietary 274 rights that may cover technology that may be required to implement 275 this standard. Please address the information to the IETF at 276 ietf-ipr@ietf.org. 278 Disclaimer of Validity 280 This document and the information contained herein are provided on an 281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 283 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 284 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 285 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 Copyright Statement 290 Copyright (C) The Internet Society (2005). This document is subject 291 to the rights, licenses and restrictions contained in BCP 78, and 292 except as set forth therein, the authors retain all their rights. 294 Acknowledgment 296 Funding for the RFC Editor function is currently provided by the 297 Internet Society.