Hi all,
2007-11-13 21:31 wrote Javier Cardona:
On 11/12/07, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
As far as I understand the specification, this
[different MAC address for the mesh interface] is not required.
That's true. The current text doesn't require this. However, it'll change.
Since we currently have no drivers supporting multi-MAC operation,
this is quite a severe limitation and the draft seems to allow MAP
operation with a single address, cf. the description of the SSID
element in 7.2.3.1 (Beacon frame format). ("Note: the SSID is a
required IE in beacon frames. To avoid having non-mesh STAs [...]")
Yeah. It's still a mess. The best thing is to consider an MAP as two
separate entities. One is an MP the other is an AP.
802.11-2007 describes the AP. There is nothing that 802.11s would add to
that. 802.11s solely defines the MP. As a maximum, 802.11s might give
some hints what to observe when an MP collocates with other entities
(AP, HC ...).
We had an extensive discussion about the beacon stuff in 802.11s. As the
group believes that the MP is a separate logic entity, it sends its own
beacon. A combined beacon is not foreseen. However, until now the latest
draft still has too much "legacy" (=non-mesh) and refers to BSS
operation etc. Therefore, there are these nasty tricks (SSID = wildcard
etc.). As soon as the group will require a separate MAC addresses when
an MP collocates with an AP, they'll also realize that a lot of existing
beacon IEs are unnecessary for the mesh. Then, there will also be no
need for tricks to prevent stations from trying to associate with an MP.
Therefore, I think that having a separate MAP type device would be
beneficial because that allows hostapd to generate a beacon including an
SSID, respond to probe requests and still be a mesh point on the same
interface.
During the discussion on the 802.11 e-mail reflector some people
described such a combined beacon. However, this construct is not
foreseen. It's really out of scope of 802.11s.
I know that there are existing products in the market that do similar
things. However, 802.11s really decouples its concept of the mesh and
the mesh devices from non-mesh devices. Thus, the mesh uses separate
beacons.
The only way hostapd would have to be aware of this is that it
needs to create a different type of interface and include the mesh
information in the beacon.
With separate beacon frames for the mesh and the BSS, the mesh may also
use a totally different beacon interval. Thus, 802.11s networks can
benefit from reduced overhead.
As there are already concerns about beacon bloat, I fear there will be
no chance for a combined beacon that carries information for both the
mesh and the BSS.
Do you see anything precluding such operation? Some more logic would
have to be provided to achieve the appropriate mesh broad/multicast vs.
AP broad/multicast behaviour, of course, as described elsewhere wrt.
mesh broad/multicast frames being broad/multicast to associated STAs.
The issue of mesh beacons is an open discussion at TGs right now (and
by now I mean this week, in the IEEE 802.11 plenary in Atlanta). It
looks like a different mac address will be needed for the mesh
interface if collocated with an AP. That will be necessary for
security and to avoid conflicts with legacy equipment. In that case,
the stack should generate the mesh beacons and hostapd generate the
infrastructure beacons.
That's right. I support Javier's point of view. Both networks are very
different. The BSS has a hierarchy of an AP and its associated stations.
A mesh will always be distributed. Thus, beacon frames serve different
purposes in both networks. I would propose to strictly decouple both
functionality and to keep them separated.
Anyway, I see no problem in renaming this IEEE80211_IF_TYPE_MESH_POINT
(even though I just heard of a proposal to rename Mesh Points as Mesh
Stations... )
Well ... That's another story :-)
Best regards,
Guido
--
Dipl.-Ing. Guido R. Hiertz | mailto:grh@xxxxxxxxxxxxxxxxxxxxxx
Chair of Communication Networks | http://www.comnets.rwth-aachen.de/~grh
RWTH Aachen University | Phone: +49 241 802 5829
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
