Subject: [seamoby] Some generic requirements

From: Rajeev Koodli <[email-masked]>
Date: Wed, 04 Apr 2001 18:31:43 -0700

Hello Hamid and CT folks,

Following the spirit of the discussion during the last conference call,
I have tried to outline a few requirements, some stemming from header
compression context relocation. Here they are,

1.  A context MUST have an inter-operable representation. In other
words,  each context (carried in a context transfer protocol) must be
able to, in a standard manner, indicate to the receiver what type of
context it is. Representing contexts using well-known objects (such as
IANA type numbers) should be considered to facilitate this
inter-operability.

2. Each context definition MUST NOT introduce a transfer protocol of its
own, in order to be useful. In other words, a context  should be
separable from the protocol used to carry it.

3. A context transfer protocol MUST have fast response time.
Specifically, for some applications (such as header compression), the
context needs to be present at the new access router almost as soon as
the link-layer handover is considered complete. In other words, an
application may start using the feature immediately after IP
connectivity is established assuming that the relevant context is
present. The absence of context in such scenarios may result in packet
loss and expensive re-initialization overheads.

4. A context transfer protocol MUST introduce minimal signaling
overhead. The overall number of messages, including those over the air
interface and the wireline links, must be kept small. And, the sizes of
those messages that are carried over an air interface must be kept small
as well.

Comments are welcome.

Regards,

-Rajeev