mtraynor@hpindwa.HP.COM (Michael Traynor) (08/10/90)
Hi,
I am looking for info on Token Ring frame sizes. I know that for a 4Mbps
Ring, the max frame is ~4KB and ~18KB on a 16Mbps Ring.
The question is, does anyone really send anything greater than ~2KB today?
I believe that most TCP/IP implementations will use Ethernet size frames.
Am I wrong?
I think Novell actually goes up to 4KB frames. How about Appletalk?
Any information on what the world REALLY does would be of interest.
Please reply to me directly.
Thank you,
Mike Traynor
------------------------------------------------------------------------------
Information Networks Division ARPA: mtraynor@hpindps.cup.hp.com
19420 Homestead Road MS 43UX UUCP: {..}!hplabs!hpindps!mtraynor
Cupertino, CA 95014 AT&T: (408) 447-3127
------------------------------------------------------------------------------
Any opinions expressed are my own and not necessarily those of my employer.
------------------------------------------------------------------------------brunner@bullhead.uucp (08/16/90)
Michael, I guess I should have read all three of your postings before replying to the first one (in the order I received them). I've replied in a seperate posting to the token-ring analyser query. The first half of this posting is in reply to the frame-size query (subject line in this posting), the second half to the source routing query. I use the Ethernet MTU in the drivers I work on (IBM/4.3 for the RT line, and OSF/1 for the PS/2), and since the OS/2 ethernet driver is really an (oldish) IBM4.3 driver, it is possible that their token-ring driver derives from the same token-ring drivers in use on the PS/2 with a ROMP processor. If so, it too uses the Ethernet MTU, 1500. >I believe that most TCP/IP implementations will use Ethernet size frames. >Am I wrong? I don't think so, but bear in mind that _most_ of the token-ringers I've communicated with (in IBM) don't view TCP/IP as their primary suite of protocols to support and tend to say things like "load balancing and (tcp) connection management (forcing a re-arp for a route when tcp reports failure, something Van Jacobson is working on the the current 4.4 post-alpha code) will be done by NETBIOS", etc., etc. RFC1042 is being revised, presently there is a "son of 1042" in draft form. 1042 as is on MTU: - The Maximum Transmission Unit (MTU) differs on the different types of - IEEE 802 networks. In the following there are comments on the MTU - for each type of IEEE 802 network. However, on any particular - network all hosts must use the same MTU. In the following, the terms - "maximum packet size" and "maximum transmission unit" are equivalent. Son-of-1042 as is on MTU: - The Maximum Transmission Unit (MTU) differs on the different types of - IEEE 802 networks. In the following there are comments on the MTU - for each type of IEEE 802 network. However, on any particular - network all hosts must use the same MTU. In addition, if different - types of IEEE 802 networks are connected via transparent link layer - bridges, all hosts on all of these networks should use the same MTU. - In the following, the terms "maximum packet size" and "maximum - transmission unit" are equivalent. I think that there will be problems ahead as non-ip token-ring developers will try to optimize for high-bandwidth applications (video, etc) using larger frame-sizes. Further complications are in order as source-routing bridges (a known evil) are replaced with source-routing-transparent bridges (a recent compromise at the 802 bridge meeting), however, that is seperate from the MTU issue. You can expect to see implementations which hold a token for up to 10ms in the blind pursuit of big frames on what are essentially propriatary networks. >I think Novell actually goes up to 4KB frames. How about Appletalk? I don't know, there is an appletalk working group in the IETF, the mailing list is apple-ip@apple.com, subscribe in the usual fashion. This working group addresses ip/appletalk issues, e.g., ip over appletalk, gateways, appletalk over ip (for the deranged pranksters) and so forth. On source routing, first, some document identifiers: Token-Ring Network Architecture Reference IBM SC30-3374-02, 3rd edition, September 1989 (my abreviation "TRARCH") Local Area Network Technical Reference (IBM SC30-3383-2) 3rd edition, September 1988 (my abreviation "LANTR") Question 1: Is the length of the routing information field 18? or 30? Page 2-6 of TRARCH defines the routing information field as a "2-byte routing control field and up to eight 2-byte route designators". I think that "bytes" here should be understood to be "octets", but it is clear that IBM defines the rif as being a variable sized element of the MAC frame, 2 =< sizeof(RIF) =< 18. What this means in real life is that no more than 8 bridges in a token-ring. When I last spoke with Radia Perlman I learned that the number of bridges (equivalent to the size of the RIF) varies from draft to draft of the IEEE 802.5 working group. I've probably munged her message, but I'll assume 8 hops max until I learn otherwise. Because TRARCH defines the IBM token-ring (802.5 with multi-ring extensions and a presumption of with source route briges, not transparent bridges, from a host's point of view, I assume that the current and near-future IBM bridge implementors will discard frames with a larger routing information field. Question 2: What is the allocation of bits within each of the eight 2-byte routes, how many bits designate the bridge and how many designate the ring. Again, TRARCH, page 2-10. Each ring in a multi-ring network has a unique ring identifier (12 bits), each bridge has a not-necessarily-unique bridge identifier (4 bits). Again, I've cross posted to the tcp-ip list, there are _always_ people who know more than I do, a fact of life I'm happy with. P.S. I have to live with the UB implementation of the 802.5 network adaptor, your milage may vary. Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner trying to understand multiprocessing is like having bees live inside your head.
rpw3@rigden.wpd.sgi.com (Rob Warnock) (08/16/90)
In article <1990Aug15.213146.2836@ibmpa> brunner@ibmsupt.UUCP () writes: +--------------- | You can expect to see implementations which hold a token for up to 10ms | in the blind pursuit of big frames on what are essentially propriatary | networks. +--------------- 10ms? That's easy. Any big, fast NFS server with lots of clients very well may have more than 10ms (125 Kbytes, on FDDI) of data ready to go when the token arrives. And frame size has nothing to do with it; all of the packets might be small. On FDDI any station is permitted to send multiple packets per token, up to the limits of T_Opr (roughly speaking). -Rob p.s. The default T_Opr -- max "operational" time per token rotation -- for FDDI is 165ms, which is just over 2 Mbytes. [O.k., it;s really T_Max, but in the absence of any real-time guys, the negotiated T_Opr will just be T_Max.] ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
my@dtg.nsc.com (Michael Yip) (08/17/90)
I agree with Rob from Silicon Graphic.
One can hold the token for a very long time (Limited by T_Opr for
the particular station). In our FDDI Lab in National Semiconductor,
I once tried to do the same experiment. I specificed a very large
value of T_Req on every station, let the ring started. When the ring
started, the FDDI token was rotating very very fast. It rotated once
per T_Ring_Latency. Then I started a station to transmit frames, not
large ones but many many small or medium size frames. That station had
so many frames to transmit until T_Opr expired and forced to release
the token and not transmitting. The result? The token rotated so slow
that I could count it myself by looking at Token Counter display on my
program. The conclusion ... yes, it is possible to hold the token for
a very long time. If the station is capable to do so.
-- Mike
PS: So Rob, can we go graceful insertion of a station into a FDDI
concentrator by holding the token and let the station into the ring?rpw3@rigden.wpd.sgi.com (Rob Warnock) (08/17/90)
In article <1379@cuckoo.nsc.com> my@cuckoo.UUCP (Michael Yip) writes: +--------------- | PS: So Rob, can we go graceful insertion of a station into a FDDI | concentrator by holding the token and let the station into the ring? +--------------- Not really. (At least I don't think so.) Remember, you can't just "hold" the token; you have to send frames at least every L_Max (3.5us), in order to reset other stations' TVX timers. (Of course, you can send properly formatted "void" frames, but then, why waste ring bandwidth? ;-} ) -Rob