Subject: RE: [seamoby] Some proposed changes to the requirements draft.

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 13 Nov 2001 18:14:12 -0600

Hi,

We agreed long time ago and mentioned several times so far,
 context transfer is about transfer of the context (great sentence...),
 Not about storage or dump of context.
Where is it stored or dumped, do you have security for the storage,
or redundancy of storage or any other issues, is not part of scope.

Now going even further and making the storage hierarchical or localized
or globalized would even more....

Why are we reopening these issues?

Madjid

-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Monday, November 12, 2001 1:15 PM
To: 'James Kempf'; Shahrier, Sharif M.; [email-masked]
Cc: Shahrier, Sharif M.
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Hello James,

4.18 "The context transfer protocol MUST support both centralized and
distributed location of context information."

This requirement should be there so that there can be a "local" context
database (LCD)  within each AR. The LCD keeps a log of the context
parameters of every session that is currently active for the MN. 

In addition, there should be a "central"  context database (CCD). The CCD
keeps a log of all parameters that the MN is likely ever to need, whether or
not they are currently used.

Thus, LCD is a local cache memory and the CCD is a secondary storage memory.
New data in the LCD may replace that in the CCD using a write-through cache
coherency policy, whenever it needs to be updated.  When a new session
becomes active, the appropriate parameters may be read from the CCD to
replace the "unused" entries in the LCD.

The LCD is local to its AR, but the CCD is centralized and may be shared by
all the ARs.

This 2-level cache-main memory hierarchy will help reduce the size of the
LCD, and the CCD will help the context transfer itself, since it is
accessable by all the ARs.

jak> I don't understand this. What is this supposed to mean?

5.6.1 "The context transfer protocol MUST include methods for
interworking
with any IETF IP handover solutions".

5.6.2 "The context transfer solution MAY include methods for
interworking
with non-IETF handover solutions".
contexts or sub-divisions thereof".

jak> These two requirements assume that there will be only one context
transfer protocol for all application areas. I tend to believe that
there will be a set of protocols, some of which are tied directly to the
handover protocol, for better integration of those areas where timing
requirements are tightly tied to handover.

Note, Iuse the word "interworking" and not "independance". I feel that it is
better come up with a single context transfer solution that meets all the
"worst-case" handover scanarios, because otherwise we may end up
standardizing many  different context transfer protocols; each to meet a
specific handover specification, possibly leading to interworking problems,
amongst other things. 

As far as the scope of the problem SEAMOBY assigned to us, I believe, should
be to come up with a single context transfer protocol.

Did you have any comments to my other requirements?

-Sharif

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 13 Nov 2001 20:07:12 -0800

> Why are we reopening these issues?

We are not. Sharif brought up the issue, and we are simply informing
him that we have WG concensus, and will not start over from scratch.

PatC