Subject: [mobile-ip] Analysis of fastv6 draft, part II

From: Rajeev Koodli <[email-masked]>
Date: Mon, 19 Mar 2001 19:38:52 -0800

(CST)
Received: from daebh01nok.americas.nokia.com (unverified) by 
davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id 
<[email-masked]> for 
<[email-masked]>;
 Fri, 16 Mar 2001 17:43:11 -0600
To: [email-masked]
Subject: Analysis of fastv6 draft, part II
Date: Fri, 16 Mar 2001 17:43:10 -0600

Hello folks,

here is my second part of the analysis. It deals with the delay
surrounding
Neighbor Advertisement message and receiving BAck before the MN is able
to
use its IP address. This delay, equal to at least one RTT, could be
significant in certain links. 

Regards,

-Rajeev

Improving "IP connectivity" latency subsequent to handover
-----------------------------------------------------------

Note that it takes an "RTT-air" delay before the MN can transmit
packets with a new IP address. The reason for this delay is due to the
following, as 
currently specified in the fast handover design team draft:

a> MN has to send an NA message, and 
b> MN has to wait until it receives packets from NAR confirming using
the IP
address, or
c> MN receives a suitable error message indicating to the MN to resort
to
address 
   configuration

It would be very desirable to have the MN send IP packets without having
to
wait for
packets arriving from NAR. We outline two ways of achieving this below.

i> Subsequent to establishing a new L2 with NAR, the MN sends IP packets
directly to
   NAR. However, the IP source address in these packets is at best
tentative. Thus, the
   MN maintains a new flag called TENTATIVE in its ND cache entry. This
flag
is set to 
   ON prior to sending any IP packets on the new L2 with NAR. This flag
is
set to OFF 
   upon receiving positive confirmation. When this flag is set to ERROR,
the
MN MUST 
   NOT send any packets using the new IP address. 

   When the ND module receives any IP packets when TENTATIVE is ON, it
encapsulates the 
   IP packet in a new ND message type called Neighbor Cache Validation
and
does normal 
   transmission. This message type, which is described below, must
include
the MN's new 
   tentative IP address and its link-layer address. When the receiver
receives this ND 
   packet, its ND module treats the new message type addressing the
scenarios described 
   earlier (and also repeated below). 

i.a> if there is already an entry belonging to another node, NAR
generates
an error
   message, and discards the packet. In the error message, the NAR may
indicate to
   the MN to use old CoA or to initiate address configuration procedure.
The
NAR MAY
   forward packets addressed to old CoA. Once it receives an error
message,
the MN 
   MUST NOT send any more IP packets using the new CoA. It MUST set the
TENTATIVE 
   flag to ERROR. 

i.b> NAR is proxying the address for the MN. In this case, the NAR
overrides
its 
   existing cache entry with the information supplied by the MN. The NAR
MAY
generate 
   a unicast NA to the MN confirming its IP address. Alternatively, it
may
simply 
   forward any queued packets as an indication to confirm the new
address.
The NAR then 
   removes the encapsulation and forwards the inner IP packet towards
destination IP 
   address specified in the inner IP packet. Once the MN receives
confirmation that its
   IP address is valid, it sets the TENTATIVE flag to OFF, and proceeds
to
behave like
   any other node. It MAY send a Neighbor Advertisement message to all
nodes
on-link
   to advertise its presence.

i.c> NAR is proxying the address for some other node. This scenario is
not
valid since
   the relevant node would not use Neighbor Cache Validation message. 

ii> Using link-layer triggers. The NAR would determine that the MN is
present on the
   link by using link-layer triggers and forward any packets. Depending
on
the 
   destination address present in these IP packets, the MN would
determine
what IP
   address to use. This solution, however, relies on the presence of IP
packets at 
   NAR in order to enable the MN to use a confirmed IP address. Indeed,
one
such 
   packet could be the BAck. However, there are two issues to consider
here.

   First, if there are no packets to be forwarded to the MN (e.g., the
BAck
packet 
   is lost and there are no other packets), then the trigger is not very
useful. 
   What is important is that the MN should be able to use its IP
connectivity as 
   soon as the link becomes enabled, whether or not there are packets
waiting for 
   it to be delivered at NAR. The second issue is that standardization
of
link 
   triggers is presumably dependent on each link layer technology. Even
if
this is
   less of an issue, the former problem persists.

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 19 Mar 2001 22:46:55 -0500

Hi Rajeev,

Could you please send me part I of this? I never got it...

Thanks
George

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 3:39 AM
To: [email-masked]
Subject: [mobile-ip] Analysis of fastv6 draft, part II

(CST)

Hello folks,

Regards,

-Rajeev