Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!shlump.nac.dec.com!dave.enet.dec.com
From: mitton@dave.enet.dec.com (Dave Mitton)
Newsgroups: comp.dcom.lans
Subject: Re: More questions regarding the LAN
Keywords: Token Ring, 802.5
Message-ID: <20553@shlump.nac.dec.com>
Date: 27 Feb 91 00:14:43 GMT
References: <146215@pyramid.pyramid.com>
Sender: newsdaemon@shlump.nac.dec.com
Reply-To: mitton@dave.enet.dec.com (Dave Mitton)
Organization: Digital Equipment Corporation, Littleton MA
Lines: 58

>From: lstowell@pyrnova.pyramid.com (Lon Stowell)
>Newsgroups: comp.dcom.lans
>Subject: Re: More questions regarding the LAN
>Date: 26 Feb 91 03:06:05 GMT
>Reply-To: lstowell@pyrnova.pyramid.com (Lon Stowell)

...
>    The bits ARE used by the MAC layer to see if other stations
>    do exist and whether or not the frame was actually copied by
>    the other station.   Some LLC implementations use them..as
>    they are available on demand from the adapter....
>
>    These bits will actually prevent ring insertion and/or cause
>    Beaconing if they are corrupted in such a way that they
>    appear invalid with no other (Code violations, FCS errors)
>    in the stripped frame.

	While it is defined at the MAC level how A&C bits are used,
	it is not defined for use at the LLC level.  Any protocol that 
	expects to be used in a Bridged environment should not use them.
	At the last 802.5 meeting, the IBM representative agreed that
	this should be clarified and a paper should be issued on this 
	subject.

...   
>   Could you cite the ISO 8802.5 or CCITT 802.5 paragraphs
>   allowing multiple frames (at 4 Mbit)...or any conforming
>   implementation that does so?   One would think that any IBM
>   or TI chipset on the ring would take offense if it tried to
>   xmit two frames without an intervening Token....

	No problem: IEEE 802.5-1989, page 53, Fig 4-3, and text section
	4.2.2.2, page 55. quote:

STATE T1: TX_DATA_FR (Transmit Data Frame(s)).  While in this state, the
station transmits one or more frames.  ... <priority and reservation
exceptions>... The foregoing does not imply that the ability to transmit
multiple frames while in this state is mandatory.

	Existence of implementation is not my issue.  Notice that I originally
	noted that the TI chip set cannot do this.  IBM does not have
	to either.  But if it cannot receive them, then it is out of 
	conformance with the standard.

>   ETR is strictly a 16 Mbit feature in all the documents i
>   have....       

	That is my understanding from IBM documents.  But I cannot find
	that in the IEEE standard.  Again, this could be explained as
	an implementation issue.  (or I am not looking in the right place)
	I'm not sure that an ETR station needs the other stations to do
	anything different on the wire.  It just releases the token sooner.

	I was wrong in my previous response, on 802.5 the next frame you
	recv (if a Beaconing or Contention doesn't start) should be your
	own, even for ETR.

	Dave Mitton.