RE: [802-ARCH] Forwarding Updates for Wireless Networks
Note also that the video could in some cases have very strict QoS
requirements, as for example live TV transmitted from digital ENG where the
MSS/QSTA would be in the portable camera. 4:2:2 SDTV/EDTV MPEG-2 is about
4-5 MBit/s and HDTV falls somewhere in the range of 20 MBit/s.
Today dedicated systems are used for these, but maybe someday it would be
possible using 802 wireless technologies. Hopefully .21 can help in this
development.
BR, Reijo Salminen
-----Original Message-----
From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org] On
Behalf Of Michael.G.Williams@NOKIA.COM
Sent: 16. joulukuuta 2004 21:45
To: STDS-802-21@listserv.ieee.org
Subject: FW: [802-ARCH] Forwarding Updates for Wireless Networks
Colleagues,
The thread below is of interest to our efforts. I encourage the .21
community to follow this discussion, understand the issues, and determine
how .21 can help the issues, given the cross-ESS 802.11 requirement.
Best Regards,
Michael Williams
IEEE 802.21 WG Vice Chair
-----Original Message-----
From: IEEE 802 Architecture [mailto:hdk-1023.dwkfdq@ATT.NET]On Behalf Of
ext Mike Moreton
Sent: Thursday, December 16, 2004 1:31 AM
To: STDS-802-ARCH@LISTSERV.IEEE.ORG
Subject: [802-ARCH] Forwarding Updates for Wireless Networks
All,
Many of you will have seen discussion of this topic on the 802.1 list. I
thought it best to slightly widen the audience as I would like to know
whether this is a topic that may be of interest to other wireless groups.
I've also reformulated it as a problem, rather than a solution.
802.11 has the characteristic that roaming to a new point of connection is a
normal part of operation, and should if possible be achieved without
disruption to the QoS provided to the attached device. One feature of this
is that frames in the core network destined for the attached device need to
be redirected to the new point of attachment.
If the core network is constructed from 802.1D bridges, this will not happen
until a frame is sent in the opposite direction that will update the bridge
forwarding tables. Unfortunately some applications such as video streaming
do not send frames in the opposite direction, and so could be subject to
serious disruption when roaming.
What is needed is a standard method for updating the bridge forwarding
tables when an attached device roams that will take effect within the sort
of timescales needed to maintain QoS (<30ms is one figure...).
Personally, I would say as a matter of principle we should not expect the
device to take responsibility for this. A properly designed core network
should be capable of updating its own forwarding tables without help from
external devices. This is especially important as 802.11 at least is
designed to be independent of core network design, and such independence is
a feature of good protocol design.
Mike.
IEEE 802 Architecture list info:
http://www.ieee802.org/1/email-pages/sjqnf904.html