[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 4908

No Specific Working Group                Kenichi Nagami(INTEC Netcore)
Internet-Draft                                     Satoshi Uda (JAIST)
Expires: January 15, 2005                Nobuo Ogashiwa(INTEC Netcore)
                                            Ryuji Wakikawa(Keio Univ.)
                                            Hiroshi Esaki(Univ. Tokyo)
                                                 Hiroyuki Ohnishi(NTT)
                                                         July 15, 2004

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

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 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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 15, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


    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 January 15, 2005                [Page 1]

Internet-Draft        Multihoming for Fixed Network            July 2004

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

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

     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 January 15, 2005                [Page 2]

Internet-Draft        Multihoming for Fixed Network            July 2004

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 January 15, 2005                [Page 3]

Internet-Draft        Multihoming for Fixed Network            July 2004

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.

                                 ||(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

             Fig.1 advertisement of aggregated prefixes

Nagami, et al.          Expires January 15, 2005                [Page 4]

Internet-Draft        Multihoming for Fixed Network            July 2004

    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.

                              ^ | |
     (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 January 15, 2005                [Page 5]

Internet-Draft        Multihoming for Fixed Network            July 2004

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.

                          HA1 <----> HA2
                           |          |
                         | The Internet |
                           |          |
                         ISP-A      ISP-B
                           |          |
                           |          |
                           +--- MR ---+
                           CoA1 | CoA2
                         Multihomed Network

              Fig.3 Architecture with HA redundancy

4. Security considerations

    This draft does not raise specific security issues beyond those of
    existing mobile IP and NEMO and routing protocols.

Nagami, et al.          Expires January 15, 2005                [Page 6]

Internet-Draft        Multihoming for Fixed Network            July 2004


    [MCOA] R. Wakikawa, et al, "Multiple Care-of Addresses
           Registration", Internet Draft,
           IETF. draft-wakikawa-mobileip-multiplecoa-02.txt, Sep.,

    [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 January 15, 2005                [Page 7]

Internet-Draft        Multihoming for Fixed Network            July 2004

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 January 15, 2005                [Page 8]

Internet-Draft        Multihoming for Fixed Network            July 2004

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.


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

Nagami, et al.          Expires January 15, 2005                [Page 9]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/