eap Mailing List: Re: Proposed Resolution to Issue 377 (NetSel NITs) (Section 4)

[Bernard Aboba (bernard_aboba]

Sounds good.


> From: "Bari, Farooq" <farooq.bari [at] cingular.com>
> To: "Bernard Aboba" <bernard_aboba [at] hotmail.com>,<eap [at] frascone.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.bari [at] att.com
> +1 425 580 5526
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com]
> > Sent: Thursday, March 01, 2007 9:38 PM
> > To: eap [at] frascone.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