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]