Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[RPRWG] RE: Fwd: RE: 802.1 architecture question



Jim & Steve,

Please see the attached mail from Tony Jeffree regarding the issue I was
chasing down - my work item from the last meeting. 

The essence of this is that I propose the 802.17 draft states something
like:
	"802.17 MAC is NOT reflective (i.e. does not pass
	transmissions from the MAC client back to the MAC client)."

With supporting text as required.

I think this should be sufficient to let us go forward.

regards
Peter

-----Original Message-----
From: John Lemon 
Sent: Friday, April 05, 2002 10:06 AM
To: 'Jim Mollenauer'
Cc: Peter Jones; 'Steven Wood'; 'Mike Takefman'; Raj Sharma; Jason Fan;
'Tom Alexander'
Subject: RE: Fwd: RE: 802.1 architecture question


Jim,

Please re-read all the attachments to see all the information Peter
collected, especially Mick's message. You really don't want to give clients
back their sourced frames in many cases, so the safe thing to do is never
give them back.

This behavior is completely different for MAC Control Sublayer originated
frames. If any diagnostics need this behavior, they can be implemented
through a request to the MAC Control Sublayer and an associated response.

jl

-----Original Message-----
From: Jim Mollenauer [mailto:jmollenauer@xxxxxxxxxxxxxxxxxxxxx]
Sent: Friday, April 05, 2002 4:50 AM
To: John Lemon
Cc: Peter Jones; 'Steven Wood'; 'Mike Takefman'; Raj Sharma; Jason Fan;
'Tom Alexander'
Subject: Re: Fwd: RE: 802.1 architecture question


I'd like to thank Peter for his hard work on this item, but John has a valid
point.  There are times when it is desirable to send a packet all the way
around
the ring, for diagnostic and network management purposes.  In fact, the
diagnostic application is more likely to exist as a client than within the
MAC
itself.  Think of traceroute in IP as an example.  Another example would be
the
token rotation time, used in FDDI as a priority mechanism; the token (a
control
packet) goes around continuously and provides information on the current
traffic
load.

My suggestion would be to set TTL to n-1 in broadcast messages (where n is
the
number of nodes on the ringlet) but to allow TTL=n in specified unicast
control
requests.  In the latter case the returned message should be sent back up to
the
client.

Jim



John Lemon wrote:

> While I agree with everything Peter writes here, I just want to be
explicit
> that this should apply only to the interaction with the client. I believe
we
> have identified at least one control message that would need to be sent to
> oneself (all the way around the ring, not a local drop off :-).
>
> jl
>
> -----Original Message-----
> From: Peter Jones
> Sent: Thursday, April 04, 2002 7:24 PM
> To: Steven Wood (E-mail)
> Cc: Mike Takefman (E-mail); jmollenauer@xxxxxxxxxxxxxxxxxxxxx; Raj
> Sharma; Jason Fan; Tom Alexander (E-mail)
> Subject: FW: Fwd: RE: 802.1 architecture question
>
> Steve,
>
> I think I'm making progress on my work item (A8: Contribution to verify
> whether or not 802.17 resolution to comment 14 is consistent with other
802
> MACs and FDDI) - it's just taken a while.
>
> It looks like the answer will be that the MAC should not pass a frame
> transmitted by the client back to the client. See below for gory details
of
> discussions. It looks like we don't have to support this - so we should
> simplify our lives and not bother.
>
> regards
> Peter
>


-------- Old History removed---


______________________________________________________
Peter Jones                      Luminous Networks
Principal Engineer               10460 Bubb Road
                                 Cupertino, CA, 95014
                                 USA
Direct: +1 408 342 2513          Main: +1 408 342 6400
mailto:pjones@xxxxxxxxxxxx       Fax:  +1 408 863 1148
______________________________________________________



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