Subject: RE: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IP v6 Handover

From: [email-masked]
Date: Thu, 29 Mar 2001 18:57:28 -0600

Hello Erik,

> 
> 
> Rajeev,
> 
> > Also, I don't agree that context relocation is an overkill 
> when few IR
> > packets are needed. Consider a channel optimized for 
> sending 24 bytes of
> > voice payload and 4 bytes of header. Such CBR-like channels 
> are common in
> > cellular, I gather. Now, if you have to send a header 84 bytes long
> > (IPv6/UDP/RTP + Home Address option), that is 3 voice 
> packets. One approach
> > used to handle surges in bandwidth is to puncture bits in 
> payload. If you
> > were to do that, you need to effectively live with the drop 
> of 9 voice
> > packets (24 bytes of payload + 4 bytes of header) for 3 IR 
> headers! This is
> > user-perceived disruption _due to context initialization_. 
> 
> Are you aware of any quantitative analysis of the wire cost 
> and delay's
> involved in any proposed context relocation protocol?

I am not aware of proposals on context relocation protocol other than our
own! See 
http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt

I can certainly say few things about how I see the cost with the above draft
in mind. We allow using our context transfer options (IPv6 destination
options and ICMP options) with MIPv6 fast handover signaling to accomplish
"fast context transfers". 

1. The MN gets a trigger from old AR to undergo handover (e.g., proxy Router
Advertisement in fast-v6 draft). The MN sends a message back to old AR prior
to relinquishing its link with old AR. This message could be the fast
Binding Update. In this message, it includes a destination option containing
context relocation request. The old AR sends context to the new AR (e.g., in
the HI message). 
Note that until the fast BU goes out, the MN is using the context present at
old AR.

2. MN establishes a new link with new AR. Here is a L2 establishment delay.
MN does Neighbor Discovery, and starts using the new IP address according to
the fast handover specification. In our draft, the MN sends a Seamless
Handover Initiate (SHIN) message with destination option along with a normal
Binding Update as encapsulation. This SHIN option, which can also be sent
along with fast handover ND message to expedite the process, indicates to
the new AR that the MN wishes to make use of its context. When the new AR
processes the SHIN option, it relates it to the context transferred during
fast handover signaling.  

3. The application packet streams can use compression assuming that context
is present at the new AR. Here, some extensions are needed to take into
account the new IP address. 
There is a companion header compression-specific draft that explains how the
context transfer framework draft is used for effecting header compression
context relocation. See

http://search.ietf.org/internet-drafts/draft-koodli-seamoby-hc-relocate-00.t
xt

This is a somewhat simplified description of what we propose in the drafts.
In summary, the cost of our proposal, in terms of delay over the air
interface, is no worse than what you incur with fast handover signaling.
Indeed, some additional bits are sent to effect context transfers, e.g., the
MN requesting old AR (in the fast BU message) to send contexts. It is
possible that this explicit request can be assumed in network-controlled
handovers (for e.g.), thus avoiding those bits to be sent.  

Just for completeness, I should also mention that our drafts also specify
how context transfer works with reactive signaling, e.g., with basic MIPv6.

> I assume it doesn't come for free thus a comparison is needed between
> context initialization and conext relocation.

My explanation above is somewhat coarse. I agree that the comparison would
be good first step towards specifying context relocation. 

> (For instance, I think some of the context relocation protocols that 
> were discussed in seamoby involved a roundtrip between the mobile and 
> the old access router as well as between the mobile and the new 
> access router which would add significant delay before the context is
> relocated.)

I can't speak for other proposals (BTW, could you point me to those
proposals ?). As far as our proposal is concerned, I don't perceive
additional overheads you mention, since, we piggy-back on fast handover
signals. I would be happy to address any specific questions/comments you may
have. 

Regards,

-Rajeev

> 
>   Erik
> 
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>