Subject: [seamoby] CT requirements

From: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 14 Nov 2001 16:28:49 -0500

Everyone:

	There hasn't been any "consensus" against the requirements that I'm
indicating below. There had been a couple of comments, to which I responded,
but I did not get anything back.

I would like to point them out again, and if there is no real WG consensus
against them, I see no reason why they should not be in the CT requirements
draft.

5.5.2 A context update MUST preserve the integrity, and thus the meaning, of
the context at each receiving AR.

   The context at the AR actually supporting an MN's traffic will change
with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
supporting AR must be replicated at those ARs that have already
   received context for that MN.

   I don't see what the paragraph above has to do with data integrity, and
thus I recommend that it should be rewritten or removed altogether. Unless I
am wrong, I had thought that data integrity refers to the "correctness" of
data.

4.17 "The context transfer protocol MUST minimize the number of 
       signaling messages at the sending and receiving Access Routers".

Minimizing signaling messages have several benefits: (a) reduces load on the
Internet by signaling messages, (b) increases the bandwidth afforded to data
traffic, (c) improves the effective utilization of data traffic, (d)
improves reliability, (e) improves scalability.

I've seen one comment on this, but did not get a response after I replied.

Now, the centralized/local context storage caused some issues. Thus, I would
like to re-word it and hope that it would be more acceptable.

The context transfer protocol MUST support localized storage of context at
the ARs.

The context transfer protocol MAY also support a centralized storage of
context belonging to  the ARs in the sub-net.

I think that keeping a "back up" of context information in a central
directory will help will fault-tolerence, i.e. reliability, and it provides
consistency with some of the current implementations in wireless networks.
It also broadens the solution space ............

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

The IETF have several handover solutions, and unless the objective is to
come up with a different context transfer solution to fit a specific
handover protocol, it should make sense to include this requirement.

Personally, I think it is good practice to have a single CT solution and
design it for the worst-case.

	-Sharif.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 14 Nov 2001 15:11:27 -0800

With the exception of 5.6.1, I am opposed to the other requirements.

        jak