Addressing the Handover Latency

The ability to immediately send packets from a new subnet link depends on the

"IP connectivity" latency, which in turn depends on the movement detection latency and the new CoA configuration latency. Once a MN is IP-capable on the new subnet link, it can send a Binding Update to its Home Agent and one or more

correspondents. Once its correspondents successfully process the Binding Update, which typically involves the Return Routability Procedure, the MN can receive packets at the new CoA. So, the ability to receive packets from correspondents directly at

its new CoA depends on the Binding Update latency as well as the IP connectivity

latency.

The protocol enables a MN to quickly detect that is has moved to a new subnet by

providing the new access point and the associated subnet prefix information when the MN is still connected to its current subnet. For instance, a MN may discover

available access points using link-layer specific mechanisms and then request

subnet information corresponding to one or more of those discovered access

points. The MN may do this after performing router discovery. The MN may also do

this at any time while connected to its current router. The result of resolving an

identifier associated with an access point is a [AP-ID, AP-Info] tuple, which a MN can use in readily detecting movement : when attachment to an access point with AP-ID takes place, the MN knows the corresponding new router's co-ordinates including

its prefix, IP address and L2 address. The "Router Solicitation for Proxy

Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)" messages

are used for aiding movement detection.

Through the RtSolPr and PrRtAdv messages, the MN also formulates a prospective

new CoA (NCoA), when it is still present on the PAR's link. Hence, the latency due to new prefix discovery subsequent to handover is eliminated. Furthermore, this

prospective address can be used immediately after attaching to the new subnet

link when the MN has received a "Fast Binding Acknowledgement(FBack)" message prior to its movement. In the event it moves without receiving an FBack, the MN can still start using NCoA after announcing its attachment through a "Fast Neighbor

Advertisement (FNA)" message ; NAR responds to FNA in case the tentative

address is already in use. In this way, NCoA configuration latency is reduced. Under some limited conditions where the probability of address collision is considered

insignificant, it may be possible to use NCoA immediately after attaching to the new link. Even so, all implementations MUST support the mechanism specified in this

document to avoid potential address conflicts and SHOULD use them.

In order to reduce the Binding Update latency, the protocol specifies a tunnel

between the Previous CoA (PCoA) and NCoA. A MN sends a "Fast Binding Update" message to its Previous Access Router to establish this tunnel. When feasible, the MN SHOULD send FBU from PAR's link. Otherwise, it should send it immediately after detecting attachment to NAR. Subsequent sections describe the protocol

mechanics. In any case, the result is that PAR begins tunneling packets arriving for PCoA to NCoA. Such a tunnel remains active until the MN completes the Binding

Update with its correspondents. In the opposite direction, the MN SHOULD reverse tunnel packets to PAR, again until it completes Binding Update. And, PAR SHOULD

forward the inner packet in the tunnel to tis destination. Such a reverse tunnel

ensures that packets containing PCoA as source IP address are not dropped due to ingress filtering. Readers may observe that even though the MN is IP-capable on

the new link, it cannot use NCoA directly with its correspondents without the

correspondents first establishing a binding cache entry (for NCoA). Forwarding

support for PCoA is provided through a reverse tunnel between the MN and the

PAR.

Setting up a tunnel alone does not ensure that the MN receives packets as soon as attaching to a new subnet link, unless NAR can detect the MN's presence.

A neighbor discovery operation involving a neighbor's address resolution typically

results in considerable delay, sometimes lasting multiple seconds. For instance,

when arriving packets trigger NAR to send Neighbor Solicitation before the MN

attaches, subsequent re-transmissions of address resolution are seperated by a

default period of one second each. In order to circumvent this delay, a MN

announces its attachment through the FNA message that allows NAR to consider

MN to be reachable. If there is no existing entry, FNA allows NAR to create one.

If NAR already has an entry, FNA updates the entry while taking potential address

conflicits into consideration. Through tunnel establishment for PCoA and fast

advertisement, the protocol provides expedited forwarding of packets to the MN.

The protocol also provides the following important functionalities. The access

routers can exchange messages to confirm that a proposed NCoA is acceptable. 

For instance, when a MN sends FBU from PAR's link, FBack can be delivered after

NAR considers NCoA acceptable to use.  This is especially useful when addresses

are assigned by the access router.  The NAR can also rely on its trust relationship

with PAR before providing forwarding support for the MN. That is, it may create a

forwarding entry for NCoA subject to "approval" from PAR which it trusts.  Finally,

the access routers could transfer network-resident contexts, such as access

control, QoS, header compression, in conjunction with handover.  For all these

operations, the protocol provides "Handover Initiate (HI)" and "Handover

Acknowledge (HAck)'" messages.  Both of these messages MUST be supported

and SHOULD be used.  The access routers MUST have necessary security

association established by means outside the scope of this document.