Subject: [eap] Issue: Section 2.1 Assumptions

From: Bernard Aboba <[email-masked]>
Date: Thu, 24 May 2007 00:18:47 -0700

Issue: Section 2.1 Assumptions
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
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.   

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap