Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!mtunh!mkd From: mkd@mtunh.ATT.COM (Mark Darby) Newsgroups: comp.dcom.lans Subject: Re: Starlan/Ethernet compatibility Message-ID: <677@mtunh.ATT.COM> Date: 15 Jun 89 00:00:06 GMT References: <2009@wasatch.utah.edu> <19449@cup.portal.com> Organization: AT&T ISL Middletown NJ USA Lines: 66 In article <19449@cup.portal.com>, John_Robert_Breeden@cup.portal.com writes: > > NOTE: AT&T, HP and UB where the only three 10baseT draft compliant vendors > as of the 1988 summer draft. At the December meeting, a new feature was > proposed but not included in the draft (it is expected to be included in the > draft when the IEEE meets this summer) and that's the"link status" packet, > it tells the network that the device is there and up. It is expected that > the draft will become a standard in the first quarter of 1990 - what this > means is that the major parts of the protocol is for all intents and > purposes set in concrete ie; there won't be any major changes in the draft > that would make either AT&T, HP or UP non-compatable with the standard. > > What about the "status packet"? No vendor today supports it (it's not even > in the draft yet). But if it becomes part of the draft, AT&T, HP, and UB The link test function in the 10BASE-T letter ballot draft (Dated April 7, 1989, Document P802.3I/D6) consists of a transmission of a single positive pulse, 100 nanoseconds in duration, every 24 to 150 milliseconds in the absence of transmit traffic. The 10BASE-T MAU receiver does not detect the link test pulse as a packet reception. The link test function provides the means for the 10BASE-T MAU to determine whether the twisted pair link is available. This comes as a result of 10BASE-T's handling of loopback (loopback is done internally on the MAU, as opposed to externally, as is done on a typical 10BASE5 MAU). The twisted pair receiver does not pass the link test pulse through the MAU to the AUI, as this would result in a lot of unnecessary garbage floating around a network. The link test function is performed on a link by link basis. EVERY 10BASE-T port, whether on a 10BASE-T MAU or HUB, requires the link test function. So if you have 10BASE-T MAU A and 10BASE-T MAU B connected together via twisted pair, and neither is transmitting true data, each MAU is sending link test pulses to the other. If the twisted pair wire got cut, for example, both A and B would detect the absence of link pulses and disable their data transmit and data receive functions. The pulse transmit and pulse receive capabilities of the MAUs would not be affected. When the cable is repaired and the MAUs detect the link pulses once again (in a manner specified in 10BASE-T), the MAU's data transmit and receive capabilities are restored. > Does this mean that anything I have > prior to the new product goes out the window - the fork lift upgrade to make > it work? No - that's the issue between compliant and compatable. A vendor > could support the "link status" packet and have a switch on a hub's port > to turn the packet OFF - then anything downstream could be a 10baseT > product that doesn't support "link status" - ie: not 100% compliant with > the standard, but 100% compatable (one must remember that "link > status" is'nt required to make the ethernet function - it's really a > management issue). This is entirely true, assuming the new post-standard hardware is flexible enough to interoperate with the pre-standard stuff by the use of switches/ options to disable the incompatibility. Otherwise you run into some interesting network problems. > >Thanks in advance for any information. > > >Walt Hass > > "I'm prejudice because it's true" > John Breeden - uunet!john_robert_breeden@portal.com ------------------------------------------------------------------- Mark K. Darby AT&T: (201)957-2706 AT&T Bell Labs uucp:..!att!mtunh!mkd DISCLAIMER: The opinions expressed here are not necessarily those of my employer.