Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- Phase CT

From: [email-masked]
Date: Fri, 13 Jul 2001 11:20:45 +0300

Hi Theo,

>   Your example is very similar to what we are proposing in 
> the proactive mobility draft
> 
> draft-pagtzis-mobileip-proactivev6-00.txt/.ps

I've printed this out - but it'll take some time
to digest all of this.

>     I have a slight reservation about the term used here 
> though. It sounds to me that it is not syncronisation that 
> is effected, since for that MN the new AR will received the 
> context superset once and that is it. There is no
> continuous streaming of context (even 'multiplexed' ) where 
> the MN needs to syncronize in the strict sense of syncronisation.
> 
> It simply enables connectivity with the proactive forwarding of the
> context; isn't that the case you refer to ?

Exactly - all I meant by the term was that context would be connected
or associated with a handoff.  Let's call it association id.

I think in the protocol design phase, we can work out the specific details.

In solution space, I would use a 32-bit integer that could be used in 
both CTP and the MIP handoff signaling messages.  The new AR can use
a hash of the association id and the IP address who sent it to save
the context, so that when a HO is completed, the new AR can easily
retrieve the context.

br,
John

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 13 Jul 2001 09:50:41 -0700

Hi John,

   Appreciated! If you go to

http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html

you should be able to also find the postscript version which gives all the
schematics to facilitate clearer understanding..

As for the association ID you are right. It is imperative that when you
exchange context information you want to avoid sending back and forth
addresses that are that long. It is best to associate the context with the
best possible factoring design with a unique identifier. This way you would
save so much more bandwidth but admittedly the AR would need to work a little
harder. That is the price of a trade of. We cannot have it all unless you try
to compress signaling (hifi).

This is why I associated the roaming context signaling with what I call in the
draft an SCoA identifier that avoids the sending back and forth of addresses
(next draft version will  optimize on that also)

Cheers

Theo