No Specific Working Group Kenichi Nagami(INTEC Netcore)
Internet-Draft Satoshi Uda (JAIST)
Expires: August 21, 2005 Nobuo Ogashiwa(INTEC Netcore)
Ryuji Wakikawa(Keio Univ.)
Hiroshi Esaki(Univ. Tokyo)
Hiroyuki Ohnishi(NTT)
Feb 21, 2005
Multi-homing for small scale fixed network Using Mobile IP and NEMO
<draft-nagami-mip6-nemo-multihome-fixed-network-03.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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 August 21, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Multi-homing technology improves the availability of host and
network connectivity. Since the node and network behavior of
mobile networking and fixed networking are different, the
different architecture has been discussed and proposed. This
document proposes the common architecture both for mobile and
fixed networking environment, using the mobile IP and NEMO. The
proposed architecture only requires a modification of the mobile
IP and NEMO so that multiple-CoA can be used. In addition,
multiple HAs which are located in different place, are required
for redundancy.
Nagami, et al. Expires August 21, 2005 [Page 1]
Internet-Draft Multihoming for Fixed Network Feb 2005
1. Motivation
Users of small-scale network need to improve the network
availability and to get load balance of several links by easy
method. Multi-homing technology is one of solutions to improve the
availability. Conventional major multi-homing network uses
BGP. But it has some issues. Therefore, we propose a multi-homing
architecture using the mobile IP and NEMO for small-scale fixed
network.
1.1 General Benefits of Multi-homing
In a multi-homing network environment, both users and network
managers takes several benefits by controlling out-going traffic,
in-comming traffic or both of them. Those benefits are listed in
the draft [GMUL] as the goals and benefits of multi-homing. The
following is a summary of those goals and benefits listed in the
draft.
o Ubiquitous Access
o Redundancy/Fault-Recovery
o Load Sharing
o Load Balancing
o Bi-casting
o Preference Settings
1.2 Problems to be Solved to Accomplish Multi-homing
Several multi-homing technologies have been proposed so far.
Conventional major multi-homing network uses BGP. But it has some
issues as follows.
(1) Increasing route entries in the Internet
In the multi-homing environments, each user's network needs to
advertise its address block to all ISPs connected to them. If
multi-homed user connects only one ISP, the ISP can advertise
routing information to aggregate them. But some multi-homed
user needs to connect with different ISPs in preparation for
failure of ISP. In this case, ISPs need to advertise routing
information for multi-homed user without aggregation.
Therefore, the number of routing entries in the Internet is
increasing one by one.
(2) Difficulty to efficiently use multiple links
It is not easy to control in-coming traffics in the case of the
conventional multi-homing architecture using BGP. Therefore,
load balancing of connected links are difficult.
Nagami, et al. Expires August 21, 2005 [Page 2]
Internet-Draft Multihoming for Fixed Network Feb 2005
1.3 Using the Architecture of Mobile IP and NEMO to Solve the Problems
Basically, the Mobile IP and the NEMO have been proposed for mobile
host or mobile network, however the architecture and the protocol
of them can be used for fixed networks. The following problems
mentioned avobe can be solved by using the architecture and the
protocol of them. The details of the solution is being described
in the later section.
o increasing route entries in the Internet
o difficulty to efficient use multiple links
Moreover, by using the architecture and the protocol of the MIP
and the NEMO, a cost of network operation will be decreased. For
instance, in the architecture of the MIP and the NEMO, renumbering
IP addresses when relocation of an office or network equipments
becomes needless in consequence of that the network address prefix
used in a user network in a Mobile IP environment is not depend on
the upstream ISP's network prefix.
2. Multi-homing Architecture Using Mobile IP and NEMO
2.1 Mobile Network Includes Fixed Network
NEMO and Mobile IP must work with multi-homing by its nature. This
is because mobile nodes need to use multiple links for improving
the availability of network connectivity since the wireless link
is not always stable. Therefore, we propose that multihoming for
fixed nodes (routers and hosts) use the framework of NEMO and
Mobile IP.
Nagami, et al. Expires August 21, 2005 [Page 3]
Internet-Draft Multihoming for Fixed Network Feb 2005
2.2 Overview multi-homing network architecture using Mobile IP
Figure 1 shows basic multi-homing network architecture. In this
architecture, a mobile router (MR), which is boarder router of
multi-homed network, sets up several tunnels between the MR and
the HA by multiple-CoA registration. A HA or a router which the HA
belongs advertise user's network prefix (Prefix X in Fig.1) to
ISPs via routing protocol. If HA has several multi-homed network
(Prefix X and Y in Fig.1), they can advertise an aggregated
network prefix to ISPs. Therefore, the Internet routing entries do
not increase one by one when multi-homed user is increased.
HA1
||(Advertise aggregated prefix X and Y)
|v
ISP
|
+------------------------+---------------------+
| The Internet |
+-+----------+--------------------+----------+-+
| | | |
ISP-A ISP-B ISP-A' ISP-B'
| | | |
| | | |
+--- MR ---+ +--- MR ---+
CoA1 | CoA2 CoA1|CoA2
| |
-------+--------- (Prefix X) -------+------ (Prefix Y)
Multihomed Network X Multihomed Network Y
Fig.1 advertisement of aggregated prefixes
Nagami, et al. Expires August 21, 2005 [Page 4]
Internet-Draft Multihoming for Fixed Network Feb 2005
Packets to multi-homed users go to HA and the HA sends packets to
MR using CoA1 and CoA2. The HA selects a route which CoA is
used. The route selection algorithm is out of scope of this
document. This can improve availability of user network and
control an in-coming traffic between ISP and MR. In the basic
architecture, HA1 is single point of failure. In order to improve
availability of user network, multiple HA is needed. This is
described in later section.
HA1
^ | |
(1) Packets to prefix X | | | (2) HA forwards the packets
are sent to HA | | v to CoA1 or CoA2
+-------+------+
| The Internet |
+-+----------+-+
| |
| | |(3) packets are forwarded over
| | | the MIP tunnel selected by
| | v the HA1
ISP-A ISP-B
| | |
| | |
+--- MR ---+ v
CoA1 | CoA2
|
-------+--------- (Prefix X)
Multihomed Network A
Fig.2 packet forwarding by HA
3. Requirements for Mobile IP and NEMO
3.1 Multiple Care-of-Addresses (CoA)
Multiple Care-of-Addresses needs to improve the availability and
to control in coming and out going traffic. The current Mobile
IPv6 and the NEMO Basic Support protocol does not allow to
register more than one care-of address bound to a home address to
the home agent. Therefore, [MCoA] is proposed to extend the MIP6
and the NEMO Basic Support to allow multiple care-of address
registrations for the particular Home Address.
Nagami, et al. Expires August 21, 2005 [Page 5]
Internet-Draft Multihoming for Fixed Network Feb 2005
3.2 Multiple Home Agents
Multiple Home Agents should be geographically distributed across
the Internet, for the improvement of service availability and for
the load balancing of HA. When all the networks that have HA
advertise the same network prefix to their adjacent
router/network, the traffic is automatically routed to the nearest
Home Agent from the view point of routing protocol topology. This
operation has been already proven operational technology in the
area of web server application, such as CDN (Contents Delivery
Network), regarding IGP and EGP.
In order to operate multiple HAs, all HAs must have the same
information such as binding information. This is the
synchronization of database among the HA. The HAHA protocol
[HAHA] introduces the binding synchornozation among HAs. This is
the same architecture as I-BGP. The database is synchronized by
full-mesh topology. In addition, in order to simplify operation of
HA, the database is synchronized using star topology. This is
analogy with I-BGP route reflector.
sync
HA1 <----> HA2
| |
+-+----------+-+
| The Internet |
+-+----------+-+
| |
ISP-A ISP-B
| |
| |
+--- MR ---+
CoA1 | CoA2
|
-------+---------
Multihomed Network
Fig.3 Architecture with HA redundancy
Nagami, et al. Expires August 21, 2005 [Page 6]
Internet-Draft Multihoming for Fixed Network Feb 2005
4. Discussion on the Mailing List
4.1. Why does the proposed architecture use NEMO protocols
The multihome architecture proposed in this draft is
basically same as the architecture of NEMO. Furthermore, NEMO
protocols meet to requirements of the proposed architecture in
this draft, which are:
- protocol can inform CoA, HoA, BID from MR to HA
- protocol can establish multiple tunnels between MR and HA
- protocol support multiple HA and can synchronize Binding
Caches among multiple HAs
The proposed multihome architecture uses NEMO protocols as one
of applications of NEMO. Needless to say, using NEMO protocol
is one of solutions to accomplish the proposed multihome
architecture. Another solution is to propose a new protocol
just like NEMO. Nevertheless, such new protocol will have
functions just same as NEMO.
4.2. Route Announcement from Geographically Distributed Multiple HAs
In proposed architecture, xSP (Multihome Service Provider) is
introduced. xSP is a conceptual Service Provider and it
doesn't have to be connected to the Internet physically for
all practical purpose. xSP has one or more aggregatable mobile
network prefixes. xSP contracts with some ISPs that are
physically connected to the Internet. The purpose of this
contract is to setup some HAs into those ISP's network. Those
HAs announce the xSP's aggregated mobile network
prefixes. This means that HAs work just like border gateway
router, and this situation is same as peering between ISP and
xSP. In this case, origin AS announced from HAs is xSP.
On the other hand, multihome user (small office user or home
user) contract with xSP to acquire a mobile network prefix
from xSP. Each multihome user has a MR and multiple L3
connectivity to the Internet via multiple ISPs and the MR will
establish multiple tunnels to HA. Since user's mobile network
prefixes are aggregated and announced from HA, packets to
user's mobile network will be sent to nearest HA depending on
global route information at that time and HA that received
such packets forward those packets to user's network over the
established multiple tunnels.
This model of route announcement from multiple HA is along
with the conventional scalable Internet architecture and it
doesn't have scalability problems.
Nagami, et al. Expires August 21, 2005 [Page 7]
Internet-Draft Multihoming for Fixed Network Feb 2005
5. Implementation and Experimentation
We have implemented and experimented the proposed architecture.
Currently, the system works well not only on our test-bed network,
but on the Internet. In our experimentation, MR has two upstream
organizations (ISPs) and two Care-of-Addresses for each
organizations. The MR uses multiple-CoA option to register the
Care-of-Addresses to HA.
Nagami, et al. Expires August 21, 2005 [Page 8]
Internet-Draft Multihoming for Fixed Network Feb 2005
6. Security considerations
This draft does not raise specific security issues beyond those of
existing mobile IP and NEMO and routing protocols.
References
[MCOA] R. Wakikawa, et al, "Multiple Care-of Addresses
Registration", Internet Draft,
IETF. draft-wakikawa-mobileip-multiplecoa-02.txt, Sep.,
2003.
[HAHA] R. Wakikawa, et al, "Inter Home Agents Protocol (HAHA)",
Internet Draft, IETF. draft-wakikawa-mip6-nemo-haha-01.txt,
Feb., 2004.
[GMUL] E. Thierry, et al, "Goals and Benefits of Multihoming",
Internet Draft,
IETF. draft-multihoming-generic-goals-and-benefits-00.txt,
Feb., 2004.
Nagami, et al. Expires August 21, 2005 [Page 9]
Internet-Draft Multihoming for Fixed Network Feb 2005
Author's Addresses
Kenichi Nagami
INTEC NetCore Inc.
1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan
Email: nagami@inetcore.com
Satoshi Uda
School of Information Science Japan Advanced Institute of
Science and Technology
1-1 Asahidai, Tatsunokuchi, Ishikawa, 923-1292, Japan
Email: zin@jaist.ac.jp
Nobuo Ogashiwa
INTEC NetCore Inc.
1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan
Email: ogashiwa@inetcore.com
Hiroshi Esaki
Graduate School of Information Science and Technology,
The university of Tokyo
7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-8656, Japan
Email: hiroshi@wide.ad.jp
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa, 252-8520, Japan
Email: ryuji@sfc.wide.ad.jp
Hiroyuki Ohnishi
NTT Network Service Systems Laboratories, NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585, Japan
Email: ohnishi.hiroyuki@lab.ntt.co.jp
Nagami, et al. Expires August 21, 2005 [Page 10]
Internet-Draft Multihoming for Fixed Network Feb 2005
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 (2005). 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.
Nagami, et al. Expires August 21, 2005 [Page 11]