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

From: "Gary Kenward" <[email-masked]>
Date: Wed, 20 Jun 2001 14:18:34 -0400

Phil:

  Interesting thoughts. I just one to be clear that the model you
have described was never the model I was thinking of. For me,
CT happens between "like" nodes. FN was simply a generic term
to described two arbitrary nodes in a network that need to exchange 
context. This approach works (I believe) for the problem statement,
it *may* work for the requirements, but something different will
likely be required when we look at the design.

  Consider that one of the goals (I think), was to develop a CT
solution that works in general, and is not specific to a particular
network solution, topology or wireless technology. As much as this
goal was discussed and agreed upon (at least, in my recollection), 
everyone still has an image in their mind as to what the network 
really looks like. So, for some, CT is happening between
GGSNs/SGSNs/PDSNs/RNCs, 
for others it is happening between 802.11 access points (although these
are L2), for others between hosts/subscriber devices, for others, between
MRs. 

  In the general situation, a CT between two "like" nodes is a nice
abstract concept. Where we seem to get into trouble is when we try
to bound the problem space - different networks have different requirements.

  I don't believe it does anyone any good to force the restrictions of
one network solution on another network solution through the bias of 
an L3 protocol. It is also risky to develop "swiss army knife" protocols
to meet all needs. On the other hand, I hope that we can avoid different
ct solutions for different networks.

  So how do we move forward? If we really knew the differences between the 
requirements for different networks, we might be better positioned to
identify
which differences really mattered and which ones could be generalized.
However,
this implies a need to develop (at least) two subsets of requirements -
wireless
access versus all-wireless. As an example, I can imagine a scenario where
two
MRs need to exchange context because one or both of the MRs have move, even
though the subscriber device hasn't; what does this imply about triggers,
AA,
etc.? Certainly many of the assumptions that one could make about an access 
network would seem to be suspect in this case.

Cheers,
Gary 

> -----Original Message-----
> From: Phillip Neumiller [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 1:35 PM
> To: 'Mark Smith'; [email-masked]
> Subject: RE: [seamoby] Issue 1: Change access network terminology
> 
> 
> 
> 
> > -----Original Message-----
> > From: Mark Smith [mailto:[email-masked]]
> > Sent: Wednesday, June 20, 2001 12:20 PM
> > To: [email-masked]
> > Subject: Re: [seamoby] Issue 1: Change access network terminology
> > 
> > 
> > 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
> 
> Hi Mark,
> 
> Well, not exactly.  It could really be both at once, in that the
> choice in which it makes to route its own MN-like traffic is the
> same choice made for its routed traffic.  Forwarding is not a
> strong enough term for me since almost any edge device, even those
> running Windoze 2000, can be forwarding nodes.  Its quite different
> if you are actually a full blown mobile router.  Then again, the
> choice for its own traffic could be completely different from the
> choices made for its routed traffic.  The MR is keeping up multiple 
> simultaneous link layers that it routes over.  It adds and drops
> these link layers frequently.  For this reason, CTP must be sent
> the MINIMUM number of times necessary, and splitting them into
> orthogonal causes like you suggest would probably be a bad idea.
> 
> One thing I am worrying about right now is path context transitivity.
> I am not completely sure I understand the implications for it yet
> myself, but allow me to try to explain it.  Since we have mobile nodes
> that are full blow SeaMoby ARs in many respects, CT may need to be
> daisy chained along the route until a fixed AR is hit.  At this
> point fixed network QoS and aggragation take over.  Its like the
> MANET has to compensate QoS and CT-wise, until the traffic hits a 
> "real" AR.  So what I am worrying about a lot is if CT has to be
> passed down the whole router chain end-to-end to work properly in
> mobile ad hoc networks.  I don't have the answer yet.
> 
> Thanks,
> 
> Phil
>

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 21 Jun 2001 06:21:48 -0700

ok, seeing how this discussion is currently going, I would favor using
ARs in the spec. If someone wants to re-use CT for other uses (e.g.
transfer context between mobile nodes and foobars), then they are free
to use the protocol. I really don't see why the possibility that a
protocol could be used for one thing or another should affect terminology
used in the requirements spec.

(btw, if an AR is mobile, it's still in AR in my mind, but witha special
mobile feature).

PatC