[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Deployment Review for Bandwidth Attributes Document
Sounds to me like there is support, especially if we added a scheme to
support the 802 traffic classes. Avi and I have talked about a simple
and optional way to do this without crossing the complexity line. It
would be good to know if this would satisfy Pat's needs.
Paul
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Thursday, September 15, 2005 9:23 PM
> To: radiusext@ops.ietf.org
> Subject: 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/>
>
--
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/>