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

From: [email-masked]
Date: Thu, 12 Jul 2001 11:29:31 +0300

Hi James,

> I think there may be some benefits to linking CT with the handover
> messaging. 

I agree with your point, so I think we should allow (not require)
context transfer to be linked to some messaging.  

However, this opens a big can of worms.  

If CT is linked with other protocols, then is the job to define
possible parameters & provide a framework on how it is used?
Then, it would be Mobile IP's job (for example) to use the 
parameters.  Or do we want to specify a protocol?  Or do we
specify a protocol seperately from the framework and seperately
from the parameter types.  The parameter types could be re-used by 
other protocols (such as MIP).  If MIP is not available, then
the protocol could be used.  

This I am not sure about, and I'd be happy to see what others 
think.

John

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 12 Jul 2001 05:20:09 -0700

Yes, it would be possible for CT to define the state blob framing,
how it is encoded, identified, etc. The other mobility management protocols
could simply include the CT framed blobs within their protocol.

The issue, though, is that each mobility management protocol has different
characteristics, and in some circumstances it may be difficult to wedge the
CT blobs within it. An example is MIP. As you probably know, Mobile IPv4
has a max length of 255 octets for any extension data added to the protocol.
This would require fragmentation of the blobs, which gets even more complex.

Another mobility management protocol may use ASN.1, and they may not like
to add a different data encoding scheme (the one CTP uses), and just decide
to mimic CTP using their own encoding scheme.

So, in order for CTP to be universally used, I think it needs to exist on
its own.

My 2 cents,

PatC