Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

From: [email-masked]
Date: Wed, 12 Mar 2003 15:03:48 -0500

Jim,
If you read the dycard draft carefully you would notice that dycard assumes that a list of authorized APs
 are available at each AR. Checks are made to compare L2 ids reported w.r.t authorized L2 ids.
The L2 ids put in the cache comes from other trusted ARs. Why can't we assume that they know
what L2 devices are connected to the ARs?   
We don't discuss how this authorized list is put there explicitly. 
This could be by any existing network management procedure.

 If Iam not wrong, in the DT draft, I  think some L2 mechanism is assumed to exist that lets
 the AR know about its APs and this is conveyed to the server. Can't the same 
L2 mechanism be used? 

Having said that no L2 mechanism is assumed in dycard. 
It is a learning procedure too. But if something can be assumed for this we can do the same.

Thanks,
Govind.
> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> Sent: Wednesday, March 12, 2003 1:31 PM
> To: Eunsoo Shim; [email-masked]
> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD
> 
> 
> The server will allow an AR to determine which APs are 
> authorized. The dycard
> draft has nothing about this. This is an important security 
> measure, though not
> directly related to exchanging the CAR information.
> 
>         jak
> 
> ----- Original Message -----
> From: "Eunsoo Shim" <[email-masked]>
> To: "James Kempf" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 12, 2003 1:00 PM
> Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD
> 
> 
> >
> >
> > > Why are these approaches mutually exclusive?
> > >
> > > One of the drawbacks of Dycard is that it needs a learning period.
> > Naturally,
> > > the ISP can hire somebody to walk around and seed the 
> cache, but that's
> > > expensive. A server could prime the cache in the router 
> with a collection
> > of
> > > AP/AR mappings that may not be geographically adjacent, 
> but over time the
> > ones
> > > that aren't would drop out. Thus, the ISP would not have 
> to go through the
> > > timeconsuming task of classifying whether they APs are 
> geographically
> > adjacent.
> > >
> > > After the server has been used to initially populate the 
> cache, any
> > changes
> > > would be propagated directly by CARD.
> > >
> >
> > [eunsoo] As Govind and Dirk pointed out, the first handoff 
> between two ARs
> > leads to populating the cache with an entry for the newly 
> discovered CAR in
> > Dycard.
> > If you claim that the server will be used only for initial 
> populating the
> > cache at ARs, please clarify difference from the DT draft. 
> The DT draft does
> > not say each AR will download a bunch of L2-L3 mapping 
> information from the
> > server in the beginning of its operation. It will download 
> one by one as MN
> > requests the mapping or reports a new BS L2 address.
> >
> > The only difference between Dycard and the server approach 
> in the learning
> > period is that MN may be able to do fast handoff for the 
> very first handoff
> > between two ARs in the server approach while MN will have 
> to do slow handoff
> > in Dycard. Well, if we are talking about ISP, I don't think 
> they just
> > install a box and start commercial services. They will go 
> through many
> > stages of network tests including roaming support. So most 
> likely initial
> > discoveries will be done during the process and thus they 
> would not feel any
> > concern for the impact of the learning period for 
> consumers. If we are
> > talking about more ad-hoc and casual network deployment, I 
> am not sure the
> > slow handoff for the very first handoff is such a big 
> concern, let say, for
> > corporate networks or campus networks. I don't think it justifies
> > introducing a sever.
> >
> > Also even if an ISP wants populating the cache by the 
> information from the
> > server, they cannot tell exactly which entry should be 
> inserted into a cache
> > unless they know exactly the radio map of the base 
> stations. Well, all this
> > work is to remove such requirement. Then what they do only 
> is just copying a
> > bunch of entries from the server to the cache as you 
> suggested. If really
> > they want to do such a thing, they can use many existing 
> tools. For example,
> > we can simply define MIB for CARD and they can use SNMP for 
> setting the
> > values for CARD. This should not affect the fundamental 
> structure of the
> > protocol. Actually it should be independent of the CARD 
> protocol. Thus it
> > should not be a part of the CARD protocol except MIB 
> definitions. Defining
> > MIB does not bring in any need of a server, of course.
> >
> > Eunsoo
> >
> >
> >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
> 
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 12:56:37 -0800

It's that assumption I am questioning.

For that to be made, there needs to be some reasonable idea of mechanism,
otherwise, the protocol is not deployable.

I'm suggesting that a server is one possible approach to providing the
mechanism.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 12:56:37 -0800

jak