Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!pyramid!lstowell
From: lstowell@pyrnova.pyramid.com (Lon Stowell)
Newsgroups: comp.dcom.lans
Subject: Re: More questions regarding the LAN
Keywords: Token Ring, 802.5
Message-ID: <146215@pyramid.pyramid.com>
Date: 26 Feb 91 03:06:05 GMT
Sender: daemon@pyramid.pyramid.com
Reply-To: lstowell@pyrnova.pyramid.com (Lon Stowell)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 83

In article <20513@shlump.nac.dec.com> mitton@dave.enet.dec.com (Dave Mitton) writes:
>
>Frank, part your answer is some what misleading.
>An 802.5 Token Ring transmitting station strips his own packet based on
>recognizing his own source address and knowing his outstanding transmitted
>packet count. The ARI and FCI bits in the Frame Status field are not used
>for anything other than status information and retransmission at the MAC
>level.  Note that they are outside of CRC and Code Violation protection
>and can easily be undetected garbage.
  
    Although true, this is also somewhat misleading....the AR
    and FC bits are part of a byte which is repeated in the
    Frame Status Field,,,so there is SOME protection against
    garbage....you would have to alter both bits twice whilst
    leaving the reserved 'oo' bits unaltered to produce that
    misleading of a result....not to likely IMHO.

    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.


>
>An 802.5 station can send multiple packets on the wire until the Token Holding
>Timer (THT) expires (however the TI chip set does not allow this).  After every
>transmit, a counter is incremented, which causes the receiver to watch for
>the incoming packet with its source address and strip it.  With Early Token
>Release (ETR) that may not be the next packet.  If the packet does not arrive
>within Timer, Return to Repeat (TRR) then the frame is declared lost, an error.
   
   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....

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


>
>To the original question, the questioner should consider how broadcast,
>multicast, and bridging were to work in such a network where the dest node
>stripped the frame.  Also, what if the node was not present?  All these cases
>are handled with source node stripping.
>
     These functions could in order be handled by the Active
     Monitor (broadcast, multicast), the Bridge or Router (for
     bridging), or the Active Monitor (or even sender) for "no
     destination" type situations...

     You would have MORE problems with Duplicate Address
     Recognition, Neighbor Notification (somewhat obscure here),
     and fault isolation (the specific failure when you know
     there is someone else on the ring, but they can't set the
     bits correctly...)

     This is where I must differ on the use of the AR and FCI
     bits fairly strongly....they are part of the fundamental
     ring mechanisms for finding Active Monitors, noting whether
     or not the destination is present and has or has not
     "copied" a xmitted frame.  Without these two bits you would
     have needed an Ack sequence at the MAC layer....overhead
     these two avoid.

     While on the subject, the EDI bit is outside the Code
     Violation and FCS fields...it also is not protected by
     duplication.   I'll agree that an erroneous SETTING would
     be harmless, but how about CLEARING this....unless you
     believe that the odds of good Code Violation, CRC, but
     clearing only this bit are slim....



>
>	Dave Mitton, Consultant Engineer, Token Ring Program
>	Digital Equipment Corp