Internet DRAFT - draft-lee-v6ops-mipv6-deployment
draft-lee-v6ops-mipv6-deployment
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]
