MEXT Working Group R. Wakikawa (Editor) Internet-Draft Toyota ITC Intended status: Informational K. Shima Expires: January 9, 2009 IIJ Research Laboratory N. Shigechika Keio University July 8, 2008 The Global HAHA Operation at the Interop Tokyo 2008 draft-wakikawa-mext-haha-interop2008-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 9, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Wakikawa (Editor), et al. Expires January 9, 2009 [Page 1] Internet-Draft HAHA experimentation July 2008 Abstract This document describes the protocol design consideration of the correspondent router for the NEMO Basic Support Protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Operational Configuration . . . . . . . . . . . . . . . . . . 4 3. Global HAHA Protocol . . . . . . . . . . . . . . . . . . . . . 5 4. Experimentation Result . . . . . . . . . . . . . . . . . . . . 9 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 11 A.1. Normative References . . . . . . . . . . . . . . . . . . . 11 A.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Wakikawa (Editor), et al. Expires January 9, 2009 [Page 2] Internet-Draft HAHA experimentation July 2008 1. Introduction The Global HAHA protocol [ID-HAHA] has been discussed for long time in MIP6, NEMO and now MEXT working group. We have published several documents [ID-HAHA] [ID-HAHAPROTO] and presented several time in IETF meetings. We implemented a protocol for the global HAHA and tested it in the real networks. Some results can be found in [PAPER- CONEXT]. We have tested a Global HAHA protocol at the Interop Tokyo 2008 [INTEROP-TOKYO]. The Interop is a global event of the networking products and services. There are more than 300 exhibitors and about 150,000 visitors in this year. In the Interop Tokyo, the Network Operation Center (NOC) team builds an experimental advanced network called "ShowNet" as a backbone of the event. The experimental network was connected to several peering points (Internet Exchange Point) by more than 120G bps links in this year. Our global HAHA experimentation was served as a part of "ShowNet". As additional information, the WIDE project [WIDE] is operating the global HAHA testbed with IIJ and other network operators. The three home agents are configured in Tokyo, Los Angeles, and Seoul. We have a dedicated autonomous system number (AS4690) for this experimentation and operates the huge block of prefix (/35) as a home prefix. Wakikawa (Editor), et al. Expires January 9, 2009 [Page 3] Internet-Draft HAHA experimentation July 2008 2. Operational Configuration In the Interop Tokyo 2008, we setup two home agents in the ShowNet. Figure 1 is the overview of ShowNet. More detail topology can be found in [INTEROP-TOKYO]. In the event, we used 6 halls for the exhibits and one conference hall for the tutorial and technical sessions. In ShowNet, two NOCs (operational center) were located in both Hall2 and Hall4. We configured the home agents in both NOCs. For IP anycast routing, the upper router of the home agent advertise the routes of the home prefix by OSPF with equal cost. The home agents did not advertise the route by themselves. If a mobile node attaches to the networks in the hall 1 to 3, it associates with the home agent in the Hall-2 (HA1 in Figure 1). Otherwise, the mobile node registers to the home agent in the Hall-4 (HA2). Internet Server Segement || Segement in Hall-1-3 || in Hall-4-6 | || | |--------- BackBone ----------| HA1 ---+ / \ +--- HA2 | / \ | | | | | Segments Segments in Hall-1-3 in Conference-Hall Figure 1: SHOWNET Overview and HAs Location Implementation informations: For the home agents, we uses the NetBSD current version (20080128). The global HAHA is implemented on top of the SHISA package [SHISA]. For the mobile nodes, we prepare two different operating systems. One is NetBSD current (20080128) with the SHISA package. Another is Ubuntu LINUX and MIPL package. The SHISA and MIPL packages were modified to support the Home Agent Switch message [RFC-5142]. We setup 6 NetBSD machines (ThinkPAD) and also distributed the virtual machine image for the Ubuntu mobile node to the experimentation participants. The mobile nodes for this experimentation was not open to the public users due to security reason, because the mobile node was grant for the permission to access the ShowNet. Wakikawa (Editor), et al. Expires January 9, 2009 [Page 4] Internet-Draft HAHA experimentation July 2008 3. Global HAHA Protocol We describe a global HAHA protocol implementing on NetBSD SHISA package in this section. This protocol is defined as an extension to the Home Agent Reliability protocol. Figure 2 shows the protocol sequence of the Global HAHA. Some new terms are introduced to explain the protocol as follows: Global Home Agent Set The set of home agents serving the same home prefix. The home agents can be located in different locations. HAHA link For the global HAHA, each home agent maintain a link to other home agents. The link can be IP-in-IP tunnel, some L2 technology like L2TP or even direct dedicated link. If the HAHA link is a dedicated fiber link, the global HAHA can be easily operated without any complexity or protocol extensions described in this section. Primary Home Agent The home agent which a mobile node is currently registering. This primary home agent must be the closest home agent of the mobile node. The primary home agent is defined per a mobile node. Initial Binding Registration (1-2 in Figure 2) As Mobile IPv6 [RFC-3775] and the NEMO Basic Support protocol [RFC- 3963], the mobile node attempts the binding registration to its home agent. In the global HAHA, the binding update is routed to the closest home agent of the mobile node by IP anycast routing. The home prefix is advertised from different location by anycast technology. As soon as the primary home agent (HA1) creates a binding cache for the mobile node, it sends a Binding Notification message to the other home agents (HA2) in the same global home agent set. HA2 creates a host route to the mobile node with the next hop set to the HAHA link of HA1 and HA2. For a mobile router, it can be the network route to the mobile network prefix of the mobile router. With that route, when HA2 receives the traffic meant to the mobile node, it can forward the traffic to the HA1 over the HAHA link. The route must be maintained with the lifetime and should be available while the binding is active on the HA1. How to maintain the host Wakikawa (Editor), et al. Expires January 9, 2009 [Page 5] Internet-Draft HAHA experimentation July 2008 route is out of scope in this document. In our implementation, we use the same lifetime of the binding cache entry at HA1. Therefore, whenever HA1 receives a binding update from the mobile node for extending the binding lifetime , it also sends another Binding Notification message to the HA2. There might be scalable issue for this periodic update approach, but we can fix this. For example, the route on HA2 is activated until the HA1 sends a new signaling indicating the route deletion (on-demand management). MN HA1 HA2 CN | | | | |----> (Primary) | | 1. Binding Registration (HA1) | |-------->| | 2. Binding Notification |<========|<========|<--------| 3. From CN to MN |========>|------------------>| 4. From MN to CN | | | | : : : : MN MOVEMENT | | | | |------------------+| | 5. Binding Registration | |<=======+| | |<--------| | | 6. Home Agent Switch |--------------> (Primary) | 7. Binding Re-registration | |<--------| | 8. Binding Notification |<==================|<--------| 9. From CN to MN |==================>|-------->| 10. From MN to CN | | | | Figure 2: Overview of Global HAHA Binding Update after Movement (5-8 in Figure 2) After the mobile node changes its point of attachment, it sends a Binding Update to renew its binding as [RFC-3775]. In this case, if the closest home agent is changed to HA2, the Binding Update is arrived at the HA2 according to the IP anycast routing. The primary home agent of the mobile node is changed from HA1 to HA2. However, the destination address of the Binding Update is still the address of the HA1 because the mobile node is unaware of the primary home agent change. Therefore, the HA2 forwards the Binding Update to the HA1 over the HAHA link. The HA1, then, detects that the primary home agent is now changed to the HA2 because the Binding Update is forwarded from the HA2. It first processes the Binding Update and returns a Binding Acknowledgment to the mobile node. In parallel, it triggers a Home Agent Switch message [RFC-5142] to the mobile node. In the Home Agent switch message, the address of the HA2 is stored in Wakikawa (Editor), et al. Expires January 9, 2009 [Page 6] Internet-Draft HAHA experimentation July 2008 the Home Agent Address field. When the mobile node receives the Home Agent Switch message from the HA1, it processes it according to [RFC-5142] and switches its home agent to the HA2. The mobile node sends another Binding Update to the HA2. After receiving the Binding Update, the HA2 creates the binding cache and sends a Binding Notification message to the other Home Agents (i.e. HA1) in the global home agent set. The HA1 removes the binding cache entry of the mobile node and creates the route for the mobile node with the next hop set to the HA2 over the HAHA link. Figure 3 shows the new message named "Binding Notification message". This message is used for the active home agent to notify the mobile node registration to the other home agents in the global home agent set. Routing Packets (3-4, 9-10 in Figure 2) The packets originated by the mobile node are always routed through the primary home agent as shown in Figure 2. They are tunneled to the primary home agent to which the mobile node is currently registering and, then, routed directly to the CN. The primary home agent does not have the state of the correspondent node and cannot forward the packets to the closest home agent of the correspondent node. On the other hand, the packets originated by the correspondent node are routed to the closest home agent by IP anycast routing. If the home agent is not the active home agent of the mobile node (destination), the home agent looks up the routing table and routes them to the active home agent of the mobile node over the HAHA link. Then, the active home agent routes the packets to the mobile node over the bi-directional tunnel. Mobile Node/Router Requirements For mobile nodes and mobile routers, no modification specific to the global HAHA is required. In addition to [RFC-3775] and [RFC-3963], the Home Agent Switch message is required. It is already standardized as [RFC-5142]. Wakikawa (Editor), et al. Expires January 9, 2009 [Page 7] Internet-Draft HAHA experimentation July 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | PfxLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Addresses + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Binding Notification Message Type 8-bit unsigned integer. PfxLen The length of the Prefix. If the message is for a home address, the prefix length is set to 128. Target Address This field is set to either Home Address or Mobile Network Prefix Wakikawa (Editor), et al. Expires January 9, 2009 [Page 8] Internet-Draft HAHA experimentation July 2008 4. Experimentation Result During the five days event, the global HAHA was successfully operated. We had about 30 mobile nodes registering to our home agents. For the network setting, we needed special consideration on the configurations of IP anycast routing. When we setup the IP anycast for the home prefix, the upper routers of both home agents advertise the home prefix with equal OSPF cost. If a router receives two different routing updates for the same prefix with the equal cost, it often operates the equal-cost multipath routing. This is a natural behavior of most of routers today when multiple routes for a same prefix with an equal cost are received. In our experimentation, if the router switches the nexthop for the home prefix in the round- robin fashion, the mobile node sometime switched the active home agent per binding update. In order to avoid the equal-cost multipath routing, we set the static route to these routers who is receiving the equal cost routes by OSPF. The equal-cost multipath routing is discussed in [RFC-2991]. The IP anycast must be carefully configured for the global HAHA specially when multiple home agents are distributed in the same autonomous system due to the equal-cost multipath routing. The IP anycast routing of the global HAHA is not effected to other parts of networks. The influence to the networks is only limited to the home network (i.e. Mobile IPv6 or NEMO operations). Wakikawa (Editor), et al. Expires January 9, 2009 [Page 9] Internet-Draft HAHA experimentation July 2008 5. IANA considerations This document does not require any IANA action. Wakikawa (Editor), et al. Expires January 9, 2009 [Page 10] Internet-Draft HAHA experimentation July 2008 6. Security Considerations Security vulnerability is not introduced in this specification. Appendix A. References A.1. Normative References A.2. Informative References [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC-2991] D. Thaler and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000. [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [RFC-4888] C. Ng, et. al, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007. [RFC-4889] C. Ng, et. al, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007. [ID-HAHA] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA protocol", draft-thubert-mext-global-haha-00.txt (Work in Progress), March 2008 [ID-HAHAPROTO] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home Agents Protocol Specification", draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), March 2006. [ID-AEROREQ] W. Eddy, et. al,"NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02.txt, May 2008. [ID-AUTOREQ] R. Baldessari, et. al, "Automotive Industry Requirements for NEMO Route Optimization", Wakikawa (Editor), et al. Expires January 9, 2009 [Page 11] Internet-Draft HAHA experimentation July 2008 draft-ietf-mext-nemo-ro-automotive-req-00.txt, February 2008. [PAPER-CONEXT] Ryuji wakikawa, Guillaume Valadon, Jun Murai., "Migrating Home Agents towards Internet-Scale Mobility Deployments", ACM 2nd CoNEXT Conference on Future Networking Technologies, Lisbon, Portugal. 4-7 December 2006 [INTEROP-TOKYO] http://www.interop.jp/ (2008, July) [WIDE] http://www.wide.ad.jp/ (2008, July) [SHISA] http://sourceforge.net/projects/shisa/ (2008, July) Authors' Addresses Ryuji Wakikawa Toyota ITC / Keio University 6-6-20 Akasaka, Minato-ku Tokyo 107-0052 Japan Phone: +81-3-5561-8276 Fax: +81-3-5561-8292 Email: ryuji@jp.toyota-itc.com Keiichi Shima Research Laboratory, Internet Initiative Japan Inc. Jinboucho Mitsui Building 1-105 Jinboucho, Kanda Chiyoda-ku, Tokyo 101-0051 JAPAN Phone: +81 3 5205 6464 Email: keiichi@iijlab.net URI: http://www.iij.ad.jp/ Wakikawa (Editor), et al. Expires January 9, 2009 [Page 12] Internet-Draft HAHA experimentation July 2008 Noriyuki Shigechika Keio University Department of Environmental Information, Keio University. 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Phone: +81-466-49-1100 Fax: +81-466-49-1395 Email: nazo@sfc.wide.ad.jp Wakikawa (Editor), et al. Expires January 9, 2009 [Page 13] Internet-Draft HAHA experimentation July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Wakikawa (Editor), et al. Expires January 9, 2009 [Page 14]