Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4908

Multi-homing for small scale fixed network Using Mobile IP and NEMO

Pages: 10

ToP   noToC   RFC4908 - Page 1
Network Working Group                                          K. Nagami
Request for Comments: 4908                                 INTEC NetCore
Category: Experimental                                            S. Uda
                                                             N. Ogashiwa
                                                            NOWARE, Inc.
                                                                H. Esaki
                                                     University of Tokyo
                                                             R. Wakikawa
                                                         Keio University
                                                              H. Ohnishi
                                                               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).


   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.
ToP   noToC   RFC4908 - Page 2


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.
ToP   noToC   RFC4908 - Page 3
   (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
ToP   noToC   RFC4908 - Page 4
   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.

                                 ||(Advertise aggregated prefix X and Y)
        |                   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.
ToP   noToC   RFC4908 - Page 5
                                ^ | |
       (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).
ToP   noToC   RFC4908 - Page 6
   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.

                             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
ToP   noToC   RFC4908 - Page 7
   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.
ToP   noToC   RFC4908 - Page 8

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:
ToP   noToC   RFC4908 - Page 9
   Satoshi Uda
   Japan Advanced Institute of Science and Technology
   1-1 Asahidai
   Nomi, Ishikawa  923-1292


   Nobuo Ogashiwa
   Network Oriented Software Institute, Inc.
   190-2, Yoshii,
   Yoshii, Tano, Gunma 370-2132


   Hiroshi Esaki
   The University of Tokyo
   7-3-1 Hongo
   Bunkyo-ku, Tokyo  113-8656


   Ryuji Wakikawa
   Keio University
   Department of Environmental Information, Keio University.
   5322 Endo
   Fujisawa, Kanagawa  252-8520

   Phone: +81-466-49-1100
   Fax:   +81-466-49-1395

   Hiroyuki Ohnishi
   NTT Corporation
   9-11, Midori-Cho, 3-Chome
   Musashino-Shi, Tokyo  180-8585

ToP   noToC   RFC4908 - Page 10
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, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an

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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.