gdrao@enuxha.eas.asu.edu (Giridhar Rao) (02/17/91)
Hi netters, I have some more questions regarding the token ring ( IEEE 802.5 ). I wish to thank those guys who responded to my previous queries. Does a station in a token ring regenerate the token immediately after the last bit in the frame is sent OR does it generate a new token until its frame has gone all the way around and come back ? What does the IEEE 802.5 follow ? What consequences arise if the destination station removes the frame instead of the sender ? The IEEE 802.5 standard says that sender removes the frame ? Any advantages in that ? Isn't it a lot of overhead ? Thanks a lot, Giri. -- =============================================================================== = Giridhar Rao Voice 602-966-0005 = = Computer Science Department Email gdrao@enuxha.eas.asu.edu = ===============================================================================
franka@hpctdlb.HP.COM (Frank Actis) (02/22/91)
> From: gdrao@enuxha.eas.asu.edu (Giridhar Rao) > Subject: More questions regarding the LAN > > Hi netters, > > I have some more questions regarding the token ring ( IEEE 802.5 ). I wish to > thank those guys who responded to my previous queries. > > Does a station in a token ring regenerate the token immediately > after the last bit in the frame is sent OR does it generate a > new token until its frame has gone all the way around and come > back ? What does the IEEE 802.5 follow ? This question has two different answers, depending on what you have. Normally, a station will wait until the frame that it has transmitted comes around the ring before the token is generated. There is a feature called "early token release" which allows the station to generate a token as soon as the frame has been transmitted. With early token release, it is possible for several tokens to be on the LAN at once. > > What consequences arise if the destination station removes the > frame instead of the sender ? The IEEE 802.5 standard says that > sender removes the frame ? Any advantages in that ? Isn't it a > lot of overhead ? The method of the sending station removing his (or her) own frames is a simple method of making sure that the destination system received the frame properly and that the ring is working. If the destination (or anyone else for that matter) were to remove the frame before it came back to the sender, the sender would never regenerate the token, causing the active monitor to purge the ring and send out a new token. The sending station knows that the frame has been received by looking at a couple of bits on the frame that has been set by the destination system. These bits are the "address recognized" (I saw the frame sent to me) and the "frame copied" (I was able to pull the frame off the LAN and into my buffers) which tell the sender if the remote station is up and that it received the frame. One thing to keep in mind is that most rings are small enough that the sending station will start receiving its frame while it is still sending it so stations using early token release rarely get to send an early token. Frank Actis Hewlett-Packard franka@hpctdlb.hp.com
mitton@dave.enet.dec.com (Dave Mitton) (02/26/91)
>From: franka@hpctdlb.HP.COM (Frank Actis) >Newsgroups: comp.dcom.lans >Subject: Re: More questions regarding the LAN >Date: 21 Feb 91 23:50:56 GMT > >> From: gdrao@enuxha.eas.asu.edu (Giridhar Rao) >> Subject: More questions regarding the LAN ... >> What consequences arise if the destination station removes the >> frame instead of the sender ? The IEEE 802.5 standard says that >> sender removes the frame ? Any advantages in that ? Isn't it a >> lot of overhead ? .... >The sending station knows that the frame has been received by looking at >a couple of bits on the frame that has been set by the destination system. >These bits are the "address recognized" (I saw the frame sent to me) and >the "frame copied" (I was able to pull the frame off the LAN and into my >buffers) which tell the sender if the remote station is up and that it >received the frame. ... >Frank Actis 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. 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. 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. Dave Mitton, Consultant Engineer, Token Ring Program Digital Equipment Corp
lstowell@pyrnova.pyramid.com (Lon Stowell) (02/26/91)
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
chw@hpctdlb.HP.COM (Charlie Whiteside) (02/27/91)
These are very interesting discussions! I don't understand something here though: > 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. I thought the FCI (I'm assuming this means the Frame Copy bits in the Frame Status Byte) had nothing to do with the Active Monitory present. Isn't the AC (Access Control xxxTMxxx) byte the one which sets the Monitor bit to alert of two active monitors? Charlie
lstowell@pyrnova.pyramid.com (Lon Stowell) (02/27/91)
In article <31710003@hpctdlb.HP.COM> chw@hpctdlb.HP.COM (Charlie Whiteside) writes: > > These are very interesting discussions! I don't understand something >here though: > > >> 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. > >I thought the FCI (I'm assuming this means the Frame Copy bits in >the Frame Status Byte) had nothing to do with the Active Monitory >present. Isn't the AC (Access Control xxxTMxxx) byte the one which >sets the Monitor bit to alert of two active monitors? > This is what I get for an incomplete posting. The processes i referred to are for discovering whether or not there is ANYONE else on the ring...and therefore YOU must become the Active Monitor whether or not your local system has told you not to. The process is actually part of the Insert, Ring Poll, and Neighbor Notification...all of which use the Active Monitor Present and Standby Monitor Present frames.....the xmitting station just makes a quick check of the AR, FCI bits to see whether or not there is other intelligent life on the LAN, and if so, who is there. The Access Control field is used only by the Active Monitor...it sets the bit the first time the frame passes. If any Active Monitor sees this bit set in a passing frame it knows that either the xmitter of the frame is unable to strip properly OR that there is another Active Monitor...and that either an error (can't strip) or monitor contention is required. The flags are used in different portions of monitor detection and selection. Active Monitors tend to become upset when seeing AMP frames on the ring without THEIR address as source.
mitton@dave.enet.dec.com (Dave Mitton) (02/27/91)
>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.