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]