NEMO WG Y. Zhao Internet-Draft SH. Huawei Tech. Intended status: Standards Track K. Lin Expires: May 22, 2008 W. Zhong SJTU. November 12, 2007 Limitations exist in IP mobility support applications draft-zhao-nemo-limitations-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 May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Zhao, et al. Expires May 22, 2008 [Page 1] Internet-Draft Limitations of Mobility Solution November 2007 Abstract There already exist several mobility support solutions and each solution uses its own method to achieve specific goals.But different solutions may not work properly when they are combined in an integrated application environment because network entities have little information about each other.Specially when PMIP meet with the Nemo network environment something need to be considered more. This document describes several limitations on NEMO application and provides a possible solution. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Current Mobility Support Solutions . . . . . . . . . . . . . . 4 3. Limitations Exist in Current Mobility Solutions . . . . . . . 5 3.1. Overlong Routing When MIPv6 Nodes Entered Mobile Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Mobile Network May Not Operate Correctly under a Pmipv6 Domain . . . . . . . . . . . . . . . . . . . . . . 5 4. Limitations of Nested NEMO . . . . . . . . . . . . . . . . . . 8 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Zhao, et al. Expires May 22, 2008 [Page 2] Internet-Draft Limitations of Mobility Solution November 2007 1. Introduction There already exist several mobility support solutions and each solution uses its own method to achieve specific goals. IP mobility support protocols are the basis of other network layer mobility management solution. Based on MIP, there are other IP mobility extensions like Proxymipv6 and NEMO which aim to provide mobility support for mobility nodes which can not manage mobility by themselves. As different methods were designed for different applications, one method may not be useful in other application.The future wireless application environment will most likely be a combination of different methods. For example a mipv6 node may be a node within a mobile network maintained by a MR. A MR may enter into the Proxymipv6 domain. If network entities have not enough information about the others, they will treat different entities with only one way. The usage of network resource may not be efficient, and the quality of service may not be guaranteed. o For example, when a MIPv6 node happens to enter a mobile network maintained by a MR, as MR can't distinguish a MIPv6 node from fixed nodes, the route of the datagram o In addition, the route between the MIPv6 node and a correspondent node is sub-optimised even they perform MIPv6 RO process. Zhao, et al. Expires May 22, 2008 [Page 3] Internet-Draft Limitations of Mobility Solution November 2007 2. Current Mobility Support Solutions There exist several mobility support solutions for Internet communication. They can be divided into two categories with network layer solutions and application layer solutions. SIP (Session initiation protocol) [RFC3261] belongs to application layer solution, which tries to keep the session by noting the correspondent node the new access address of the mobile node as quickly as possible. On the other hand, the network layer solution like IP mobility support protocol [RFC3344][RFC3775], introduces two types of IP addresses and home agent to support the movement of MNs. In MIP solutions, the datagram to a MN is targeted to a fixed address and transferred by home agent to the current access address of the MN. And network layer solutions are transparent to upper applications. The network layer mobility support solutions can also be divided into single node support solutions and subnet support solution. The former are IP Mobility Support protocols and PMIPv6 [draft-ietf-netlmm-proxymip6-07],the latter is Network Mobility Basic Support Protocol [RFC3963]. The network mobility solutions can also be divided into active mode through which the MN control its own mobility and passive mode where the MN does not manage the mobility. The former solutions like IP Mobility Support and the other like NEMO and Proxymipv6. Different solutions defined different function entities to perform specific function. For example, NEMO introduces Mobile Router to maintain a subnet, provide Internet connections for all nodes within that subnet. Proxymipv6 defined MAG and LMA to help normal nodes without IP Mobility Support to have a session unbroken while moving. Zhao, et al. Expires May 22, 2008 [Page 4] Internet-Draft Limitations of Mobility Solution November 2007 3. Limitations Exist in Current Mobility Solutions In the future, the application will more likely be a combined and compromised solution. In a actual wireless environment there will have different kinds of mobile nodes. For example, in a PMIPv6 domain, the nodes it serves may be a combination of fixed IPv6 nodes, MIPv6 hosts and Mobile Router. MIPv6 node may also move into a mobile network maintained by a mobile router. So some problems may be encountered like that: 3.1. Overlong Routing When MIPv6 Nodes Entered Mobile Network NEMO take nodes as fixed nodes which have not the capacity of IP mobility support. MR encapsulates the datagram of the node within its subnet, then tunnels the datagram to it's HA, HA deencapsulates the datagram then transport it to the correspondent node. But for MIPv6 host, as MR maintained a mobile network, it need not send bindings to its HA as usual, it at least can reduces the binding frequency for resource saving. As depicted in Figure 1, because MR can not distinguish MIPv6 node from fixed nodes, the datagram of MIPv6 host will also be encapsulated by MR and finally routed to its HA through two tunnels which is not route efficiently. If MR and MIPv6 host have some information about each other, route optimization could take place without much cost. +---+ +--+ ,,,,, +-----+ +------+ +--+ |MNN|<=====>|MR|<=====>|HA_MR|<=====>|HA_MNN|<----->|CN| +---+ +--+ ''''' +-----+ +------+ +--+ +---+ +--+ +------+ +--+ |MNN|<----->|MR|<=====>|HA_MNN|<----->|CN| +---+ +--+ +------+ +--+ Figure 1: Overlong Routing Exists When MIPv6 Node in NEMO 3.2. Mobile Network May Not Operate Correctly under a Pmipv6 Domain PMIPv6 solution is initially designed to support mobility for single node and it can support both fixed node and MIP node. Its architecture is similar to [RFC3775] and it introduces LMA and MAG for local mobility management, LMA works like a HA and it is responsible for data transport of fixed nodes in PMIPv6 domain. In PMIPv6, LMA and MAG build a virtual home network for MIPv6 node so it will not send bindings to its HA while the network will register to MN's HA on behalf of MN. Zhao, et al. Expires May 22, 2008 [Page 5] Internet-Draft Limitations of Mobility Solution November 2007 But mobile router is a special mipv6 node which has mobile network prefix option. Without capacity negotiation, pmipv6 domain probably could not distinguish MR from normal mipv6 hosts. And PMIPv6 domain could not understand MNP so it will not work properly. For example, as depicted in Figure 2, when MR1 initiates its IP connection in PMIPv6 domain, MR1 thinks it is at home and will not register to its HA, instead, the MAG in PMIPv6 domain will send BU to MR1's HA on behalf of MR1, but the R bit will not exist in the BU message because the PMIPv6 domain couldn't distinguish MR from normal MIPv6 hosts. As a result, the HA of MR1 will not take MR1 as a Mobile Router and the MR1 might not find out that it actually operates as a normal MIPv6 host. +---------------------------+ _-----_ +---------------+ |PMIPv6 | / \ | | |Domain | | | | | | +-----+ | Data for MR1 | +-------+ | | +---+ | MAG |<==========================>|HA of | | | |LMA| |(AR) |<==========X==X============>|Root MR| | | +---+ +--A--+ | Data for MNNs | +-------+ | | | | and MR2 | | | +------------V------+ | | | | | | | +---+ | | | | | | | | NEMO |MR1| | | | | | | | | +-+-+ | | | | | | | | | | | | | | Home | | | +-----+-+---+ | | |IPv4/IPv6| | Network| | | | | | | | |network | +---------------+ | | +-+-+ +-+-+ +-+-+ | | | | | | |MR2| |MNN| |MNN| | | | | | | +---+ +---+ +---+ | | | | | +-------------------+ | \ / +---------------------------+ "-----" Figure 2: MR Might not Work Properly in PMIPv6 Domain When It Initiates Its Network Access When MR1 moves into a PMIPv6 domain from foreign network, as depicted in Figure 3, it will take PMIPv6 domain as its home link and de- register as [RFC3963] defined. The MAG will send BU to MR1's HA to continue its IP connection while the BU not containing R flag. Even if HA continues to forward packets targeted to MNNs to MAG, the MAG might not send MNN's packets correctly to MR1's HA because MAG doesn't have information about MNP or the relation between MNP and MR. Zhao, et al. Expires May 22, 2008 [Page 6] Internet-Draft Limitations of Mobility Solution November 2007 +---------------------------+ _-----_ +---------------+ |PMIPv6 | / \ | | |Domain | | | | | | +-----+ | | | | +-------+ | | +---+ | MAG |<===========================|HA of | | | |LMA| |(AR) |===========X==X============>|Root MR| | | +---+ +--A--+ | | | | +-------+ | | | | | | | | | +------------V------+ | | | | | | | +---+ | | | | | | | | NEMO |MR1| | | | | | | | | +-+-+ | | | | | | | | | | | | | | Home | | | +-----+-+---+ | | |IPv4/IPv6| | Network| | | | | | | | |network | +---------------+ | | +-+-+ +-+-+ +-+-+ | | | | | | |MR2| |MNN| |MNN| | | | | | | +---+ +---+ +---+ | | | | | +-------------------+ | \ / +---------------------------+ "-----" Figure 3: MR Might Not Work Properly in PMIPv6 Domain When It Moves From a Foreign Network Zhao, et al. Expires May 22, 2008 [Page 7] Internet-Draft Limitations of Mobility Solution November 2007 4. Limitations of Nested NEMO NEMO hide the MR's movement to the nodes within its mobile network. MR looks like a normal access router to the mobile nodes it serves, while MR looks like a node rather than a router to its access router. MR can not distinguish MR from normal routers, so a MR may choose a MR as its access router instead of a fixed router unwisely, as depicted in Figure 4, which make the mobile network nested and is not route efficient. Without capacity negotiation, MR can not distinguish each other and nested mobile network is hard to achieve route optimization and avoid router loop, as depicted in Figure 5. +--------+ +-----+ | HA of ||HA of| |Root MR | | MNN | +---A----+ +-----+ |x| |x| |x| |x| +-----+----V--+-----------+ +------+ | |Root MR||MNN|<-----RA---+ |Domain +---+ | +-------------------------+ Figure 4: MR might choose a MR as its access router instead of a fixed one in some application Zhao, et al. Expires May 22, 2008 [Page 8] Internet-Draft Limitations of Mobility Solution November 2007 ---------- ---------- ---------- ---------- | | | | | | | | | NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Host 1 | | | | | | | | | | ---------- ---------- ---------- | ---------- | ---------- ---------- | | | | | |----| HA 2 | | HA 1 |---------| | | | | | ---------- ---------- | ---------- | | | HA 3 | | | ---------- Figure 5: Overlong routing exists in nested NEMO basic support application Zhao, et al. Expires May 22, 2008 [Page 9] Internet-Draft Limitations of Mobility Solution November 2007 5. Conclusion If network entities do not know other's capacity and treat different kind of entities as the very one, it could not maximize the network resources and provide good service. Those limits seem to be a big issue to NEMO application because MR is a different mobile node. On the other hand, if we want to prompt the route efficiency of mobile network, potential solutions most likely is based on information the MRs got. The information for application optimization may be received directly through AAA, or through the access network. And in some applications, network entities can get information required only through messages exchange, then they can perform specific optimization process. Zhao, et al. Expires May 22, 2008 [Page 10] Internet-Draft Limitations of Mobility Solution November 2007 6. Proposed Solution By inserting an indication bit in router solicitation, MR can tell the network it's a MR not a MN. On the other hand, MR can insert a bit in its router advertisement to indicate that it is not a normal router. Based on this method, MRs can exchange other information to negotiate a specific RO process for potential NEMO application. Zhao, et al. Expires May 22, 2008 [Page 11] Internet-Draft Limitations of Mobility Solution November 2007 7. IANA Consideration There is no IANA consideration in this document. Zhao, et al. Expires May 22, 2008 [Page 12] Internet-Draft Limitations of Mobility Solution November 2007 8. Security Consideration This document states some limitations when some mobility management solutions cooperate. In particular, it does not introduce new security concerns to current architecture. Optimization for current solutions might introduce new threats, but it is out of the scope of this document. Zhao, et al. Expires May 22, 2008 [Page 13] Internet-Draft Limitations of Mobility Solution November 2007 9. References [draft-ietf-netlmm-proxymip6-07] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-07 (work in progress), Nov 2007. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. Zhao, et al. Expires May 22, 2008 [Page 14] Internet-Draft Limitations of Mobility Solution November 2007 Authors' Addresses Yuankui zhao Shanghai Huawei Technology Email: john.zhao@huawei.com Ke Lin Shanghai Jiao Tong University Wentao Zhong Shanghai Jiao Tong University Zhao, et al. Expires May 22, 2008 [Page 15] Internet-Draft Limitations of Mobility Solution November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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). Zhao, et al. Expires May 22, 2008 [Page 16]