[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: 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]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/