Multi-homing for small scale fixed network Using Mobile IP and NEMO
draft-nagami-mip6-nemo-multihome-fixed-network-04
This document is an Internet-Draft (I-D) that has been submitted to the Independent Submission stream.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4908.
|
|
|---|---|---|---|
| Authors | Kenichi Nagami , Hiroyiki Ohnishi , Satoshi Uda , Ryuji Wakikawa , Nobuo Ogashiwa , Hiroshi Esaki | ||
| Last updated | 2015-10-14 (Latest revision 2007-05-14) | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Experimental | ||
| Formats | |||
| Stream | ISE state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 4908 (Experimental) | |
| Action Holders |
(None)
|
||
| Telechat date | (None) | ||
| Responsible AD | Jari Arkko | ||
| Send notices to | [email protected], [email protected] |
draft-nagami-mip6-nemo-multihome-fixed-network-04
No Specific Working Group K. Nagami
Internet-Draft INTEC NetCore
Expires: November 16, 2007 S. Uda
JAIST
N. Ogashiwa
INTEC NetCore
H. Esaki
U. Tokyo
R. Wakikawa
Keio University
H. Ohnishi
NTT
May 15, 2007
Multi-homing for small scale fixed network Using Mobile IP and NEMO
draft-nagami-mip6-nemo-multihome-fixed-network-04.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 November 16, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Nagami, et al. Expires November 16, 2007 [Page 1]
Internet-Draft Multihoming for Fixed Network May 2007
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 [1] and NEMO [2]. 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.
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 [3] 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.
Nagami, et al. Expires November 16, 2007 [Page 2]
Internet-Draft Multihoming for Fixed Network May 2007
(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 is difficult.
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 November 16, 2007 [Page 3]
Internet-Draft Multihoming for Fixed Network May 2007
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
Figure 1: advertisement of aggregated prefixes
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.
Nagami, et al. Expires November 16, 2007 [Page 4]
Internet-Draft Multihoming for Fixed Network May 2007
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
Figure 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, [4] is proposed to extend the MIP6 and the NEMO Basic
Support to allow multiple care-of address registrations for the
particular Home Address.
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
Nagami, et al. Expires November 16, 2007 [Page 5]
Internet-Draft Multihoming for Fixed Network May 2007
of database among the HA. The HAHA protocol [5] 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
Figure 3: Architecture with HA redundancy
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:
o protocol can inform CoA, HoA, BID from MR to HA
o protocol can establish multiple tunnels between MR and HA
o 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.
Nagami, et al. Expires November 16, 2007 [Page 6]
Internet-Draft Multihoming for Fixed Network May 2007
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.
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.
6. Security considerations
This document describes requirements of multiple CoAs and HAs for
redundancy. It is necessary to enhance the protocol of the MIP and
the NEMO to solve the requirements. Security considerations of these
multihoming network must be considered in a specification of the each
protocol.
7. References
Nagami, et al. Expires November 16, 2007 [Page 7]
Internet-Draft Multihoming for Fixed Network May 2007
7.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
7.2. Informative References
[3] Ernst, T., Montavont, N., Wakikawa, R., and E. Paik, "Goals and
Benefits of Multihoming",
draft-multihoming-generic-goals-and-benefits (work in progress),
February 2004.
[4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
Addresses Registration", draft-ietf-monami6-multiplecoa-02 (work
in progress), February 2007.
[5] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home
Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress),
March 2006.
Authors' Addresses
Kenichi Nagami
INTEC NetCore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075
Japan
Phone: +81-3-5565-5069
Fax: +81-3-5565-5094
Email: [email protected]
Satoshi Uda
Japan Advanced Institute of Science and Technology
1-1 Asahidai
Tatsunokuchi, Ishikawa 923-1292
Japan
Email: [email protected]
Nagami, et al. Expires November 16, 2007 [Page 8]
Internet-Draft Multihoming for Fixed Network May 2007
Nobuo Ogashiwa
INTEC NetCore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075
Japan
Email: [email protected]
Hiroshi Esaki
The university of Tokyo
7-3-1 Hongo
Bunkyo-ku, Tokyo 113-8656
Japan
Email: [email protected]
Ryuji Wakikawa
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: [email protected]
URI: http://www.wakikawa.org/
Hiroyuki Ohnishi
NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585
Japan
Email: [email protected]
Nagami, et al. Expires November 16, 2007 [Page 9]
Internet-Draft Multihoming for Fixed Network May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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
[email protected].
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nagami, et al. Expires November 16, 2007 [Page 10]