[RPRWG] FW: Mick's comments on encapsulation bridging
FYI...for those who are not on the 802.1 reflector.
-Anoop
-----Original Message-----
From: Tony Jeffree [mailto:tony@xxxxxxxxxxxxx]
Sent: Monday, March 11, 2002 1:45 PM
To: stds-802-1@xxxxxxxx
Subject: Mick's comments on encapsulation bridging
The following was Mick's response to an 802.17 question about encapsulation
bridging.
Regards,
Tony
The essence of the statement in .1D is to facilitate bridging from MAC to
MAC, as well as the service immediately offered by that MAC. So it is
necessary, if encapsulation bridging were to be specified, to also specified
how a 802.3 to 802.thingy bridge can be built without requiring an 802.3 end
station to put extra addressing information in the frame. This exposes
"architectural" arguments in the .thingy MAC of the form "these additional
addressing fields are internal to the MAC and not exposed at the MAC Service
boundary".
The key really is that the .thingy MAC has got to be able to support the MAC
Internal Layer Service without additional information crossing that
boundary.
The issues to who has to do what if someone really wants to develop a wierd
MAC with encapsulation are summarized in 802.1D Clause 5.5 especially item
(d) - which rules out the obvious idea that you simply put in a lot of extra
discovery procedures to support the MILS at the point where the 802.thingy
MAC interoperates with the 802.3 MAC, by requiring that a MAC that supports
bridging actually support the detail of 802.1D in additional to anything
else the 802.thingy group comes up with, simultaneously on the same
802.thingy LAN - plus all end stations have to be able to talk together,
they can't be divided into a .1D subset and a .thingyBridge subset.
Operation of special procedures or some kind of interworking unit is not
ruled out, but per Exec agreement when 5.5 was put in place .1 has to be
able to affirm that the interworking really works - it is up to the .thingy
group to design it. All this is a defence against nominal behavior by a
.thingy group in support of such a resolution.
At 19:16 28/02/2002 -0800, Tom Alexander wrote:
>Tony,
>
>The present P802.17 draft (D0.1) does not include encapsulation bridging.
>However, encapsulation bridging within the context of P802.17 and
>802.1D compatibility remains a niggling open issue. My reading of Std
>802.1D seems to indicate that while encapsulation bridging does not
>appear to be specifically prohibited, it is nevertheless alien to the scope
>and architecture of a classical 802.1D bridge.
>
>In fact, there are interesting statements in Std 802.1D such as:
>
> "A Bridge is not directly addressed by communicating end
> stations, except
> as an end station for management purposes; frames transmitted
between
> end stations carry the MAC Address of the peer-end station in
their
> Destination Address field, not the MAC Address, if any, of the
> Bridge."
> (Clause 6.2, Preservation of the MAC Service)
>
>which would seem to actively preclude some of the functions necessary to
>implement encapsulation bridging over an RPR ring, assuming that P802.17
>wishes to remain compatible with 802.1D.
>
>The issue of Std 802.11 compatibility with 802.1D has also been brought up.
>The question here is, how does 802.11 retain compatibility with 802.1D when
>it supports a frame format with intermediate node addresses as well as
final
>node addresses? This is clearly a form of encapsulation bridging that would
>seem to lie outside the architecture supported by 802.1D.
>
>Therefore, I have some questions:
>
> 1. Is 802.11 deemed to be 802.1D compliant? (I must confess that I am
> somewhat mystified as to how one would implement an 802.1D bridge
> using 802.11 MACs in practice!)
>
> 2. Is encapsulation bridging outside the scope and architecture of
802.1D?
>
> 3. If encapsulation bridging is indeed outside the purview of 802.1D,
would
> it be possible for the 802.1D group to make a formal statement to
P802.17
> that would put this issue to bed once and for all? (A liaison letter
> would
> be an excellent way of doing this, for example.)
>
>Any light you can shed on the above would be most appreciated.
>
>Best regards,
>
>- Tom Alexander
>Chief Editor, P802.17
>
>
>P.S. You have an impressive web site indeed! I particularly enjoyed
wandering
>through your model engineering pages ...