Here are comments on Section 3
3. Design Issues
The following factors should be taken into consideration
while
evaluating solutions for problem of network selection and
discovery:
3.1. AAA issues
Access network or realm selection may leverage or
interact with the
AAA infrastructure. The solution should therefore be
compatible with
all AAA protocols. AAA routing mechanisms should work
for requests,
responses, as well as server-initiated messages. The
solution should
not prevent the introduction of new AAA or access network
features,
such as AAA routing protocols or fast handoffs.
[BA] I'm not sure I understand how access network selection
can leverage
AAA infrastructure, since this needs to take place prior to
authentication.
Proposals such as RFC 4284 do interact with AAA
infrastructure for realm
selection, but this has drawbacks as noted in Appendix A.
In any case,
I think the issue here is universality and backward
compatibility, not
network selection or realm routing.
3.2. Backward Compatibility
The solution should allow interoperability with clients,
protocols,
access networks, AAA proxies, and AAA servers that have
not been
modified to support network discovery and selection. For
example, it
should not cause a problem with limited packet sizes of
current
protocols. Where new protocol mechanisms are required,
it should be
possible to deploy the solution without requiring changes
to the
largest base of installed devices -- network access
servers, wireless
access points, and clients.
[BA] I think we need to be clear exactly what we mean by
backward
compatibility. For example, do we mean that a client that
does not
support network selection can work with an access network
that
does? Or that AAA infrastructure components that support
network
selection can work with legacy infrastructure that doesn't?
As the
paragraph currently reads, it is a bit vague.
3.3. Efficiency Constraints
The solution should be efficient in network resource
utilization,
specially on bandwidth constrained sections of the
network (E.g.
wireless link). Mechanisms that could significantly
increase
communication of an unauthenticated device with more than
one points
of attachment during the selection process should be
avoided. For
many handheld devices, battery life is a significant
constraint.
Mechanisms that could significantly drain battery e.g. by
requiring
one or more radios in multimode devices to continuously
scan for
networks, should be avoided. In addition, the solution
should not
significantly impact network attachment time.
[BA] I think we are talking about several performance
metrics here:
network attachment time, channel utilization (not the same
thing as
bandwidth, in the case of discovery mechanisms), energy
usage. These
seem most applicable to the mobile node. Are there any
efficiency
metrics applicable to the AAA infrastructure?
3.4. Scalability
Depending upon deployment scenarios and business
agreements amongst
the network operators, the number of networks to be
advertised can
range from a few to a very large number. The solution
should
therefore be scalable so that it can handle from a small
to very
large number of networks without violating the efficiency
constraints
described in Section 3.3.
[BA] I am confused by the use of the term
"networks" here. Are we
talking about scaling of network advertisements here (e.g.
virtual
APs) or about scaling in terms of realms?
I think we should avoid using the term
"advertised" since this
implies a particular solution; maybe "provided in an
advertisement,
or in response to query" would be better. I think the
key
characteristic is that we want a solution that does not
increase
channel utilization or bandwidth consumption in proportion
to the
number of networks or realms that are supported.
3.5. Realm discovery and selection decision making
"Phone-book" based approaches such as RFC 3017
appear attractive due
to their ability to provide sufficient information for
automatic
selection decisions. However, there is no experience on
applying
such approaches to wireless access. The number of WLAN
access points
is significantly higher than the number of dial-in POPs;
the
distributed nature of the access network has created a
more
complicated business and roaming structure, and the
expected rate of
change in the information is high.
[BA] The statement about "no experience" is no
longer true -- the
largest public WLAN deployment in the US (T-Mobile)
maintains a
phone book listing all APs in their client. No scaling
issues
have been reported, as far as I know, even with support for
thousands
of locations. However, this is a homogeneous network.
Therefore
I think we need to focus the criticism more on the
difficulties
introduced by roaming. For example, even with a phone book,
it is
still necesssary for the client to determine if an AP is
within
range, so dynamic discovery is still required. Also, when
roaming is supported, it is typically not possible for the
phone book to remain both comprehensive and up to date.
As noted in [Priest04] and
[I-D.groeting-eap-netselection-results], a large fraction
of current
WLAN access points operate on the default SSID, which may
make the
use of the phone book approach difficult.
[BA] I'm not sure what the problem is, exactly. Are we
saying that
duplicate SSIDs make it difficult to determine which APs are
operated
by roaming partners? Typically the phone book is organized
by
link layer identifier (e.g. phone number, BSSID), so that
the SSID
is not needed to identify a candidate NAS.
Suggested rewrite:
3. Design Issues
The following factors should be taken into consideration
while
evaluating solutions for problem of network selection and
discovery:
3.1. AAA Routing
Solutions to the AAA routing issues discussed in Section
2.3 need
to apply to a wide range of AAA messages, and should not
restrict
the introduction of new AAA or access network
functionality. For
example, AAA routing mechanisms should work for access
requests
and responses as well as accounting requests and
responses and
server-initiated messages. Solutions should not restrict
the
development of new AAA attributes, access types, or
performance
optimizations (such as fast handoff support).
3.2. Backward Compatibility
Solutions need to maintain backward compatibility. In
particular:
* Selection-aware clients need to interoperate with
legacy NAS
devices and AAA servers.
* Selection-aware AAA infrastructure needs to
interoperate with
legacy clients and NAS devices.
For example, selection-aware clients should not transmit
packets larger
than legacy NAS devices or AAA servers can handle. Where
protocol
extensions are required, changes should be required to as
few
infrastructure elements as possible. For example,
extensions that
require upgrades to existing NAS devices will be more
difficult to
deploy than proposals that are incrementally deployable
based on
phased upgrades of clients or AAA servers.
3.3. Efficiency Constraints
Solutions should be efficient as measured by channel
utilization, bandwidth consumption, handoff delay, and
energy
utilization. Mechanisms that require depend on
multicast
frames need to be designed with care since multicast
frames
are often sent at the lowest supported rate and therefore
consume
considerable channel time as well as energy on the part
of
listening nodes. Depending on the deployment, it is
possible
for bandwidth to be constrained both on the link, as well
as
in the backend AAA infrastructure. As a result, chatty
mechanisms such as keepalives or periodic probe packets
are
to be avoided. Given the volume handled by AAA servers,
solutions should also be conscious of adding to the
load,
particularly in cases where this could enable denial of
service attacks. For example, it would be a bad idea
for
a NAS to attempt to obtain an updated realm routing
table
by periodically sending probe EAP-Response/Identity
packets
to the AAA infrastructure in order to obtain "realm
hints"
as described in [RFC4284]. Not only would this add
significant
load to the AAA infrastructure (particularly in cases
where
the AAA server was already overloaded, thereby dropping
packets resulting in retransmission by the NAS), but it
would also not provide the NAS with a complete realm
routing table, for reasons described in Section 2.3.
Battery consumption is a significant constraint for
handheld
devices. Therefore mechanisms which require significant
increases in packets transmitted, or the fraction of
time
during which the host needs to listen (such as proposals
that require continuous scanning), are to be
discouraged.
In addition, the solution should not significantly
impact
the time required to complete network attachment.
3.4. Scalability
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. Similarly, "virtual AP"
approaches
introduce additional Beacons in proportion to the number
of
networks being advertised. Neither approach scales to
support a large number of networks and realms.
3.5. Static Versus Dynamic Discovery
"Phone-book" based approaches such as [RFC3017]
can provide information
for automatic selection decisions. While this approach
has been
applied to wireless access, it typically can only be used
successfully
within a single operator or limited roaming partner
deployment. For
example,
were a "Phone-Book" approach to attempt to
incorporate information
from a large number of roaming partners, it could become
quite difficult to keep the information simultaneously
comprehensive
and up to date. As noted in [Priest04] and
[I-D.groeting-eap-netselection-results], a large fraction
of current
WLAN access points operate on the default SSID, which may
make it
difficult to distinguish roaming partner networks by
SSID.
In any case, in wireless networks dynamic discovery
is a practical requirement since a node needs to know
which APs
are within range before it can connect.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
