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

Versions: 00 01 02 03 04 RFC 4908

No Specific Working Group                                      K. Nagami
Internet-Draft                                             INTEC NetCore
Expires: November 16, 2007                                        S. Uda
                                                                   JAIST
                                                             N. Ogashiwa
                                                           INTEC NetCore
                                                                H. Esaki
                                                                U. Tokyo
                                                             R. Wakikawa
                                                         Keio University
                                                              H. Ohnishi
                                                                     NTT
                                                            May 15, 2007


  Multi-homing for small scale fixed network Using Mobile IP and NEMO
         draft-nagami-mip6-nemo-multihome-fixed-network-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 November 16, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).





Nagami, et al.          Expires November 16, 2007               [Page 1]

Internet-Draft        Multihoming for Fixed Network             May 2007


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 [1] and NEMO [2].  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.


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 [3] 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.




Nagami, et al.          Expires November 16, 2007               [Page 2]

Internet-Draft        Multihoming for Fixed Network             May 2007


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

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 November 16, 2007               [Page 3]

Internet-Draft        Multihoming for Fixed Network             May 2007


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

              Figure 1: advertisement of aggregated prefixes

   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.











Nagami, et al.          Expires November 16, 2007               [Page 4]

Internet-Draft        Multihoming for Fixed Network             May 2007


                                 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 (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, [4] is proposed to extend the MIP6 and the 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, 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



Nagami, et al.          Expires November 16, 2007               [Page 5]

Internet-Draft        Multihoming for Fixed Network             May 2007


   of database among the HA.  The HAHA protocol [5] 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

                 Figure 3: Architecture with HA redundancy


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:

   o  protocol can inform CoA, HoA, BID from MR to HA

   o  protocol can establish multiple tunnels between MR and HA

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





Nagami, et al.          Expires November 16, 2007               [Page 6]

Internet-Draft        Multihoming for Fixed Network             May 2007


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.


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.


6.  Security considerations

   This document describes requirements of multiple CoAs and HAs for
   redundancy.  It is necessary to enhance the protocol of the MIP and
   the NEMO to solve the requirements.  Security considerations of these
   multihoming network must be considered in a specification of the each
   protocol.


7.  References



Nagami, et al.          Expires November 16, 2007               [Page 7]

Internet-Draft        Multihoming for Fixed Network             May 2007


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., and E. Paik, "Goals and
        Benefits of Multihoming",
        draft-multihoming-generic-goals-and-benefits (work in progress),
        February 2004.

   [4]  Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
        Addresses Registration", draft-ietf-monami6-multiplecoa-02 (work
        in progress), February 2007.

   [5]  Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home
        Agents Protocol Specification",
        draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress),
        March 2006.


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
   Tatsunokuchi, Ishikawa  923-1292
   Japan

   Email: zin@jaist.ac.jp





Nagami, et al.          Expires November 16, 2007               [Page 8]

Internet-Draft        Multihoming for Fixed Network             May 2007


   Nobuo Ogashiwa
   INTEC NetCore Inc.
   1-3-3, Shin-suna
   Koto-ku, Tokyo  135-0075
   Japan

   Email: ogashiwa@inetcore.com


   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













Nagami, et al.          Expires November 16, 2007               [Page 9]

Internet-Draft        Multihoming for Fixed Network             May 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Nagami, et al.          Expires November 16, 2007              [Page 10]


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