Network Working Group H. Yokota
Internet-Draft KDDI Lab
Intended status: Standards Track K. Chowdhury
Expires: December 3, 2007 Starent Networks
R. Koodli
Nokia Research Center
B. Patil
Nokia Siemens Networks
June 2007
Fast Handovers for PMIPv6
draft-yokota-mipshop-pfmipv6-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 December 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Yokota, et al. Expires December 3, 2007 [Page 1]
Internet-Draft Proxy-based Fast Handover June 2007
Abstract
This document specifies the usage of FMIPv6 when Proxy Mobile IPv6 is
applied for the mobility management protocol. Necessary amendments
are shown for FMIPv6 to work under the condition that the mobile node
does not have IP mobility functionality and it is not involved with
either MIPv6 or FMIPv6 operations.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 14
5.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 15
5.3. Context Request Option . . . . . . . . . . . . . . . . . . 16
5.4. NAI Option . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Tunnel-ID Option . . . . . . . . . . . . . . . . . . . . . 18
5.6. New option-code for the IP Address Option . . . . . . . . 18
5.7. Vendor Specific Option . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Normative References . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Yokota, et al. Expires December 3, 2007 [Page 2]
Internet-Draft Proxy-based Fast Handover June 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 [1].
Yokota, et al. Expires December 3, 2007 [Page 3]
Internet-Draft Proxy-based Fast Handover June 2007
2. Introduction
Proxy Mobile IPv6 [2] provides IP mobility to a mobile node that does
not have Mobile IPv6 [4] functionality. The proxy agent in the
network performs the signaling and does the mobility management on
behalf of the mobile node. Although the signaling between the mobile
node and the network can be saved, the basic performance for handover
such as handover latency is considered to be not different from that
of Mobile IPv6.
To improve handover latency due to Mobile IPv6 procedures, fast
handovers for MIPv6 is specified in FMIPv6[3]. By applying the
FMIPv6 solution to Proxy MIPv6 as well, it is expected that the
handover latency due to Proxy MIPv6 procedures will be improved as
much. However, Mobile IPv6 and Proxy MIPv6 are intrinsically
different in the sense that the mobile node is not involved with IP
mobility and hence does not directly handle the care-of address.
Hence, there are some issues in directly applying the original
specifications of FMIPv6 to Proxy MIPv6. This document identifies
those differences and specifies amendments to apply FMIPv6 solution
principles to Proxy MIPv6.
Yokota, et al. Expires December 3, 2007 [Page 4]
Internet-Draft Proxy-based Fast Handover June 2007
3. Terminology
This document refers to [2][3][4] for terminology. The following
terms and abbreviations are additionally used in this document. The
reference network is illustrated in Figure 1.
Previous Access Network (P-AN):
The access network to which the MN is attached before handover.
New Access Network (N-AN):
The access network to which the MN is attached after handover.
Previous Mobile Access Gateway (PMAG):
The MAG that manages mobility related signaling for the MN
before handover. In this document, the MAG and the Access
Router (AR) are collocated.
New Mobile Access Gateway (NMAG):
The MAG that manages mobility related signaling for the MN after
handover.
HO-Initiate:
A generic signaling that indicates the handover of the MN sent
from the P-AN to the PMAG. While this signaling is dependent on
the access technology, it is assumed that HO-Initiate can carry
the information to specify the MN and to help the PAR resolve
the NAR (e.g. the new access point or base station to which the
MN is moving to).
Yokota, et al. Expires December 3, 2007 [Page 5]
Internet-Draft Proxy-based Fast Handover June 2007
+----------+
| LMA |
| |
+----------+
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference network for fast handover
Yokota, et al. Expires December 3, 2007 [Page 6]
Internet-Draft Proxy-based Fast Handover June 2007
4. Proxy-based FMIPv6 Protocol Overview
To reduce the handover latency due to signaling between the MAGs
(Mobile Access Gateways) and the LMA (Local Mobility Anchor), FMIPv6
in this document specifies a bi-directional tunnel between the
Previous MAG (PMAG) and the New MAG (NMAG). To expedite sending the
Proxy Binding Update (PBU) by the NMAG, FMIPv6 protocol is also used
for context transfer, whereby the necessary information for sending
the PBU is transferred from the PMAG.
In this document, the Previous Access Router (PAR) and New Access
Router (NAR) are interchangeable with the PMAG and NMAG,
respectively.
Since the MN is not directly involved with IP mobility, it is natural
to think that the MN is not directly involved with fast handover
procedures, either at least from the IP layer perspective.
Therefore, among the messages for fast handovers defined in RFC4068,
those that are initiated by and targeted to the MN are not used when
PMIPv6 is in use. Such messages are the Router Solicitation for
Proxy Advertisement (RtSolPr), Proxy Router Advertisement (PrRtAdv),
Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and
Fast Neighbor Advertisement (FNA).
RFC4068 specifies two types of fast handovers; the predictive fast
handover and the reactive fast handover. In the predictive fast
handover, the MN sends the FBU to the PAR before handover, which then
triggers to establish a bi-directional tunnel between the PAR and NAR
to transfer packets for the MN. On the other hand, in the reactive
fast handover, the FBU is sent by the MN to the NAR after it has
moved to the new network, which is then transferred to the PAR to
trigger to send the Handover Initiate (HI) towards the NAR. Based on
the above observations, the fast handover procedures for PMIPv6 need
to work without the involvement of the MN. Figure 2 illustrates the
predictive fast handover procedures for PMIPv6, where the bi-
directional tunnel establishment is initiated by the PAR.
Yokota, et al. Expires December 3, 2007 [Page 7]
Internet-Draft Proxy-based Fast Handover June 2007
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
| Report | | | | |
(a) |-(MN ID,-->| | | | |
| New AP ID)| | | | |
| | HO Initiate | | |
(b) | |--(MN ID, New AP ID)-->| | |
| | | | | |
| | | | HI | |
(c) | | | |-(MN ID, ->| |
| | | |MN-HoA,LMA)| |
| | | | | |
(d) | | | |<---HAck---| |
| | | | (MN ID) | |
| | | | | |
(e) | | | |==DL data=>| |
| | | | | |
(f) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(g) |<---establishment---->|<----establishment----->| |
| | | (substitute for FNA) | |
| | | | | |
(h) |<==================DL data=====================| |
| | | | | |
(i) |===================UL data====================>|# |
| | | #|<==========|# |
| | | #|===================>|
/ | | | | | | \
|(j) | | | | |--PBU-->| |
| | | | | | | |
|(k) | | | | |<--PBA--| |
\ | | | | | | /
Figure 2: Predictive fast handover for PMIPv6 (PAR initiated)
The detailed descriptions are as follows:
(a) The MN detects that a handover is imminent and reports the
identifications of itself (MN ID) and the access point (New AP ID)
to which the MN is most likely to move. These IDs can be Link-
Layer Addresses (LLAs) or any other types of IDs. This step is
access technology specific. In some cases, the P-AN will figure
out which AP ID the MN is moving to.
Yokota, et al. Expires December 3, 2007 [Page 8]
Internet-Draft Proxy-based Fast Handover June 2007
(b) The previous access network (P-AN), to which the MN is currently
attached, indicates the handover of the MN to the PAR (PMAG).
(c) The PAR sends the HI to the NAR. The HI message MUST include
the MN ID and SHOULD include the MN-HoA and the address of the LMA
that is currently serving the MN.
(d) The NAR sends back the Hack to the PAR. At this point, the bi-
directional tunnel between the PAR and NAR is established.
(e) Packets destined for the MN are transferred from the PAR to the
NAR over the tunnel that is established at the previous step.
After detunneling, those packets may be buffered at the NAR based
on the U flag in the HI message. If the connection between the
N-AN and NAR has already been established, those packet may reach
the N-AN (access technology specific).
(f) The MN hands over to the New Access Network (N-AN).
(g) The MN establishes a connection (e.g. radio channel) with the
N-AN, which in turn triggers the establishment of the connection
between the N-AN and NAR if it has not been established, yet
(access technology specific). This can be regarded as a
substitute for the FNA.
(h) The NAR starts to transfer packets destined for the MN via the
N-AN.
(i) The uplink packets from the MN are sent to the NAR via the N-AN
and the NAR forwards them to the PAR. The PAR then sends the
packets to the LMA that is currently serving the MN.
(j) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA,
whose address can be obtained in (c). Steps (j) and (k) are not
part of the fast handover procedure, but shown for reference.
(k) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the
NAR (NMAG). From this time on, the packets to/from the MN go
through the NAR instead of the PAR.
According to Section 4 of RFC4068, the PAR establishes a binding
between the PCoA and NCoA to forward packets for the MN to the NAR,
and the NAR creates a proxy NCE to receive those packets for the NCoA
before the MN arrives. In the case of PMIPv6, however, the only
address that is used by the MN is MN-HoA, so the PAR transfers the
packets for the MN to the NAR instead of the NCoA. The NAR then
simply detunnels (decapsulates) those packets and delivers them to
the MN. If the NAR obtains the LLA (=MN ID) and MN-HoA by the HI, it
Yokota, et al. Expires December 3, 2007 [Page 9]
Internet-Draft Proxy-based Fast Handover June 2007
can create the NCE for the MN and deliver packets to it before the MN
performs the ND. For the uplink packets from the MN after handover
in (i), the NAR forwards the packets to the PAR through the tunnel
established in step (d). The PAR then decapsulates and sends them to
the LMA.
The IP addresses in the headers of those user packets are summarized
below:
In (e),
Inner source address: IP address of the CN
Inner destination address: MN-HoA
Outer source address: IP address of the PAR (PMAG)
Outer destination address: IP address of the NAR (NMAG)
In (h),
Source address: MN-HoA
Destination address: IP address of the CN
In (i),
- from the MN to the NMAG,
Source address: MN-HoA
Destination address: IP address of the CN
- from the NMAG to the PMAG,
Inner source address: MN-HoA
Inner destination address: IP address of the CN
Outer source address: IP address of the NAR (NMAG)
Outer destination address: IP address of the LMA
- from the PMAG to the LMA,
Yokota, et al. Expires December 3, 2007 [Page 10]
Internet-Draft Proxy-based Fast Handover June 2007
Inner source address: MN-HoA
Inner destination address: IP address of the CN
Outer source address: IP address of the PAR (PMAG)
Outer destination address: IP address of the LMA
If the network that the MN has moved in does not support PMIPv6 but
only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6
at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA
in steps (j) and (k). If this is the case, the LMA and HA will most
likely be collocated and the LMA (HA) address should be maintained in
the new network for communication continuity. Since the LMA (HA)
address is transferred to the NAR in step (c), the MN can retrieve it
at or after step (g) by e.g. the authentication or DHCP procedure
(not shown in the figure).
In the case of the reactive handover for PMIPv6, since the MN does
not send either the FBU or FNA, it would be more natural that the NAR
sends the HI to the PAR after the MN has moved to the new network.
Figure 3 illustrates the reactive fast handover procedures for
PMIPv6, where the bi-directional tunnel establishment is initiated by
the NAR.
Yokota, et al. Expires December 3, 2007 [Page 11]
Internet-Draft Proxy-based Fast Handover June 2007
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(b) |<--establishment-->|<-------establishment------>| |
| (MN ID) | (MN ID) | |
| | |(substitute for FNA and FBU)| |
| | | | | |
| | | | HI | |
(c) | | | |<---(MN ID) ---| |
| | | | | |
| | | | HAck | |
(d) | | | |---(MN ID, --->| |
| | | | MN-HoA, LMA) | |
| | | | | |
(e) | | | |===DL data====>|# |
|<====================DL data====================|# |
| | | | | |
(f) |=====================UL data===================>|# |
| | | #=|<==============|# |
| | | #=|=======================>|
/ | | | | | | \
|(g) | | | | |--PBU-->| |
| | | | | | | |
|(h) | | | | |<--PBA--| |
\ | | | | | | /
Figure 3: Reactive fast handover for PMIPv6 (NAR initiated)
The detailed descriptions are as follows:
(a) The MN hands over from the P-AN to the N-AN.
(b) The MN establishes a connection (e.g. radio channel) with the
N-AN, which triggers the establishment of the connection between
the N-AN and NAR. The MN ID is transferred to the NAR for the
subsequent procedures. This can be regarded as a substitute for
the FNA and FBU.
(c) The NAR sends the HI to the PAR. The HI message MUST include
the MN ID. The Context Request Option MAY be included to
request additional context information on the MN to the PAR.
Yokota, et al. Expires December 3, 2007 [Page 12]
Internet-Draft Proxy-based Fast Handover June 2007
(d) The PAR sends back the HAck to the NAR. The HAck message MUST
include the MN-HoA that is corresponding to the MN ID in the HI
message and SHOULD include the LMA address that is currently
serving the MN. The context information requested by the NAR
MUST be included. At this point, the bi-directional tunnel
between the PAR and NAR is established.
(e) Packets destined for the MN are transferred from the PAR to the
NAR over the tunnel that is established at the previous step.
After detunneling, those packets are delivered to the MN via the
N-AN.
(f) The uplink packets from the MN are sent to the NAR via the N-AN
and the NAR forwards them to the PAR. The PAR then sends the
packets to the LMA that is currently serving the MN.
Steps (g)-(h) are the same as (j)-(k) in the predictive fast handover
procedures.
In step (c), The IP address of the PAR needs to be resolved by the
NAR to send the HI to the PAR. This information may come from the
N-AN or some database that the NAR can access.
Also, in step (c), the NAR could send an unsolicited HAck message to
the PAR, which then triggers the HI message from the PAR. By doing
so, the directions of HI/HAck messages are aligned with the
predictive (PAR-initiated) fast handover. Further study is needed if
this call flow is more appropriate than the current one.
Yokota, et al. Expires December 3, 2007 [Page 13]
Internet-Draft Proxy-based Fast Handover June 2007
5. Message Format
This document extends the HI and HAck to work with PMIPv6 and further
defines new options and option-codes for the IP Address option to
convey context information.
5.1. Handover Initiate (HI)
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 | Code | Checksum |
+--------------+-+-+-+--------+--------------------------------+
| Subtype |S|U|P|Reserved| Identifier |
+--------------+-+-+-+--------+--------------------------------+
| Options ...
+------------------------
IP Fields:
Source Address
The IP address of PAR or NAR
Destination Address
The IP address of the peer AR
All the other fields follow RFC4068.
ICMP Fields:
Code not used when P flag is set and MUST be set to zero.
S flag not used when P flag is set and MUST be set to zero.
U flag Buffer flag. Same as RFC4068.
P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed
for the mobility management protocol. All the involved
nodes MUST perform based on this document for fast handover
procedures.
All the other fields follow RFC4068.
Valid options:
Yokota, et al. Expires December 3, 2007 [Page 14]
Internet-Draft Proxy-based Fast Handover June 2007
MN ID This identifier can be the link-layer address of the MN or
any other type of information that can uniquely identify
the MN (e.g. IMSI or NAI). This option MUST be included
so that the destination can recognize the MN. If the link-
layer address is used, the Link-Layer Address (LLA) option
defined in RFC4068 MUST be used.
MN-HoA This information is stored in the IP Address option.
Context Request Option Context Request Option This option is used to
request context information typically by the NAR to the PAR
in the NAR-initiated fast handover.
5.2. Handover Acknowledge (HAck)
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 | Code | Checksum |
+--------------+-+------------+--------------------------------+
| Subtype |P| Reserved | Identifier |
+--------------+-+------------+--------------------------------+
| Options ...
+------------------------
IP Fields:
Source Address
Copied from the destination address of the
Handover Initiate message to which this message
is a response.
Destination Address
Copied from the source address of the Handover
Initiate message to which this message is a
response.
All the other fields follow RFC4068.
ICMP Fields:
Code:
Yokota, et al. Expires December 3, 2007 [Page 15]
Internet-Draft Proxy-based Fast Handover June 2007
0: Handover Accepted
128: Handover Not Accepted
129: Administratively prohibited
130: Insufficient resources
P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed
for the mobility management protocol. All the involved
nodes MUST perform based on this document for fast handover
procedures.
Valid options:
MN ID Copied from the corresponding HI message.
MN-HoA Stored in the IP Address option so that the NAR can use
this address for the PBU.
LMA Stored in the IP Address option so that the NAR can use
this address for the PBU.
Requested option(s) All the other context information requested by
the Context Request Option in the HI message.
5.3. Context Request Option
This option is sent in the HI message to request context information
on the MN.
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 |
+---------------------------------------------------------------+
| Reserved |
+---------------+---------------+-------------------------------+
| Req-type-1 | Req-option-1 | Padding |
+---------------------------------------------------------------+
| Padding |
+---------------+---------------+-------------------------------+
| Req-type-2 | Req-option-2 | Vendor-ID |
+-------------------------------+-------------------------------+
| Vendor-ID | VS-Type |
+---------------------------------------------------------------+
| ... |
Yokota, et al. Expires December 3, 2007 [Page 16]
Internet-Draft Proxy-based Fast Handover June 2007
Context Request Option is typically used for the reactive (NAR-
initiated) fast handover mode to retrieve the context information
from the PAR. When this option is included in the HI message, the
requested option(s) MUST be included in the HAck message.
Type TBD
Length Number of requested context(s)+1.
Option-Code 0
Req-type-n The Type value for the requested option.
Req-option-n The Option-Code for the requested option.
Padding 6 octets of padding are added if the requested type is
not the Vendor-Specific Option. MUST be set to zero.
Vendor/Org-ID Defined in the Vendor Specific Option.
VS-Type Defined in the Vendor Specific Option.
5.4. NAI Option
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 | NAI-Length |
+---------------------------------------------------------------+
| NAI ...
+------------------------------
This option is used to transfer the Network Address Identifier
(NAI)[5] of the MN.
Type TBD
Length The size of this option is in 8 octets including the
Type, Length and Option-Code.
Option-Code 0
NAI-Length The length of the NAI in octets.
Yokota, et al. Expires December 3, 2007 [Page 17]
Internet-Draft Proxy-based Fast Handover June 2007
NAI The NAI value in a string format.
5.5. Tunnel-ID Option
This option is used to transfer additional information that
associates the MN with the tunnel used by the MN. The exact format
of the Tunnel-ID is outside the scope of this document.
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 | TID-Length |
+---------------------------------------------------------------+
| Tunnel-ID ...
+------------------------------
Type TBD
Length The size of this option is in 8 octets including the
Type, Length and Option-Code.
Option-Code 0
NAI-Length The length of the Tunnel-ID in octets
Tunnel-ID The Tunnel-ID value.
5.6. New option-code for the IP Address Option
To convey the MN-HoA and LMA in the HI or HAck message, new Option-
Codes for the IP Address Option[3] are defined:
Option-Code
4 MN-HoA
5 LMA
5.7. Vendor Specific Option
This option is to send other information than defined in this
document. Many of the context information can be vendor specific
(access technology specific). This option is used for such
information.
Yokota, et al. Expires December 3, 2007 [Page 18]
Internet-Draft Proxy-based Fast Handover June 2007
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 |
+---------------------------------------------------------------+
| Vendor/Org-ID |
+-------------------------------+-------------------------------+
| VS-Type | VS-Length |
+---------------------------------------------------------------+
| VS-Value ...
+------------------------------
Type TBD
Length The size of this option is in 8 octets including the
Type, Length and Option-Code.
Option-Code 0
Vendor/Org-ID The SMI Network Management Private Enterprise Code of
the Vendor/Organization as defined by IANA.
VS-Type The type of the Vendor-Specific information carried in
this option. The type value is defined by the vendor
or organization specified by Vendor/Org-ID.
VS-Length The length of the Vendor-Specific information carried
in this option.
VS-Value The value of the Vendor-Specific information carried
in this option.
Yokota, et al. Expires December 3, 2007 [Page 19]
Internet-Draft Proxy-based Fast Handover June 2007
6. Security Considerations
Security issues for this document follow those for PMIPv6[2] and
FMIPv6[3]. In this document, it is assumed that the PAR (PMAG), NAR
(NMAG) and LMA have trust relationship with each other and the
connection between any pair is securely protected.
Yokota, et al. Expires December 3, 2007 [Page 20]
Internet-Draft Proxy-based Fast Handover June 2007
7. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Gundave, S., Ed., "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-00.txt, April 2007.
[3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068,
July 2005.
[4] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004.
[5] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
Yokota, et al. Expires December 3, 2007 [Page 21]
Internet-Draft Proxy-based Fast Handover June 2007
Authors' Addresses
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama, 356-8502
JP
Email: yokota@kddilabs.jp
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Email: kchowdhury@starentnetworks.com
Rajeev Koodli
Nokia Research Center
975 Page Mill Road, Suite 200
Palo Alto, CA 94304
US
Email: rajeev.koodli@nokia.com
Basavaraj Patil
Nokia Siemens Networks
6000 Connection Drive
Irving, TX 75039
US
Email: basavaraj.patil@nsn.com
Yokota, et al. Expires December 3, 2007 [Page 22]
Internet-Draft Proxy-based Fast Handover June 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).
Yokota, et al. Expires December 3, 2007 [Page 23]