Subject: [seamoby] Issue 1: Change access network terminology

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 16:58:11 -0700

Gary,

My personal preference is to keep using AR. I understand that AR is commonly
used in the wired space, but I believe that many folks make wireless to be
much more complicated than it is really necessary (can you say 3G?). So, 
by using AR, I believe that our message to the community is that this is really
nothing more than a router with a few extra features.

Thanks,

PatC

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Jun 2001 17:13:57 -0700

If we do this (which would be find for me, regardless of what my last 
post said :), make sure we define it to address Phil's requests.  I 
think if we were to specify that an AR, in our case, is not neccessarily 
a fixed, wired device, that it can, infact, be an MN itself, that should 
do the trick.

Whatever we call it, it should be defined.

-Mark

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 17:05:12 -0700

> Whatever we call it, it should be defined.

yes, you posts crossed each other :)

Well, if a CT peer can be an MN, then the use of AR is clearly innapropriate.
AR is an access router, and this is typically where I see CT being used, but
I understand that there are others, such as Phil, that see CT as having many
other uses.

Perhaps we should first have someone open an issue on whether an MN can in fact
be a CT peer, and the result of that issue would dictate the future of this one.

PatC

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Jun 2001 09:19:48 -0700

I guess my question is, does it matter if a Forwarding Node (as Gary has 
defined them) is also a Mobile Node?  What effect does it have on our 
design/requirement/problem statement?

I think the idea is that, for the sake of a particular CTP session, a 
node is either an MN or an FN.  If it's an FN for this CTP session, it 
may be an MN for another session, but those two sessions are independant 
of each other and should be viewed as such.

-Mark

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 20 Jun 2001 10:03:02 -0700

> design/requirement/problem statement?

The decision should be based on performance.  As a simple example,
imagine that the access routers are separated by very slow media,
and that the mobile node has a 55 Mb/sec wireless link to its local
access router.  Then, context transfer of header compression is
unnecessary.  If we postulate that the 55 Mb/sec is the _slowest_
link between the mobile node and the AAA in the visited domain,
then even transfering security associations is questionable.

On the other hand, I am much in favor of focusing the context
transfer discussion on a solvable problem.  From previous days'
discussion, it seems logical that the context transfer protocol
can be invoked in more than one way (layer-2 trigger, layer-3
protocol, ...) and it SHOULD be controlled in a way that depends
upon characteristics of the local access router, but as well on
the application needs of the mobile node.

Related to the question of what initiates the context transfer,
the transfer request itself has to include some authentication
data generated from a security association with the mobile node.
The credentials for authorizing or finalizing the context transfer
are to be provided by the mobile node.  The authentication data
could be checked by the previous access router in the case of
reactive context transfer, or they could be checked by the new
access router against something provided by the previous access
router, in the case of predictive handover.

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 20 Jun 2001 12:05:51 -0700

Perhaps I am missing something.. Aren't we concerned about the "entity" which offers
different features (QoS, HC,..) ?  I guess we went with AR because that's the entity
that typically offers the features.

Regards,

-Rajeev