One document matched: draft-wakikawa-mext-haha-interop2008-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 06:53:42 |