NEMO Working Group H. Cho Internet-Draft T. Kwon Expires: January 19, 2007 Seoul National University E. Paik KT July 18, 2006 Route Optimization Expected Properties and Performance Metrics for Nested Mobile Networks draft-cho-nemo-ro-expected-properties-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 January 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo categorizes the route optimization problem of NEMO and clarifies the expected properties of the route optimization protocols. The route optimization can be classified into NEMO optimization and nested NEMO optimization. Since NEMO basic support protocol is based on bi-directional tunneling, the packets from the Cho, et al. Expires January 19, 2007 [Page 1] Internet-Draft RO expected properties July 2006 CN to the MNN are suffer from inefficient routing all the cases. This routing inefficiency is getting worse when a number of MRs are nested. This memo is especially interested in nested NEMO optimization. To solve the routing inefficiency problem, there were several proposals. However, those proposals could not be compared or evaluated properly since there was no consensus on the expected properties of nested mobile networks. This memo is willing to suggest the expected properties of nested mobile networks, so as to help coming route optimization proposals find their strength and weakness according to the commonly accepted desirable properties. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. NEMO optimization and nested NEMO optimization . . . . . . . . 4 2.1. NEMO optimization . . . . . . . . . . . . . . . . . . . . 4 2.2. Nested NEMO optimization . . . . . . . . . . . . . . . . . 5 3. Mobility awareness to mobile nodes in NEMO . . . . . . . . . . 5 3.1. When we hold the mobility transparency . . . . . . . . . . 5 3.1.1. Reduced signaling . . . . . . . . . . . . . . . . . . 5 3.1.2. Long handoff disruption time . . . . . . . . . . . . . 5 3.1.3. Loose location privacy . . . . . . . . . . . . . . . . 6 3.2. When we discard the mobility transparency . . . . . . . . 6 3.2.1. Flexible route optimization . . . . . . . . . . . . . 6 3.2.2. Reduced handoff disruption time . . . . . . . . . . . 6 3.2.3. Strong location privacy . . . . . . . . . . . . . . . 6 4. Expected properties and Performance metrics . . . . . . . . . 6 4.1. Efficient routing . . . . . . . . . . . . . . . . . . . . 6 4.2. Location privacy . . . . . . . . . . . . . . . . . . . . . 7 4.3. Mobility transparency . . . . . . . . . . . . . . . . . . 7 4.4. Handoff disruption time . . . . . . . . . . . . . . . . . 7 4.5. Inter-NEMO routing . . . . . . . . . . . . . . . . . . . . 7 4.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Relationship among expected properties . . . . . . . . . . . . 8 6. Security consideration . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Case studies of existing proposals . . . . . . . . . 9 A.1. Access Router Option (ARO) . . . . . . . . . . . . . . . . 10 A.2. Recursive Binding Update (RBU+) . . . . . . . . . . . . . 10 A.3. Reverse Routing Header (RRH) . . . . . . . . . . . . . . . 10 Cho, et al. Expires January 19, 2007 [Page 2] Internet-Draft RO expected properties July 2006 A.4. Nested Path Info (NPI) . . . . . . . . . . . . . . . . . . 10 A.5. HMIP based route optimization (HMIP-RO) . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Cho, et al. Expires January 19, 2007 [Page 3] Internet-Draft RO expected properties July 2006 1. Introduction Mobile IP [1] is the basic solution to provide host mobility whereas network mobility [2] refers to the concept of collective mobility of a set of nodes. In the simplest scenario, a mobile network moves as a single unit with one mobile router (MR) that connects it to the global Internet. A mobile network can have a hierarchical structure, e.g. a mobile network within another mobile network. This situation is referred to as a nested mobile network. For example, a personal digital assistant and a mobile phone might be organized together to form a user's personal area network (PAN). A PAN may travel a vehicle, which also contains a mobile network of larger scale. In a nested mobile network, multiple MRs form a tree hierarchy in which the root MR is called the top-level mobile router (TLMR). Nested mobile networks exhibit the inefficient routing problem, which becomes worse in proportion to the number of nested levels in the hierarchy. This is the so-called pinball routing problem. To solve the pinball problem, there were several proposals. However, those proposals could not be compared or evaluated properly since there was no consensus on the expected properties of nested mobile networks. This memo is willing to suggest the expected properties of nested mobile networks, so as to help coming route optimization proposals find their strength and weakness according to the commonly accepted desirable properties. All terminologies used in this memo follow [3]. 2. NEMO optimization and nested NEMO optimization The routing optimization in NEMO context can be divided into NEMO optimization and nested NEMO optimization. 2.1. NEMO optimization As the NEMO basic support protocol adopts the tunneling based mechanism, there exists a routing inefficiency naturally. NEMO optimization is focused on how the routing path in the NEMO protocol can be optimized. One possible solution is to adopt mobile IPv6 style route optimization by sending BU to CN. However, this approach can result in the massively occurred binding update messages at the same time, so called binding update storm (BU storm) since there will be many MNNs inside the NEMO. As preventing the BU storm while a group of nodes are moving was the basic concept of NEMO, mobile IPv6 style route optimization is not desirable. Furthermore, since some Cho, et al. Expires January 19, 2007 [Page 4] Internet-Draft RO expected properties July 2006 NEMO optimization schemes might be opposed to the already standardized NEMO basic support protocol, this memo will not deal with NEMO optimization. 2.2. Nested NEMO optimization The nested NEMO optimization does not seek to solve the inefficiency of the NEMO basic support protocol. In the nested NEMO, the inefficiency is proportional to the nested level of the NEMO without any measure. The nested NEMO can have arbitrary levels of nesting. It is thought that there are two types of nesting: physical nesting and logical nesting. physical nesting means a NEMO getting into another NEMO (e.g. a PAN inside a vehicle). On the other hand, the logical nesting is not assuming the physical containing relation between the NEMOs. For example, in an area where a NEMO cannot access to the Internet like a tunnel, the NEMO may be attached to its neighbor NEMO to access to the Internet. This situation will cause logical nesting of NEMOs. Therefore, the degree of nesting can be increased to more than two levels, and nested NEMO optimization should be achieved for commercial deployment of NEMO. This memo is especially interested in nested NEMO optimization. 3. Mobility awareness to mobile nodes in NEMO One of the basic concept of network mobility is the mobiltity transparency. The mobility transparency means that an MR hides its movement to the MNNs. The only entity that knows the movement of NEMO is MR and it aggregate the location registration of underlaying VMNs and sub-MRs. However, as we take care of the nested NEMO, the mobility transparency makes the route optimization of nested NEMO too difficult. Therefore, it is needed to compare the pros and cons about holding the mobilty transparency. 3.1. When we hold the mobility transparency 3.1.1. Reduced signaling As the top-level MR only knows the movement of the NEMO, the mobility transparency will prevent the BU storm while a mass group of nodes are moving. 3.1.2. Long handoff disruption time If a route optimization scheme makes a short-cut to the nested tunnel, the MR should register the current location of nested NEMO as soon as possible to reduce the handoff disruption time. As the mobility transparency hinder the fact that it move to the MR, there Cho, et al. Expires January 19, 2007 [Page 5] Internet-Draft RO expected properties July 2006 will exist long handoff disruption time. 3.1.3. Loose location privacy The location privacy means that an MR hides its and thus all MNNs' current location to the CNs. For an example, in the route optimization scheme in mobile IPv6, an MN can send a BU to a CN to let the CN know the current location (CoA) of the MN. As the CN knows the CoA of the MN, packets toward the MN will be routed directly to the MN without visiting the HA of the MN. In this case, the location privacy is neglected for efficient routing. For the NEMO case, the same rule could be applied. 3.2. When we discard the mobility transparency 3.2.1. Flexible route optimization As the nested bi-directional tunnel could be skewed or omitted, the route optimization schemes will have more flexibility. 3.2.2. Reduced handoff disruption time All the MRs and the VMNs in the NEMO can know the movement of the whole nested NEMO. It will help the fast location update and the handoff disruption time will be shorten. 3.2.3. Strong location privacy Violating both the mobility transparency and the location privacy at the same time will cause the potential BU storm. When MRs or VMNs let the CNs know the current point of attachment of the TLMR, if the MRs and VNNs can know the movement of the TLMR, all MRs and VMNs are willing to update their location simultaneously. 4. Expected properties and Performance metrics Besides the mobility transparency and the location privacy mentioned in the previous section, there are several expected properties and performance metrics for route optimization schemes. Following sections will explain about the properties and show there exist trade-off relationships among those properties. 4.1. Efficient routing Nested mobile networks exhibit the pinball routing problem. In the NEMO basic support protocol, each mobile node (MR or VMN) has its own HA. In the worst case, when a CN sends a packet to the MNN which is Cho, et al. Expires January 19, 2007 [Page 6] Internet-Draft RO expected properties July 2006 located at the bottom level of the nested mobile network, the packet has to visit the HAs of all the MRs. As the pinball routing cause long latency and packet overhead, how short the routing path is is important. As this memo is concentrated in only nested NEMO optimization, the minimum routing path will be triangular routing (visiting only one HA). The routing efficiency will be measured by the round trip time (RTT) from CN to MNN. The increasing factor of RTT as the degree of nesting increases is matter. The constant RTT will be desirable regardless of the depth of nesting. 4.2. Location privacy The information about the location of a node (e.g. CoA) is a matter of privacy, and ideally should not be exposed to a non-administrative domain (e.g. a CN). However, the location privacy is not mandatory, since the mobile IPv6 protocol already permits a binding update to the CN for the route optimization. As many entities involved in the routing know the location of a destination node, the routing path can be shorten, however the location information might be abused by malicious entity. 4.3. Mobility transparency The NEMO basic support protocol uses a bi-directional tunnel between the HA and the MR to keep MNNs from sending all their location registrations simultaneously when the MR changes its point of attachment. This characteristic is called mobility transparency, which is a desirable feature for the route optimization scheme, as preventing the BU storm while a group of nodes are moving was the basic concept of NEMO. The mobility transparency can be measured by the number of messages per changing its location. 4.4. Handoff disruption time The handoff latency is composed with the sum of a movement detection time and a location registration time. The movement detection is achieved by very fast router advertisement. To shorten the registration time, each MRs should update their location as soon as possible. However, reducing the registration time might potentially cause the BU storm and violate the mobility transparency. Coming route optimization scheme should take care of both mobility transparency and seamless handoff. 4.5. Inter-NEMO routing A inter-NEMO routing and a intra-NEMO routing designate the same situation ironically in the nested NEMO context since a NEMO can have another NEMO and a communication between sub-NEMOs is intra-NEMO Cho, et al. Expires January 19, 2007 [Page 7] Internet-Draft RO expected properties July 2006 communication as well as inter-NEMO communication. Usually, the route to be optimized is taken to be the path between the MNN and the CN, which is outside the nested mobile network. As peer-to-peer applications proliferate, communication inside a mobile network must also be considered. 4.6. Security As the NEMO basic support protocol is based on bi-directional tunneling between HA and MR, many security concerns are shifted to the IPsec or secured tunnel mechanism. Once the tunnel established, all signaling messages and data traffics was safe from malicious entity. However, in the case of route optimization, most approaches skew the nested tunneling to shorten the routing path. In this situation, the security considerations are mostly responsible to protocol designers. Especially, for the intra-NEMO routing, intermediate MR laying in the routing path may look into the packets pass through to redirect their forwarding. The security associations among entities are necessary. 5. Relationship among expected properties Mobility | / Location transparency | / privacy | / | / | / | / |/ --------------+---------------- Inter-NEMO /| Security routing / | / | / | / | Optimal / | Seamless routing / | handoff Figure 1. Relationship among expected properties As shown in Figure 1, mobility transparency and handoff disruption time are in relation of tradeoff. "Location privacy and routing efficiency" and "inter-NEMO routing and security" properties show contrary characteristics to each other. When designing a new route optimization scheme, each expected properties should be considered. A route optimization schemes inclined to one property will lose Cho, et al. Expires January 19, 2007 [Page 8] Internet-Draft RO expected properties July 2006 another property. Finding balanced point is essential. 6. Security consideration We do not consider any security issues in this draft. 7. References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-05 (work in progress), March 2006. [4] Ng, C. and J. Hirano, "Securing Nested Tunnels Optimization with Access Router Option", draft-ng-nemo-access-router-option-01 (work in progress), July 2004. [5] Cho, H., Paik, E., and Y. Choi, "RBU+: Recursive Binding Update for End-to-End Route Optimization in Nested Mobile Networks", LNCS Vol. 3079, pp.468-478, June 2004. [6] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo-reverse-routing-header-05 (work in progress), June 2004. [7] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Secure Nested Tunnels Optimization using Nested Path Information", draft-na-nemo-nested-path-info-00 (work in progress), September 2003. [8] Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route optimization method in a mobile network", draft-ohnishi-nemo-ro-hmip-00 (work in progress), October 2003. [9] Soliman, H., Castelluccia, C., El-Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mobileip-hmipv6-08 (work in progress), June 2003. Appendix A. Case studies of existing proposals Cho, et al. Expires January 19, 2007 [Page 9] Internet-Draft RO expected properties July 2006 A.1. Access Router Option (ARO) ARO [4] is based on the route optimization mechanism of Mobile IPv6, which is then extended with an access router option. In this approach, the home agents of the MRs collect binding information from upper-level mobile routers one by one and deduce the optimal route recursively. This approach is simple and needs minimum changes in the existing NEMO basic support protocol. However, since the route is optimized step by step, the process needs a long convergence time, which is proportional to the degree of nesting. In ARO, the whole binding cache in the HA has to be searched recursively to find the optimal path to the MNN and the number of recursive steps for each packet is proportional to its degree of nesting. Furthermore, since the correspondent node also participates in the route optimization mechanism, location privacy is not guaranteed. A.2. Recursive Binding Update (RBU+) RBU+ [5] is a modification of ARO, in which the optimal route is found when the binding update messages are received by the HAs. This recursive binding update allows the HAs to maintain the binding information for the CoA of the TLMR. To handle a packet that arrives at the TLMR, RBU+ adopts ad hoc network routing inside the mobile network. MRs can maintain a routing table (proactive) or construct a routing path on demand (reactive). However, the extensive handoff disruption caused by a long convergence time, and weak location privacy, are still problems in RBU+. A.3. Reverse Routing Header (RRH) RRH [6] uses new extension headers to inform an MR's home agents of the nested structure of a mobile network and route the packets optimally. In RRH, when a packet is sent from an MNN, each intermediate MR inserts its HoA into the reverse routing header of the packet. This means that, when a packet arrives at its destination, that node can determine the optimal route back to the MNN. RRH has the problem that this header modification needs to be performed for every outgoing packet. A.4. Nested Path Info (NPI) In NPI [7], the binding update message is updated so that it informs the HAs (of the MRs) of the nested path information. However, when the TLMR moves to another site, the new nested path information will be propagated to the whole nested mobile network. After receiving this new information, every MR and VMN in the nested mobile network will send BUs at the same time; this may cause binding update storm. Cho, et al. Expires January 19, 2007 [Page 10] Internet-Draft RO expected properties July 2006 A.5. HMIP based route optimization (HMIP-RO) HMIP-RO [8] borrows the concept of a mobility anchor point (MAP) from Hierarchical MIPv6 [9], and uses it to separate routing between the CN and the MAP (outside the NEMO) and routing inside the NEMO. HMIP-RO uses a modified version of HMIPv6 to propagate MAP advertisement messages. So an MR has two care-of addresses, as it would in HMIPv6 by listening to the MAP advertisement and router advertisement messages; one is the regional CoA from the MAP and another is the on-link CoA from its closest MR. By informing the HA of the MR of the regional CoA and the MAP of the on-link CoA, respectively, packets for the MR can be routed via the MAP. However, when the MR moves to the domain of another MAP, a similar problem may occur with NPI Cho, et al. Expires January 19, 2007 [Page 11] Internet-Draft RO expected properties July 2006 Authors' Addresses Hosik Cho Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9147 Fax: +82-2-876-7170 Email: hscho@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~hscho/ Taekyoung Kwon Seoul National University Multimedia Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9105 Fax: +82-2-872-2045 Email: tk@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~tk/ Eunkyoung Paik KT Advanced Technology Lab. KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5233 Fax: +82-2-526-5759 Email: euna@kt.co.kr URI: http://mmlab.snu.ac.kr/~eun/ Cho, et al. Expires January 19, 2007 [Page 12] Internet-Draft RO expected properties July 2006 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cho, et al. Expires January 19, 2007 [Page 13]