[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Deployment Review for Bandwidth Attributes Document



Yes, I agree.  

WME/802.11e (w/Call Admission Control - CAC) deployments in Enterprise
networks is now happening.  And, WME/802.11e enabled Public WLAN hotspot
deployments are next in order to provide WLAN users real-time services
w/ QoS over WLAN and also enabling end-2-end QoS.  The draft was
originally intended to allow the home network to indicate the Bandwidth
Authorization (BA) to the WLAN access network for a given user, and also
enable the access network to indicate the allocated bandwidth in the
accounting messages.  Later also profile ID was added. Based on the BA
information and the profile ID, the access network should be able to
decide whether it can accept an 80211e/ADDTS request from a user.

While use of DSCP/802.1 tags over WLAN link and their mappings to wired
segments are important, it is outside the scope of this document - IMHO.


Thanks,
Farid

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Sunday, September 18, 2005 8:52 AM
> To: Mick Seaman
> Cc: 'Bari, Farooq'; radiusext@ops.ietf.org; tony@jeffree.co.uk
> Subject: RE: Deployment Review for Bandwidth Attributes Document
> 
> 
> From a technical point of view,  the Bandwidth Attributes and 
> VLAN/Priority documents were chartered in RADEXT WG for the 
> purpose of 
> satisfying requests originating in the IEEE 802 community.  The BW 
> Attributes request came from WFA (marketing arm of IEEE 
> 802.11), and the 
> VLAN/Priority document came out of IEEE 802.1. 
> 
> While it is ok (good, in fact) if those documents satisfy other 
> constituencies as well, at the end of the day, these 
> documents MUST meet 
> the needs of the groups making the original request. 
> 
> 
> On Sat, 17 Sep 2005, Mick Seaman wrote:
> 
> > 
> > Farooq,
> > 
> > Given that a lot of bridges are deployed in environments 
> were keeping
> > management to a minimum is a practical necessity, and that 
> there are very
> > widespread deployments which use fairly well known values 
> what you say is
> > legalistically correct but can only give rise to conflict. 
> One of the future
> > items of working that is being proposed in 802.1 is the use 
> of Ethernet for
> > residential home entertainment applications including a 
> variety of music and
> > video applications. The notion that a home owner is going to make a
> > management decision abut his or her network and then manage a lot of
> > different equipment with different natural backgrounds will 
> kill ease of
> > use, or prevent equipment that departs far from usual practice being
> > successful. 
> > 
> > So my legalistic response here is that we are talking about 
> 802.1D/.1Q
> > priorities here, whose aim is to support Diffserv and does 
> provide a lot of
> > flexibility but also whose aim is to provide as much usual 
> guidance as
> > possible an advocate the default use of mappings that seem 
> to provide
> > maximal interoperability with minimum management. A lot of 
> effort has been
> > put into that so far, and the notion that all might be 
> discarded and revised
> > to a new set that requires further management because 
> "anything is possible"
> > is not something that should happen without examination.
> > 
> > Goals that are impossible to achieve fully  can still yield 
> substantial
> > benefit to many people if 80% achieved. There is no reason 
> to suppose that
> > in the absence of perfection we should advocate anarchy.
> > 
> > Mick
> > 
> > -----Original Message-----
> > From: Bari, Farooq [mailto:farooq.bari@cingular.com]
> > Sent: Saturday, September 17, 2005 8:49 AM
> > To: mick_seaman@ieee.org; Congdon, Paul T (ProCurve)
> > Cc: radiusext@ops.ietf.org; Bernard Aboba; tony@jeffree.co.uk
> > Subject: RE: Deployment Review for Bandwidth Attributes Document
> > 
> > Hi Mick,
> > 
> > I look forward to hearing from you. I do want to float my 
> understanding
> > of DSCP usage and understand if other folks disagree (although this
> > topic does not have much to do with radext). 
> > My understanding is that interpretation and usage of DSCP within a
> > network is whatever the owner of the network decides to 
> have i.e. it can
> > choose to ignore them, overwrite/remark them, use them to prioritize
> > traffic the way it decides etc. The importance of standard
> > interpretation/marking of these settings is typically at 
> the boundaries
> > of networks. However this standard interpretation is 
> dependent upon on
> > the SLAs that the networks have amongst themselves i.e. the
> > interpretation is not global but limited to SLA. SLAs 
> between networks
> > can vary significantly based on network technologies and the type of
> > traffic that they carry. Also I am not aware of any forum 
> in the world
> > that can standardize this for all the networks in the world. So if I
> > understood the comments correctly, although the goals seem 
> noble they
> > may be quite hard to get (if not impossible).....
> > 
> > BR,
> > 
> > Farooq Bari
> 
> --
> 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/>