eap Mailing List: RE: decisions from ietf-59: network selection

[Johnston, Dj (dj.johnston]

802.21 is in a requirements defining phase right now. ISP Discovery and
selection, vs. network discovery and selection is something we should
probably explore in .21. Whether we support it at all or its a byproduct
or its a first class concept in 802.21 is open to debate.

DJ



-----Original Message-----
From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On Behalf
Of Alper Yegin
Sent: Monday, March 15, 2004 2:48 AM
To: jari.arkko [at] piuha.net
Cc: eap [at] frascone.com
Subject: RE: [eap] decisions from ietf-59: network selection


Hi Jari,

> > Nevertheless, I'd recommend we don't drop the more appropriate
solution
> > from the radar, that is handling this issue on the EAP lower layer.
> 
> I agree. I do believe there is actually quite a lot of work in
progress
> in this area, and the matter will not be forgotten. The primary driver

> appears to be faster movements, which makes it necessary to have
better
> information distribution from the link layer to higher layers. When
such
> mechanisms are available, they can be used for various other purposes 
> as well.
> 
> Note that much of this work happens outside the IETF (e.g. 802.21) or 
> at least outside the EAP WG.

There is some relation here, but I cannot really say that 802.21
solution would also handle network (ISP) discovery and selection. This
might be a by-product of their solution, but I guess not a targeted
deliverable. 

I really don't know where directly related work is happening in IEEE
(.1ae??)

> > We should capture this somewhere (too late for section 3 of
rfc2284bis)
> and
> > provide guidance to new EAP lower layer designers.
> 
> Well, we do have the problem definition document... it has also been 
> sent as input to the IEEE efforts, for instance.

This is a good start, but if EAP WG has a recommendation to EAP
lower-layer designers, I think this requires another vehicle (unless we
expand the scope of the problem definition draft).

> It would probably be useful to think about these issues also in the 
> context of PANA. Or does PANA assume link layer under it provides 
> assistance? But at least some of the limited discovery & selection 
> functions in the current PANA base protocol are on the IP layer, so 
> maybe more extensive mechanisms would go there as well. Has there been

> any thoughts on where link layer hints fit in the PANA model, for 
> instance?

In PANA, the ISP discovery and selection is already provided by:
- PAA advertising list of ISPs
- PaC stating the chosen ISP

I'm not sure what else we need in the context of PANA.

Actually, this whole selection problem is two fold:
a- how to discover and select the network attachment point.
b- how to discover and select the ISP.

At any given point in time, there may be several distinct attachment
points which serve differing sets of ISPs available to my host. A host
should perform (a) and (b). 

(a) and (b) might be integrated in some designs. For example if 802.11
AP could advertise ISPs with the beacons. A STA could select the AP
based on its ultimate choice of ISP, and later indicate its ISP choice
to the AP in later stages (e.g., during EAP).

On the other hand, for example, in DSL networks (a) does not happen
dynamically. Network attachment is dictated by the physical connection
of your residence. (b) takes place over that pre-configured network
attachment.

The network discovery and selection facility in PANA enables (b),
assuming (a) has already taken place. This is because PANA runs after
the link-layer is connected. (a) requires link-layer facilities. Is that
what you mean by "link-layer assistance?"

Alper

> 
> --Jari


_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap