Issue: Section 2.1 Assumptions
From: Bernard Aboba (bernard_abobahotmail.com)
Date: Thu, 24 May 2007 00:18:49 -0700 (PDT)
Issue: Section 2.1 Assumptions
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: May 23, 2007
Reference:
Document: NETSEL-07
Comment type: Editorial
Priority: S
Section: 2.1
Rationale/Explanation of issue:
In Section 2.1, there is a discusion of out-of-band and link layer 
advertisement mechanisms, followed by a discussion of advertisment
mechanism scalability.  The links between these topics could be
made more clear by a discussion of the underlying assumptions.
My suggestion is to change the initial paragraphs of Section 2.1 
to the following:
2.1.  Discovery of Points of Attachment
   Traditionally, discovery of points of attachment has been handled by
   out-of-band mechanisms or link or network layer advertisements.
   RFC 2194 [RFC2194] describes the pre-provisioning of dialup roaming
   clients, which typically included a list of potential phone numbers,
   updated by the provider(s) with which the client had a contractual
   relationship.  RFC 3017 [RFC3017] describes the IETF Proposed
   Standard for the Roaming Access eXtensible Markup Language (XML)
   Document Type Definition (DTD).  This covers not only the attributes
   of the Points of Presence (POPs) and Internet Service Providers
   (ISPs), but also hints on the appropriate NAI to be used with a
   particular POP.  The XML DTD supports dial-in and X.25 access,
   but has extensible address and media type fields.
   As access networks and the points of attachment have proliferated, 
   out-of-band pre-configuration has become increasingly difficult.
   For networks with many points of attachment, keeping a list of
   points of attachment complete and up to date can be difficult.
   As a result, wireless network access clients typically only
   attempt to pre-configure information relating to access networks,
   rather than individual points of attachment.
   In IEEE 802.11 Wireless Local Area Networks (WLAN), the Beacon and
   Probe Request/Response mechanism provides a way for Stations to
   discover Access Points (AP) and the capabilities of those APs.
   The IEEE 802.11 specification [IEEE.802.11-2003] provides
   support for both passive (Beacon) and active (Probe Request/Response)
   discovery mechanisms; [Fixingapsel] studied the effectiveness of
   these mechanisms.
 
   Among the Information Elements (IE) included within the Beacon
   and Probe Response is the Service Set Identifier (SSID), a non-unique
   identifier of the network to which an Access Point is attached.  The
   Beacon/Probe facility therefore enables network discovery, as well as
   the discovery of points of attachment and the capabilities of those
   points of attachment.
 
   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:
   o  Access network name (e.g.  IEEE 802.11 SSID)
   o  Lower layer security mechanism (e.g.  IEEE 802.11 WEP vs. WPA2)
   o  Quality of Service capabilities (e.g.  IEEE 802.11e support)
   o  Bearer capabilities (e.g. circuit switched, packet switched or
      both)
 
   Even though pre-configuration of access networks scales better
   than pre-configuration of points of attachment, where many
   access networks can be used to authenticate to a home realm,
   providing complete and up-to-date information on each
   access network can be challenging.
   In such a situation, network access client configuration can
   be minimized by providing information relating to
   each home realm, rather than each access network.  One way
   to enable this is for an access network to support "virtual
   Access Points" (Virtual APs), and for each point of attachment
   to support virtual APs corresponding to each reachable home realm.
   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 rate, or perhaps the
   lowest supported rate.  As a result, "virtual AP" mechanisms that
   require a separate Beacon for each "virtual AP" do not scale well.
 

 
  • (no other messages in thread)

Results generated by Tiger Technologies using MHonArc.