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