Network Working Group F. Xia
Internet-Draft B. Sarikaya
Expires: May 21, 2008 Huawei USA
November 18, 2007
Mobile Node Agnostic Fast Handovers for Proxy Mobile IPv6
draft-xia-netlmm-fmip-mnagno-02
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 May 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Xia & Sarikaya Expires May 21, 2008 [Page 1]
Internet-Draft MN Agnostic FMIP November 2007
Abstract
Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility
management protocol, that is, a mobile node does not implement any
mobility management protocol. This document proposes an enhancement
to PMIPv6 protocol in order to improve layer 3 handover performance
and to transfer context borrowing some ideas from Fast Handovers for
Mobile IPv6 (FMIPv6) protocol. In predictive mode, the previous
mobile access gateway (PMAG) transfers context to the next MAG (NMAG)
using Handover Indication (HI) message, while in reactive mode, NMAG
uses Fast Binding Update (FBU) to request context from PMAG. A bi-
directional tunnel is established between PMAG and NMAG to transfer
packets during handover.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 4
3.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 6
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 7
4.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 9
4.3. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 9
4.4. Fast Binding Acknowledgement (FBack) . . . . . . . . . . . 10
4.5. New Options . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.1. Mobile Node Identifier Option . . . . . . . . . . . . 10
4.5.2. IPv4 Address Option . . . . . . . . . . . . . . . . . 10
4.5.3. Vendor Specific Option . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative references . . . . . . . . . . . . . . . . . . 12
Appendix A. Interaction Fast PMIPv6 and IEEE802.16e . . . . . . . 14
A.1. IEEE802.16e terminology . . . . . . . . . . . . . . . . . 14
A.2. IEEE 802.16e Network Entry and Handover Overview . . . . . 14
A.3. Interaction between Fast PMIPv6 and IEEE 802.16e . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Xia & Sarikaya Expires May 21, 2008 [Page 2]
Internet-Draft MN Agnostic FMIP November 2007
1. Introduction
[I-D.ietf-mipshop-fmipv6-rfc4068bis] introduces the operation of fast
handovers for Mobile IPv6. [I-D.ietf-netlmm-proxymip6] defines Proxy
Mobile IPv6 procedures. [I-D.ietf-netlmm-pmip6-ipv4-support]
elaborates the support for the mobile node's IPv4 home address
mobility in order to support the scenario where the local mobility
anchor (LMA) and the mobile access gateway (MAG) are separated by an
IPv4 transport network. This memo combines FMIPv6 operation with
PMIPv6 protocol, and proposes a network based handover solution in
PMIPv6.
The handovers in FMIPv6 always involve the mobile node. In
predictive mode, MN solicits the next access router (NAR)'s
information by sending RtSolPr message; MN uses prefix information in
PrRtAdv to formulate NCoA; MN initiates handover sending FBU to the
previous access router (PAR); MN sends a UNA message to the NAR as
soon as it regains connectivity on the new link so that arriving or
buffered packets can be immediately forwarded.
In PMIPv6, MNs attached to the same MAG have the same CoA which is
called Proxy-CoA. Using network side layer 2 trigger, previous
mobile access gateway (PMAG) can initiate predictive handover on
behalf of MNs. The next mobile access gateway (NMAG) may also
initiate reactive handover procedure when related layer 2 triggers
are received.
2. Terminology
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].
The terminology in this document is based on the definitions in
[I-D.ietf-netlmm-proxymip6], in addition to the ones specified in
this section:
[BS-ID, Proxy-CoA] tuple: Contains Proxy-CoA of an MAG and the Base
Station (identified by BS-ID) which is attached to MAG. The tuple
is probably manually configured or using other mechanisms that are
out of scope.
PMAG: Previous Mobile Access Gateway. The MN's default router prior
to its handover. In this memo, it has the same meaning as the
Previous Access Router (PAR) of FMIPv6.
Xia & Sarikaya Expires May 21, 2008 [Page 3]
Internet-Draft MN Agnostic FMIP November 2007
NMAG: New Mobile Access Gateway. The MN's default router subsequent
to its handover. In this memo, it has the same meaning as the New
Access Router (NAR) of FMIPv6.
3. Protocol Operation
Depending on whether layer 2 Handover (HO) signaling is finished on a
previous link, there are two modes of operation, that is, predictive
and reactive mode. The predictive mode is that L2 HO signaling
finish on the previous link. In the following section, BS and MAG
can be collocated or in different physical entities. The picture in
Figure 1 illustrates the scenario where BS and MAG are physically
separated from each other.
3.1. Predictive Mode
--------------- -----------
MN | s-BS PMAG | | NMAG t-BS |
--------------- -----------
| 1 Network Entry | | | |
|<----------------->|<---------->| | |
| 2 L2 HO | | | |
| Signalling | | | |
|<=================>|===========>| | |
disconnect | | | |
| |3 L2-HO-IND | | |
| |----------->| | |
| | buffering | |
| | | 4 HI | |
| | |--------------->| |
| | | 5 HAck | |
| | |<---------------| |
| | | 6 forward | |
| | | packets | |
| | |===============>| |
| | | buffering |
connect | | | |
| | | | 7 LUP |
| | | 8 RA |<------>|
|<------------------------------------------------| |
| | | 10 deliver | 9 PBU |
| | | packets |---------->LMA
|<================================================| |
Xia & Sarikaya Expires May 21, 2008 [Page 4]
Internet-Draft MN Agnostic FMIP November 2007
Figure 1: Predictive Mode
The procedure is as follows:
1. MN performs network entry procedure in which access
authentication and IPv6 address configuration is done. After
finishing IP connectivity, the PMAG does the mobility related
signaling on behalf of the MN. For detailed information, please
refer to [I-D.ietf-netlmm-proxymip6].
2. Before the MN moves from serving Base Station (s-BS) to target
Base Station (t-BS), negotiation occurs between the MN and s-BS
through L2 handover signaling.
3. When the L2 handover decision is made, the s-BS sends the PMAG
L2-HO-IND message in which target BS-ID SHOULD be included. The
details on L2-HO-IND is out of scope.
4. There are [BS-ID, Proxy-CoA] tuples in MAGs. Once receiving L2-
HO-IND message, PMAG then
* collects MN's related context which includes the following
information: MN identifier, MN-HoA, MN-HNP, MN's Proxy-CoA in
the PMAG and MN's MAC.
* determines the NMAG's address for the destination of HI
message. Using BS-ID in L2-HO-IND message, the PMAG
retrieves NMAG's Proxy-CoA from [BS-ID, Proxy-CoA] tuple.
* sends HI to NMAG with options which are defined in
Section 4.1.
5. The NMAG creates a Binding Update List defined in
[I-D.ietf-netlmm-proxymip6] for the MN based on the information
in the HI message and probably synchronizes the context with
corresponding BS. NMAG then sends HAck to the PMAG. Once HAck
is received by the PMAG, a bi-directional tunnel is established,
and the PMAG's Proxy-CoA and the NAR's Proxy-CoA are the
tunnel's two ends.
6. Packets destined to the MN are tunneled from the PMAG to the
NMAG based on the MN-HoA. PMAG decapsulates the packets
received from the tunnel to the LMA, encapsulates into PMAG/NMAG
tunnel, and then sends them to NMAG. NMAG SHOULD buffer the
packets until the link between NMAG and MN is ready.
7. Network re-entry is performed when MN attaches to t-BS. Context
transferred from PMAG can be used to expedite the procedure.
When a layer 2 link is established, the t-BS sends a Link Up
(LUP) message to NMAG.
8. The NMAG sends Router Advertisement(RA) with the NMAG's
information which facilitates the MN to send packets.
9. The NMAG sends PBU for updating the binding in LMA. For detail,
please refer to [I-D.ietf-netlmm-proxymip6].
10. The NMAG delivers the buffered packets to the MN.
Xia & Sarikaya Expires May 21, 2008 [Page 5]
Internet-Draft MN Agnostic FMIP November 2007
3.2. Reactive Mode
---------- ------------
MN | s-BS PMAG | | NMAG t-BS|
--------- ------------
| | | 1 Network Re-entry | |
|<---------------------------------------------->|<------->|
| | | | |
| | 2 movement detection | |
| | and buffering | |
| | | | 3 LUP |
| | | |<--------|
| | | 4 FBU | |
| | |<--------------------| |
| | | | 5 PBU |
| | | |---------->LMA
| | | 6 FBack | |
| | |-------------------->| |
| | | | |
| | | 7 forward packets | |
| | |====================>| |
| | | | |
| | | 8 RA | |
|<-----------------------------------------------| |
| | | | |
| | | 9 deliver packets | |
|<===============================================| |
| | | | |
Figure 2: Reactive Mode
The procedure is as follows:
1. MN performs network re-entry process to establish the link layer.
Context from original session are necessary to expedite link
establishment.
2. To minimize packet loss during handover, PMAG SHOULD
automatically buffer packets for all MNs that have disappeared
off its link. There are two cases to cover here. Case A, MN
just moved and the PMAG didn't know that it was handing over.
Case B, MN exchanged L2 messages with the PMAG and it knew that
it was moving, but it may not have completed the whole procedure.
PMAGs automatically buffer packets (perhaps for a default period
of time) for each MN that is not on its link in case A, or PMAGs
Xia & Sarikaya Expires May 21, 2008 [Page 6]
Internet-Draft MN Agnostic FMIP November 2007
just buffer packets in case B because it's less open to denial of
service (DoS) attacks or errors.
3. After network re-entry process is finished, t-BS sends a LUP
message to the NMAG. The detail about LUP is out of scope.
4. Once previous BS-ID and MN's MAC are available during network re-
entry process, NMAG sends FBU to the PMAG with the following
information: the NMAG's Proxy-CoA and MN's MAC. NMAG determines
the PMAG's address through referring to [BS-ID, Proxy-CoA] tuples
in NMAG. In this step, it is reasonable to assume that the
previous BS-ID is exchanged during network re-entry as for
example in WiMAX links [802.16e].
5. NMAG sends PBU for updating the binding in LMA. For details,
please refer to [I-D.ietf-netlmm-proxymip6].
6. Based on the MN's MAC, PMAG identifies MN's Binding Update List
and collects MN's related context which includes the following
information: MN identifier, MN-HoA, MN-HNP, MN's Proxy-CoA in the
PMAG, and MN's MAC. PMAG transfers the context to NMAG through
FBack message. When FBack is received by NMAG, a bi-directional
tunnel is established, and the PMAG's Proxy-CoA and the NMAG's
Proxy-CoA are the tunnel's two ends.
7. Once the bi-directional tunnel is established, PMAG forwards the
buffered packets to NMAG.
8. NMAG sends Router Advertisement (RA) with the NMAG's information
which facilitates the MN to send packets.
9. NMAG then delivers packets to the MN.
4. Message Formats
All the messages between PMAG and NMAG are ICMPv6 messages and are as
defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. Some new options
are defined. Only the messages that require modification are
specified below.
4.1. Handover Initiate (HI)
HI is an ICMPv6 message sent by PMAG to NMAG to convey context and
establish bi-directional tunnel. Please refer to
[I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.2.1 for details. The
following information are included in options for bi-directional
tunnel creation and context transfer:
MN Identifier The information is conveyed by Mobile Node Identifier
option defined in Section 4.5.1. The identifier is used for
retrieving MN's profile from a policy store.
Xia & Sarikaya Expires May 21, 2008 [Page 7]
Internet-Draft MN Agnostic FMIP November 2007
Proxy-CoA of PMAG The information is conveyed by IP Address Option
defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.1.
PMAG's Proxy-CoA is one end of the bi-directional tunnel between
PMAG and NMAG.
Proxy-CoA of NMAG The information is conveyed by IP Address Option
defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. The address is
intended to be the other end of the bi-directional tunnel. NMAG
can return another address in HAck message as the tunnel end if
the address is not proper.
MN MAC The information is conveyed by Link-layer Address (LLA)
Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section
6.4.3. MAC is used to correlate Bind Update List and the
corresponding layer 2 link.
MN-HoA The information is conveyed by IP Address Option defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.1. It is the
main element for Bind Update List in NMAG. All traffic from the
source address MN-HoA is routed via the bi-directional tunnel
between PMAG and NMAG when the new tunnel between LMA and NMAG is
not created. The option is necessary only if MN is IPv6 or dual
stack support.
LMAA The information is conveyed by IP Address Option defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.1. The address
is configured on the interface of the local mobility anchor and is
the transport endpoint of the tunnel between the local mobility
anchor and the mobile access gateway. The option is necessary
only if transport network is IPv6.
IPv4 LMAA The information is conveyed by IPv4 Address Option defined
in Section 4.5.2. The option is necessary only if transport
network is IPv4.
MN-HNP The information is conveyed by New Router Prefix Information
Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section
6.4.2. To emulate MN's home link, MN's Home Network Prefix is
included in the NMAG's Router Advertisement.
Link-local Address of PMAG The information is conveyed by IP Address
Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. The value
will be the link-local address of the first MAG to which this MN
attached. NMAG MUST advertise RA using the PMAG's link-local
address with the Router Lifetime field set to value 0, then it is
possible to force the flush out of the Previous Default-Router
entry from the mobile node's cache.
Xia & Sarikaya Expires May 21, 2008 [Page 8]
Internet-Draft MN Agnostic FMIP November 2007
DHCP Server Address The information is conveyed by IP Address Option
defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. If Address
Configuration using DHCP is supported on the link on which the
mobile node is attached, the DHCP relay agent needs to be
configured on the MAG. When the mobile node sends a DHCPv6
Request message, the relay agent function on the MAG must relay
the message to the DHCP server. The option is necessary only if
DHCP Server Address is IPv6.
IPv4 DHCP Server Address The information is conveyed by IPv4 Address
Option defined in Section 4.5.2. The option is necessary only if
DHCP Server Address is IPv4.
Vendor Specific Option A new option is defined in Section 4.5.3.
This option is defined for implementation specific context such as
security parameters, compression parameters and so on.
4.2. Handover Acknowledge (HAck)
HAck is a reply to the HI message. Please refer to
[I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.2.2. The following
option is needed:
Proxy-CoA of NMAG The information is conveyed by IP Address Option
defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. PMAG MUST use
this as one end of a bi-directional tunnel.
4.3. Fast Binding Update (FBU)
The Fast Binding Update message is defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.3.1. The following
modifications are made:
Proxy-CoA of PMAG . The information is conveyed by IP Address
Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. PMAG's
Proxy-CoA is one end of the bi-directional tunnel between PMAG and
NMAG.
Proxy-CoA of NMAG . The information is conveyed by IP Address
Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. The
address is intended to be the other end of the bi-directional
tunnel. NMAG can return another address in HAck message as the
tunnel end if the address is not proper.
Xia & Sarikaya Expires May 21, 2008 [Page 9]
Internet-Draft MN Agnostic FMIP November 2007
MN MAC The information is conveyed by Link-layer Address (LLA)
Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section
6.4.3. MAC is used to correlate Bind Update List and
corresponding layer 2 link.
4.4. Fast Binding Acknowledgement (FBack)
FBack message is sent by the PMAG to acknowledge receipt of a Fast
Binding Update message and is defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.3.2. The message has
the same option set as HI message to establish bi-directional tunnel
and transfer contexts.
4.5. New Options
4.5.1. Mobile Node Identifier Option
Various forms of identifiers can be used to identify a MN. Since
[I-D.ietf-netlmm-proxymip6] uses the mobile node identifier option
for Mobile IPv6 defined in [RFC4283], this document also adopts the
same format.
4.5.2. IPv4 Address Option
A mobile node operating in IPv4-only mode or in a dual-stack mode
should be able to obtain an IPv4 home address. When the transport
network between the local mobility anchor and the mobile access
gateway is an IPv4 network, LMA IPv4 address is necessary. This
option is used for IPv4 address context transfer between PMAG and
NMAG.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be assigned by IANA
Length the length of the option in units of 8 octets.
Option-Code
1 IPv4 MN-HoA
2 IPv4 LMA Address when transport network is IPv4.
Xia & Sarikaya Expires May 21, 2008 [Page 10]
Internet-Draft MN Agnostic FMIP November 2007
IPv4 Address
The IPv4 address defined by the Option-Code field
4.5.3. Vendor Specific Option
Like Mobile IPv6 Vendor Specific Option defined in
[I-D.ietf-mip6-vsm], the option defined here is for vendors specific
implementation. MAGs not equipped to interpret the option MUST
ignore it.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be assigned by IANA
Length The length of the option in units of 8 octets.
Vendor ID
The SMI Network Management Private Enterprise Code of the Vendor/
Organization as defined by IANA
String The String field is one or more octets. The actual format of the
information is site or application specific. It SHOULD be encoded as
a sequence of type / length / value fields. Multiple
sub-options MAY be encoded within a single Vendor Specific option.
5. Security Considerations
AAA-based secret keys or local CAs can be used to protect the
signalling exchange between PMAG and NMAG.
Xia & Sarikaya Expires May 21, 2008 [Page 11]
Internet-Draft MN Agnostic FMIP November 2007
6. IANA consideration
The values of Vendor Specific Option and IPv4 Address Option MUST be
allocated by IANA.
7. Acknowledgements
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[802.16e] Institute of Electrical and Electronics Engineer,
"Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE 802.16e/D12.
8.2. Informative references
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005.
[I-D.ietf-mipshop-fmipv6-rfc4068bis]
Koodli, R., "Mobile IPv6 Fast Handovers",
draft-ietf-mipshop-fmipv6-rfc4068bis-03 (work in
progress), October 2007.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
Xia & Sarikaya Expires May 21, 2008 [Page 12]
Internet-Draft MN Agnostic FMIP November 2007
draft-ietf-netlmm-proxymip6-07 (work in progress),
November 2007.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01
(work in progress), July 2007.
[I-D.ietf-mip6-vsm]
Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
Vendor Specific Option", draft-ietf-mip6-vsm-03 (work in
progress), October 2007.
Xia & Sarikaya Expires May 21, 2008 [Page 13]
Internet-Draft MN Agnostic FMIP November 2007
Appendix A. Interaction Fast PMIPv6 and IEEE802.16e
A.1. IEEE802.16e terminology
MOB_MSHO-REQ: handover request message sent by MN.
MOB_BSHO-RSP: handover response message sent by BS.
MOB_BSHO-REQ: handover request message sent by BS.
MOB_HO-IND: handover indication message sent by MN.
RNG-REQ: Ranging Request.
RNG-RSP: Ranging Response.
REG-REQ: Registration Request.
REG-RSP: Registration Response.
PKM-REQ: Privacy Key Management Request.
PKM-RSP: Privacy Key Management Response.
A.2. IEEE 802.16e Network Entry and Handover Overview
Related IEEE 802.16e processes are highlighted in the following
section.
Network Entry. Once the MN makes a first network attachment, it
conducts 802.16e ranging through which it can acquire physical
parameters from the target BS, tuning its parameters to the target
BS. After ranging with the target BS successfully, the MN negotiates
basic capabilities such as maximum transmit power and modulator/
demodulator type. It then performs authentication and key exchange
procedure, and finally registers with the target BS. After
successful registration, the target BS become a serving BS.
Handover Preparation. The handover preparation can be initiated by
either the MN or the BS. During this period, neighboring BSs are
compared by the metrics such as signal strength or QoS parameters and
a target BS is selected among them. Once the MN decides handover, it
notifies the serving BS by sending a MOB_MSHO-REQ message. The BS
then replies with a MOB_BSHO-RSP containing the recommended BSs to
the MN after negotiating with candidates. Optionally it may confirm
handover to the target BS over backbone when the target is decided.
The BS alternatively may trigger handover with a MOB_BSHO-REQ
message.
Xia & Sarikaya Expires May 21, 2008 [Page 14]
Internet-Draft MN Agnostic FMIP November 2007
Handover Execution. When the MN is about to move to the new link
after deciding the target BS, it sends a MOB_HO-IND message to the
serving BS as a final indication for its handover.
Network Reentry. The process is almost the same as the network
entry. If the target BS has already learned some contexts such as
authentication or capability parameters through backbone, it may omit
the corresponding procedures.
A.3. Interaction between Fast PMIPv6 and IEEE 802.16e
o Predictive Mode. In handover execution phase which is described
in the above section, a MN sends MOB_HO-IND to the serving BS.
The target BSID should be included in the MOB_HO-IND. Upon
receiving MOB_HO-IND, the serving BS notifies PMAG with L2-HO-IND
event as described in Figure 1. The target BSID should be
included in the L2-HO-IND. The PMAG can decide the corresponding
NMAG by referring to [BS-ID, Proxy-CoA] tuple. The details of the
handover are described in Section 3.1.
o Reactive Mode. After switching links, the MN synchronizes with
the target BS and performs the 802.16e network reentry
procedure.The MN exchanges the RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/
RSP and REG-REQ/RSP messages with the target BS. When the network
reentry procedure is completed and the link layer is ready for
data transmission, the target BS informs the NMAG with a LUP
primitive in which the previous serving BSID is included. The
NMAG can decide the corresponding PMAG by referring to [BS-ID,
Proxy-CoA] tuple. The details of the handover are described in
Section 3.2
Xia & Sarikaya Expires May 21, 2008 [Page 15]
Internet-Draft MN Agnostic FMIP November 2007
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires May 21, 2008 [Page 16]
Internet-Draft MN Agnostic FMIP November 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).
Xia & Sarikaya Expires May 21, 2008 [Page 17]