NEMO WG JH. Choi
Internet-Draft Hee Jin. Jang
Intended status: Informational Samsung AIT
Expires: April 19, 2007 Youngdon. Chung
Samsung Electronics
October 16, 2006
Prefix binding based mobility management in WiMAX network
draft-jinchoi-nemo-pbm-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 April 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Choi, et al. Expires April 19, 2007 [Page 1]
Internet-Draft pbm October 2006
Abstract
This document describes a protocol which provides movbility support
for an ordinary IPv6 host in WiMAX network. The protocol allows
session continuity for every IPv6 node in WiMAX network as it moves
across subnets. The protocol exploits the facts that a single prefix
is assigned per an IPv6 host in WiMAX network and prefix binding
scheme is defined in NEMO WG. WiMAX access routers perform prefix
binding for the hosts' stead and the mobility is transparent to the
hosts inside WiMAX network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Home Access Router (HAR) . . . . . . . . . . . . . . . . . 5
2.2. Prefix table for AR . . . . . . . . . . . . . . . . . . . 5
2.3. Prefix table for AAA server . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 8
4.1. Home Access Router (HAR) operation . . . . . . . . . . . . 8
4.1.1. Assigning prefix . . . . . . . . . . . . . . . . . . . 8
4.1.2. Receiving Binding Update . . . . . . . . . . . . . . . 8
4.1.3. Forwarding packets . . . . . . . . . . . . . . . . . . 9
4.2. New Access Router (NAR) operation . . . . . . . . . . . . 9
4.2.1. Detecting prefix . . . . . . . . . . . . . . . . . . . 9
4.2.2. Sending Binding Update . . . . . . . . . . . . . . . . 9
4.2.3. Forwarding packets . . . . . . . . . . . . . . . . . . 9
4.3. AAA server operation . . . . . . . . . . . . . . . . . . . 10
4.3.1. Managing prefix . . . . . . . . . . . . . . . . . . . 10
4.3.2. Informing prefix . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Choi, et al. Expires April 19, 2007 [Page 2]
Internet-Draft pbm October 2006
1. Introduction
This document presents a way to support mobility for an ordinary IPv6
host in WiMAX network. The scheme exploits the fact that, in WiMAX
network, a prefix is assigned per an MS (mobile station) and extends
the prefix binding defined in NEMO basic protocol [4].
WiMAX network follows the point-to-point link model, i.e. 'per MS
prefix model'. RFC 2461 defines link as a communication facility or
medium over which nodes can communicate at the link layer, i.e., the
layer immediately below IP. When an MS moves within a link, it can
keep using its IP addresses.
In WiMAX, there exists a connection (service flow) between an MS and
the AR via a BS, over which packets are transferred. [9] 'per MS
prefix model' defines the collection of all service flows (transport
connections) to the same MS as a single link. An AR should treat the
collection of service flows to each MS as a separate virtual link and
manage a virtual interface for each virtual link. Each MS belongs to
a different link.
A different prefix should be assigned to a different link [2]. An AR
assigns a separate 64-bit prefix on a link for each MS. Bear in mind
that a prefix is assigned not to an MS but to the link between the MS
and the AR. The AR advertises an assigned prefix by sending the
prefix in a Router Advertisement (RA) message. To prevent steep
routing table increase, the prefixes should be aggregated. An AR may
get a 48-bit prefix, allocate 64-bit sub prefixes to MSs and inject
only the aggregated prefix uplink.
An AR has the pool of prefixes and assigns a prefix for each MS. The
AR manages the prefix table to keep track of a prefix per an MS and
forward packets properly. The AR advertises an MS its prefix
according to the prefix table. If an MS sends an RS, the AR refers
the prefix table to find the prefix associated with the soliciting MS
and replies an RA to the MS with the prefix.
When an MS moves within an AR and makes a new attachment, the AR
recognizes its previous attachment and advertises the MS's existing
prefix. The MS can keep using its existing IP address. When an MS
moves to a different AR, the MS can't use the existing IP address and
should perform mobility signaling.
However, we may use prefix binding method defined in NEMO [4] to
provide mobility support without an MS's involvement. When an MS,
which is an ordinary IPv6 node, attaches to a New Access Router
(NAR), during the AAA procedure the NAR finds out the MS's existing
prefix and the AR to which the prefix is allocated. The NAR sends
Choi, et al. Expires April 19, 2007 [Page 3]
Internet-Draft pbm October 2006
the AR a prefix Binding Update (BU) for the MS's stead to establish a
bi-directional tunnel with the AR. The NAR advertises the existing
prefix to the MS which keeps using its IP address. The packets
destined for the MS are delivered, through the tunnel, from the AR to
the NAR and finally to the MS.
Choi, et al. Expires April 19, 2007 [Page 4]
Internet-Draft pbm October 2006
2. Terminology
2.1. Home Access Router (HAR)
Each AR plays the role of NEMO Home Agent as defined in RFC 3963 [4].
When an MS is attached to an WiMAX AR for the first time, the AR
assigns a prefix for the MS and becomes its Home Access Router (HAR).
When the MS moves to a New Access Router (NAR), the HAR established
the binding for the prefix with the NAR to provide mobility support.
2.2. Prefix table for AR
An AR manages the prefix table which, as an entry, has 3-tuple of [MS
ID, the prefix assigned for the MS, the virtual interface for the
MS]. The prefix table is used to properly forward packets to its
destination. (Further work is needed for lifetime management.)
2.3. Prefix table for AAA server
An AAA server manages the prefix table which, as an entry, has
3-tuple of [MS ID, the prefix assigned for the MS, the MS's HAR
address]. The prefix table is used to inform an NAR an MS's existing
prefix and HAR address. (Further work is needed for lifetime
management.)
Choi, et al. Expires April 19, 2007 [Page 5]
Internet-Draft pbm October 2006
3. Protocol Overview
A WiMAX Access Router (AR) is an omniscient AR, i.e. it knows all MS
attached to itself and all prefixes associated with MSs [9]. The AR
manages a prefix table which, as an entry, has 3-tuple [MS ID, the
prefix assigned for the MS, the virtual interface for the MS]. The
virtual interface may be represented as a GRE key for the ISF. When
a packet arrives, the AR compares the destination address's prefix
with its prefix table to find an associated interface. The packet is
delivered to the interface and forwarded to the destined MS
accordingly.
Each AR also plays the role of Home Agent for mobile router as of RFC
3963 [4].
When an MS is attached to an WiMAX AR for the first time, the AR
becomes the MS's Home Access Router (HAR) and performs AAA procedure
as defined in WiMAX specification. After completing access
authentication, the HAR establishes an Initial Service Flow (ISF)
with the MS. The HAR forms a virtual link with the ISF and manages a
virtual interface for the link.
The HAR assigns on the link a prefix from its prefix pool and adds a
new entry of 3-tuple [MS ID, the newly assigned prefix, the
associated virtual interface] to updates its prefix table. The HAR
advertises the prefix to the MS by sending an RA with the prefix.
The MS receives the RA and starts communication.
The HAR also informs the prefix to the AAA server by sending 3-tuple
of [MS ID, the prefix assigned for the MS, the HAR address for the
MS] [5], [6]. Accordingly the AAA server update its prefix table.
When the MS moves to a New Access Router (NAR), it performs AAA
procedure. The NAR sends an AAA-Request message [5], [6] to the AAA
server with the MS ID. The AAA server compares the MS ID with its
prefix table to find a matching entry of [MS ID, the MS's prefix, the
MS's HAR address]. When the AAA server sends the NAR an Access-
Accept [5], [6] for the MS, it includes the MS's prefix and HAR
address.
Upon receiving the Access-Accept, the NAR detects the MS's prefix and
HAR address. The NAR establishes another ISF. The NAR forms another
link and an associated virtual interface. The NAR sends a prefix
Binding Update (BU) message to the MS's HAR with the MS ID and the
prefix. (Further work is needed for the exact message format.)
Upon receiving the BU, if the HAR decides to accept the binding, the
HAR establishes a bi-directional tunnel with the NAR. The HAR
Choi, et al. Expires April 19, 2007 [Page 6]
Internet-Draft pbm October 2006
manages a virtual interface for the tunnel and updates its prefix
table accordingly. The HAR sends the NAR a prefix Binding
Acknowledgement (BAck) accepting binding and the NAR establishes the
bi-directional tunnel with the HAR.
The NAR adds a new entry of 3-tuple [MS ID, the prefix, the virtual
interface] to its prefix list and advertises the prefix to the MS
with the RA message. The MS keeps using its existing IP address.
When a corresponding node sends a packet to the MS, the packet is
delivered to the HAR because the destination address's prefix is
allocated to the HAR. The HAR compares the prefix of the packet's
destination address with its prefix table and finds the associated
interface, i.e. the tunnel end point. The packet is delivered to the
interface and forwarded to the NAR through the bi-directional tunnel.
Upon receiving the packet, the NAR also refers its prefix table to
find the associated interface. The packet is delivered to the
interface, i.e. GRE tunnel, and forwarded to the MS accordingly.
Choi, et al. Expires April 19, 2007 [Page 7]
Internet-Draft pbm October 2006
4. Protocol Specification
4.1. Home Access Router (HAR) operation
4.1.1. Assigning prefix
When an MS attaches to a Home Access Router (HAR) for the first time,
it performs access authentication procedure with an AAA server
through the HAR. After completing access authentication procedure,
the HAR grants network access to the MS and establish an Initial
Service Flow (initial service flow) with the MS. With the ISF, the
HAR forms a (virtual) link and manages a virtual interface for the
link.
The HAR assigns the link a 64bit prefix (Take notice that HAR is
delegated a bigger prefix and allocate its subprefix for an MS.) and
adds a new entry of [MS ID, the new prefix, the new virtual
interface] to its prefix table.
The HAR registers the newly assigned prefix to the AAA server [5],
[6]. The HAR sends the 3-tuple of [MS ID, the prefix, the HAR IP
address]. (Further work is needed about the exact AAA message
format.)
The HAR advertise the prefix to MS in a Router Advertisement (RA)
message. Upon receiving the RA, the MS sets its IP configuration and
starts communication.
4.1.2. Receiving Binding Update
Upon receiving a prefix Binding Update (BU) message from a New Access
Router (NAR), the HAR verifies the BU message properly. (Further
work is needed about the exact BU format.)
The HAR extracts the prefix and the MS ID from the BU and check
whether the prefix belongs to its prefix table and the MS left the
HAR. If not, it rejects the BU and send back Binding Acknowledgement
(BAck) informing such.
When the HAR determines that the prefix belongs to its prefix table,
the MS left the HAR and decides to grants the binding to provide
mobility support, it establishes the bi-directional tunnel with the
NAR and forms a new virtual inteface to the tunnel.
The HAR updates its prefix table accordingly and set lifetime as the
BU lifetime in the BU message.
Choi, et al. Expires April 19, 2007 [Page 8]
Internet-Draft pbm October 2006
4.1.3. Forwarding packets
When a packet destined for the prefix arrives, the HAR refers its
prefix table and finds an associated interface. The HAR deliver the
packet to the associated interface, i.e. the tunnel end-point and the
packet is forwarded to the NAR through the tunnel.
4.2. New Access Router (NAR) operation
4.2.1. Detecting prefix
When the MS moves to a New Access Router (NAR), it performs access
authentication procedure with an AAA server through the NAR. The NAR
sends Access-Request message [5], [6] to the AAA server with the MS
ID. The AAA server replies with the Access-Accept message [5], [6]
with the MS's prefix and HAR address.
Upon receiving the Access-Accept, the NAR finds out the prefix
assigned for the MS and the HAR to which the prefix is delegated.
4.2.2. Sending Binding Update
The NAR establish a new Initial Service Flow (initial service flow)
with the MS and with the ISF, the NAR forms a (virtual) link and
manages a virtual interface for the link.
The NAR sends a prefix Binding Update (BU) message to the MS's HAR
with MS's prefix and MS ID. The NAR manages the Binding Update list
accordingly. (Further work is needed for exact message format and
Binding Update list management.)
When the NAR receives a Binding Acknowledgement (BAck) message
accepting binding, it establishes the bi-directional tunnel with the
HAR. The NAR assigns the prefix to the (virtual) link for the MS and
updates its prefix table accordingly. The NAR advertises the prefix
to the MS with an RA message. The MS keeps using its current IP
address.
When the NAR receives a Binding Acknowledgement (BAck) message
rejecting binding, the NAR assigns one of the prefixes assigned to
itself to the (virtual) link for the MS and updates its prefix table
accordingly. The NAR advertise the prefix to the MS with an RA
message. The MS detects movement and changes its IP configuration.
4.2.3. Forwarding packets
When a packet destined for the prefix arrives through the tunnel from
the HAR, the NAR refers its prefix table and finds the associated
Choi, et al. Expires April 19, 2007 [Page 9]
Internet-Draft pbm October 2006
interface. The NAR deliver the packet to the interface and the
packet is forwarded to the MS.
4.3. AAA server operation
4.3.1. Managing prefix
An AAA server manages the prefix table which, as an entry, has
3-tuple of [MS ID, the prefix assigned for the MS, the MS's HAR
address].
When an HAR informs a newly assigned prefix with the 3-tuple [MS ID,
the prefix assigned for the MS, the MS's HAR address], the AAA server
updates its prefix table accordingly. [Further work is needed for
exact message format and signaling procedure.]
4.3.2. Informing prefix
When the AAA server receives an AAA-Request message [5], [6] with an
MS ID from an NAR, it checks its prefix table with the MS ID to find
a matching entry, i.e. the MS's prefix and HAR address. If the AAA
server grants network access and there is a matching entry, it sends
the NAR the MS's prefix and HAR address in Access-Accept message [5],
[6].
Choi, et al. Expires April 19, 2007 [Page 10]
Internet-Draft pbm October 2006
5. Security Considerations
TBD
Choi, et al. Expires April 19, 2007 [Page 11]
Internet-Draft pbm October 2006
6. References
6.1. Normative References
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[5] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[7] IEEE Std 802.16-2004, "IEEE Standard for Local and
metropolitan area networks, Part 16: Air Interface for
Fixed Broadband Wireless Access Systems", October 2004.
[8] IEEE802.16e-2005, "IEEE Standard for Local and metropolitan
area networks, Amendment for Physical and Medium Access
Control Layers for Combined Fixed and Mobile Operation in
Licensed Bands", 2005.
[9] WiMAX Forum Network Working Group (NWG),
http://www.wimaxforum.org
6.2. Informative References
[10] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 based
Networks", draft-ietf-16ng-ipv6-link-model-analysis-00 (work in
progress), October 2006.
[11] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[12] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication Dial
In User Service (RADIUS)", RFC 3576, July 2003.
Choi, et al. Expires April 19, 2007 [Page 12]
Internet-Draft pbm October 2006
Authors' Addresses
JinHyeock Choi
Samsung AIT
Networking Lab
P.O.Box 111 Suwon 440-600
KOREA
Phone: +82 31 280 9233
Email: jinchoe@samsung.com
Hee Jin Jang
Samsung AIT
Networking Lab
P.O.Box 111 Suwon 440-600
KOREA
Phone: +82 31 280 9233
Email: heejin.jang@samsung.com
Youngdon Chung
Samsung Electronics
Maetan 3
Youngtond Suwon
KOREA
Phone: +82 31 213 3506
Email: yd.chung@samsung.com
Choi, et al. Expires April 19, 2007 [Page 13]
Internet-Draft pbm October 2006
Full 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.
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.
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).
Choi, et al. Expires April 19, 2007 [Page 14]