Multi-homing for small scale fixed network Using Mobile IP and NEMO
Using Mobile IP and NEMO protocols to improve network availability for small fixed networks.
Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, R., and H. Ohnishi, "Multi-homing for small scale fixed network Using Mobile IP and NEMO", RFC 4908, DOI 10.17487/RFC4908, June 2007, <https://www.rfc-editor.org/info/rfc4908>.
@misc{rfc4908,
series = {Request for Comments},
number = 4908,
howpublished = {RFC 4908},
publisher = {RFC Editor},
doi = {10.17487/RFC4908},
url = {https://www.rfc-editor.org/info/rfc4908},
author = {K. Nagami and S. Uda and N. Ogashiwa and H. Esaki and R. Wakikawa and H. Ohnishi},
title = {{Multi-homing for small scale fixed network Using Mobile IP and NEMO}},
pagetotal = 10,
year = 2007,
month = jun,
} RFC text
Contents
Network Working Group K. Nagami
Request for Comments: 4908 INTEC NetCore
Category: Experimental S. Uda
JAIST
N. Ogashiwa
NOWARE, Inc.
H. Esaki
University of Tokyo
R. Wakikawa
Keio University
H. Ohnishi
NTT
June 2007
Multihoming for Small-Scale Fixed Networks
Using Mobile IP and Network Mobility (NEMO)
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
IETF Note
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols. The RFC Editor
has chosen to publish this document at its discretion. Readers of
this document should exercise caution in evaluating its value for
implementation and deployment. See RFC 3932 for more information.
Abstract
Multihoming technology improves the availability of host and network
connectivity. Since the behaviors of fixed and mobile networks
differ, distinct architectures for each have been discussed and
proposed. This document proposes a common architecture for both
mobile and fixed networking environments, using mobile IP (RFC 3775)
and Network Mobility (NEMO; RFC 3963). The proposed architecture
requires a modification of mobile IP and NEMO so that multiple Care-
of Addresses (CoAs) can be used. In addition, multiple Home Agents
(HAs) that are located in different places are required for
redundancy.
1. Motivation
Users of small-scale networks need an easy method to improve network
availability and to load balance several links. Multihoming
technology is one of the solutions to improve availability.
Conventional major multihoming networks use BGP, but it has some
issues. Therefore, we propose a multihoming architecture using
mobile IP [1] and NEMO [2] for small-scale fixed networks.
1.1. General Benefits of Multihoming
In a multihoming network environment, both users and network managers
benefit from controlling outgoing traffic, incoming traffic, or both
of them. Those benefits are described in "Goals and Benefits of
Multihoming" [3]. The following is a summary of those goals and
benefits:
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 Multihoming
Several multihoming technologies have been proposed so far.
Conventional major multihoming networks use BGP, but it has some
issues, as follows.
(1) Increasing route entries in the Internet
In the multihoming environments, each user's network needs to
advertise its address block to all ISPs connected to them. If a
multihomed user connects to only one ISP, the ISP can advertise
routing information to aggregate them. But some multihomed users
need to connect with different ISPs to be prepared for ISP
failure. In this case, ISPs need to advertise routing information
for multihomed users without aggregation. Therefore, the number
of routing entries in the Internet is increasing one by one.
(2) Difficulty of using multiple links efficiently
It is not easy to control incoming traffic in the case of the
conventional multihoming 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, mobile IP (MIP) and NEMO have been proposed for mobile
hosts or mobile networks; however, their architecture and protocol
can be used for fixed networks and to solve the problems mentioned
above. The details of the solution are described in the sections
below.
Moreover, by using the architecture and the protocol of MIP and the
NEMO, the cost of network operation will be decreased. For instance,
in the architecture of MIP and NEMO, renumbering IP addresses when
office or network equipment is relocated becomes unnecessary, as the
network address prefix used by a user network in a mobile IP
environment does not depend on the upstream ISP's network prefix.
2. Multihoming Architecture Using Mobile IP and NEMO
2.1. Mobile Network Includes Fixed Network
By their nature, NEMO and mobile IP must work with multihoming. This
is because mobile nodes need to use multiple links to improve the
availability of network connectivity since the wireless link is not
always stable. Therefore, we propose that multihoming for fixed
nodes (routers and hosts) uses the framework of NEMO and mobile IP.
2.2. Overview of Multihoming Network Architecture Using Mobile IP
Figure 1 shows the basic multihoming network architecture. In this
architecture, a mobile router (MR), which is a border router of the
multihomed network, sets up several tunnels between the MR and the HA
by multiple-CoA registration. An HA (or a router to which the HA
belongs) advertises the user's network prefix (Prefix X in Figure 1)
to ISPs via the routing protocol. If the HA has several multihomed
networks (Prefix X and Y in Figure 1), they can advertise an
aggregated network prefix to ISPs. Therefore, the Internet routing
entries do not increase one by one when the number of multihomed
users 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 multihomed users go to the HA, and the HA sends packets to
the MR using CoA1 and CoA2. The HA selects a route in which a CoA is
used. The route selection algorithm is out for scope of this
document. This can improve the availability of the user network and
control traffic going from the ISP to the MR. In the basic
architecture, HA1 is the single point of failure. In order to
improve the availability of the user network, multiple HAs are
needed. This is described in Section 3.2.
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 (CoAs)
Multiple Care-of-Addresses are needed to improve the availability and
to control incoming and outgoing traffic. The current Mobile IPv6
and the NEMO Basic Support protocol does not allow registration of
more than one Care-of Address bound to a home address to the home
agent. Therefore, [4] proposes to extend MIP6 and 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 to improve service availability and for the load balancing
of the 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 viewpoint of
routing protocol topology. This operation has already been proven to
work in the area of Web server applications, such as CDN (Contents
Delivery Network), with the Interior Gateway Protocol (IGP) and
Exterior Gateway Protocol (EGP).
In order to operate multiple HAs, all HAs must have the same
information such as binding information. This synchronizes the
databases among the HAs. The HAHA protocol [5] introduces the
binding synchronization among HAs. This is the same architecture as
Internal BGP (IBGP). The database is synchronized by full-mesh
topology. In addition, in order to simplify operation of the HA, the
database is synchronized using star topology. This is analogous to
the IBGP 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 the Proposed Architecture Uses NEMO Protocols
The multihomed architecture proposed in this document is basically
the same as the architecture of NEMO. Furthermore, NEMO protocols
meet the requirements of the proposed architecture in this document,
which are:
o The protocol can be used by the MR to send information such as the
CoA, Home Address (HoA), and Binding Unique Identifier (BID) [4]
to the HA.
o The protocol can establish multiple tunnels between the MR and HA.
o The protocol supports multiple HAs and can synchronize Binding
Caches among multiple HAs.
The proposed multihomed architecture uses NEMO protocols as one of
the applications of NEMO. Needless to say, using the NEMO protocol
is one of the solutions to accomplish the proposed multihome
architecture. Another solution is to propose a new protocol just
like NEMO. Nevertheless, such a protocol would have functions just
like those of NEMO.
4.2. Route Announcement from Geographically Distributed Multiple HAs
In the proposed architecture, the xSP (Multihomed Service Provider)
is introduced. The xSP is a conceptual service provider; it doesn't
have to be connected to the Internet physically for all practical
purposes. 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 set up some HAs in
those ISPs' networks. Those HAs announce the xSP's aggregated mobile
network prefixes. This means that HAs work just like border gateway
routers, and this situation is the same as peering between the ISP
and xSP. In this case, the origin Autonomous System (AS) announced
from the HAs is the xSP.
On the other hand, a multihomed user (a small office user or home
user) contracts with the xSP to acquire a mobile network prefix from
the xSP. Each multihomed user has an MR and multiple L3 connectivity
to the Internet via multiple ISPs, and the MR will establish multiple
tunnels to the HA. Since the user's mobile network prefixes are
aggregated and announced from the HA, the packets to the user's
mobile network will be sent to the nearest HA depending on global
routing information at that time. The HA that received such packets
will forward them to the user's network over the established multiple
tunnels.
This model of route announcement from multiple HAs is compatible with
the conventional scalable Internet architecture, and it doesn't have
scalability problems.
5. Implementation and Experimentation
We have implemented and experimented with the proposed architecture.
Currently, the system works well not only on our test-bed network,
but on the Internet. In our experimentation, the MR has two upstream
organizations (ISPs) and two Care-of Addresses for each organization.
The MR uses the multiple-CoA option to register the Care-of Addresses
to the HA.
6. Security Considerations
This document describes requirements of multiple CoAs and HAs for
redundancy. It is necessary to enhance the protocols of MIP and NEMO
to solve the requirements. Security considerations of these
multihoming networks must be considered in a specification of each
protocol.
7. References
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., Paik, E., Ng, C.,
Kuladinithi, K., and T. Noel, "Goals and Benefits of
Multihoming", Work in Progress, February 2004.
[4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
Addresses Registration", Work in Progress, March 2007.
[5] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home
Agents Protocol (HAHA)", Work in Progress, February 2004.
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: nagami@inetcore.com
Satoshi Uda
Japan Advanced Institute of Science and Technology
1-1 Asahidai
Nomi, Ishikawa 923-1292
Japan
EMail: zin@jaist.ac.jp
Nobuo Ogashiwa
Network Oriented Software Institute, Inc.
190-2, Yoshii,
Yoshii, Tano, Gunma 370-2132
Japan
EMail: ogashiwa@noware.co.jp
Hiroshi Esaki
The University of Tokyo
7-3-1 Hongo
Bunkyo-ku, Tokyo 113-8656
Japan
EMail: hiroshi@wide.ad.jp
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: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/
Hiroyuki Ohnishi
NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585
Japan
EMail: ohnishi.hiroyuki@lab.ntt.co.jp
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1The Problem with BGP Multihoming
Traditional multihoming for networks relies on the Border Gateway Protocol (BGP) to advertise network prefixes to multiple Internet Service Providers. However, this approach has two main problems. First, when multihomed networks connect to different ISPs separately (rather than through a single ISP), each must advertise its own prefix without aggregation, adding one routing entry per network to the global routing table. With many small multihomed networks, this creates explosive growth in routing table size. Second, BGP is designed for routing decisions, not traffic control: it is difficult to use BGP to manage incoming traffic load balancing.
For small networks (home offices, small businesses), the overhead and complexity of managing BGP is impractical. A simpler solution that preserves IP addresses and improves availability is needed.
When many small networks try to use two internet connections, each one adds an entry to routing tables everywhere. That gets big and slow. Plus, it is hard to balance traffic fairly between the two connections.
§2Mobile IP and NEMO Architecture
Mobile IP (RFC 3775) and Network Mobility (NEMO, RFC 3963) were designed to handle devices and networks that move and change their network attachment point. The core idea is that a mobile device or mobile network maintains a home address and a Home Agent (HA) that knows where it currently is. The device registers a Care-of Address (CoA)—its current location—with the Home Agent, which tunnels packets to it.
This RFC proposes using this same architecture for small fixed networks that want multihoming. A border router (called a mobile router in the NEMO terminology) registers multiple CoAs—one for each link to an ISP—with a Home Agent. The Home Agent advertises the network's prefix to the internet. This avoids the per-link routing entries: the Home Agent aggregates multiple prefixes under its control and advertises one aggregated prefix, keeping the global routing table small.
Instead of telling the internet 'I have two cables, here are both routes', you tell one central place 'I have two cables'. That place forwards everything to you down whichever cable is best, and the internet only knows about the one place.
| Aspect | BGP approach | NEMO approach |
|---|---|---|
| Routing entries per network | One per ISP connection | One (aggregated) |
| Load balancing | Limited to BGP policies | HA controls traffic |
| Operator complexity | High (BGP expertise needed) | Lower (leverages Mobile IP) |
| Address renumbering on move | Required (ISP addresses change) | Not required (home prefix stays) |
§3Multiple Care-of Addresses and Redundancy
In the proposed architecture, a mobile router (MR), which is the border router of the multihomed network, establishes multiple tunnels to the Home Agent by registering multiple Care-of Addresses. If the mobile router has two ISP connections, it registers two CoAs—the IP address assigned on each ISP's link. The Home Agent maintains bindings for all CoAs.
For resilience, multiple Home Agents should be deployed across the internet. All Home Agents share the same binding information through synchronization protocols (such as the Inter Home Agent Protocol, HAHA). When multiple HAs advertise the same prefix from geographically different locations, packets are routed to the nearest Home Agent based on standard routing topology. This is the same approach used by Content Delivery Networks (CDNs). Route selection and forwarding across multiple CoAs is outside the scope of this RFC.
The central place (Home Agent) needs to not be a single point of failure. So you have several copies of it, in different places, all synchronized, so if one fails the others keep working.
- Multihomed NetworkOffice or home network with internal prefix
- Mobile RouterBorder router managing two ISP connections
- ISP LinksMultiple connections to different providers
- Home Agent (central)Advertises aggregated prefix to internet
- InternetPackets routed to nearest HA by BGP
§4Protocol Extensions Needed
The current Mobile IP and NEMO Basic Support protocols do not allow a single home address to be bound to more than one Care-of Address simultaneously. To support multihoming, these protocols must be extended to allow multiple CoA registrations. The RFC references work (then in progress) to define a multiple Care-of Address registration mechanism that would allow the mobile router to bind the network's home address to multiple CoAs at the same Home Agent.
Additionally, when multiple Home Agents are used, they must be able to synchronize binding information. The HAHA protocol, analogous to Internal BGP (IBGP) in routing, enables this through either full-mesh or hierarchical (route-reflector-like) topologies, allowing simplified operation by using a central synchronization point.
The mobile IP system needs two upgrades: it needs to let one address point to two places at once, and the central places need to copy their knowledge to each other.
§5Practical Benefits and Experimentation
The authors implemented and tested the proposed architecture on both private test networks and the live internet. In their experiments, a mobile router had two upstream ISP connections and two CoAs for each organization, registering all four addresses with the Home Agent using the multiple-CoA option. The system operated successfully.
Beyond immediate redundancy and load balancing, the Mobile IP and NEMO approach offers an operational benefit: when network equipment is relocated or office networks change topology, the internal IP addresses and prefixes do not need to change because they are not tied to any particular ISP's prefix. This eliminates the costly and disruptive process of renumbering addresses.
They tested it and it works. Plus, you never have to change your office IP addresses just because you moved or switched internet providers.