Sounds good.
>From: "Bari, Farooq" <farooq.bari cingular.com>
>To: "Bernard Aboba" <bernard_abobahotmail.com>,<eapfrascone.com>
>Subject: RE: [eap] Proposed Resolution to Issue 377
(NetSel NITs) (Section
>4)
>Date: Fri, 2 Mar 2007 11:27:24 -0800
>
>Hi Bernard,
>
>One clarification - the scope of network discovery is
not just for
>mobile users but also for nomadic users where network
discovery happens
>just for initial attachment and not for handoffs.
Latency in those cases
>of initial attach will not be an issue.
>
>Suggest chnaging proposed text
>
>As a result, we believe that use of EAP as described in
[RFC4284] is
>not a sound long-term approach for solution of the realm
discovery
>problem. Instead, we believe it is more appropriate for
this
>functionality to be handled within the link layer, so
that the
>information can be available early in the handoff
process.
>
>to
>
>As a result, we believe that use of EAP as described in
[RFC4284] is
>not a sound long-term approach for solution of the
realm discovery
>problem for mobile users where the information is needed
for handoff
>purposes. Instead, we believe it is more appropriate
for this
>functionality to be handled within the link layer, so
that the
>information can be available early in the handoff
process.
>
>BR,
>
>Farooq Bari
>farooq.bariatt.com
>+1 425 580 5526
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_abobahotmail.com]
> > Sent: Thursday, March 01, 2007 9:38 PM
> > To: eapfrascone.com
> > Subject: Re: [eap] Proposed Resolution to Issue
377 (NetSel NITs)
>(Section 4)
> >
> > I am enclosing a proposed cleanup of Section 4 to
address grammar and
> > readability issues.
> >
> > Recommended rewrite:
> >
> > 4. Conclusions
> >
> > This document describes the network selection
and discovery
>problem.
> > In the opinion of the authors, the major
findings are as follows:
> >
> > o There is a need for additional work on
access network discovery,
> > identifier
> > selection, AAA routing, and payload
routing.
> >
> > o Credential selection and AAA routing are
aspects of the same
>problem,
> > namely identity selection.
> >
> > o When considering selection among a large
number of potential
> > access networks and points of attachment, the
issues described in
> > the document become much harder to solve, in
an automated way,
> > particularly if there are constraints on
handoff latency.
> >
> > o The proliferation of network discovery
technologies within
> > IEEE 802, IETF, and 3GPP has the potential
to become a
> > significant problem going forward. Without
a unified approach,
> > multiple non-interoperable solutions may be
deployed, resulting
>in
> > fragmentation.
> >
> > o New link layer designs should include the
efficient distribution
> > of network and realm information as a
design requirement.
> >
> > o It may not be possible to solve all aspects
of the problem for
> > legacy NAS devices on existing link layers.
Therefore a phased
> > approach may be more realistic. For
example, a partial solution
> > could be made available for existing link
layers, with a more
> > complete solution requiring support for
extensions.
> >
> > With respec to specific mechanisms for access
> > network discovery and selection:
> >
> > o Studies such as [MACScale] and [Velayos],
demonstrate that the
>IEEE
> > 802.11 Beacon/Probe Response mechanism has
substantial scaling
> > issues, and as a result a single physical
access point is in
> > practice limited to less than a dozen
virtual APs on each
>channel
> > with IEEE 802.11b.
> >
> > The situation is improved substantially with
successors such as
> > IEEE 802.11a which enable additional
channels, thus potentially
> > increasing the number of potential virtual
APs.
> >
> > However, even with these enhancements it is
not feasible to
>advertise
> > more than 50 different networks, and
probably less in most
> > circumstances.
> >
> > As a result, there appears to be a need to
enhance the
>scalability of
> > IEEE 802.11 network advertisements.
> >
> > o Work is underway in IEEE 802.1, IEEE 802.21
and the IEEE
> > 802.11u to provide enhanced discovery
functionality. Similarly,
> > IEEE 802.1af has discussed addition of
network functionality to
> > IEEE 802.1X. However, neither IEEE 802.1ab
nor IEEE 802.1af is
> > likely to support fragmentation of
advertisement frames, so that
> > the amount of data that can be transported
will be limited.
> >
> > o While IEEE 802.11k provides support for the
Neighbor Report,
> > this only provides for gathering of
information on neighboring
> > 802.11 APs, not points of attachment
supporting other link
>layers.
> > Solution to this problem would appear to
require coordination
> > across IEEE 802 as well as between standards
bodies.
> >
> > o Given that EAP does not support
fragmentation of EAP-Request/
> > Identity packets, the volume of "realm
hints" that can be fit
>with
> > these packets is limited. In addition,
within IEEE 802.11,
> > EAP packets can only be exchanged within
State 3 (associated
> > and authenticated). As a result, use of EAP
for realm discovery
> > may result in significant delays. In
addition, the ability of
>EAP to
> > carry Quality of Service information
> > [I-D.groeting-eap-netselection-results]
> > appears limited. As a result, we believe
that use of EAP as
>described
> > in
> > [RFC4284] is not a sound long-term approach
for solution of
> > the realm discovery problem. Instead, we
believe it is more
> > appropriate
> > for this functionality to be handled within
the link layer, so
>that
> > the
> > information can be available early in the
handoff process.
> >
> > o Where link layer approaches are not
available, higher layer
>approaches
> > can be considered. A limitation of higher
layer solutions is
>that
> > they
> > can only optimize the movement of already
connected hosts, but
> > cannot address scenarios where network
discovery is required for
> > successful attachment.
> >
> > Higher layer alternatives worth considering
include the SEAMOBY
>CARD
> > protocol [RFC4066], which enables
advertisement of network
>device
> > capabilities over IP and Device Discovery
Protocol (DDP)
> > [I-D.marques-ddp], which provides
functionality equivalent to
> > IEEE 802.1ab using ASN.1 encoded
advertisements sent to a
> > link-local scope multicast address.
> >
> >
> >
____________________________________________________________
_____
> > To unsubscribe or modify your subscription
options, please visit:
> > http:/
/lists.frascone.com/mailman/listinfo/eap
> >
> > Arhives: http://lists.
frascone.com/pipermail/eap
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
