[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Deployment Review for Bandwidth Attributes Document
As part of the pre-work item review process, Bert Wijnen, our esteemed O&M
AD, has suggested that RADEXT WG determine the level of customer interest,
in order to avoid having the WG spend time developing specifications that
are unlikely to be deployed.
Since work on bandwidth limitation was originally requested by the
Wifi Alliance (WFA) which had developed VSAs for Bandwidth Limitation,
we requested feedback from 802.11 vendors on whether they had
implemented the existing WFA VSAs.
We also requested feedback from IEEE 802.3 switch vendors on
whether they would implement the bandwidth limitation
attributes described in the document.
Detailed responses are enclosed below.
The response from the IEEE 802.11 vendors indicates that the existing WFA
bandwidth limitation attributes have not been deployed, although some
vendors have deployed their own VSAs (which typically provide more
granular control).
The response form IEEE 802.3 switch vendors indicates that while there is
interest in Bandwidth Limitation, the proposed attributes do not provide
the desired degree of granularity.
-----------------------------------------------------------------------
IEEE 802 Review of Bandwidth Attributes Document
---------------------------------------------------------------------------------------
Feedback from IEEE 802.11 Vendors
---------------------------------------------------------------------------------------
Gerard Goubert (formerly of UNH, now with Funk Software)
We do not have any evidence of bandwidth limitation attributes being
deployed. I can only assume that as more and more voice gets deployed more
people (WISP ops) will have to use QoS and provision bandwidth via
some method. This one seems reasonable; though we would have further
input to this draft and possible improvements to offer.
I personally wonder how well it will work in practice (I hope it does), as
the RADIUS servers will send the bandwidth requirements, but it is up to
the NAS to enforce it. This sort of implies a MAC based filtering firewall
for each entry in the filtering database of the NAS, which some people have
started to do. (aruba has admission control and load balancing `things'
that seem to do this) This is pretty complex and can get expensive in terms
of CPU and memory on the NAS. And in the wireless case, if there is a
client filing up the airwaves on the access side, the NAS can choose to not
forward them, but cannot _make_ the client stop `polluting' the access
side. (there may be dis-assoc requests and PAUSE and other things that try
to limit the client, but who says the client will pay attention?)
We have seen usage of Filter-ID in Access-Accept messages, but this
has been primarily for security issues (session hijacking to redirect to
forced landing page) and VLAN assignment, but not (yet) for QoS reasons.
I am interested in this and will try to keep track of it and provide input
where I can.
-gerard
Funk Software, Inc.
222 Third Street
Cambridge, MA 02142
USA
---------------------------------------------------------------------------------------
Pat Calhoun, CTO of Cisco WNBU
Yes, our product does something similar, but the capabilities of the
draft would not be sufficient (read: expansive) enough for our needs.
---------------------------------------------------------------------------------------
Clint Chaplin, Symbol Technologies
We currently implement bandwidth limiting, usually using a UI and/or MIBs
to administer it. We would be very interested in using RADIUS attributes
to communicate the bandwidth policies on a per-client basis to the
APs/Wireless Switches during authentication.
Clint Chaplin
---------------------------------------------------------------------------------------
Feedback from IEEE 802.1 Participants
---------------------------------------------------------------------------------------
Norm Finn of Cisco:
This might be interesting, both in the enterprise and in the metro
environment. I assume we're talking about limits per .1Q tag priority
value.
---------------------------------------------------------------------------------------
John Roese, CTO of Enterasys:
I am not sure about bandwidth limits per tag but in general retrieving a
bandwidth limit parameter as the result of the RADIUS transaction is of
interest. Today this is something we trigger quite often in Enterprise
environments using other mechanisms that relate to the AAA transaction
or are associated with attributes that do flow in that exchange.
As far as deployment levels today, while not the majority, at least in
my customer base it is something that is of high interest and deployed
by a sizable minority. The real sticking point is the ability of the
edge device to enforce such limits as there is a wide range of "rate
limiting" capability and granularity in edge products today so we would
need to be pretty broad in our approach to the values sent.
---------------------------------------------------------------------------------------
Paul Congdon of HP:
We deploy this capability today in our products using VSAs.
The current draft does not take into account traffic classes and is
purely a 'port based' bandwidth specification. However, the bandwidth
profile ID attribute could be used to define per-priority bandwidth
limits, but I think it would be reasonable to add traffic class to the
other attribute specifications without making this too complex. We have
been attempting to keep this as simple as possible, while still being
useful, and avoiding overlap with more general and complex QoS schemes.
---------------------------------------------------------------------------------------
Mick Seaman, formerly of Telseon (Ethernet ISP):
I think it would be essential to introduce traffic clases for this to have
any real positive impact, given the likely evolution of the .1 standards. I
also think, again without wishing to make this too complex, that this
should accomodate at least the cut down notions of "what bandwidth means"
(not to exceed x bits in y milliseconds, simplified by having y quantized
using a well known quantum) that a few of us having been discussing in the
context of Residential Etherenet/Residential Bridging to meet Home
Entertainment requirements on Etherent. That may be quite a step from the
goals of the original proponents, but I think it is reality if this is
going to have any staying power as an effort.
---------------------------------------------------------------------------------------
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>