NEMO Working Group M. Watari Internet-Draft T. Ernst Expires: April 14, 2005 WIDE at Keio University October 14, 2004 Route Optimization with Nested Correspondent Nodes draft-watari-nemo-nested-cn-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 14, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document aims at assisting the problem statement of route optimization in nested mobile networks. We describe the paths packets would take using existing Mobile IPv6 and NEMO Basic Support mechanisms when one or both end nodes of a communication flow are located in a nested NEMO. One of both of the end nodes may themselves be either mobile nodes performing Mobile IPv6, or standard IPv6 nodes performing no mobility function at all. The path can Watari & Ernst Expires April 14, 2005 [Page 1] Internet-Draft RO with Nested CN October 2004 become extremely suboptimal if no optimization is provided. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. CN located in the fixed infrastructure . . . . . . . . . . . . 4 2.1 Case A: LFN and standard IPv6 CN . . . . . . . . . . . . . 4 2.2 Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 5 2.3 Case C: VMN and standard IPv6 CN . . . . . . . . . . . . . 5 3. CN located in distinct nested NEMOs . . . . . . . . . . . . . 7 3.1 Case D: LFN and standard IPv6 CN . . . . . . . . . . . . . 7 3.2 Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 8 3.3 Case F: VMN and standard IPv6 CN . . . . . . . . . . . . . 8 4. CN and MNN located in the same nested NEMO . . . . . . . . . . 10 4.1 Case G: LFN and standard IPv6 CN . . . . . . . . . . . . . 10 4.2 Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 11 4.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 11 5. CN located behind the same nested MR . . . . . . . . . . . . . 13 5.1 Case H: LFN and standard IPv6 CN . . . . . . . . . . . . . 13 5.2 Case I: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 14 5.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 14 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Watari & Ernst Expires April 14, 2005 [Page 2] Internet-Draft RO with Nested CN October 2004 1. Introduction This document assumes the reader is familiar with the NEMO Basic Support protocol defined in [1], and with Mobile IPv6 defined in [4]. The reader should also be familiar with the NEMO Terminology defined in [2]. The NEMO Basic Support protocol uses a bi-directional tunnel established between the mobile router and its home agents for all communications. Such communication path brings many problems such as delay, packet loss, less MTU and so on as described in [3]. The values become even more crucial under a nested mobile network, and brings the need for route optimization. As the solutions to provide such route optimization are proposed, in this document, we try to describe some different communication models which involves a nested mobile network, and to clarify the issues for each cases. We focus on the different cases involving nested correspondent nodes, from the NEMO Basic Support perspective. A nested correspondent node is a correspondent node which itself is also a mobile network node. In the following sections, we illustrate the path followed by packets if we assume nodes only performing Mobile IPv6 and NEMO Basic Support mechanisms. There are different cases to consider since a CN may either be located in the fixed infrastructure, in a nested NEMO, or in the same nested NEMO as the MNN. Also, we have to consider the cases where CNs and MNNs are either standard IPv6 nodes or MIPv6 nodes. As defined in [2], standard IPv6 nodes are nodes with no mobility functions whatsoever, i.e. they are not MIPv6-enabled nor NEMO-enabled (this does not only mean they cannot move around keeping open connections, but also that they can't process BUs sent by MIPv6-enabled peers). Watari & Ernst Expires April 14, 2005 [Page 3] Internet-Draft RO with Nested CN October 2004 2. CN located in the fixed infrastructure The most typical configuration is the case where a MNN communicates with a Correspondent Node (CN) attached in the fixed infrastructure. Figure 1 below shows an example of such topology. The 3 models generally assumed for route optimization are CN as a MIPv6-enabled node, CN attached behind a Correspondent Router, or a standard IPv6 node using a bi-directional tunnel between the root-MR and its HA. +--------+ +--------+ +--------+ | MR1_HA | | MR2_HA | | MR3_HA | +---+----+ +---+----+ +---+----+ | | | +-------------------------+ | Internet |----+ CN +-------------------------+ | | +---+---+ +--+-----+ root-MR | MR1 | | VMN_HA | +---+---+ +--------+ | +---+---+ sub-MR | MR2 | +---+---+ | +---+---+ sub-MR | MR3 | +---+---+ | ----+---- MNN Figure 1: CN located at the infrastructure 2.1 Case A: LFN and standard IPv6 CN The simplest case is where both MNN and CN are fixed nodes with no mobility functions. That is, MNN is a LFN, and CN is a standard IPv6 node. Packets are encapsulated between each MR and its respective HA. As shown in Figure 2, in such case, the path between the two nodes would go through: Watari & Ernst Expires April 14, 2005 [Page 4] Internet-Draft RO with Nested CN October 2004 1 2 3 4 3 2 1 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN LFN IPv6 Node The digits represent the number of IPv6 headers. Figure 2: MNN and CN are standard IPv6 nodes Route optimization would require collaboration among the MRs. To avoid tunneling through any HA, Correspondent Routes (CRs) may be placed near CNs to handle bindings. CRs are routers enhanced which the ability to handle bindings for a mobile network, allowing a direct tunnel to the MR providing a certain level of optimization. 2.2 Case B: VMN and MIPv6 CN In this second case, both end nodes are MIPv6-enabled mobile nodes, that is, MNN is a VMN. MIPv6 route optimization may thus be initiated between the two and packets wouldn't go through the HA of the VMN nor the HA of the CN (not shown in the figure). However, packets will still be tunneled between each MR and its respective HA, in both directions. As shown in Figure 3, the path between VMN and CN would go through: 1 2 3 4 3 2 1 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN VMN MIPv6 Figure 3: MMN and CN are MIPv6 mobile nodes 2.3 Case C: VMN and standard IPv6 CN When the communication involves a MIPv6 node either as a MNN or as a CN, MIPv6 route optimization can not be performed because the standard IPv6 CN cannot process MIPv6 signaling. Therefore, VMN would establish a bi-directional tunnel with its HA, which causes the flow to go out the nested NEMO. Packets between MNN and CN would thus go through VMN's own HA (VMN_HA). The path would therefore be as shown on Figure 4: Watari & Ernst Expires April 14, 2005 [Page 5] Internet-Draft RO with Nested CN October 2004 2 3 4 5 4 3 2 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA VMN | | 1 | CN IPv6 Node Figure 4: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Providing route optimization involving a MIPv6 node may require optimization among the MRs and the MIPv6 node. Watari & Ernst Expires April 14, 2005 [Page 6] Internet-Draft RO with Nested CN October 2004 3. CN located in distinct nested NEMOs The CN may be located in another nested NEMO, different from the one MNN is attached to, as shown on Figure 5. We define such configuration as ``distinct nested NEMOs.'' The models generally assumed for route optimization are optimization among all MRs in both NEMOs, and a bi-directional tunnel between the two root-MRs. +--------+ +--------+ +--------+ +--------+ | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +-------------------------+ +--------+ | MR1_HA |----| Internet |----| VMN_HA | +--------+ +-------------------------+ +--------+ | | +---+---+ +---+---+ root-MR | MR1 | | MR4 | +---+---+ +---+---+ | | +---+---+ +---+---+ sub-MR | MR2 | | MR5 | +---+---+ +---+---+ | | +---+---+ ----+---- sub-MR | MR3 | CN +---+---+ | ----+---- MNN Figure 5: MNN and CN located in distinct nested NEMOs 3.1 Case D: LFN and standard IPv6 CN Similar with Case A, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every mobile router on the way out the nested NEMO, decapsulated by the HAs and then encapsulated again on its way down the nested NEMO. Watari & Ernst Expires April 14, 2005 [Page 7] Internet-Draft RO with Nested CN October 2004 1 2 3 4 3 2 1 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA LFN | | 2 1 2 3 | CN --- MR5 --- MR4 --- MR4_HA IPv6 Node Figure 6: MNN and CN are standard IPv6 nodes 3.2 Case E: VMN and MIPv6 CN Similar with Case B, when both end nodes are MIPv6 nodes, the two nodes may initiate MIPv6 route optimization. Again, packets will not go through the HA of the VMN nor the HA of the MIPv6 CN (not shown in the figure). However, packets will still be tunneled for each MR to its HA and vise versa. Therefore, the path between MNN and CN would go through: 1 2 3 4 3 2 1 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA VMN | | 2 1 2 3 | CN --- MR5 --- MR4 --- MR4_HA MIPv6 Figure 7: MNN and CN are MIPv6 mobile nodes 3.3 Case F: VMN and standard IPv6 CN Similar to Case C, when the communication involves a MIPv6 node either as a MNN or as a CN, MIPv6 route optimization can not be performed because the standard IPv6 CN cannot process MIPv6 signaling. VMN would therefore establish a bi-directional tunnel with its HA. Packets between MNN and CN would thus go through VMN's own HA as shown on figure Figure 8: Watari & Ernst Expires April 14, 2005 [Page 8] Internet-Draft RO with Nested CN October 2004 2 3 4 5 4 3 2 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA VMN | | 1 1 2 3 2 | CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA IPv6 Node Figure 8: MNN is a MIPv6 mobile node and CN a standard IPv6 node Watari & Ernst Expires April 14, 2005 [Page 9] Internet-Draft RO with Nested CN October 2004 4. CN and MNN located in the same nested NEMO Figure 9 below shows the case where the two communicating nodes are connected behind a different MR, but the MRs are connected in the same nested NEMO, and thus behind the same root-MR. Route optimization can avoid packets being tunneled outside the nested NEMO. +--------+ +--------+ +--------+ +--------+ | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +-------------------------+ +--------+ | MR1_HA |----| Internet |----| VMN_HA | +--------+ +-------------------------+ +--------+ | +---+---+ root-MR | MR1 | +-------+ | | +-------+ +-------+ sub-MR | MR2 | | MR4 | +---+---+ +---+---+ | | +---+---+ +---+---+ sub-MR | MR3 | | MR5 | +---+---+ +---+---+ | | ----+---- ----+---- MNN CN Figure 9: CN and MNN located in the same nested NEMO 4.1 Case G: LFN and standard IPv6 CN Again, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every mobile router on the way out the nested NEMO via the root-MR, decapsulated and encapsulated by the HAs and then make their way back to the nested NEMO through the same root-MR. Therefore, the path between MNN and CN would go through: Watari & Ernst Expires April 14, 2005 [Page 10] Internet-Draft RO with Nested CN October 2004 1 2 3 4 3 2 1 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA LFN | | 2 1 2 3 4 3 | CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA IPv6 Node Figure 10: MNN and CN are standard IPv6 nodes 4.2 Case H: VMN and MIPv6 CN Similar with Case B and E, when both end nodes are MIPv6 nodes, the two nodes may initiate MIPv6 route optimization which will avoid the packets to go through the HA of the VMN nor the HA of the MIPv6 CN (not shown in the figure). However, packets will still be tunneled between each MR and its respective HA in both directions. Therefore, the path would be the same with Case G and go through: 1 2 3 4 3 2 1 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA VMN | | 2 1 2 3 4 3 | CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA MIPv6 Node Figure 11: MNN and CN are MIPv6 mobile nodes 4.3 Case I: VMN and standard IPv6 CN As for Case C and Case F, when the communication involves a MIPv6 node either as a MNN or as a CN, MIPv6 route optimization can not be performed. Therefore, VMN will establish a bi-directional tunnel with its HA. Packets between MNN and CN would thus go through VMN's own HA. The path would therefore be as shown on Figure 12: Watari & Ernst Expires April 14, 2005 [Page 11] Internet-Draft RO with Nested CN October 2004 2 3 4 5 4 3 2 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA VMN | | 1 1 2 3 4 3 2 | CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA IPv6 Node Figure 12: MNN is a MIPv6 mobile node and CN a standard IPv6 node Watari & Ernst Expires April 14, 2005 [Page 12] Internet-Draft RO with Nested CN October 2004 5. CN located behind the same nested MR Figure 13 below shows the case where the two communicating nodes are connected behind the same nested MR. The optimization is required when the communication involves MIPv6-enabled nodes. +--------+ +--------+ +--------+ +--------+ | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +-------------------------+ +--------+ | MR1_HA |----| Internet |----| VMN_HA | +--------+ +-------------------------+ +--------+ | +---+---+ root-MR | MR1 | +---+---+ | +-------+ sub-MR | MR2 | +---+---+ | +---+---+ sub-MR | MR3 | +---+---+ | -+--+--+- MNN CN Figure 13: MNN and CN located behind the same nested MR 5.1 Case H: LFN and standard IPv6 CN If both end nodes are LFNs, no special function is necessary for optimization of their communication. The path between the two nodes would go through: Watari & Ernst Expires April 14, 2005 [Page 13] Internet-Draft RO with Nested CN October 2004 1 MNN --- CN LFN IPv6 Node Figure 14: MNN and CN are standard IPv6 nodes 5.2 Case I: VMN and MIPv6 CN Similar with Case H, when both end nodes are MIPv6 nodes, the two nodes may initiate MIPv6 route optimization. Although few packets would go out the nested NEMO for the Return Routability initialization, however, unlike Case B and Case E, packets will not get tunneled outside the nested NEMO. Therefore, packets between MNN and CN would eventually go through: 1 MNN --- CN VMN MIPv6 Node Figure 15: MNN and CN are MIPv6 mobile nodes If the root-MR is disconnected while the nodes exchange keys for the RR procedure, they may not communicate even though they are connected on the same link. 5.3 Case I: VMN and standard IPv6 CN When the communication involves a MIPv6 node either as a MNN or as a CN, MIPv6 route optimization can not be performed. Therefore, even though the two nodes are on the same link, VMN will establish a bi-directional tunnel with it's HA, which causes the flow to go out the nested NEMO. Path between MNN and CN would require another HA (HA4) to go through for this MIPv6 node: Watari & Ernst Expires April 14, 2005 [Page 14] Internet-Draft RO with Nested CN October 2004 2 3 4 5 4 3 2 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA VMN | | 1 | CN IPv6 Node Figure 16: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Watari & Ernst Expires April 14, 2005 [Page 15] Internet-Draft RO with Nested CN October 2004 6. Conclusion This document described the paths packets would take using existing Mobile IPv6 and NEMO Basic Support mechanisms when one or both end nodes of a communication flow are located in a nested NEMO. One of both of the end nodes may themselves be either mobile nodes performing Mobile IPv6, or standard IPv6 nodes performing no mobility function at all. This draft aims at helping the definition of the problem statement for route optimization when one or both end nodes are located in a nested NEMO. As emphasized on our figures, the path can become extremely un-optimal if no optimization is provided besides the sole opetation of existing Mobile IPv6 by some end nodes and NEMO Basic Support by the MR. The generic solution to come up should cover all cases, providing certain level of optimization for each case. 7 References [1] Devarapalli, V., Wakikawa, R., Pestrescu, A. and P. Thubert, "Nemo Basic Support Protocol", Internet Draft: draft-ietf-nemo-basic-support-03.txt, Work In Progress, June 2004. [2] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", Internet Draft: draft-ietf-nemo-terminology-01.txt, Work In Progress, February 2004. [3] Thubert, P., Molteni, M., Ng, C-W., Ohnishi, H. and E. Paik, "Taxonomy of Route Optimization models in the Nemo Context", Internet Draft: draft-thubert-nemo-ro-taxonomy-02.txt, Work In Progress, February 2004. [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC: 3775, June 2004. [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6", RFC: 2461, December 1998. Watari & Ernst Expires April 14, 2005 [Page 16] Internet-Draft RO with Nested CN October 2004 Authors' Addresses Watari Masafumi WIDE at Keio University Jun Murai Lab., Keio University. Shonan Fujisawa Campus, 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Phone: +81-466-49-1394 Fax: +81-466-49-1395 EMail: watari@sfc.wide.ad.jp Ernst Thierry WIDE at Keio University Jun Murai Lab., Keio University. K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Kawasaki, Kanagawa 212-0054 Japan Phone: +81-44-580-1600 Fax: +81-44-580-1437 EMail: ernst@sfc.wide.ad.jp URI: http://www.sfc.wide.ad.jp/~ernst/ Watari & Ernst Expires April 14, 2005 [Page 17] Internet-Draft RO with Nested CN October 2004 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 (2004). 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. Watari & Ernst Expires April 14, 2005 [Page 18]