Internet DRAFT - draft-melia-mobopts-niho-fmip
draft-melia-mobopts-niho-fmip
IP Mobility Optimizations (Mob T. Melia
Opts) RG NEC
Internet-Draft R. Aguiar
Expires: January 18, 2006 N. Senica
IT
July 17, 2005
Network initiated handover in fast mobile IPv6
draft-melia-mobopts-niho-fmip-01
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 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Mobile IPv6 enables a Mobile Node to maintain its connectivity to the
Internet when moving from an Access Router to another, a process
referred to as handover. Several proposals [5] and [6] were made in
order to improve the handover delay to support real-time traffic,
such as Voice over IP. These proposals keep a fundamental
characteristic of Mobile IP, namely the handover process is triggered
Melia, et al. Expires January 18, 2006 [Page 1]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
by the Mobile Terminal. This document expands this concept to cover
situations where the handover has to be performed by network
management issues, such as spectrum allocation. The document
describes a control architecture based on the policy management.
Requirements Language
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 RFC 2119 [10].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Building Blocks . . . . . . . . . . . . . . . . . . . . . 7
3.2 Protocol Operation . . . . . . . . . . . . . . . . . . . . 7
3.3 Mobile Terminal Initiated Handover . . . . . . . . . . . . 9
3.4 Network Initiated Handover . . . . . . . . . . . . . . . . 10
4. ICMPv6 Messages Format . . . . . . . . . . . . . . . . . . . . 12
4.1 HandoverRequest . . . . . . . . . . . . . . . . . . . . . 12
4.2 HandoverDecision . . . . . . . . . . . . . . . . . . . . . 14
4.3 HandoverAcknowledge . . . . . . . . . . . . . . . . . . . 16
4.4 FastNeighborAdvertisement . . . . . . . . . . . . . . . . 17
4.5 New Options . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.1 Handover Priority Options . . . . . . . . . . . . . . 19
4.5.2 Link-Layer Address (LLA) Options . . . . . . . . . . . 19
4.5.3 IPv6 Address Options . . . . . . . . . . . . . . . . . 20
4.5.4 Handover Refused Options . . . . . . . . . . . . . . . 21
4.5.5 Candidate AR Options . . . . . . . . . . . . . . . . . 21
5. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1 DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Determining New Care of Address . . . . . . . . . . . . . 22
5.3 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 Technology Customization and Optimizations . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Normative References . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
A. Mobility Extensions to COPS . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 33
Melia, et al. Expires January 18, 2006 [Page 2]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
1. Introduction
Current standard Mobile IPv6 provides Internet connectivity to mobile
nodes roaming from one access router to another. To reduce the
handover latency some extensions to standard Mobile IPv6 have been
proposed and are currently in the stage to be accepted as
experimental RFC. In all these approaches, handover is initiated by
the mobile terminal.
It is expected that radio resource usage optimization will be a task
of major relevance in future wireless network environments, with
millions of users roaming between access routers across multiple
technologies (i.e. 802.11, 802.16...). This can resort to mechanisms
and algorithms able to gather measurements and instruct an handover
according to predefined mobility patterns, mechanisms for intelligent
flow balancing, mechanisms for optimized resource re-allocation,
mechanisms for user-traffic performance optimization, or mechanisms
for user profiling (e.g. access rights). For these expectations to
be realized, network control capabilities are required, including the
ability to force specific terminals to perform handovers, either
between access points or between different technologies. This
proposal addresses the problem of how to deploy fast mobility in such
an environment where the network can also impose terminal handover.
Based on the Fast Mobile FMIPv6 protocol [6], we propose a new
approach to globally manage mobility, supporting both existing Mobile
Terminal initiated handovers (MTIHO), and new Network initiated
handovers (NIHO). In both cases, handover will be managed by a
control entity, performing access control and network resources
optimization. Although, the protocol is independent of specific
layer two technologies, cross layer integration for specific
technologies can be possible.
Figure 1 represents the target network architecture.
In this architecture, a control entity is required. This is an usual
entity in radio networks, managing spectrum resources. This unit
acts as Policy Decision Point (PDP), decides on which mobile nodes
should move to what location (the case of NIHO) and (eventually)
performs admission control in case of MTIHO. A MTIHO is mainly
initiated because of user preferences settings (including link level
signal drop) and a NIHO is initiated either because of terminal
mobility or optimization reasons.
Mobile Nodes (MN) are moving across (potentially heterogeneous)
wireless networks. MNs are equipped with one/several network
device(s) and are capable to discover surrounding wireless network
(via for instance CARD [2]). MN are capable to initiate an handover
Melia, et al. Expires January 18, 2006 [Page 3]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
procedure (MTIHO) as well as to act in response to handover
procedures initiated by the network.
Access Routers (ARs) support different types of wireless access
technologies, managed at the IP level. ARs are able to instruct the
MNs about an initiated handover procedure. ARs also act as network
access control points, performing as Policy Enforcement Points (PEP).
Out of the scope of this document is to define how a PDP takes any
decision to initiate an handover (e.g. predictive algorithms based on
cross layer solutions), and how the PDP performs admission control in
case of MTIHO (e.g. network access control restrictions). In
Figure 1 the handover situation is represented, with both the old
link and the new link connections.
+------------+
+-+ old | Previous | <
| | ---------- | Access | ------ > ----\
+-+ link | Router | < \
MN | (PAR) | \
| +------------+ \
| - ^ \
| | v +---------------+
| | +-----+ IP | Correspondent |
| | | PDP | Network | Node |
| | +-----+ +---------------+
| | ^ /
| v v /
V +------------+ /
+-+ new | New | < /
| | ---------- | Access | ------ > ----/
+-+ link | Router | <
MN | (NAR) |
+------------+
Figure 1: Network Architecture
Melia, et al. Expires January 18, 2006 [Page 4]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
2. Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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 BCP 14 [1]. This document
frequently uses the following terms:
Handover (HO)
Namely the process of changing the current point of attachment to
the Network.
Mobile Terminal Initiated Handover (MTIHO)
An HO initiated by the mobile node.
Network Initiated Handover (NIHO)
An HO initiated by the network.
Previous Access Router (PAR)
The MN's default router prior to its handover.
New Access Router (NAR)
The MN's anticipated default router subsequent to its handover.
Old CoA (oCoA)
The MN's Care of Address valid on the PAR's subnet.
New CoA (nCoA)
The MN's Care of Address valid on the NAR's subnet.
Policy Decision Point (PDP)
A logical entity that makes policy decisions for itself or for
other network elements that request such decisions [7].
Policy Enforcement Point (PEP)
A logical entity that enforces policy decisions [7]. In our case,
the AR performs this function.
This document also uses frequently the following terms, associated
with protocol messages:
Handover Request (HOReq)
A protocol message, adapted from the Router Solicitation for Proxy
as defined in [6]. This message indicates here simply the MN
willingness to roam.
Melia, et al. Expires January 18, 2006 [Page 5]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
Handover Decision (HODec)
This is the protocol control message to handover, either in
response to a HOReq, in the case of a solicited handover (MTIHO)
or as consequence of network spectrum optimization, in the case of
a NIHO.
Handover Acknowledge (HOAck)
A message from the MN instructing its PAR to redirect its traffic
(towards NAR), thus confirming the realization of an handover.
Previously known (see [6]) as FBU.
FastNeighborAdvertisement (FNA)
A message from the MN to the NAR to announce attachment, and to
confirm use of nCoA [6].
Melia, et al. Expires January 18, 2006 [Page 6]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
3. Protocol Overview
3.1 Building Blocks
The proposed protocol uses the following functional entities: HO
client and attendant, PEP and PDP.
The HO client is installed on the mobile terminal. The HO client is
responsible for the termination of the messages on the access network
part, inside the MN.
The HO attendant is installed in the AR. It implements the logic to
handle the engine protocol and terminates the message on the access
network part, inside the AR.
A PEP is located in each AR. Logically can be implemented internally
or externally to the HO attendant.
The PDP is typically the control entity in the network (e.g. user
access control unit, network management unit). It is the central
entity in this architecture that performs admission control, in case
of MTIHO, and takes decision on relocation of MN across different
ARs, in the case of NIHO. This entity effective performs inter AR
communication, and thus avoid superfluous direct message exchange
between the PAR and the NAR.
The protocol is implemented via the ICMPv6 protocol, over the last
wireless/wired hop. The communication between PEP and PDP is
performed via COPS messages, as defined in [8]. For this purpose
extensions for mobility purposes have been proposed in Appendix A.
Out of the scope of this document is to describe how the internal
PEP--HO attendant communication inside the AR can be implemented.
One of the functions that the PDP SHOULD implement is the Duplicate
Address Detection (DAD) process. The protocol specification allows
the PDP to perform DAD during the HO process before admission control
mechanisms take place. If the MN is suggesting a nCoA already in
use, then the PDP should compute an alternative CoA to be sent to the
MN. Note that any mechanism (e.g. stateless autoconfiguration,
Cryptographically Generated Addresses (CGA)) could have been applied
here.
3.2 Protocol Operation
In the following sections, the protocol operation is described. A
two level architecture, i.e. Access Routers (PEP) and PDP, is
assumed. The PDP entity is integrated in the fast mobility process
to allow terminal admission control and system performance
Melia, et al. Expires January 18, 2006 [Page 7]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
optimization. In future wireless networks, the shared radio media
will need to be managed and optimized: even MTIHO has to be
authorized by the PDP before being able to be completed, for access
authorization and network resource issues.
{MN} {PAR,oPEP} PDP {NAR,nPEP}
| | | |
|------HOReq------->| | |
| (ICMPv6) |-----HOCRequest----->| |
| | (COPS) | |
| | | |
| |<----HOCDecision-----|--HOCDecision->|
| | (COPS) | (COPS) |
|<----HODec---------| | |
| (ICMPv6) | |<--HOCRequest--|
| | | (COPS) |
| | | |
| | |--HOCDecision->|
| | | (COPS) |
|------HOAck------->|--HOCReport/Request->| |
| (ICMPv6) | (COPS) | |
| | | |
==== L2 ===== | |
| reassociation | | |
|--------------------------FNA--------------------------->|
| |
| | |<--HOCReport---|
| | | (COPS) |
| |<----HOCDecision-----| |
| | (COPS) | |
| |-----HOCReport------>| |
| | (COPS) | |
Figure 2: Signalling Flow
In Figure 2 an overview of the signalling scheme is presented. The
protocol operation involve MNs (implementing an HO client), ARs
(implementing an HO attendant and a PEP) and the PDP. The protocol
provides an homogeneous way to manage mobile terminal initiated
handover (MTIHO) and network initiated handover (NIHO).
HandoverRequest (HOReq)- only used in MTIHO
This message initiates a MTIHO. The datagram is sent to the
current AR (oAR) containing a list, ordered by preference, up to 3
possible candidate ARs. This message has a flag indicating if the
HO is imminent. This flag should be set if the MN is requesting
the HO by loss of signal reasons. The handover might be initiated
Melia, et al. Expires January 18, 2006 [Page 8]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
because of mobility reasons (loss of signal) or as a consequence
of user preferences.
HandoverDecision (HODec)
This message contains the candidate access router to which the MN
should handover to. This indication could be solicited (e.g.
reply to an HoReq in case of MTIHO) or unsolicited, in case of
NIHO.
HandoverAcknowledge (HOAck)
By means of this datagram the MN could either accept to change its
point of attachment or reject/sustain the undergoing handover. It
is realistic to assume that between the HOReq and the HOAck
messages the MN, due to mobility specific patterns, might not have
access to the target AP specified in the HODec. In this case the
MN COULD stop the handover process by means of a specific flag.
However, the usage of this option SHOULD then be followed by a
MTIHO.
FastNeighborAdvertisement (FNA)
After changing his physical connection the mobile terminal has to
advertise his presence on the new link in order to populate the
nAR's IPv6 neighbour cache. This step is important for packet
delivery.
COPS HOCRequest
In order to request a handover admission the PEP in oAR sends the
list of candidate access routers to the PDP for validation.
Additionally the message acknowledges an unsolicited handover
decision.
COPS HOCDecision
By means of this message the PDP can advertise the handover
candidate access router or indicate to the HO attendant in the oAR
the conclusion of a successful HO.
COPS HOCReport
This message is used for reporting purposes.
3.3 Mobile Terminal Initiated Handover
When a Mobile Terminal (MT) initiates a MTIHO, the HO client sends a
HOReq message to its current AR containing a list, ordered by
preference, of up to three possible candidate ARs that is able to
access, and the associated nCoA requested for each one of these sub-
networks. Note that, although the draft does not specify how to
perform network discovery, any mechanism such as [2] smootly
Melia, et al. Expires January 18, 2006 [Page 9]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
integrates with the proposed protocol. The AR (via the PEP
component) forwards the request for approval to the PDP. Upon
receiving this message, the PDP verifies the request and answers
according to its internal rules, preferentially with the first
occurrence of the list.
The PDP sends a HOCDecision (COPS) message to both the NAR
(unsolicited policy message) and the PAR. The oAR processes the
message, and informs the MN that it can now move to the network
provided in the message HODec (ICMPv6). As soon as the HO client
receives a HODec it sends a HOAck (ICMPv6) message to the oAR, and
performs the (link layer) disconnection from the current link and
attachment to the new one. Note that the MT may stop the handover
when it receives the HODec message, sending a HOAck (ICMPv6) message
with code 1. By means of a HOCReport message the PDP is informed.
The HOCDecision message received by the NAR indicating the MN's
movement is unsolicited, which means that there was no prior request.
Acording to COPS protocol semantics, PEPs require handles to
unequivocally identify a specific session. Thus, unsolicited
decisions' handle MUST be set to the Configuration Request value, by
protocol definition. Upon the reception of unsolicited messages the
NAR MUST acknowledge with a HOCRequest message containing the same
infomation. Finally, the PDP sends a HOCDecision with the correct
handle set with no specific fields.
When connected to the new link, the MN MUST send a FNA message to the
nAR; by means of this message the IPv6 neighbour cache is updated.
The nAR after receiving this message informs the PDP that the MT is
attached on the new link, and therefore this indication is then
forwarded to the oAR in order to conclude the successful handover.
The process is finalized with a confirmation Report, HOCReport
(COPS), from the oAR.
To better support real time applications, layer two latency should be
optimized. Furthermore, flow duplication techniques at IP level
SHOULD be considered. Intelligent duplication mechanisms would allow
data to be bicasted, during the HO duration, to the old CoA and the
new CoA. In the MN side the only operation required is the
reordering of the duplicated packets that has to be processed in an
application-independent way.
3.4 Network Initiated Handover
When the network initiates a NIHO the procedure is similar to the one
described in Section 3.3, with a single exception. The mobile
terminal does not send any HOReq (ICMPv6) message and the datagram
Melia, et al. Expires January 18, 2006 [Page 10]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
HODec (ICMPv6) contains a flag indicating that this is a Network
Initiated Handover and the AR to where the MN has to move. The
remaining process is exactly the same as MTIHO, except of the
HOCReport message which is replaced by a HOCRequest message due to
the same reasons explained above about COPS Handle. A MT may send an
HOAck (ICMPv6) with code 1 to stop the Handover procedure; this must
only be used if the AR that the PDP is targeting is no longer
available to the MN. In this case the MT must send a HOReq (ICMPv6)
immediately afterwards. The policies taken by the PDP in case the MT
rejects the HODec (ICMPv6) are outside the scope of this document.
Melia, et al. Expires January 18, 2006 [Page 11]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
4. ICMPv6 Messages Format
All the ICMPv6 messages have a common Type specified in [3]. The
messages are distinguished based on the subtype field. In section
Section 7 the Subtypes are specified. For all the ICMPv6 messages
the checksum is defined as in [4].
4.1 HandoverRequest
The HandoverRequest message is sent by Mobile Nodes willing to roam
to another access router. Mobile Nodes will be expecting an
HandoverDecision.
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 | Reserved | HOSessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: HandoverRequest (HOReq) message
IP Fields:
Source Address
IP address of the sending interface
Destination Address
IP address of the Access Router
Hop Limit
1
Authentication Header
If a Security Association is established between the Mobile Node
and the Access Router the sender SHOULD include this header.
ICMP Fields:
Melia, et al. Expires January 18, 2006 [Page 12]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
Type
The Experimental Mobility protocol Type
Code
0 Intra-Domain HO (default)
1 Inter-Domain HO
Checksum
The ICMPv6 Checksum
Subtype
See section Section 7.
Reserved
MUST be set to zero from the sender and ignored by the receiver.
HOsessionID
This field has a first bit equal to 0 in this message. The
HO_client MUST also compute a 15 bit number for the leftover bits,
in order to identify the ongoing handover. This is an useful
countermeasure to solve race conditions in case both MTIHO and
NIHO are issued for the same target Mobile Node. Furthermore,
this number SHOULD be incremental, in order for the network to
have an idea of how often the MT performs HOs.
Valid Options:
Handover Priority Option
Indicates the priority of the Handover with increasing values.
Link Layer Address Option
This indicates the source link layer of the sender.
IPv6 Address Option (HomeAddress)
This indicated the home address of the mobile node, helping to
identify the MT.
Candidate AR Option
This option MUST be included indicating the number of candidate
access routers the terminal is asking for validation. The PEP in
the PAR is in charge of forwarding this request to the PDP.
According to the number of identified candidate ARs this option
will contain, up to a maximum of three tuples. Each tuple
contains a LLA field (Candidate LLA1) for the access interface of
the AP belonging to the NAR, a IPv6 Address field (Candidate AR
Melia, et al. Expires January 18, 2006 [Page 13]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
IPv6 1) for the NAR IPv6 address, and a second IPv6 Address
field(Candidate nCoA 1) containing a precomputed nCoA. If this
field is filled with 0s, the MT is requesting a nCoA from the PDP.
The tuple {LLA, NAR IPv6 addr, nCoA} is intended to avoid any lengthy
discovery phase during an HO process. Already existing mechanisms
SHOULD be used (see [2]) to perform address resolution starting from
the layer two identifier.
The HOReq message could be set to be Imminent or Not-Imminent. For
instance, if the MN triggers a MTIHO because of mobility reasons, the
loss of connection could be imminent. In that case the network
should consider this handover as high priority and should wait the
current HO to be concluded before issuing any NIHO for the same
target mobile node. This mechanism SHOULD be implemented to avoid
unuseful handshakes and wastage of bandwidth.
4.2 HandoverDecision
The HandoverDecision is sent to mobile nodes either in response to a
HOReq (MTIHO), or as an unsolicited message (NIHO).
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 | Reserved | HOSessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: HandoverDecision (HODec) message
IP Fields:
Source Address
IP address of the sending interface.
Destination Address
IP address of the Access Router.
Hop Limit
1
Melia, et al. Expires January 18, 2006 [Page 14]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
Authentication Header
If a Security Association is established between the Mobile Node
and the Access Router the sender SHOULD include this header.
ICMP Fields:
Type
The Experimental Mobility protocol Type
Code
0 Network Initiated HO
1 Mobile Terminal Initiated HO
2 Handover Refused
Checksum
The ICMPv6 Checksum.
Subtype
See section Section 7.
Reserved
MUST be set to zero from the sender and ignored by the receiver.
HOsessionID
If the message is a response to a MTIHO, it contains the same
HOSessionID of the HOReq message. If this message is the first
message in a NIHO, then this field has a first bit equal to 1.
The HO_attendant MUST fill the left bits with a 15 bits number, to
identify the ongoing handover. Furthermore, this number SHOULD be
incremental.
Valid Options:
Link Layer Address Option
This indicates the source link layer of the sender.
Handover Refused Option
Indicates whether the HO can be performed or not. This option is
valid only in case of MTIHO.
Melia, et al. Expires January 18, 2006 [Page 15]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
Candidate AR Option
This option is included in both MTIHO and NIHO. The tuple
included is only one. It cannot be combined with an Handover
Refused Option. This option is useful to help the DAD mechanisms
implemented in the PDP. In fact in case the nCoA provided in the
HOReq message cannot be used in the new AR subnet the PDP MUST
compute an alternative CoA and provide the MN with this fresh
information.
If the message is sent to initiate a NIHO the mobile node SHOULD obey
to the network. The only situation when the mobile node may refuse
the HO is because it cannot see the AR selected by the network,
because of his own movement. After rejecting this HO, the MT has to
start a MTIHO.
4.3 HandoverAcknowledge
The HandoverAcknowledge is sent from a mobile node to the PAR to
confirm the undergoing handover will take place. In case of MTIHO
the mobile node can still reject the handover mainly because of the
mobility pattern. In case of NIHO the mobile node can reject the
handover because the network is targeting an AP not "visible" form a
mobile node point of view.
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 | Reserved | HOSessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: HandoverAcknowledge (HOAck) message
IP Fields:
Source Address
IP address of the sending interface
Destination Address
IP address of the Access Router
Melia, et al. Expires January 18, 2006 [Page 16]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
Hop Limit
1
Authentication Header
If a Security Association is established between the Mobile Node
and the Access Router the sender SHOULD include this header.
ICMP Fields:
Type
The Experimental Mobility protocol Type
Code
0 Handover Performed
1 Handover Sustained
Checksum
The ICMPv6 Checksum
Subtype
See section Section 7.
Reserved
MUST be set to zero from the sender and ignored by the receiver.
HOsessionID
This field should have the same value of the corresponding field
of the HODec message referred to by this HOAck.
Valid Options:
No options MUST be included.
The CODE field in the ICMPv6 header indicates if the HO is performed
or not. No extra options are here required.
4.4 FastNeighborAdvertisement
A MN sends a Fast Neighbor Advertisement to announce itself to the
NAR.
Melia, et al. Expires January 18, 2006 [Page 17]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Fast Neighbor Advertisement (FNA) Message
IP fields:
Souce Address
The nCoA.
Destination Address
The NAR's IP address.
Mobility Options
The message MUST contain the Mobility Header Link-Layer Address of
the MN in MH-LLA option format (see Figure 7.)
The MN sends Fast Neighbor Advertisement to the NAR, as soon as it
regains connectivity on the new link. Arriving packets can be
immediately forwarded. If there is no entry at all, it creates one
and sets it to REACHABLE. If there is an entry in INCOMPLETE state
without a link-layer address, it sets it to REACHABLE.
The combination of NCoA (present in source IP address) and the Link-
Layer Address (present as a Mobility Option) SHOULD be used to
distinguish the MN from other nodes.
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 | Pad0=0 | LLA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Mobility Header Link-Layer Address Option
The size of this option in octets not including the Type, Length and
Option-Code fields.
Melia, et al. Expires January 18, 2006 [Page 18]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
Option-Code: 2 Link-layer Address of the MN.
LLA: The variable length link-layer address.
4.5 New Options
All the options are specified according to the format in Figure 8.
The type values are defined from the Neighbor Discovery options
space. The Length field is in units of 8 octets. The Option Code
provides additional information.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Option Format
4.5.1 Handover Priority Options
Handover Priority 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 | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Handover Priority Option
Type: To be Assigned by IANA
Option-Code: 0
Priority: 0 Regular
1 Imminent
4.5.2 Link-Layer Address (LLA) Options
Link-Layer Address (LLA) Option:
Melia, et al. Expires January 18, 2006 [Page 19]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Link Layer Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: LLA Option
Type: To be Assigned by IANA
Option-Code: 0 MT LLA
1 AP LLA
4.5.3 IPv6 Address Options
IPv6 Address 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 | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPv6 Option
Type: To be Assigned by IANA
Option-Code: 0 Home Address
1 New Care Of Address
2 Old Care Of Address
3 New AR Address
Melia, et al. Expires January 18, 2006 [Page 20]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
4.5.4 Handover Refused Options
Handover Refused 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 | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: HO Refused Option
Type: To be Assigned by IANA
Option-Code: 0
Reason: 0 Not Available
1 QoS Reasons
2 A4C Reasons
3 Unknown Reason
4.5.5 Candidate AR Options
Candidate AR 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 | Candidate Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 LLA Option + 2 IPv6 Address Options......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Candidate AR Option
Type: To be Assigned by IANA
Option-Code: 0
Candidate Nr: Number of LLA+2xIPv6 for Candidate ARs
Melia, et al. Expires January 18, 2006 [Page 21]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
5. Miscellaneous
5.1 DAD Handling
Duplicate Address Detection (DAD) was defined in [9] to avoid address
duplication on links when stateless address auto-configuration is
used, and is a source of extra delay in an handover.
The probability of a identifier duplication on the same AR cannot be
ignored. In this draft, the PDP takes the responsibility for DAD
process.
Note that in many cases, the PDP may already have the knowledge
required to assess whether the expectable MN's CoA request will be a
duplicate or not, even before the MN tries to move to the new subnet.
The PDP can have a list of all nodes on its controlled PEPs (ARs),
and by periodically searching this list, and evaluating potential
nCoA created by stateless autoconfiguration, can detect danger of
potential MN address duplication or not. For these potential
conflicting addresses, the PDP can prepare alternative CoA before the
HOReq message appears (even if this potential conflict may eventually
never appear). This reduces the DAD time to a process performed
decoupled from the HO. Note that for non-imminent HOReq messages,
DAD can be performed during the handover process.
5.2 Determining New Care of Address
Typically, the MN formulates its prospective nCoAs using the
information provided by discovering its surrounding wireless networks
(via for instance CARD [2], or by router advertisements received).
The PDP should use this prospective nCoA in the HODec message, unless
it detects a potential DAD situation. In this case it provides a new
nCoA in the HODec message. The MT must always use the nCoA indicate
in the HODec message.
5.3 Packet Loss
Two problems exist associated with packet loss. The loss of one of
the fast-handover messages and the loss of packets during the
handover process.
For the loss of control messages, timing mechanisms should be in
place both in the MT, in the AR and in the PDP, per HOSession. These
timers will reissue ONCE a message if no corresponding answer is
received before the timeout.
For the loss of data packets, the link switching required during
handover may not be synchronous with the handover signalling and
Melia, et al. Expires January 18, 2006 [Page 22]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
packet transmission. Thus packets may arrive at NAR before the MN is
able to establish its link there, or arrive to the OAR when the link
does not exist anymore. These packets will be lost unless they are
buffered by the NAR. The protocol considers the use of bicasting
from the PAR to the NAR in order to minimize this situation. No
buffering is considered in order to simplify protocol operation in
very large networks.
5.4 Technology Customization and Optimizations
The signaling described in Figure 2 enables a MN and the PDP to
respectively initiate a MTIHO or NIHO. These handovers might be
horizontal handovers, -intra technology handovers-, or vertical
handovers, -inter technology handovers-. During an handover
procedure link characteristics may vary, depending on the environment
considered, affecting therefore at different levels application
behavior (typically unaware of the undergoing handover). Moreover,
optimization algorithms, either implemented at the PDP (e.g. resource
optimization, admission control) or at the MN, might improve their
performance if notified on time about the new link configuration
(e.g. uplink/downlink bit rate stream).
Although not yet presented in this document, an effort has been
undertaken to specify new options to allow MNs, ARs and PDP to
exchange link characteristics during the handover process. In [12]
some specifications are provided to enable Mobile IPv6 and Mobile
IPv4 capable nodes to exchange link information with the HA and any
CN. However, to generalize the approach, the link characteristics
exchange should happen during the handover process, since the Binding
Update handshake conclude the handover process, when (bicasted)
packets are already routed to the nCoA. For instance, specialized
traffic shapers could be installed in the ARs to adapt a selected
MT-CN flow to the specific underlaying wireless/wire line access
technology. In addition the PDP could implement several algorithms
specific for a given access technology.
As an example of the relevance of the proposed strategy, it is
expected that predictive or stochastic algorithms could be
implemented at the PDP (leaving less complex logic for the MN) to
perform handover decision depending on the mobile user environment.
For that additional (to the link characteristics) parameters such as
bit rate, quality of service parameters (e.g. in 802.11e) , radio
frequency, MN's view of the access point signal level, network view
of the MN's sending power may have to be evaluated prior to any
handover decision. This type of approach has been described, for
instance, in [13] where a WLAN scenario is presented and extensions
to Mobile IPv6 messages are introduced to support an handover control
function for handover decision.
Melia, et al. Expires January 18, 2006 [Page 23]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
The authors of this document believe [12] and [13] represent only a
subset on the potential scenarios for real deployment. This document
is thus centered on a general framework and related protocol
functionalities to provide a flexible solution able to take into
account both current and emerging wireless/wire line access
technologies. For incorporating future technologies seamlessly it is
essential that specific solutions are framed under a general
solution, and novel COPS objects are then defined depending on the
technology.
Melia, et al. Expires January 18, 2006 [Page 24]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
6. Security Considerations
Security SA previous HO -- It is likely that MNs have to get
authenticated and authorized previous to any handover. During this
process a security association with the serving AR will be
established to protect the ongoing communications. During the
handover the transfer of such keying material from the PAR to the NAR
ensures only already authenticated nodes can roam within the same
administrative domain. It is out of the scope of this document to
define how those mechanisms should be in place, however the handover
latency interaction between the proposed approach and existing
security mechanisms SHOULD be optmized.
Securing HOreq, HODec, HOAck -- These messages have to be secured by
means of key material exchanged during the authentication phase.
Securing COPS messages -- It can be assumed that PEPs and PDPs belong
to the same administrative domain and the COPS signaling can be
therefore protected using already in place technologies such as IPsec
or TLS.
Usage of handover keys -- Recent work, see [11], introduced a new way
of protecting handover signaling exchanged between the PAR, NAR and
MN. The documents introduces a protocol handshake to derive handover
keys prior to an handover process. The procedure, triggered from the
MN and terminated at the AAA server, can exchange keys with all the
available surrounding MN's access routers. To reduce network
overhead (i.e. an handshake is required prior to any handover) we
suggest to interface with a AAA server via the PDP entity, thus
allowing secured unsolicited handover decisions being notified to a
MN. This particular feature is required to avoid malicious nodes to
forge "fake" HODec messages and disrupt MNs' connectivity.
Melia, et al. Expires January 18, 2006 [Page 25]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
7. IANA Considerations
This document defines three new experimental messages which use the
Experimental Mobility Protocol format. These require three new
Subtype value assignments of the Experimental Mobility Protocol
Subtype Registry as follow:
Subtype Description Reference
------- ----------- ---------
2 HOReq Section 4.1
3 HODec Section 4.2
4 HOAck Section 4.3
8. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[11] Narayanan, V., "Handover Keys Using AAA",
draft-vidya-mipshop-handover-keys-aaa-00 (work in progress),
June 2005.
[12] Park, S., "Link Characteristics Information for Mobile IP",
draft-daniel-mip-link-characteristic-02 (work in progress),
June 2005.
[13] Cui, Y., "Handover Control Function Based Handover for Mobile
IPv6", draft-cui-mobopts-hcf-wlan-00 (work in progress),
July 2005.
[2] Liebsch, M., "Candidate Access Router Discovery",
draft-ietf-seamoby-card-protocol-08 (work in progress),
September 2004.
[3] Kempf, J., "Instructions for Seamoby Experimental Protocol IANA
Allocations", draft-ietf-seamoby-iana-02 (work in progress),
June 2004.
[4] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[5] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier,
Melia, et al. Expires January 18, 2006 [Page 26]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
"Hierarchical MIPv6 mobility management (HMIPv6)",
draft-ietf-mobileip-hmipv6-06 (work in progress), July 2002.
[6] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-03 (work in progress),
October 2004.
[7] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for
Policy-based Admission Control", RFC 2753, January 2000.
[8] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
Sastry, "The COPS (Common Open Policy Service) Protocol",
RFC 2748, January 2000.
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Authors' Addresses
Telemaco Melia
NEC Europe Network Laboratories
Kufuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511 42
Email: telemaco.melia@netlab.nec.de
Rui L.A. Aguiar
Instituto de Telecomunicacoes Universidade de Aveiro
Aveiro 3810
Portugal
Phone: +351 234 377900
Email: ruilaa@det.ua.pt
Nuno Senica
Instituto de Telecomunicacoes Universidade de Aveiro
Aveiro 3810
Portugal
Phone: +351 234 377900
Email: njs@av.it.pt
Melia, et al. Expires January 18, 2006 [Page 27]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
Appendix A. Mobility Extensions to COPS
Here are described the extensions proposed to handle the mobility
options.
Common Header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Op Code | Client-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 1
Flags: 0x01 (HO Request, MTIHO Decision, HO Report)
0x00 (NIHO Decision)
Op. Code: 1 (HO Request)
2 (HO Decision)
3 (HO Report)
Client-type: To be defined
Message Length: computed internally
Client Handle
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (octets) | C-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cops Handler |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Num: 1
C-Type: 1
Cops Handler:
Context
Melia, et al. Expires January 18, 2006 [Page 28]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (octets) | C-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R-Type | M-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Num: 2
C-Type: 1
R-Type: 0x01 Incoming Message / Admission Control
M-Type: 0x01 Mobile Terminal Initated Handover
0x02 Network Initiated Handover
Decision: Flags
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (octets) | C-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command-Code | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Num: 6
C-Type: 1
Command-Code:
0 No decision
1 Request Accepted
2 Request Denied
Flags: 0
Report-Type
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (octets) | C-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Type | //////////////////// |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Melia, et al. Expires January 18, 2006 [Page 29]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
C-Num: 12
C-Type: 1
Report-Type:
1 Success
2 Failure
ClientSI Data -- ClientSI Message Header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (octets) | C-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Num: 9
C-Type: 1
Fast HO ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (octets) | D-Num | D-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HOSessionID | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address Prefix Length | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Melia, et al. Expires January 18, 2006 [Page 30]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
D-Num: 9
D-Type: 1
HOSessionID: Session Identifier
Priority: Handover Priority
Home Address: Home Address
Home Address: Prefix Length: Home Address IPv6 Prefix Length
Prefix Length: IPv6 prefix length
IPv6 Address: MT Care of Address
Fast HO Candidate AR Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (octets) | D-Num | D-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AP Link Layer Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ AR Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AR Prefix Length | MT CoA Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MT CoA +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D-Num: 10
D-Type: 1
AP Link Layer Address: new AP Link Layer Address
AR Prefix Length: IPv6 prefix length
AR Address: new AR IPv6 Address
MT CoA Prefix Length: IPv6 prefix length
MT CoA: new MT Care of Address
Melia, et al. Expires January 18, 2006 [Page 31]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
Fast HO Status Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (octets) | D-Num | D-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HOSessionID | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D-Num: 11
D-Type: 1 (Handover Decision)
2 (Handover Status Decision)
HOSessionID: Session Identifier
Status: 0x00 (Handover Decision) Handover not performed
0x01 (Handover Decision) Handover performed
0x02 (Handover Status Decision) Handover Timed out
0x03 (Handover Status Decision) Handover performed
Fast HO Accepted AR Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (octets) | D-Num | D-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ///////////////// | AR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D-Num: 12
D-Type: 1
AR: 0, 1 or 2 corresponding to the 1st, 2nd or 3rd match
Melia, et al. Expires January 18, 2006 [Page 32]
Internet-Draft Network Initiated Handover in FMIPv6 July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Melia, et al. Expires January 18, 2006 [Page 33]
