One document matched: draft-lee-netlmm-fmip-00.txt
Network Working Group J-C. Lee
Internet-Draft D. Kaspar
Intended status: Standards Track ETRI
Expires: January 19, 2008 July 18, 2007
PMIPv6 Fast Handover for PMIPv6 Based on 802.11 Networks
(draft-lee-netlmm-fmip-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 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Lee & Kaspar Expires January 19, 2008 [Page 1]
Internet-Draft Fast Handover for PMIPv6 July 2007
Abstract
The PMIPv6 protocol provides local mobility to a mobile node without
requiring any modification of the mobile node. A PMIPv6 domain
contains multiple MAGs which the mobile node is attached to, and they
advertise the same prefix to the mobile node so that the mobile node
feels like it is always on the same link. However, horizontal/
vertical handover still happens while the mobile node moves among
MAGs in a PMIPv6 domain, and this handover could give undesirable
delay to mobile nodes running real time applications, such as VoIP.
To solve this problem, this memo proposes a fast handover for PMIPv6
based on 802.11 networks. This scheme uses IAPP to transfer context
information like the mobile node's authentication information and
HNP.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. 802.11 Network Architecture . . . . . . . . . . . . . . . 7
5.2. IAPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Architectural Consideration . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Lee & Kaspar Expires January 19, 2008 [Page 2]
Internet-Draft Fast Handover for PMIPv6 July 2007
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Lee & Kaspar Expires January 19, 2008 [Page 3]
Internet-Draft Fast Handover for PMIPv6 July 2007
2. Introduction
The PMIPv6 protocol provides local mobility to mobile nodes without
requiring any involvement of a mobile node stack. From the
perspective of a mobile node, the entire PMIPv6 domain appears as a
single link, the network ensures the mobile node believes it is
always on its home link. Therefore, mobile nodes in a PMIPv6 domain
may operate as if they were still on the same link, while roaming in
the PMIPv6 domain.
A MAG is an access router that manages mobility related signaling
instead of the mobile node. Hence, if a mobile node roams in the
PMIPv6 domain, handover between MAGs always happens.
When a mobile node moves from a previous MAG to new MAG, it enters an
access authentication process first. After successful access
authentication, the new MAG obtains the mobile node's profile from
the policy store, and then sends a Router Advertisement message to
the mobile node for reconfiguration of the default router. It also
sends a Proxy Binding Update message to the LMA for updating the
current location of the mobile node. These successive procedures
constitute the total handover delay of PMIPv6. (See Figure 1)
|<-------------->|<------------------------->|<----->|<------------>|
L2 detach/attach access authentication RA PBU/PBA
Figure 1: Handover Delay in the PMIPv6 Domain
To reduce this handover delay, this memo focuses on reducing the
"access authentication/obtaining MN's profile" portion of total
handover delay. The scheme described in this memo is based on 802.11
networks, thus the context information (authentication information,
MN's Profile) is transferred from a previous MAG to a new MAG via the
IAPP [802.11f] protocol. IAPP is a protocol used by an AP to
communicate with other APs on a common DS (Distribution System). By
transferring context information in advance, handover delay could be
reduced significantly.
The more detailed procedure is described in Section 5.
Lee & Kaspar Expires January 19, 2008 [Page 4]
Internet-Draft Fast Handover for PMIPv6 July 2007
3. Terminology
Access Point (AP):
Any entity that has station functionality and provides access
to the distribution services, via the wireless medium (WM) for
associated stations.
Association:
The service used to establish access point/station (AP/STA)
mapping and enable STA access to the Distribution System.
Basic Service Set (BSS):
A set of stations controlled by a single coordination function,
where the coordination function may be centralized (e.g., in a
single AP) or distributed (e.g., for an ad hoc network). The
BSS can be thought of as the coverage area of a single AP.
Distribution System (DS):
A system used to interconnect a set of basic service sets
(BSSs) and integrated local area networks (LANs) to create an
extended service set (ESS).
Extended Service Set (ESS):
A set of one or more interconnected basic service sets (BSSs)
and integrated local area networks (LANs) that appears as a
single BSS to the logical link control layer at any station
associated with one of those BSSs. The ESS can be thought of
as the coverage area provided by a collection of APs all
interconnected by the Distribution System. It may consist of
one or more IP subnets.
Station (STA):
Any device that contains an IEEE 802.11 conformant medium
access control (MAC) and physical layer (PHY) interface to the
wireless medium (WM). In this memo a mobile node means a STA.
Inter AP Protocol (IAPP):
IAPP is a set of functionalities and a protocol used by an AP
to communicate with other APs on a common DS.
Lee & Kaspar Expires January 19, 2008 [Page 5]
Internet-Draft Fast Handover for PMIPv6 July 2007
4. Assumptions
Layer 3 AP
The IAPP does not deal directly with the delivery of 802.11
data frames to the STA (AP); instead the DS utilizes existing
network functionality (like TCP/IP protocol) for data frame
delivery, thus all APs mentioned in this memo support IP
protocol.
AP and MAG
APs and MAGs can exist as separate entities or as a merged
entity. If the AP and the MAG exist separately it is assumed
that both maintain the same context information (authentication
information, HNP) for a mobile node, or the AP can get this
information from the MAG.
AP and DS
All APs in a PMIPv6 domain are connected with one another via
the same DS.
Lee & Kaspar Expires January 19, 2008 [Page 6]
Internet-Draft Fast Handover for PMIPv6 July 2007
5. Protocol Details
5.1. 802.11 Network Architecture
The basic building block of an 802.11 network is the BSS. Within a
BSS, STAs can communicate with each other and access the wired
internet via the STA serving as an AP of the BSS. Instead of being
standalone, a BSS may also be a component of an extended form of
network built with multiple BSSs, as shown in Figure 2. This
extended form of network is called an ESS and the architectural
component used to interconnect BSSs is the DS. The IAPP uses the DS.
+-------------------------- ESS -----------------+
| +---------+ |
| | BSS1 | |
| +--[AP1]--+ |
| | |
| +---+----------------+ +----------+ |
| | | | | |
| | DS |----[AP2] BSS2 | |
| +---------+----------+ | | |
| | +----------+ |
| | |
| +---[AP3]------+ |
| | | |
| | BSS3 | |
| +--------------+ |
+------------------------------------------------+
Figure 2: 802.11 Network Architecture
Figure 3 is a conceptual view for A PMIPv6 domain based on 802.11
networks. In this case, each AP and MAG exists separately, and each
{MAG, AP} pair shares context information for a mobile node.
There are several 802.11 access network architectures based on the
characteristics of the DS, but this memo does not handle more
detailed 802.11 access network architectures. For more information,
see [RFC4118].
Lee & Kaspar Expires January 19, 2008 [Page 7]
Internet-Draft Fast Handover for PMIPv6 July 2007
PMIPv6 Domain
+--------------------------[ LMA ]-----------------------+
| / | \ |
| / | \ |
| | | | |
| +-------------+ | +------------+ |
| | | | |
| | | | |
| [MAG1] [MAG2] [MAG3] |
| | | | |
| | _________________|________________ | |
| |/ DS | \| |
| +-----[AP1]----+ +-----[AP2]----+ +-----[AP3]----+ |
| | \_____|___|______________|__|______/ | |
| | | | | | | |
| | BSS1 | | BSS2 | | BSS3 | |
| +--------------+ +--------------+ +--------------+ |
| |
+----------------------------------------------------------+
Figure 3: Example Architecture for a PMIPv6 Domain Based on 802.11
Networks
5.2. IAPP
IAPP is designed for the enforcement of unique association throughout
a ESS and for secure exchange of STA's security context between
previous AP and new AP during handover period. The DS utilizes an
IAPP that provides the necessary capabilities to achieve multi-vendor
AP interoperability within the DS. This IAPP uses TCP or UDP/IP to
carry IAPP packets between APs.
When a STA moves away from its previous AP, it starts searching for
new APs. When the STA found a new AP, it attempts to reassociate
itself with this new AP by sending a reassociation message. On
receiving this reassociation message the new AP replies to the STA
with a reassociation response message. After this response the new
AP also sends an IAPP MOVE-notify message to the previous AP via the
DS. Then, the previous AP responds to the new AP with a MOVE-
response message.
With the MOVE-notify and MOVE-response messages, the IAPP is able to
provide context transfer between APs. By using the context
information carried in these packets, a new AP can expedite the
reauthentication of the STA on reassociation, thus reducing link-
layer handoff latency [802.11f].
In this proposal the mobile node's HNP and authentication information
Lee & Kaspar Expires January 19, 2008 [Page 8]
Internet-Draft Fast Handover for PMIPv6 July 2007
are included in the context information.
5.3. Message Flow
The following scheme is activated when a mobile node roams among MAGs
in a PMIPv6 domain. Figure 4 describes the message flow for this
scheme.
(1) Sending Disassociation message: a mobile node moves away from
the current AP. When the received signal strength reaches a
specific threshold value, the mobile node sends a
Disassociation message to the current AP (pAP). The
Disassociation message includes the mobile node's MAC address.
(2) Forwarding the mobile node's ID: on receiving the
Disassociation message from the mobile node, the pAP sends the
mobile node's ID (MAC) information to the pMAG.
(3) Sending FPBU message: on receiving the mobile node's ID, the
pMAG sends an FPBU(Fast PBU) message to the LMA. This FPBU
message contains the mobile node's NAI option.
(4) Buffering: on receiving the FPBU message, the LMA starts
buffering packets toward the mobile node.
(5) Sending Reassociation message: the mobile node attaches at the
new AP (nAP), and sends a Reassociation message. This message
contains the mobile node's MAC address and the BSSID of the
pAP.
(6) Sending MOVE-notify message: on receiving the Reassociation
message, the nAP sends a MOVE-notify message via the DS.
(7) Sending MOVE-response message: on receiving the MOVE-notify
message, the pAP responds to the nAP with a MOVE-response
message which carries context information for the mobile node.
This context information contains authentication information
and HNP for the mobile node.
(8) Forwarding context information: on receiving the MOVE-response
message, the nAP forwards the mobile node's context information
to the nMAG.
(9) Reconfigure default router for the mobile node: on receiving
the mobile node's context information, the nMAG sends a RA
message to reconfigure the default router of the mobile node.
Lee & Kaspar Expires January 19, 2008 [Page 9]
Internet-Draft Fast Handover for PMIPv6 July 2007
(10) Configure forwarding information: on receiving the mobile
node's context information, the nMAG constructs a PBU message
by using the context information, and sends it to the LMA.
(11) ~ (12) Forwarding buffered packets: on receiving the PBU
message, the LMA sets up a route for the mobile node and starts
forwarding buffered packets to it.
+----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | | pAP | | pMAG| | nAP | | nMAG| | LMA |
+----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | |
|====(1)===>| | | | |
| |-----(2)--->|----------------(3) FPBU-------------->|[ ]
| | | | | |[ ]
~disconnect | | | | |[ ]
| | | | |[ ]
~connect | | | | |[4]
| | | | | |[B]
==================(5)================>| | |[U]
| | | | | |[F]
| | | | | |[F]
| | | | | |[E]
| |<----(6) MOVE-notify-----| | |[R]
| | | | | |[I]
| | | | | |[N]
| | | | | |[G]
| |-----(7) MOVE-response-->| | |[ ]
| | | |---(8)----->| |[ ]
| | | | | |[ ]
| | | | | |[ ]
|<-----------------(9) Router Advertisement--------|--(10) PBU-->|[ ]
| | | | | |
| | | | | |
| | | | | |
|<---------------------(11) forward packets----------------------|
| | | | | |
| | | | | |
| | | | |<--(12)PBAck-|
| | | | | |
| | | | | |
====>: Layer 2 message
---->: Layer 3 message
Figure 4: Protocol Message Flow
Lee & Kaspar Expires January 19, 2008 [Page 10]
Internet-Draft Fast Handover for PMIPv6 July 2007
This scheme reduces handover delay as follows,
Before applying this scheme:
|<------------->|<------------------------->|<----->|<------------>|
L2 detach/attach access authentication RA PBU/PBA
After applying this scheme:
|<-------->|<------------->|<------->|<-------------->|
L2 detach L2 attach/ RA PBU/PBA
context transfer
5.3.1. Architectural Consideration
If the AP and MAG are collocated, steps (2) and (8) are not necessary
for this scheme.
Lee & Kaspar Expires January 19, 2008 [Page 11]
Internet-Draft Fast Handover for PMIPv6 July 2007
6. IANA Considerations
There is no IANA consideration in this document.
Lee & Kaspar Expires January 19, 2008 [Page 12]
Internet-Draft Fast Handover for PMIPv6 July 2007
7. Security Considerations
[802.11f] has some security considerations. This memo follows
section 1.4 of [802.11f].
Lee & Kaspar Expires January 19, 2008 [Page 13]
Internet-Draft Fast Handover for PMIPv6 July 2007
8. References
8.1. Normative References
[802.11f] "802.11F IEEE Trial-Use Recommended Practice for Multi-
Vendor Access Point Interoperability via an Inter-Access
Point Protocol Across Distribution Systems Supporting IEEE
802.11 Operation", July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[pmipv6] Gundavelli, S., "Proxy Mobile IPv6", March 2007.
8.2. Informative References
[802.11] "Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", June 2003.
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access Points
(CAPWAP)", RFC 4118, June 2005.
[RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11
Networks", RFC 4260, November 2005.
Lee & Kaspar Expires January 19, 2008 [Page 14]
Internet-Draft Fast Handover for PMIPv6 July 2007
Authors' Addresses
Joo-Chul Lee
ETRI
161 Gajeong-dong Yuseong-gu
Daejeon, 305-700
Korea
Fax: +82 42 861 5404
Email: rune@etri.re.kr
Dominik Kaspar
ETRI
161 Gajeong-dong Yuseong-gu
Daejeon, 305-700
Korea
Fax: +82 42 861 5404
Email: dominik@etri.re.kr
Lee & Kaspar Expires January 19, 2008 [Page 15]
Internet-Draft Fast Handover for PMIPv6 July 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).
Lee & Kaspar Expires January 19, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 01:56:40 |