Peter -
As you say, no-one has objected, so it looks like this is a reasonable
course of action.
Regards,
Tony
At 14:20 15/04/2002 -0700, Peter Jones wrote:
>Tony,
>
>I haven't had any response to the attached email from April 4th.
>
>Given the discussions, it seems that no-one from 802.1 will seriously
object
>if 802.17 states that the 802.17 MAC does not "reflect" packets transmitted
>by the MAC client back to the MAC client.
>
>Is this your understanding? If so, I will advise 802.17 of the result of
>these discussions.
>
>regards
>Peter
>
>-----Original Message-----
>From: Peter Jones
>Sent: Thursday, April 04, 2002 6:42 PM
>To: pat_thaler@xxxxxxxxxxx; Steve Haddock; 'mick_seaman@xxxxxxxx';
>rich@xxxxxxxxxxxxxxx; nfinn@xxxxxxxxx; tony@xxxxxxxxxxxxx
>Cc: stds-802-1@xxxxxxxx; Raj Sharma
>Subject: RE: Fwd: RE: 802.1 architecture question
>
>
>Gentlemen,
>
>I think "reflective" is a good term.
>
>Let me attempt to summarize what I am hearing, and see if this flies.
>
>1) MACs used to be reflective, but mostly aren't any more.
>2) If a MAC is not reflective when you want this, you can fix it in
>Software.
>3) If a MAC is reflective and you don't want this - it's a real pain.
>4) Reflective behavior is very bad for a bridge.
>5) Full duplex MACs normally aren't reflective
>6) There is no reason for 802.17 to be require reflective behavior
>in the standard
>
>Give this, is it OK if 802.17 says:
> "802.17 MAC is NOT reflective (i.e. does not pass
> transmissions from the MAC client back to the MAC client)."
>
>It seems like the best solution.
>
>Does anyone seriously object to this proposal on any of the following:
>1) Violates 802.1 architecture
>2) Violates 802.2 requirements
>3) Violates 802.x standard practice
>4) Makes it hard to build useful products.
>
>If not - then I think we are done.
>
>Regards
>Peter
>
>-----Original Message-----
>From: Steve Haddock [mailto:shaddock@xxxxxxxxxxxxxxxxxxx]
>Sent: Thursday, April 04, 2002 9:38 AM
>To: 'mick_seaman@xxxxxxxx'; 'Peter Jones'
>Cc: stds-802-1@xxxxxxxx
>Subject: RE: 802.1 architecture question
>
>
>I agree with Mick that the desirability of reflective behavior is more of a
>system issue than a MAC issue. Consider two examples.
>
>1) A long time back I was writing FDDI drivers for Sun systems. These were
>derived from Ethernet drivers that were architecturally divided into a
>hardware independent portion and a hardware dependent portion. We were
>trying to only modify the hardware dependent portion to turn an Ethernet
>driver into an FDDI driver. The original driver was written for Ethernet
>MACs that were not 'reflective', so the driver had a shim to perform
>reflection of self-addressed or broadcast packets. It also reflected all
>packets when any of the system debug utilities were enabled. For whatever
>reason this was in the hardware independent portion. The FDDI MAC was
>reflective, so broadcast packets went around the ring and were received and
>passed up to the system, causing a duplicate of every broadcast sent.
>Initially we ended up with a solution that had a shim to simulate
reflection
>in one portion of the driver, and a shim to inhibit the natural reflection
>in the other portion. Eventually we re-wrote the whole thing to let the
>natural reflection work. In the days where processors were slower than the
>network, removing the shims and taking advantage of the natural reflection
>gave a significant performance improvement.
>
>2) If you are building a bridge, the last thing you want is to receive
>something you transmitted. It screws up learning, and is a very easy way
to
>create loops. As Mick notes, if the hardware has a reflective behavior, it
>can be very difficult to suppress it in a shim. In the case of ring
>networks, it's not all that easy to suppress it at the hardware level, but
>at least you have tools like TTL that make it possible.
>
>The only conclusion I can draw is that there is no right answer for every
>application. Whether a particular implementation supports reflection is a
>system level trade-off, and shouldn't be mandated in the standard.
>
>Steve
>
>
>-----Original Message-----
>From: Mick Seaman [mailto:mick_seaman@xxxxxxxx]
>Sent: Thursday, April 04, 2002 7:52 AM
>To: 'Peter Jones'
>Cc: stds-802-1@xxxxxxxx
>Subject: RE: 802.1 architecture question
>
>
>
>
>Peter,
>
>I suspect that this defies a clear and authoritative answer since it has
>been an item of dispute, to my knowledge since before I started attending
>802 meetings in 1985. It is so black and white that it is hard to arrange a
>win-win for the different opinions and thus it has been left unaddressed
for
>many years now.
>
>I hope the following observations may help:
>
>a) 802.1D used to specify an option by which frames with DA=SA were
>forwarded by the Bridge in order to support the LLC duplicate address
check.
>That option was present up to and including the 1993 edition, but was
>removed from the 1998 edition when the relevant section was rewriten. The
>address check therefore does not work, reliably at least across bridges.
>Nobody has ever complained about this (there was a lot of heat about
putting
>the support in the first edition). I believe most bridges have never
>supported the option, so the check has never worked in the majority of
>bridged networks - the majority of networks today.
>
>b) That means, I believe that the choice between being locally turned
around
>or being sent as well if 'reflective' behavior is to be supported is (your
>question (3)) entirely up to the specification of an individual LAN
>segment - i.e. up to the MAC group.
>
>(c) That means that you simply have to look to the behavior expected by the
>MAC clients. Token ring implementaions (I believe - source of information
>Neil Jarvis many years ago) used to transmit to themselves over the media
>when printing to a printer that just happened to be on the same machine. I
>think clients vary here, and may continue to do so, and we won't be able to
>rewrite history to fix the problem.
>
>(d) However if my logic deducing (b) holds then any client that expects
>reflective behavior can induce it through the use of a service layer shim
in
>the local station (we often incorrectly fail to distinguish between a MAC
>protocol and the service it is used to provide, the latter at least
involves
>assignments and mappings if not extra local procedures).
>
>(e) Suppressing a reflection once one has been created is a lot harder than
>creating one where none exists, particularly if the real implementation has
>the possibility of significant queuing.
>
>(f) So, if it was up to me, I wouldn't add reflective behavior unless that
>was somehow already part of the MAC functionality. I would write clients
>that tolerated reflectivity, though not ones that relied upon it.
>
>Mick
>
>
>
>
>
>-----Original Message-----
>From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
>Sent: Thursday, April 04, 2002 10:00 AM
>To: PJones@xxxxxxxxxxxx; pat_thaler@xxxxxxxxxxx
>Cc: stds-802-1@xxxxxxxx; raj@xxxxxxxxxxxx; rich@xxxxxxxxxxxxxxx;
>nfinn@xxxxxxxxx; tony@xxxxxxxxxxxxx
>Subject: RE: Fwd: RE: 802.1 architecture question
>
>
>Peter,
>
>Making an effort to be succinct rather than comprehensive: I believe that
we
>do not currently require a MAC to receive a self-addressed packet. MAC
>behavior has changed since 802.2 was completed. When 802.2 was completed,
>all MACs were half duplex.
>
>When we added full duplex to 802.3 we didn't put in any function to echo a
>self-addressed frame transmitted by the MAC to the receiver of the MAC and,
>obviously, the receiver won't see the frame on its external input.
>
>So, given the strictest reading of the 802.3 standard, I believe that a MAC
>operating in half-duplex will receive self-addressed frames it transmits
and
>a MAC operating in full-duplex will not. (This is my opinion and it would
>require an interpretation request to get a definitive answer from 802.3.)
>
>In actual implementations, I think that frequently self-addressed frames
>will not be echoed even in half-duplex mode. For example, if the
transceiver
>is capable of both kinds of operation and thinks it is in full-duplex, it
>won't echo transmitted packets to the receiver.
>
>The service varies from MAC to MAC (and may even vary for a single MAC
>depending on operating mode and physical layer).
>
>Regards,
>Pat
>
>-----Original Message-----
>From: Peter Jones [mailto:PJones@xxxxxxxxxxxx]
>Sent: Wednesday, April 03, 2002 9:24 PM
>To: 'pat_thaler@xxxxxxxxxxx'
>Cc: stds-802-1@xxxxxxxx; Raj Sharma; rich@xxxxxxxxxxxxxxx;
>nfinn@xxxxxxxxx; tony@xxxxxxxxxxxxx
>Subject: RE: Fwd: RE: 802.1 architecture question
>
>
>Pat,
>
>Thanks for the comprehensive answer.
>
>I agree that 802.2 is not used a lot - but other (probably dead) protocols
>also used to use this (e.g. DECNET LAT). It's also the case that use of
>802.2 is not controlled by the MAC itself - it's a higher layer protocol
>issue. 802.2 used to be MAC layer agnostic. If the service delivered by the
>MAC varies from MAC to MAC - that's not a good thing.
>
>What I would like to get a clear answer on is the following:
>1) If a normal (i.e. not bridge relay) client of an 802.xxx MAC
> requests transmission of a frame with a destination address that
> the MAC would normally receive (i.e. local station address,
> broadcast, multicast), is the MAC required to pass the frame back
> to the MAC client as a received frame.
>
>2) If the answer to 1) is no, then I can stop bothering you. We can
> specify 802.17 as not passing a transmitted frame back to the
> transmitting client.
>
>3) If the answer to 1) is yes, then should it be locally turned
around,
> or received back from the media.
>
>With a bit of luck the answer to 1) today is NO.
>
>This would imply that MAC behavior has changed since 802.2 was done - and
>802.2 probably should be updated to note that this behavior doesn't work
any
>more.
>
>regards
>Peter
>
>-----Original Message-----
>From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
>Sent: Tuesday, April 02, 2002 1:03 PM
>To: PJones@xxxxxxxxxxxx; rich@xxxxxxxxxxxxxxx; nfinn@xxxxxxxxx;
>tony@xxxxxxxxxxxxx
>Cc: stds-802-1@xxxxxxxx; raj@xxxxxxxxxxxx
>Subject: RE: Fwd: RE: 802.1 architecture question
>
>
>Peter,
>
>Yes, 802.2 implied that when a self-addressed frame was transmitted, it
>would be received by the transmitting MAC. But many (probably the vast
>majority) of Ethernet interfaces shipped today don't use 802.2. They use
the
>Ethernet type field so this implication doesn't mean much for today's
>Ethernet implementations.
>
>I think that for half duplex, the 802.3 spec implies that a self-addressed
>frame will be received. The MAC transmitter and receiver defined in 802.3
>Clause 4 operate independently of each other and the half-duplex
transceiver
>delivered the transmitted frame to the MAC receiver. The theoretical
>Ethernet MAC was a full duplex MAC (a MAC with seperately operating
transmit
>and receive channels) sitting above a half-duplex physical layer. Some of
>the actual hardware MAC implementations were half-duplex. They shared
>cirucitry (e.g. FIFOs) between the transmit and receive sides and therefore
>did not receive a packet they sent. However, it was not uncommon to put the
>echo of a self-addressed frame in the software above such a MAC so that the
>resulting received frames were the same as that implied by the Clause 4 MAC
>definition.
>When we added full-duplex physical layers, we didn't add anything to the
MAC
>definition to cause a self-addressed frame to be echoed to the receiver and
>the receiver no longer sees the transmitted frames. I can see why we didn't
>because of the receive bandwidth implications. If a full duplex 1 Gbit/s
MAC
>is sending a link-rate stream of self addressed packets and receiving a
>link-rate stream of packets at the same time, then its receive path would
>need to be able to support twice the data rate (1 Gbit/s of looped-back
>packets and 1 Gbit/s of exterally received packets) if it was to keep up.
>
>As a consequence, it appears that this behavior will be different for
>Ethernet between full and half duplex operating modes.
>
>So, I think the implication for 802.1 is that the MACs below them may or
may
>not receive self-addressed packets that they transmit. Whether they do or
>not will depend on whether they are full duplex if everyone reads the same
>implications in the standard that I do :^) but it is based on subtle enough
>points that I doubt that you can depend upon it.
>
>It is perhaps worth an interpretation request to 802.3.
>
>Regards,
>Pat Thaler
>
>-----Original Message-----
>From: Peter Jones [mailto:PJones@xxxxxxxxxxxx]
>Sent: Monday, April 01, 2002 5:22 PM
>To: 'Rich Seifert'; Norman Finn; Tony Jeffree
>Cc: stds-802-1@xxxxxxxx; Raj Sharma
>Subject: RE: Fwd: RE: 802.1 architecture question
>
>
>
>Hi There,
>
>I found the following in 8802-2-1998.PDF - 6.9.2 Station component overview
>page 68(pdf page 83)
>
>-------------
>The station component shall be capable of receiving and responding to the
>XID and TEST command PDUs. It shall optionally be capable of initiating the
>XID command PDU, if duplicate address checking is per-formed by the LLC
>entity in a particular implementation; see table 2. These PDUs shall use
the
>null DSAP address to denote that the station component is being referenced.
>
>The performance of the duplicate address check requires that the station
>component be prepared to receive its own XID PDUs. The definition of the
MAC
>operation provides for the ability to simultaneously transmit and receive.
>Since the DA=SA in the XID PDUs can be used for duplicate address check,
the
>MAC will rec-ognize its own address and pass the PDU to the station
>component. The station component will respond to an XID command PDU with an
>XID response PDU, regardless of whether it originated from itself or a
>remote LLC. The station component provides the duplicate address check by
>maintaining a count of received XID response PDUs. If more than one XID
>response PDU is received, then at least one other identical MAC DA exists
on
>the LAN. See figure 24 and table 1 for details.
>----------------
>
>This requires that MAC receive messages that it sends to itself. I think it
>is fairly clear that it you accept that a MAC should receive messages it
>sends to it's own station address - then it should also receive messages it
>sends to broadcast/multicast addresses.
>
>Where does this leave us? If this functionality is required by 802.2 - then
>the MAC's should support this. If so, it should be defined. If this is no
>longer required - then 802.2 needs an update.
>
>I couldn't find clear text on this on a quick browse through 802.3, 802.5.
I
>know that a lot of older protocols used to use this idea of transmitting to
>a multicast group and receiving it yourself(e.g. Decnet LAT).
>
>regards
>peter
>
>-----Original Message-----
>From: Rich Seifert [mailto:rich@xxxxxxxxxxxxxxx]
>Sent: Saturday, March 30, 2002 10:13 AM
>To: Norman Finn; Tony Jeffree; Peter Jones
>Cc: stds-802-1@xxxxxxxx
>Subject: Re: Fwd: RE: 802.1 architecture question
>
>
>At 1:36 AM -0800 3/30/02, Norman Finn wrote:
> >
> >Is the question whether a MAC can send a frame to itself? The
> >answer is, "No, it can't." That should be in the architecture
> >if it's not, shouldn't it?
> >
>
>There is specifically NOTHING in 802.3 that precludes a MAC from
>sending frames to itself over the wire. Indeed, such behavior was
>quite common in the original coaxial Ethernet, where the transmitter
>and receiver were simultaneously active on the shared medium. A
>device could (and did) perform loopback all the way through the wire
>and back, receiving its own transmitted frames and passing them up to
>the appropriate client(s).
>
>In half-duplex 10BASE-T, the transceiver is required to emulate the
>coax behavior (of looping back one's own transmissions into the
>receiver), since the hub does not send a station's own signals back
>down the receive pair.
>
>Of course, this loopback function is disabled in full-duplex mode.
>--
>
>--
>Rich Seifert Networks and Communications Consulting
>rich@xxxxxxxxxxxxxxx 21885 Bear Creek Way
>(408) 395-5700 Los Gatos, CA 95033
>(408) 395-1966 FAX