[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: April 25, 2005                  Nobuo Ogashiwa(INTEC Netcore)
                                            Ryuji Wakikawa(Keio Univ.)
                                            Hiroshi Esaki(Univ. Tokyo)
                                                 Hiroyuki Ohnishi(NTT)
                                                          Oct 25, 2004



  Multi-homing for small scale fixed network Using Mobile IP and NEMO
        <draft-nagami-mip6-nemo-multihome-fixed-network-02.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 January 15, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).  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 April 25, 2005                 [Page 1]

Internet-Draft        Multihoming for Fixed Network             Oct 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
    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 April 25, 2005                 [Page 2]

Internet-Draft        Multihoming for Fixed Network             Oct 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 April 25, 2005                 [Page 3]

Internet-Draft        Multihoming for Fixed Network             Oct 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.


                                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 April 25, 2005                 [Page 4]

Internet-Draft        Multihoming for Fixed Network             Oct 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.



                               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 April 25, 2005                 [Page 5]

Internet-Draft        Multihoming for Fixed Network             Oct 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.


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


              Fig.3 Architecture with HA redundancy




















Nagami, et al.           Expires April 25, 2005                 [Page 6]

Internet-Draft        Multihoming for Fixed Network             Oct 2004



4. Miscellaneous Issues


4.1 Discussion on the Mailing List


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


    (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 April 25, 2005                 [Page 7]

Internet-Draft        Multihoming for Fixed Network             Oct 2004



5. 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 April 25, 2005                 [Page 8]

Internet-Draft        Multihoming for Fixed Network             Oct 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 April 25, 2005                 [Page 9]

Internet-Draft        Multihoming for Fixed Network             Oct 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
   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 (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.



Acknowledgment


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










Nagami, et al.           Expires April 25, 2005                [Page 10]


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