GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4908

Network Working Group K. Nagami Request for Comments: 4908 INTEC NetCore Category: Experimental S. Uda

                                                                 JAIST
                                                           N. Ogashiwa
                                                          NOWARE, Inc.
                                                              H. Esaki
                                                   University of Tokyo
                                                           R. Wakikawa
                                                       Keio University
                                                            H. Ohnishi
                                                                   NTT
                                                             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).

IETF Note

 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.

Nagami, et al. Experimental [Page 1] RFC 4908 Multihoming for Fixed Network June 2007

Abstract

 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.

Nagami, et al. Experimental [Page 2] RFC 4908 Multihoming for Fixed Network June 2007

 (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

Nagami, et al. Experimental [Page 3] RFC 4908 Multihoming for Fixed Network June 2007

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

Nagami, et al. Experimental [Page 4] RFC 4908 Multihoming for Fixed Network June 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 (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).

Nagami, et al. Experimental [Page 5] RFC 4908 Multihoming for Fixed Network June 2007

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

Nagami, et al. Experimental [Page 6] RFC 4908 Multihoming for Fixed Network June 2007

 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.

Nagami, et al. Experimental [Page 7] RFC 4908 Multihoming for Fixed Network June 2007

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: nagami@inetcore.com

Nagami, et al. Experimental [Page 8] RFC 4908 Multihoming for Fixed Network June 2007

 Satoshi Uda
 Japan Advanced Institute of Science and Technology
 1-1 Asahidai
 Nomi, Ishikawa  923-1292
 Japan
 EMail: zin@jaist.ac.jp
 Nobuo Ogashiwa
 Network Oriented Software Institute, Inc.
 190-2, Yoshii,
 Yoshii, Tano, Gunma 370-2132
 Japan
 EMail: ogashiwa@noware.co.jp
 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. Experimental [Page 9] RFC 4908 Multihoming for Fixed Network June 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 at www.rfc-editor.org/copyright.html, 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.

Acknowledgement

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

Nagami, et al. Experimental [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4908.txt · Last modified: 2007/06/26 00:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki