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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 25 Jun 2001 13:50:36 -0500

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 5:02 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Mark Smith'; [email-masked]
Subject: RE: [seamoby] Issue 1: Change access network terminology

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 12:38 PM
> To: 'Mark Smith'; [email-masked]
> Subject: RE: [seamoby] Issue 1: Change access network terminology
> 
> 
> 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? 

How is this issue different than the MN being mobile?  

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.

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?  

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,
how do you solve the security, authentication,... issues for all the
context, 
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 :)

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?

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.

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? 

MN>> how does doing partial CT make things easier. Besides nobody has
brought up multidevice CT when different context is going to different
devices, as far as I remember, so I guess I am missing something.

>   	2-How would you handle the associations in case you are using 
> 	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.

MN>> Finally, You won the million dollar question!!! that is what we have
been talking about all along.
 
> 	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. 

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.

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

-Kulwinder.

> 
> 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.
> > 
> > 
> >>-----Original Message-----
> >>From: Rajeev Koodli [mailto:[email-masked]]
> >>Sent: Wednesday, June 20, 2001 3:06 PM
> >>To: Mark Smith
> >>Cc: [email-masked]
> >>Subject: Re: [seamoby] Issue 1: Change access network terminology
> >>
> >>
> >>
> >>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:
> >>
> >>
> >>>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
> >>>
> >>>Pat Calhoun wrote:
> >>>
> >>>
> >>>>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.
> >>>>>
> >>>>>
> >>>>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: Pat Calhoun <[email-masked]>
Date: Mon, 25 Jun 2001 15:11:56 -0700

All,

Based on the discussions so far, I believe that consensus shows that we
can reject this issue, and leave the term AR in the document.

Thanks,

PatC