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

From: "Gary Kenward" <[email-masked]>
Date: Wed, 20 Jun 2001 10:04:20 -0400

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2001 8:05 PM
> To: Mark Smith
> Cc: [email-masked]
> Subject: Re: [seamoby] Issue 1: Change access network terminology
> 
> 
> On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote:
> > 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.

I changed the nomenclature in the problem statement simply because even
though we had spent significant time working on clear definitions of "AP"
and "AR", there was still fervent debate over what an "AP" was, and what an 
"AR" was on the list.

The English language, particularly technical nomenclature is overburdened 
with the baggage of common usage and perceived meaning. So using a term 
that is "already recognized" is at best, guaranteed to produce mixed 
results. Case in point: Phil's recent concerns that AR's were not MR's and
that the requirements for all-wireless networks were being ignored.

In general, I have no preference either way, except that I would rather
avoid endless debates over what we define versus what the industry usage is.
I fear that simply publishing a definition will never be enough.

Gary

> 
> 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: Phillip Neumiller <[email-masked]>
Date: Wed, 20 Jun 2001 13:35:28 -0400

> From: Mark Smith [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 12:20 PM
> To: [email-masked]
> 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: "Hamid Syed" <[email-masked]>
Date: Thu, 21 Jun 2001 11:08:30 -0400

I agree. Lets keep the definition of AR as it is.

-Hamid

> From:	Pat Calhoun [SMTP:[email-masked]]
> Sent:	Thursday, June 21, 2001 9:22 AM
> To:	Kenward, Gary [WDLN2:AN10:EXCH]
> Cc:	'Phillip Neumiller'; 'Mark Smith'; [email-masked]
> 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
> 
> On Wed, Jun 20, 2001 at 02:18:34PM -0400, Gary Kenward wrote:
> > 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 
> > 
> > > 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
> > > 
> > > 
> > > 
> > >

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 21 Jun 2001 11:38:02 -0500

Mark, 

Well, it seems like we are going with ARs (which I like).

I don't know much about MRs and Manet, however I think AR has a more
precise scope than FN. Does AR imply that the router cannot be mobile?
i.e. MR cannot be a subset of AR?

I don't care too much about the physical or software definition of a node
as Kulwinder described (although, from the implementation point, it is
important :)
I care about the functionality. 
For the neutralness in this discussion I use my own favorite term CT peer
 instead of FN or AR.

Now, But To answer your question::
of course if the node offering CT is mobile, it makes
a lot of difference, 
 	1-how would you handle the security associations for 
	 pre-authentication between CT peers, if the CT peer is mobile? 
  	2-How would you handle the associations in case you are using 
	a transport protocol like SCTP? 
	3- The context also needs to be available at the CT peer prior 
	to the CT, so whatever network element that wants to make sure
	 CT peer has enough supply for the next CT, needs to track the
	CT peer to feed it. 

These are problems that do need a WHOLE lot of consideration when the 
CT peer is mobile.

Madjid

-----Original Message-----
From: Mark Smith [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 3:57 PM
To: [email-masked]
Subject: Re: [seamoby] Issue 1: Change access network terminology

Thank you, yes, that summarizes quite nicely what I was trying to say.

I'm not trying to say that this isn't a problem, I'm asking if anyone 
can see why it would be.  I can't, but I don't claim to be all knowing.  :)

-Mark

Kulwinder Atwal wrote:

> To expand on Mark's comment:
> 
> If we think of an AR or MN as a software thread/task/process with its own
AR
> context/MN context, instead of physical devices, then we should be able to
> keep the terms AR and MN seperate.
> 
> 1. A physical device may have just the AR task running, in which case it
is
> only an AR.
> 
> 2. A physical device may have just the MN task running, in which case it
is
> only an MN.
> 
> 3. A physical device may have a MN task and an AR task running in which
case
> it is both, but the functionality is modularized.
> 
> With the AR discovery protocol is possible to learn in a mobile
environment
> which mobile device nearby has an AR task running before attempting CT.
> 
> - Kulwinder.
> 
> 
>>From: Rajeev Koodli [mailto:[email-masked]]
>>Sent: Wednesday, June 20, 2001 3:06 PM
>>To: Mark Smith
>>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
>>
>>
>>Mark Smith wrote:
>>
>>
>>>defined them) is also a Mobile Node?  What effect does it 
>>>
>>have on our
>>
>>>I think the idea is that, for the sake of a particular CTP 
>>>
>>session, a
>>
>>>may be an MN for another session, but those two sessions 
>>>
>>are independant
>>
>>>Pat Calhoun wrote:
>>>>>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
>>
>>>>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: Kulwinder Atwal <[email-masked]>
Date: Thu, 21 Jun 2001 18:02:23 -0400

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 12:38 PM

How is this issue different than the MN being mobile?  

If the CT is aggreated by a device that appears to the network as an large
MN how does the network know that the IP stream is for one physical device,
or multiple physical devices?  

Why should it care as long as the 'root MN' has a valid security association
that establishes a _Chain_Of_Trust_ to the terminal MN?

If we can do partial Context transfer, how will the network actually know
that there are two physical devices instead of one as far as CT is
concerned?  If it does know do you not think this knowledge would best be
modularized and handled by a Mobile Router Protocol/AR Discovery Protocol? 

> 	a transport protocol like SCTP?

This is a Mobile Router Protocol issue.  This begs the need for a Mobile
Router Protocol that does route aggregation using IPv6 subnet prefixes.
 
> 	 CT peer has enough supply for the next CT, needs to track the

Enough supply of what? Bandwidth?  This is an AR Discovery issue.  If the AR
Discovery Protocol is based on triggers I don't see where the problem is.

-Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Mon, 25 Jun 2001 22:23:13 -0400

> Sent: Monday, June 25, 2001 2:51 PM
> To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Mark Smith';
> [email-masked]
> From: Kulwinder Atwal [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 5:02 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Mark Smith'; [email-masked]
> MN>> I don't even see the relevance. The discussion was about
> how much of different CT scenario do you have if the AR that is 
> doing CT for an MN is mobile AR or fixed.  Not about the MN.
> 
> MN>> we are not only talking about the IP streams, we are 
> talking about the
> contexts that relate all these mobiles. All of sudden you 
> have an AR that is
> supposed to do CT for a lot of MNs. How do you feed that AR with the
> contexts,

What is is this 'feeding' comment about?  
It is a networking term that I am not familiar with.  

You send the context from oldAR to newAR.

> how do you solve the security, authentication,... issues for all the
> context,

Is there a specific security issue in this comment?
 
> I am sure you admit that things get more completed when the 
> CT peers are
> mobile themselves (Analogy of IP and Mobile IP should be enough :)

I don't believe that you have specific issues here.  Broad generalizations
do not lead to specific solutions.

> MN>> You need to explain the difference between root MN and 
> terminal MN
> for me. If by root MN you mean AR, then establishing trust 
> that goes through
> a Mobile AR is more difficult.

In what way?  State specific issues.

> MN>> Supply of context for the CT peer !!!
> 

Specifically, why do you think it will be a problem to supply CT?

- Kulwinder.