IETF Monami6 Working Group K. Aso Internet-Draft Matsushita Electric Industrial Expires: August 28, 2006 Co., Ltd. (Panasonic) B. Koh Panasonic Singapore Labs February 24, 2006 Multiple Forwarding Destinations Notification draft-aso-monami6-multiple-forwarding-00 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 August 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document considers a mobile terminal with multiple interfaces which uses Mobile IPv6[1]. With multiple interfaces, the mobile terminal may use them simultaneously for communication with a peer device. Hence enabling the mobile terminal to achieve fault tolerance, load balancing and so on. This document deals with the mobile terminal with multiple interfaces, so it is possible that each Aso & Koh Expires August 28, 2006 [Page 1] Internet-Draft Multiple Forwarding Destinations February 2006 kind/type of interface may have its own characteristics or differences. In particular, we take a closer look at the path between mobile terminal and its home agent. In the case when the mobile terminal has multiple interfaces, there exists several paths to the home agent. A general approach would be to first take a look at effective use of the multiple interfaces from a pure Mobile IPv6 perspective. As a matter of course, RFC3775 is used as the basic reference with which we consider the multiple interfaced mobile terminal operating in a Mobile IPv6 environment. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Limitations with Mobile IPv6 and Multiple CoAs Registrations[2] . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Impact of Multiple Interfaces on Mobile IPv6 . . . . . . . 3 4.1.1. Use of the interface as one forwarding destination . . 3 4.1.2. Need of multiple forwarding destinations . . . . . . . 4 4.2. Path between the mobile node and the correspondent node . 4 4.2.1. Another path to the CN . . . . . . . . . . . . . . . . 4 4.2.2. Meaning of the notified path to CN . . . . . . . . . . 5 5. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 7. Possible Operations . . . . . . . . . . . . . . . . . . . . . 7 7.1. Notifying multiple forwarding destinations . . . . . . . . 7 7.2. Changing of forwarding destination . . . . . . . . . . . . 7 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Aso & Koh Expires August 28, 2006 [Page 2] Internet-Draft Multiple Forwarding Destinations February 2006 1. Introduction Today's consumer electronics market has seen an explosion of devices containing more than one type of wireless interface. As a greater amount of functionality is packed into each user terminal, cell phones with PDA-like capabilities are becoming more common. Users of such multimode devices typically desire "always on" internet access at the lowest possible cost, hence the proliferation of multimode devices with diverse wireless interfaces such as WLAN and WPAN in addition to the de facto cellular network connectivity. By utilizing the more reliable cellular coverage for making voice calls and WLAN or WPAN connectivity for other forms of digital data communications, the user may more effectively leverage upon the strengths of each technology. A foreseeable scenario involves the user purchasing some entertainment content through the cellular service operator. The user or the service operator may now choose to receive or transmit the stream via a more economical wireless interface. While enjoying the bought content, a voice call is put through to the user's handset and the user effortlessly receives the call, ends it and resumes his entertainment. In this document, we analyze similar scenarios in greater detail and discuss the required functionalities on the mobile terminal and network in order to achieve it. 2. Terminology General mobility terminology can be found in Mobile IPv6[1]. 3. Scope It is the intention of this draft to only focus on the notification mechanism for multiple interfaces and not discuss selection policies. 4. Limitations with Mobile IPv6 and Multiple CoAs Registrations[2] 4.1. Impact of Multiple Interfaces on Mobile IPv6 The following sections describe some considerations regarding multiple interfaces which the mobile node using Mobile IPv6 has. 4.1.1. Use of the interface as one forwarding destination Mobile IPv6 allows the mobile node to continue to communicate with a Aso & Koh Expires August 28, 2006 [Page 3] Internet-Draft Multiple Forwarding Destinations February 2006 correspondent node regardless of mobility. The tunnel between the mobile node and its home agent connects the correspondent node to the mobile node when the mobile node is away from home, providing session continuity. However Mobile IPv6 assumes that the mobile node uses only one interface at a point in time. If the mobile node has multiple interfaces, it must choose one and notify the home agent of its selected interface. The selected interface is used as the forwarding destination by the home agent for packets addressed to HoA. When the mobile node wants to select another interface, it must notify the home agent of its new forwarding destination. Basically, even if the mobile node has multiple interfaces which are usable, it can use only one of them as the forwarding destination. When a home agent serves as a mobile node's home agent, it intercepts packets to the mobile node's HoA, searches the Binding Cache for the HoA entry. It then tunnels the intercepted packets to the CoA found in the binding cache entry. In this case, this CoA is the forwarding destination. On the other hand, if the home agent does not serve as the mobile node's home agent, it does not intercept packets to the mobile node's HoA. Hence all packets to the mobile node's HoA are received by the mobile node directly via the home network. In this case, there is no forwarding destination in the home agent. 4.1.2. Need of multiple forwarding destinations As stated in Section 4.1.1, the mobile node needs to send a binding update to notify the home agent of the forwarding destination. So, as described in [2], in order to enable the home agent to initiate the change of the forwarding destination, the mobile node should notify the home agent of possible alternatives for the forwarding destination. According to [2], when the mobile node is connected to both home and foreign networks, it can use only either the interface attached to the home network or the interface attached to the foreign network. It is important to allow the selection of source or forwarding destination at either endpoint of a path, regardless of the network the mobile node is connected to. 4.2. Path between the mobile node and the correspondent node The following sections describe the mechanism for utilizing the direct path between the mobile node and the correspondent node. 4.2.1. Another path to the CN Looking at the communication between the mobile node and CN, the CN knows only the peer node's address as an initial condition. The CN is not aware that the peer node is a mobile node. If the mobile node is at its home network, the packets sent by the CN are routed to the Aso & Koh Expires August 28, 2006 [Page 4] Internet-Draft Multiple Forwarding Destinations February 2006 mobile node directly. If the mobile node is away from home, they are routed by the home agent to the mobile node. Currently, Mobile IPv6 has available a mechanism to inform the CN about the existence of another path and that is route optimization. By using this mechanism, the CN could be made aware of another direct path between itself and the peer node. In this case, there are now two paths between the mobile node and the CN. When the CN sends the packet, it may prefer the direct path because the direct path is typically shorter than the other one. 4.2.2. Meaning of the notified path to CN The path notified from the mobile node to CN has the meaning of "optimized path" and Mobile IPv6 fundamentally already incorporates a mechanism to inform a peer of the difference regarding multiple paths to the same node. The existence of two different paths arises from the mobility of the mobile node as well as the presence of a home agent. Such a meaning is not provided between the home agent and the mobile node. 5. Scenario Consider the scenario when a user's mobile terminal is both cellular and WiFi enabled. The cellular connection is provided by a cellular operator and also provides a home agent for the node. The WiFi connection is obtained via a wireless hotspot in a restaurant. The user which is away from home network is utilizing a video conferencing application while simultaneously participating in an online game. For reasons of cost versus quality of service, the user would like to utilize his cellular connection for his online gaming data stream and the free WiFi connection for his video streams. He proceeds to set the appropriate policies on his home agent. The home agent is supposed to select suitable interface to forward the specific flow based on such policies set by the user. At one point, when the user moves to the coverage area of the home network provided by a cellular operator, the network configuration after the movement is shown in Figure 1. The figure shows the cellular home network provided by a cellular operator and WiFi network via a hotspot. The cellular interface(IF1) is connected to the cellular home network and WiFi interface(IF2) is connected to WiFi network. As described above, the mobile terminal is currently connected to both home and foreign network via its two interfaces. Aso & Koh Expires August 28, 2006 [Page 5] Internet-Draft Multiple Forwarding Destinations February 2006 /~~~~~~~~~~~~~~~~\ | cellular | | home network | | | | +----------+ | (tunnel)/~~~~~~~~~~~~~~~~~\ | |home agent|=========== | WiFi | | +----------+ | Path2 | foreign network | \_______________/ \________________/ \ // Path1 \ (tunnel)// Path2 \ // +---+ +---+ |IF1| |IF2| +---------------+ |mobile terminal| +---------------+ Figure 1: Network Configuration There are two possible paths between the home agent and the mobile terminal. The first is the direct path (Path1) from the home agent via the mobile node's cellular interface and the other is through the foreign network via the mobile terminal's WiFi interface (Path2). According to current Mobile IPv6 protocol, when communicating with a CN without using Route Optimization the mobile terminal and home agent may choose to use either Path1 or Path2. 6. Problem Statement It does not allow the home agent to initiate a change of forwarding destination in the above described scenario. Even if [2] is available, the existence of a binding cache entry in the home agent reflects only a part of several possible states of the mobile node. This seems to be the same problem as the conventional Mobile IPv6 without multiple CoAs registration, so it creates inefficient overheads due to the sending of messages and replies. Thereby the policies set by the mobile node before the movement is not available any more because the home agent does not know of the existence of multiple paths between itself and the mobile node. If the mobile node uses IF2, there must be a binding cache entry for HoA and CoA at the home agent. In this case for packets sent from the CN, the home agent must intercept the packets addressed to the mobile node's HoA and tunnel them to the mobile node. For packets sent from the mobile node, the mobile node must utilize the reverse tunnel and send the packets to the home agent which then decapsulates Aso & Koh Expires August 28, 2006 [Page 6] Internet-Draft Multiple Forwarding Destinations February 2006 the tunneled packets and forwards the inner packets to the CN. Thereby the mobile node can send and receive the packets utilizing interface IF2. If the mobile node chooses to use IF1, there must not be any binding cache entries at the home agent. In this case, the mobile node does not need to use any reverse tunnel. It can use it's own HoA normally to send packets and the home agent is not involved in the packet transmission. 7. Possible Operations This section introduces two possible operations, first one is for the mobile node, second one is for the home agent. 7.1. Notifying multiple forwarding destinations In the scenario in Section 5, the mobile node should be able to notify the Home Agent of possible alternative paths whenever it is connected to both home and foreign networks in order to prevent excluding of flow control by the home agent. And then the home agent should be aware of the existence of both paths to the mobile node. One possible method is allowing the mobile node to create CoA in the home network which is different from the HoA. The mobile node can notify the home agent of both its address and other CoA. This enables the home agent to intercept the packets addressed to the mobile node's HoA which is connected to the home network and also perform what described in the next section. 7.2. Changing of forwarding destination The home agent should be able to initiate a change of forwarding destination whenever there exists multiple paths to the mobile node. This may be due to policies or filters placed by the mobile node. As described in Section 4.2, notifying the correspondent node of the optimized route is treated as a fundamental part of the protocol in RFC3775. RFC3775 includes the mechanism for route optimization and stipulates that the correspondent node SHOULD use route optimization. If there are similarities in the multiple paths between the mobile node and its home agent to that described in RFC3775, it would be prudent to reuse the mechanism already defined. As it so happens, we can find a similar situation between the home agent and the mobile node. When the mobile node is in the state of the scenario in Section 5, there is an explicit difference between Path1 and Path2. If the home agent can be made aware of the difference, similar to the correspondent node during the route optimization mechanism, the home Aso & Koh Expires August 28, 2006 [Page 7] Internet-Draft Multiple Forwarding Destinations February 2006 agent can initiate the change of forwarding destination using a similar mechanism. 8. Conclusion In order to allow the home agent to change of forwarding destination in the specific scenario, the use of CoA at home network enables flow control based on policies set by the mobile node even when attaching to the home and foreign network simultaneously. Moreover, as stated in Section 7.2, in that case there is the explicit difference of paths between the home agent and the mobile node from a pure Mobile IPv6 perspective, which is the similar to the situation between the correspondent node and the mobile node because the correspondent node can learn the existence of paths and its path's characteristics through route optimization mechanism. This work explained the mobile node and the home agent operation which can be applied to a situation where the mobile node is connected to both home network and foreign network. 9. Security Considerations As this operation follows Mobile IPv6 operations, no additional security issues have been identified. Please refer to the Mobile IPv6 specification [1] for security considerations. 10. References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Wakikawa, R., Uehara, K., and K. Nagami, "Multiple Care-of Addresses Registration", draft-wakikawa-mobileip-multiplecoa-04.txt (work in progress), June 2005. Aso & Koh Expires August 28, 2006 [Page 8] Internet-Draft Multiple Forwarding Destinations February 2006 Authors' Addresses Keigo Aso Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3 Hikarino-oka Yokosuka, Kanagawa 239-0847 JP Phone: +81 46 840 5123 Email: asou.keigo@jp.panasonic.com Benjamin Koh Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Email: benjamin.kohtm@sg.panasonic.com Aso & Koh Expires August 28, 2006 [Page 9] Internet-Draft Multiple Forwarding Destinations February 2006 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 (2006). 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. Aso & Koh Expires August 28, 2006 [Page 10]