idnits 2.17.1 draft-deng-giap-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 279. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 17, 2008) is 5905 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) == Unused Reference: 'RFC4067' is defined on line 224, but no explicit reference was found in the text == Unused Reference: 'RFC4068' is defined on line 227, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4068 (Obsoleted by RFC 5268) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Deng 3 Internet-Draft China Mobile 4 Intended status: Standards Track February 17, 2008 5 Expires: August 20, 2008 7 Problem Statement and Requirement: Inter Mobile Access Router Protocol 8 draft-deng-giap-ps-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 20, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document discusses the problem and requirement of the 42 communication between mobile access router. With the evolution of 43 mobile communication, mobile wirless access point will not only using 44 IP for transporation, but also has much more function to support 45 mobile communication such as self organization/optimization network, 46 flat network archtiecture, multiple connections and distributed 47 network architecture et al . 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Scenarios of implementing inter mobile access router 53 protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Distributed Mobile IP Access Network . . . . . . . . . . . 4 55 2.2. Half Distributed Mobile IP Access Network . . . . . . . . 5 56 3. Implementations of the Protocol . . . . . . . . . . . . . . . 6 57 3.1. Plug in Play Configuration . . . . . . . . . . . . . . . . 6 58 3.2. Self Organization/Optimization Network . . . . . . . . . . 6 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 Intellectual Property and Copyright Statements . . . . . . . . . . 12 66 1. Introduction 68 while more and more mobile operators are thinking that IP function 69 will not only be used for transporation by mobile access network, it 70 could also undertake more tasks such as self organization/ 71 optimization network, multiple connections, IP mobility management, 72 and distributed IP access network. 74 There are several distributed wireless IP access network scenarios 75 may implement inter mobile access router protocol such as self 76 organization network, mesh, and structured P2P based mobile IP access 77 network. 79 In the current mobile operator's network, they have to spend huge 80 resource for test drive during mobile network deployment and 81 optimization, which consist of major part of CAPEX and OPEX. With 82 the potential requirement of multiple connections of wireless 83 communications and distributed IP access network, IP communications 84 between mobile access routers could help to reduce the CAPEX and 85 OPEX, for example this communication could realize an alternative way 86 of conventional drive test and configuration which need a huge man 87 power performaning and only get a snapshop result. 89 2. Scenarios of implementing inter mobile access router protocols 91 There are two scenarios implementing inter mobile access router 92 protocols, one is distributed mobile IP access network, the other is 93 half distributed mobile IP access network for the sake of self 94 organization and configuration. . 96 2.1. Distributed Mobile IP Access Network 98 Recent development of distributed network has bring several benefit 99 to industry such as less investment and simple network 100 infrastructure. 102 The distributed IP Mobile Access Network is shown in the figure 103 below: 105 +-----+ 106 | AGW | 107 +-----+ 108 | 109 v v | v 110 | | | | 111 +-----+ +-----+ +-----+ 112 | MAR |........| MAR |........| MAR | 113 +-----+ +-----+ +-----+ 114 v ,': : `. v 115 | ,' : : `. | 116 +-----+ : : +-----+ 117 | MAR | : : | MAR | 118 +-----+ : : +-----+ 119 `. : v v v : ,' 120 `. : | | | : ,' 121 +-----+ +-----+ +-----+ 122 | MAR |........| MAR |........| MAR | 123 +-----+ +-----+ +-----+ 125 The scenario of the above could be wireless mesh network and 126 structured P2P wireless network architecture. After bringing into 127 P2P function into each mobile access router and each mobile access 128 router has multiple wireless radios. One is specifically for mobile 129 terminal access, others could be used for communication with other 130 mobile access router. Under such direction, several purpose of inter 131 access router protocol could be realized in the Internet level, we 132 are going to illustrate it in the next section. 134 2.2. Half Distributed Mobile IP Access Network 136 Centralized distributed network still cover major deployment in the 137 current network, based on this network architecture, self 138 organization/optimization become possible after development of inter 139 mobile access router protocol. 141 The half distributed IP mobile access network is shown in the figure 142 below: 144 +-----+ 145 | AGW | 146 +-----+ 147 v v | v v 148 | | | | | 149 +-----+ +-----+ | +-----+ +-----+ 150 | MAR |.............| MAR | | | MAR |.............| MAR | 151 +-----+ +-----+ | +-----+ +-----+ 152 v ,' `. v ,': | `. v ,' `. v 153 | ,' `. | ,' : | `. | ,' `.| 154 +-----+ +-----+ : | +-----+ +-----+ 155 | MAR |....... | MAR |-------------+-----------| MAR |.....| MAR | 156 +-----+ +-----+ : +-----+ +-----+ 157 `.v ,' `. : v v ,' `. ,'v 158 `| ,' `. : | | ,' `. ,' | 159 +-----+ +-----+ +-----+ +-----+ 160 | MAR |...........| MAR | | MAR |...........| MAR | 161 +-----+ +-----+ +-----+ +-----+ 162 v ,' 163 | ,' 164 +-----+ 165 | MAR | 166 +-----+ 168 This scenario has two distributed mobile access network domain, the 169 core mobile access router is connected with each other and could be 170 connected to access gateway, and several mobile access router could 171 work as relay mobile router. Based on this scenario, zero network 172 configuration could be done based on inter access router IP protocol. 173 As well self organization/optimization network would prefer to be 174 implemented based on this. 176 3. Implementations of the Protocol 178 Current organization and optimization is based on low-level interface 179 and per-device basis, it lacks scalability and testability in real 180 time operational mobile network. 182 3.1. Plug in Play Configuration 184 Mobile network require zero configuration of new mobile IP access 185 router where Plug and Play could realize based on Internet protocol. 186 Which could save huge of human resource for test drive and manual 187 opeartions. 189 3.2. Self Organization/Optimization Network 191 The time and cost of deploying, configuring and operating networks, 192 is expected to increase even further due to the exponential growth in 193 numbers of network elements in the Internet,especially mobile 194 networks such as mobile access router. The increasing complication 195 and dynamic nature of many mobile networks make configuration more 196 complex and further mandate continuous adaptation and validation of 197 active configurations in real-time. 199 To Achieve the characterstical like real time, adaptive, flexibity, 200 we need not only engineering principles for automated configuration, 201 but also standardized inter mobile IP access router protocol. The 202 ultimate goals are to support future large-scale mobile networks that 203 will self-organize/optimize, dynamically adapt to external events and 204 allow for low-cost operation. 206 4. IANA Considerations 208 This document makes no requests to IANA. 210 5. Security Considerations 212 Mobile inter access router protocol do require IPsec based protection 213 mechanism, IKE could be used for neogiation IPsec tunnel between 214 mobile access routers. 216 6. Conclusion 218 This draft discusses problem and requirement for inter mobile access 219 router protocol which could support self organziation and 220 optimization of mobile IP access network. 222 7. Informative References 224 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 225 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 227 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 228 July 2005. 230 Author's Address 232 Hui Deng 233 China Mobile 234 53A,Xibianmennei Ave., 235 Xuanwu District, 236 Beijing 100053 237 China 239 Email: denghui02@gmail.com 241 Full Copyright Statement 243 Copyright (C) The IETF Trust (2008). 245 This document is subject to the rights, licenses and restrictions 246 contained in BCP 78, and except as set forth therein, the authors 247 retain all their rights. 249 This document and the information contained herein are provided on an 250 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 251 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 252 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 253 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 254 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 255 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 257 Intellectual Property 259 The IETF takes no position regarding the validity or scope of any 260 Intellectual Property Rights or other rights that might be claimed to 261 pertain to the implementation or use of the technology described in 262 this document or the extent to which any license under such rights 263 might or might not be available; nor does it represent that it has 264 made any independent effort to identify any such rights. Information 265 on the procedures with respect to rights in RFC documents can be 266 found in BCP 78 and BCP 79. 268 Copies of IPR disclosures made to the IETF Secretariat and any 269 assurances of licenses to be made available, or the result of an 270 attempt made to obtain a general license or permission for the use of 271 such proprietary rights by implementers or users of this 272 specification can be obtained from the IETF on-line IPR repository at 273 http://www.ietf.org/ipr. 275 The IETF invites any interested party to bring to its attention any 276 copyrights, patents or patent applications, or other proprietary 277 rights that may cover technology that may be required to implement 278 this standard. Please address the information to the IETF at 279 ietf-ipr@ietf.org. 281 Acknowledgment 283 Funding for the RFC Editor function is provided by the IETF 284 Administrative Support Activity (IASA).