v6ops B. Lee Internet-Draft S. Pack Expires: January 12, 2006 Seoul National University M. Nam E. Paik KT July 11, 2005 Mobile IPv6 Deployment Scenarios for Broadband Wireless Access Networks draft-lee-v6ops-mipv6-deployment-00.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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes Mobile IPv6 deployment scenarios for Broadband Wireless Access (BWA) network such as IEEE 802.16 standard. It lists questions that Internet Service Provider (ISP) should consider when they deploy Mobile IPv6. The deployment scenarios are discussed in terms of integration with Hierarchical Mobile IPv6 and Lee, et al. Expires January 12, 2006 [Page 1] Internet-Draft MIPv6 deployment for BWA July 2005 Network Mobility support. The scenarios and considerations described in this document will be the basis for further analysis to archieve optimization of Mobile IPv6 deployment. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Mobile IPv6 Deployment over Broadband Wireless Access Service . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Handover Considerations . . . . . . . . . . . . . . . . . . . 4 5. Hierarchical MIPv6 Deployment Considerations . . . . . . . . . 5 6. NEMO Deployment Scenarios . . . . . . . . . . . . . . . . . . 7 6.1 egress interface: IEEE 802.16, ingress interface: IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2 egress interface: IEEE 802.16, ingress interface: IEEE 802.15 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. NEMO and HMIPv6 Integration Scenarios . . . . . . . . . . . . 9 7.1 MN knows MAP's existence . . . . . . . . . . . . . . . . . 9 7.2 MN doesn't know MAP's existence . . . . . . . . . . . . . 9 8. BWA Coexistence with IEEE 802.11 Hotspot . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Lee, et al. Expires January 12, 2006 [Page 2] Internet-Draft MIPv6 deployment for BWA July 2005 1. Introduction Recently, Broadband Wireless Access (BWA) is emerging as an alternative solution for wireless Metropolitan Area Network (MAN). IEEE 802.16 WG specifies a new air interface and medium access control (MAC) protocol and provides high data rate as well as large cell coverage. In addition, it provides seamless mobility so that mobile users can use wireless Internet services while they are on the vehicles, which move fast. In this environment, Mobile IPv6[2] is a proper solution to provide session continuity. In this document, we focus Mobile IPv6 deployment scenarios for broadband wireless access network. With the respect of internet service providers (ISPs), we describe requirements and considerations for deploying Mobile IPv6. It helps for enterprise administrators to refine their deployment scenarios and to make plans to deploy wireless access service based on Mobile IPv6. We also consider Hierachical Mobile IPv6 [3] and Network Mobilty Basic Support [4] specifications for performance optimization and their integration scenarios. 2. Terminology Terms used in this draft are defined in [2], [3] and [4]. 3. Overview of Mobile IPv6 Deployment over Broadband Wireless Access Service When an ISP deploys Mobile IPv6 over Broadband Wireless Access networks, it should consider followings : Low handoff delay to support real-time applications: Fast handover [5], Fast handover for 802.11 [6], Hierarchical Mobile IPv6 Reducing signaling overhead at core networks: Hierarchical Mobile IPv6, Network Mobility Integration with prior hotspot services: Vertical Handover With the respect of network management, following questions are arising : How many Base Stations (BSs) can be placed in an AR? One to one correspondence, one to many correspondence, many to many correspondences Lee, et al. Expires January 12, 2006 [Page 3] Internet-Draft MIPv6 deployment for BWA July 2005 How can Home Agents (HAs) be located? Centralized or distribute manner How can MNs are allocated IP address? Static allocation, dynamic allocation at HA, dynamic allocation at Dynamic Host Configuration Protocol (DHCP) server How can MNs are authenticated? Authenticated by Diameter, authenticated by Radius, authenticated by the HA 4. Handover Considerations +--+ +--+ +-----------|AR| |AR| subnet1 +--+ +--+ | | | +---------+ subnet2 subnet3 |L2 switch| | | +---------+ | | / \ | | / \ | | / \ | | +--+ +--+ +--+ +--+ |BS| |BS| |BS| |BS| +--+ +--+ +--+ +--+ +--+ A B C |MN|-----> ------> --------> +--+ Figure 1. Handover Cases. In BWA deployment scenario, handover is classified into three cases. Intra-AR L2 handover (case A in Figure 1) Intra-AR L2 handover occurs when an MN moves into a new BS area within a AR area. In this case, its CoA is not changed, so that no IP layer-signaling messages are required. As soon as MN attaches to new AP, it can communicate immediately with CN. Lee, et al. Expires January 12, 2006 [Page 4] Internet-Draft MIPv6 deployment for BWA July 2005 Intra-AR L3 handover (case B in Figure 1) Intra-AR L3 handover occurs when an MN moves into a new BS area and change the subnet but doesn't change the serving AR. Even though its AR doesn't change, the MN should configure new CoA and should register it with its HA Inter-AR L3 handover (case C in Figure 1) Inter-AR L3 handover occurs when an MN moves into a new BS area and the BS attaches to a new AR. In this case, the MN should configure new CoA and register it with its HA Generally speaking, since L3 handover delay is much longer than L2 handover delay, If possible L3 handover should be surpressed. So from a handover point of view It is better that the number of AR is small and each AR manages a lot of BSs. But if the number of AR is too small, load of each AR becomes higher. So When decide the number of AR, ISP should consider the tradeoff between handover delay and load of each AR. 5. Hierarchical MIPv6 Deployment Considerations An MN should send binding update messages whenever it changes its subnet. Since binding update messages travel through core Internet to reach the HA, inter AR handover delay may be long and it can be burden of core Internet. To resolve this problem, Hierarchical Mobile IPv6 was proposed. In the Hierarchical Mobile IPv6, a new agent called mobility anchor point (MAP) is introduced. If an MN moves in the same MAP domain, it sends Binding Update to the local MAP rather than the HA. In other words, the MAP manages movements of the MN locally. Consequently, Hierarchical Mobile IPv6 can reduce inter AR handover delay and also reduce the burden of core Internet. As metioned in the previous section, the number of AR can be small. In this case, deploying Hierarchical Mobile IPv6 just result in adding packet delay. But in terms of fast handover Hierarchical Mobile IPv6 would be effective. In [5], every AR should receive Binding Update message and hold binding caches for the mobile nodes. And ARs should be fully conneted to setup efficient bi-directional tunnel. But if Hierarchical Mobile IPv6 is deployed, MAP can be local anchor point to support fast handover and can simplify the function of ARs. For further details refer to appendix section of the document [3] When deploying Hierarchical Mobile IPv6, ISP should consider followings : Lee, et al. Expires January 12, 2006 [Page 5] Internet-Draft MIPv6 deployment for BWA July 2005 MAP locates above AR +---+ +--------|MAP|-------+ | +---+ | | | +--+ +--+ |AR| |AR| +--+ +--+ | | | | subnet1 subnet2 / | \ / | \ / | \ / | \ / | \ / | \ +--+ +--+ +--+ +--+ +--+ +--+ |BS| |BS| |BS| |BS| |BS| |BS| +--+ +--+ +--+ +--+ +--+ +--+ Figure 2. MAP locates above AR. In this case, a MAP domain covers a lot of ARs. This deployment scenario is economically efficient but MAP can be bottleneck point because MAP should encapsulate every incoming and outgoing packet. Also, if a failure occurs at the MAP, every MN served by the MAP will suffer from service disruptions. MAP co-locates with AR (flat architecture) Lee, et al. Expires January 12, 2006 [Page 6] Internet-Draft MIPv6 deployment for BWA July 2005 +--+ +---+ +--+ +---+ |AR|-|MAP| |AR|-|MAP| +--+ +---+ +--+ +---+ | | | | subnet1 subnet2 / | \ / | \ / | \ / | \ / | \ / | \ +--+ +--+ +--+ +--+ +--+ +--+ |BS| |BS| |BS| |BS| |BS| |BS| +--+ +--+ +--+ +--+ +--+ +--+ Figure 3. MAP co-locates with AR. In this case, a MAP domain covers only one AR. The MAP can reduce handoff time when intra AR L3 handover occurs. At the same time, the MAP is distributed over the network, so that the MAP load is lower than the previous case. However, this scenarios is not useful when inter AR handover occurs frequently. 6. NEMO Deployment Scenarios Network Mobility (NEMO) basic support proposes a solution for mobile networks. In the solution, a mobile router (MR) manages mobile network and sends binding update on the behalf of visiting mobile nodes and local fixed nodes. When NEMO basic support is deployed in Mobile IPv6 environment, signaling traffic can be reduced and it is very attractive to ISP administrators. NEMO deployment scenarios are divided into following cases based on the types of MR's ingress/egress interfaces. 6.1 egress interface: IEEE 802.16, ingress interface: IEEE 802.11 Lee, et al. Expires January 12, 2006 [Page 7] Internet-Draft MIPv6 deployment for BWA July 2005 +-----------------+ +---------------------------------+ | | | | | +------+ +------+ +-------+ | | | | 802.16 | | 802.11 | | | Internet ------| BS |---------------| MR |--------| VMN | | | | | | | | | | | | | +------+ | | +------+ +-------+ | | | | | | | | VEHICLE | +-----------------+ +---------------------------------+ Figure 4. NEMO deployment scenario 1. This case is appropriate for initial deployment of BWA network. At initial deployment phase, the number of mobile devices with a 802.16 interface may be small, while mobile devices with a 802.11 interface are common. Therefore, a service model for the 802.16 egress interface and 802.11 ingress interface is required. The BS and MR can be included in the same administrative domain or not. In the latter case, the negotiation such as authentication and billing should be done between two domains. 6.2 egress interface: IEEE 802.16, ingress interface: IEEE 802.15 +-----------------+ +---------------------------------+ | | | | | +------+ +------+ +-------+ | | | | 802.16 | | 802.15 | | | Internet ------| BS |---------------| MR |--------| VMN | | | | | | | | | | | | | +------+ | | +------+ +-------+ | | | | | | | | VEHICLE | +-----------------+ +---------------------------------+ Figure 5. NEMO deployment scenario 2. IEEE 802.15 specifies a standard for short coverage and a low data rate wireless Personal Area Network (PAN). In a private car, there can be many devices connected to intenet such as car audio system and air conditioning system. In general, a private car can be covered in a small communication range of IEEE 802.15 standards. So this scenario can be useful to serve private car without interference of IEEE 802.11 or IEEE 802.16 radio frequency. Lee, et al. Expires January 12, 2006 [Page 8] Internet-Draft MIPv6 deployment for BWA July 2005 7. NEMO and HMIPv6 Integration Scenarios When NEMO and HMIPv6 are deployed together, a deployment model is divided into two cases, depending on whether the MN knows the existence of MAP or not 7.1 MN knows MAP's existence This scenario is specified in [7] for Route Optimization purpose. In this case, an MR forwards an MAP's prefix which is received from its egress interface to its ingress interface. If an MR enters a new MAP domain, MNs in the mobile network as well as the MR recognizes that MAP's prefix has changed. Then, the MR and MNs send binding update messages to their HAs and register new RCoAs. But if the MR enters a new AR in the same MAP domain, MNs in the mobile network can't recognize that AR has changes so only the MR send new LCoA to MAP. Strong point An MN in a mobile network configures its RCoA based on the MAP's prefix which is contained in RA and registers it with its HA, so that packets destined to or originated from the MN don't need to visit the MR's HA. In other words, bi-directional tunnel is established between the MN's HA and MAP and considerable level of route optimization can be achieved. Weak point If the MR enters new MAP domain, both the MR and MNs under the MR send binding update messages to their HAs. Therefore, collisions may occur at the ingress interface of the MR and it result in high signaling overhead. 7.2 MN doesn't know MAP's existence In this case an MR doesn't forward prefix of MAP to MNs in the mobile network. When an MR receive a RA message from the AR, the MR creates an RCoA by using a MAP prefix in the RA's MAP option field. But the MR doesn't forward prefix of the MAP to its ingress interface. As a result, an MN doesn't recognize the MR's movement when the MR moves from one MAP domain to another MAP domain. Accordingly, while an MN is in the mobile network, the movement of the MN is transparent to the HA of the MN and the MAP. Lee, et al. Expires January 12, 2006 [Page 9] Internet-Draft MIPv6 deployment for BWA July 2005 Strong point When an MN is in a mobile network, the MN doesn't have to send a binding update message when the MR moves to a new AR or to a new MAP domain. In this case, the handoff delay can be decreased and the core network load can be reduced even though the MN doesn't support Hierachical Mobile IPv6 functionality. And MAP should maintain security association only with MRs and may not take care of MNs. Weak point Packets destined to or originated from the MN should always visit the MN's HA, MR's HA and MAP. Therefore, the end-to-end packet delay increase. 8. BWA Coexistence with IEEE 802.11 Hotspot In nomal case, IEEE 802.11 hotspot service doesn't consider IP layer mobility. This is because object of hotspot service is only to support connectivity to internet by using wireless medium and it doesn't consider session continuity. But If we think of NEMO in BWA access, two coexitence of BWA and hotspot scenarios are arising to support session continuity. Case 1 : When user moves from station to bus, train, or subway An mobile user at the station has been using real time streaming service via IEEE 802.16 BWA network and the user now get on vehicle such as bus, train or subway. The user wants the session to be contiued. Case 2 : When user moves from bus, train, or subway to station As mentioned in previoius case, an mobile user on the vehicle wants a session to be contiued after he or she gets off the vehicle. To support seamless handover between IEEE 802.11 and IEEE 802.16, mobile deivce such as laptop and PDA should be equipped with both interface cards and should have proper vertical handover algorithms. And network should support intersystem handover. If each services is done by different administrative domain, they shoud negotiate each other for authentication and billing. Lee, et al. Expires January 12, 2006 [Page 10] Internet-Draft MIPv6 deployment for BWA July 2005 9. References [1] Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband Access Networks", draft-ietf-v6ops-bb-deployment-scenarios-02 (work in progress), May 2005. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [5] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in progress), October 2004. [6] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", draft-ietf-mipshop-80211fh-04 (work in progress), April 2005. [7] Ohnishi, H., "HMIP based Route optimization method in a mobile network", draft-ohnishi-nemo-ro-hmip-00 (work in progress), October 2003. Authors' Addresses Byoungwook Lee Seoul National University Multimedia and Mobile Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-886-7170 Fax: +82-872-2045 Email: bwlee@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~bwlee/ Lee, et al. Expires January 12, 2006 [Page 11] Internet-Draft MIPv6 deployment for BWA July 2005 Sangheon Pack Seoul National University Multimedia and Mobile Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-1832 Fax: +82-2-872-2045 Email: shpack@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~shpack/ Min-ji Nam KT Portable Internet Team, Convergence Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6121 Fax: +82-2-526-5200 Email: mjnam@kt.co.kr URI: http://mmlab.snu.ac.kr/~mjnam/ Eun Kyoung Paik KT Portable Internet Team, Convergence Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5233 Fax: +82-2-526-5200 Email: euna@kt.co.kr URI: http://mmlab.snu.ac.kr/~eun/ Lee, et al. Expires January 12, 2006 [Page 12] Internet-Draft MIPv6 deployment for BWA July 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. Lee, et al. Expires January 12, 2006 [Page 13]