eap Mailing List: NITs on Network Selection -08

[Bernard_Aboba (Bernard_Aboba]

On reading through the document again, I found a few NITs:

 

Some NITs:

 

Section 2.1

 

Change:

 

"  The Global System for Mobile Communications (GSM) specifications also
   provide for discovery of points of attachment, as does the Candidate
   Access Router Discovery (CARD) [RFC4066] protocol developed by the
   IETF SEAMOBY Working Group (WG).  Along with discovery of points of
   attachment, capability of access networks are also typically
   discovered.  These may include:"

 

To:

"  The Global System for Mobile Communications (GSM) specifications also
   provide for discovery of points of attachment, as does the Candidate
   Access Router Discovery (CARD) [RFC4066] protocol developed by the
   IETF SEAMOBY Working Group (WG). 

 

   Along with discovery of points of attachment, capability of access
   networks are also typically discovered.  These may include:"

 

Move the following material from Section 2.1 to the end of section 3.4:

 

"  However, while such an approach may minimize the pre-configuration
   required for network access clients, the proliferation of "virtual
   APs" can result in high utilization of the wireless medium.  The
   802.11 Beacon is sent only at a rate within the basic rate set, which
   typically consists of the lowest supported rates, or perhaps only the
   lowest supported rate.  As a result, "virtual AP" mechanisms that
   require a separate Beacon for each "virtual AP" do not scale well.

 

   For example, with a Beacon interval of 100 Time Units (TUs) or 102.4
   ms (9.8 Beacons/second), twenty 802.11b "virtual APs" each announcing
   their own Beacon of 170 octets would result in a channel utilization
   of 37.9 percent.  The calculation can be verified as follows:

 

   1. A single 170 octet Beacon sent at 1 Mbps will utilize the channel
      for 1360us (1360 bits @1Mbps)

 

   2. Adding 144us for the Physical Layer Convergence Procedure (PLCP)
      long preamble (144 bits @1Mbps), 48us for the PLCP header (48 bits
      @1 Mbps), 10us for the Short Interframe Space (SIFS), 50us for the
      Distributed Interframe Space (DIFS), and 320us for the average
      minimum Contention Window without backoff (CWmin/2 * aSlotTime =
      32/2 * 20 us) implies that a single Beacon will utilize an 802.11b
      channel for 1932us;

 

   3. Multiply the channel time per Beacon by 196 Beacons/second, and we
      obtain a channel utilization of 378672us/second = 37.9 percent.

 

   In addition, since Beacon/Probe Response frames are sent by each AP
   over the wireless medium, stations can only discover APs within
   range, which implies substantial coverage overlap for roaming to
   occur without interruption.  Another issue with the Beacon and Probe
   Request/Response mechanism is that it is either insecure or its
   security can be assured only as part of authenticating to the network
   (e.g. verifying the advertised capabilities within the 4-way
   handshake).

 

   A number of enhancements have been proposed to the Beacon/Probe
   Response mechanism in order to improve scalability and performance in
   roaming scenarios.  These include allowing APs to announce
   capabilities of neighbor APs as well as their own [IEEE.802.11k].
   More scalable mechanisms for support of "virtual APs" within IEEE
   802.11 have also been proposed [IEEE.802.11v]; generally these
   proposals collapse multiple "virtual AP" advertisements into a single
   advertisement.

 

   Higher layer mechanisms can also be used to improve scalability,
   since by running over IP they can utilize facilities such as
   fragmentation which may not be available at the link layer.  For
   example, in IEEE 802.11, Beacon frames cannot use fragmentation
   because they are multicast frames."

 

Rewrite the first paragraphs of Section 3.4 as follows:

 

"  Given limitations on frame sizes and channel utilization, it is
   important that solutions scale less than linearly in terms of the
   number of networks and realms supported.  For example, solutions such
   as [RFC4284] increase the size of advertisements in proportion to the
   number of entries in the realm routing table.  This approach does not
   scale to support a large number of networks and realms.

 

   Similarly, approaches that utilize separate Beacons for each
   "virtual AP" introduce additional Beacons in proportion to the
   number of networks being advertised.  While such an approach
   may minimize the pre-configuration required for network access
   clients, the proliferation of "virtual APs" can result in
   high utilization of the wireless medium.  For example, the
   802.11 Beacon is sent only at a rate within the basic rate set, which
   typically consists of the lowest supported rates, or perhaps only the
   lowest supported rate.  As a result, "virtual AP" mechanisms that
   require a separate Beacon for each "virtual AP" do not scale well."