No Specific Working Group Kenichi Nagami(INTEC Netcore) Internet-Draft Satoshi Uda (JAIST) Expires: January 15, 2005 Nobuo Ogashiwa(INTEC Netcore) Ryuji Wakikawa(Keio Univ.) Hiroshi Esaki(Univ. Tokyo) Hiroyuki Ohnishi(NTT) July 15, 2004 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 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 January 15, 2005 [Page 1] Internet-Draft Multihoming for Fixed Network July 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 January 15, 2005 [Page 2] Internet-Draft Multihoming for Fixed Network July 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 January 15, 2005 [Page 3] Internet-Draft Multihoming for Fixed Network July 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 January 15, 2005 [Page 4] Internet-Draft Multihoming for Fixed Network July 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 January 15, 2005 [Page 5] Internet-Draft Multihoming for Fixed Network July 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 4. Security considerations This draft does not raise specific security issues beyond those of existing mobile IP and NEMO and routing protocols. Nagami, et al. Expires January 15, 2005 [Page 6] Internet-Draft Multihoming for Fixed Network July 2004 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 January 15, 2005 [Page 7] Internet-Draft Multihoming for Fixed Network July 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 January 15, 2005 [Page 8] Internet-Draft Multihoming for Fixed Network July 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 January 15, 2005 [Page 9]