| Issue: Section 2.1 Assumptions | <– Date –> <– Thread –> |
|
From: Bernard Aboba (bernard_aboba |
|
| 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.