Chapter Three continues our look into the lower layer network technologies, starting with IEEE 802.3 (a.k.a. Ethernet). We treat IEEE 802.5 (IBM Token-Ring) and ANSI FDDI in considerable detail. ARCNET and LocalTalk receive a more high-level treatment. Both are obsolete technologies. They are included for two reasons: there are still ARCNET and LocalTalk networks in use, and both have features that offer instructive counterpoints to Ethernet and Token-Ring.
- IEEE 802.3 (Ethernet)
- IEEE 802.5 (Token-Ring)
- Fiber Distributed Data Interface (FDDI)
- ARCNET
- LocalTalk
- Conclusion
- Self Check
[ IV ] IEEE 802.3 (ETHERNET)
History
Ethernet was developed in the latter 1970s by the Xerox Corporation at its Palo Alto Research Center (PARC). Ethernet is a descendent of several early network technologies, including the ALOHA network described in chapter two. The design objective was to create a simple, efficient, and inexpensive LAN architecture. Ethernet made its commercial debut in 1980 as the collective product of Xerox, Digital Equipment Corp., and Intel. An improved Ethernet II was developed in the early 1980s.
By the mid 1980s the IEEE 802 Working Committe had formed its 802.3 Committee. The 802.3 Committee released the 802.3 standard for an Ethernet II-like CSMA/CD network. Throughout this section I will be highlighting the technical similarities between Ethernet and 802.3. Most people refer to both types of network as "Ethernet"; when I am referring to both I will follow this practice as well.
Collision Detection
Both Ethernet and 802.3 implement CSMA/CD as their channel access method. The steps in the graphic below illustrate Ethernet's collision detection and recovery mechanism:
- Both stations I and II sense the network wire for an ongoing
transmission. Sensing none, both stations decide that it is OK to
begin transmitting.
- Both stations start to transmit frames of data at slightly different times.
Their signals propogate away from the points of origin toward the
ends of the wire.
- The signals collide.
- Station II, being the nearest transmitting station to the point
of collision, detects the collision first and starts broadcasting a
jamming signal (purple).
- Station I receives the jamming signal before it finishes transmitting
its data. Now both stations I and II are aware that a collision has
corrupted their transmissions. Both will now back off and try their
transmissions again.
Frame Format
The formats for an Ethernet and an 802.3 frame are shown in the chart below. The two are very similar. Both can be used on the same network; Ethernet devices can tell the two types of frame apart. The purpose of each field in the frames is described below.
IEEE 802.3
Preamble and SFD -- Both frames are started by a preamble. The preamble is an alternating series of ones and zeros; it is there to alert other stations that a data frame is coming down the wire. The SFD (Start Frame Delimeter) in the 802.3 frame has bit order of 10101011. The double ones at the end is designed to tell other stations that the data frame is starting NOW!.
If you spend some time studying MAC addresses on the network you will begin to recognize which belong to 3Com NICs, HPs, IBMs, etc. Though this sounds like an intensly boring activity, it can come in very handy when you are troubleshooting.
Source Address -- This is the 48-bit MAC address of the NIC in the sender's system. It is there so that the recipient knows who to respond to!
Type / Length -- This is the other area where Ethernet and 802.3 frames differ. In an 802.3 frame this field indicates the length of the following data field, which can vary from 46 to 1474 bytes long. In an Ethernet frame this field indicates what type of information is contained in the data field. Ethernet stations can use this field to tell the two types of frames apart: any of the values that are valid Type values are not valid Length values, and vice versa.
Data -- This is the cargo hold of the frame. In an Ethernet frame it carries the layer three header and data. In an 802.3 frame it carries the 802.2 (LLC) header and data. If the data is not at least 46 bytes long, the sending station will pad the data with extra bits until it reaches the 46 byte minimum. You can think of this as akin to a very short person putting on platform shoes to reach the "You must be 54 inches tall to ride this ride" standard at many amusement parks.
CRC -- "CRC" stands for Cyclic Redundancy Check, sometimes referred to as a Frame Check Sequence (FCS). The CRC is a 32bit number computed when the frame is sent. The values of the Destination, Source, Type/Length, and Data fields are used in a mathematical formula to generate the CRC. When the recipient station receives the frame it recomputes the CRC and compares it to the value stored in the frame. If the two match then the frame crossed the network without error. If the newly computed value and the stored value do not match then the frame was corrupted somehow in transmission and will be discarded.
Types
The chart below shows the currently used types of Ethernet / 802.3, giving the network speed, maximum segment length, media type, and physical topology (all of them use a logical bus topology). For the sake of brevity I have omitted several older 802.3 types which are no longer used.
The IEEE 802.3 standards use a (mostly) consistant naming scheme. The first digit indicates the signalling rate in megabits per second (Mpbs). The middle word indicates the signalling type. All the types presented here use some variety of baseband (digital) signalling. 10Broad36 (designed for use over Cable TV wire) uses broadband (analog) signalling. The third segment is either a number -- indicating the maximum segment length in hundreds of meters -- or an abbreviation indicating the type of cable used.
| Parameter | Ethernet | IEEE 10Base5 | IEEE 10Base2 | IEEE 10BaseT | IEEE 10BaseFL | IEEE 100BaseTX | IEEE 100BaseFX |
Ethernet and 10Base5 are one and the same for practical purposes. 10Base5 is the original IEEE 802.3 specification. Both use an external device called a transceiver to connect the NIC to the thick coaxial cable. The transceiver draws power from the NIC to operate. Though Ethernet and 10Base5 use different terms to describe the arrangement of NIC, drop cable, and transceiver, they are functionally the same.
A common misconception is that because something runs over fiber-optic cabling it is somehow "faster". The fiber is just the media. Study the chart: the fiber-optic implementations carry data no faster than the copper implementations. The difference is that the maximum distances are longer.
10BaseFL and 100BaseFX both use multimode fiber-optic cabling. These technologies are used to extend Ethernet and Fast Ethernet beyond the reach of copper cabling. Generally these are used to connect 10BaseT and 100BaseTX hubs in different locations together. Sometimes fiber-optic solutions are used for hub-to-station runs when extreme distances are involved, or there is a lot of electronic "noise" that would interfere with copper cabling in the area.
[ II ] TOKEN-RING
IEEE 802.5 is an example of a networking technology developed by an industry leader and adopted in its entirety (almost) for the IEEE standard. IBM developed Token-Ring, a ring-topology token-passing LAN. Token-Ring, originally available as a 4 or 16 Mbps network, has been updated with High Speed Token-Ring (HSTR), a 100 Mbps technology. Because of the high cost associated with Token-Ring (Token-Ring hardware costs 3 to 3.5 times what Ethernet costs) it has lost market share to Ethernet. Token-Ring still has a large installed base in corporate networks. Wherever you find IBM mainframes you will probably find Token-Ring.
Token-Ring's chances for future popularity and growth were hampered in the middle 1990s by indecision on IBM's part. With the development of Fast Ethernet (100BaseT) IBM needed an answer -- something to provide greater speed for existing Token-Ring users. IBM first offered 25 Mbps ATM, with little success. HSTR appeared in 1997 from IBM and a group of Token-Ring vendors. HSTR is a "real" answer to the Fast Ethernet threat, but probably represents an offering that was made too late and cost too much to stem the tide of defections from Token-Ring to Ethernet. Becuase of its large installed base in corporate networks, Token-Ring will remain on the networking scene at least through the first decade of the 2000s. HSTR might trigger a renewal of interest in Token-Ring in the networking community. Chances of this, in my opinion, are slim. But, HSTR will keep the Token-Ring faithful going for some time to come.
Token-Ring, in both its IBM and IEEE 802.5 forms fits into the OSI Model in the same manner as 802.3 Ethernet: it uses 802.2 for Logical Link Control, and provides a MAC sublayer and Physical layer protocol.
The table below shows the characteristics of IEEE 802.5, "Original" IBM Token-Ring, and HSTR. The three differ in terms of expected topology, data rate, and media.
The Topology line in the chart may seem contradictory: Token-Ring is a ring topology network, yet the chart indicates a star. Bear with me -- the explanation will become clear by the end of this section. While 802.5 and IBM Token-Ring both support two different speeds, different speeds are not supported on the same ring at the same time. If the ring is configured to operate at 4Mbps, all of the stations on the ring must be configured to operate at 4Mbps. If a station tries to enter the ring at a different speed it will interfere with the ring's operation. At best your Token-Ring hub will "wrap out" the port belonging to the offending station and will limit the interference to a brief disruption. I say "at best" because not all Token-Ring hubs have this automatic feature.
Token-Ring Mechanics
Each station in a Token-Ring network acts as a unidirectional repeater. It receives a stream of data from its "upstream" neighbor, and repeats that stream to its "downstream" neighbor. Under Token-Ring's MAC rules a station may modify parts of a frame as it is repeating it to its downstream neighbor. Under the token passing MAC, a small frame called the Token circulates around the ring. When none of the stations has any information to transmit, the stations keep circulating the token. Only one token is allowed to circulate at a time. If no token is circulating, and no data frame is on the ring, Token-Ring's MAC rules will force the generation of a new token. The graphic below depicts the operation of a Token-Ring. Each step in the process is explained below.
- A token is circulating on the ring. Station A has data it wants
to transmit to station C, so it seizes the token (takes it off the ring)
- Station A places a data frame on the ring. It is repeated around
the ring until it reaches the destination station (C).
- Station C saves a copy of the frame from station A in memory. It
checks the frame for errors, and if all is well sets certain bits in
the trailing end of the frame to indicate "received OK". It then
puts the modified frame back on the ring to repeated back to the
sending station (A).
- Station A receives its data frame back. It verifies that it was
received correctly by the destination (by checking bits in the frame's
trailer). If the frame was received correctly it generates a new token
and passes it on. If the frame was not received correctly it has the
option to retransmit the frame.
A feature added to 16Mbps Token-Ring is Early Token Release (ETR). ETR can speed up ring operation if two contiditions are met. First, all stations on the ring must support ETR, and all must have ETR enabled. Second, the ring must be small enough (in terms of the time it takes for a frame to be repeated all the way around the ring) that a station starts to recive the head end of it's own frame back before it finishes transmitting the end of the frame. If both of these conditions are met, then the transmitting station may generate a new token and start transmitting the token as soon as it finishes transmitting its data frame. Without ETR, a station must wait until it receives the entirety of its data frame back before generating a new token. ETR increases ring efficiency by removing the time lost to waiting. On the down side, if the transmitting frame uses ETR to release a new token, and then discovers as it receives the last of its data frame that the recieving station did not receive the data frame correctly, it has lost its opportunity to immediately retransmit the data frame: it must wait for the token to come around again before it can retransmit.
Data flows from a station into the hub/MAU. From the MAU it flows out to the next station, and then back to the MAU. This is repeated for each station connected to the MAU. If the segment only has one hub/MAU, wiring in the MAU loops the data back to the first station, completing the logical ring. With more than one hub/MAU, patch cables are used to connect the Ring Out (RO) port of one MAU to the Ring In (RI) port on the next. The RO on the last MAU is connected back to the RI on the first MAU, completing a larger logical loop. MAUs and hubs are wired together in both a physical and logical ring. Stations, with the two-way flow of data in their lobe cables, are physically star-wired into the logical ring.
When a station is powered up it tries to insert itself into the ring. Relays in the MAU sense the signal coming from the station and switch position to permit data to flow out from the ring to the station, and back from the station into the ring. When the station is powered off the relays switch back and bypass the station so that the continuity of the ring is not broken.
Token-Ring Frame Format
Token-Ring has three distinct types of frames; a Data/Command frame, a Token frame, and an Abort frame. The three types of frame are shown below.
Data/Command Frame
Token Frame
Abort Frame
The Data/Command frame carries either LCC sublayer data (information from the upper layers being carried from station to station) or MAC sublayer commands (ring maintenance traffic -- such as "I'm here" messages from the active monitor). Token frames are the token that is passed from station to station. An abort frame is a special frame that will only appear if a station has started to transmit a frame and then decides to stop transmitting for some reason. I will explain the name and function of each field below.
Start Delimiter (SD) -- The SD plays the same role as the Preamble in Ethernet: it is a byte of data with a unique coding sequence used to alert receiving stations that a frame is about to begin.
Access Control (AC) Byte -- The AC byte consists of three priority (P) bits, a token bit (T), monitor bit (M), and three reservation bits (R).
The six P and R bits are used to regulate Token-Ring's traffic prioritization system, and are discussed in the Priority and Reservation section below.
If there wasn't a mechanism built in for removal of constantly circulating frames, a station that crashed while it had a data frame out on the ring would effectively prevent any other station from transmitting on the ring until all the stations were shut down and the ring reinitialized.
The T bit is set to indicate that the frame is a token. In data/command frames the T bit is always 0.
Frame Control (FC) Byte -- The FC byte contains information indicating whether the frame is a data or command frame. If it is a command frame, the information in the FC byte indicates what type of command is in the Info field. Commands might include the active monitor announcing its presence, new stations inserting into the ring and checking for duplicate addresses, other stations announcing that they are available as standbys to the active monitor, etc..
Destination Address (DA) -- This is the 48 bit MAC address of the intended recipient of the frame. In command frames this address might be set to a broadcast address so that all stations on the ring will receive the message as it comes by. Token-Ring permits the use of locally administered addresses -- that is, addresses that the administrator assigns through software which override the MAC address burned into the NIC. Use of locally administered addresses should be avoided whenever possible to elimintate the possibility of duplicate addresses.
Source Address (SA) -- The 48 bit MAC address of the originating station.
Information Field (INFO) -- This field contains information from the upper layers of the model. It is analogous to the Data field in an Ethernet or 802.3 frame. The INFO field is the cargo hold of a Token-Ring data frame.
Frame Check Sequence (FCS) -- In Ethernet this field is known as the CRC (Cyclic Redundancy Check). It contains a CRC calculated from the contents of the FC, DA, SA, and INFO fields. The recieving station recomputes the CRC upon receipt of the frame. If the newly computed CRC and the CRC stored in the FCS match then the frame has been repeated correctly across the ring from origin to destination. If they do not match, then some part of the FC, DA, SA, and INFO fields has been corrupted. The receiving station can indicate either of these two outcomes in the ED byte.
End Delimiter (ED) -- The ED is akin to the caboose on the end of a freight train; it tells a station that the end of the frame has arrived.
Frame Status (FS) Byte -- This byte, at the very end of the command/data frame is used by the destination station to signal the sending station about the disposition of the frame it has received. When the sending station transmits the frame out onto the ring, it sets two pairs of bits (A - Address Resolution bits, and C - Frame Copied bits) to 0. If the sending station receives its frame back with both pairs of bits still 0s it concludes that the destination station is not active on the ring. When the destination station receives the frame it sets the A bits to 1s to indicate that it has received the frame. If all is well with the frame -- the FCS checks out, the receiver has adequate buffer space to store the frame, etc. -- the receiving station sets the C bits to 1s to indicate that is has correctly copied the frame's information. If the sending station receives its frame back with both sets of bits set to 1s it knows that its transmission was successful. If the A bits are set, but the C bits are not, it knows that something was wrong with the frame it sent, and it may try to retransmit. (Note: if ETR is in use, the sending station will have to wait for the token is has just generated to come around to it before it can attempt a retransmission.)
Token-Ring Priority and Reservation
Token-Ring implements a Priority/Reservation system to permit network and application designers some control over which stations can seize the token and when. This capability is helpful when the network carries a mix of time-critical traffic (such as machine control or streaming media) and general data traffic. The P and R bits in the AC byte are used in this system. Eight levels of priority or reservation (0-7) are possible.
The three P bits set a token's priority. Only stations with a priority equal to, or higher than, the token's priority can sieze the token and transmit data. Stations with a priority lower than the priority of the token are simply out of luck: they must wait until a token at their priority level (or below) comes along before they can seize it and begin to transmit.
The three R bits are used by stations to indicate the priority level for the next token. For example, a station with a priority of 2 would like to reserve the next token for itself. When the data frame that is currently travelling the ring comes by, the station sets the reservation to 2. The originator of the frame receives the frame back after it has gone around the ring. It sees that the reservation level has been set to 2, so, as it generates a new token it sets the token's priority level to 2. Now, only stations with a priority of 2 or above can seize the token. It's up to the station that set the reservation level to remember what the previous priority was and to restore that priority level when it generates the next token.
This system is not a guarantee of access to the token for the station that sets the reservation level. Two things might happen to delay the reserving station's access to the token. First, a station with a higher priority might set the reservation level even higher before the new token is generated. Second, an upstream station with the same or higher priority might seize the high priority token before it gets around to the reserving station. In case #1 the higher priority station that "trumped" the reservation level is obliged to issue a new token with a priority equal to the lower reservation level when it finishes transmitting. In case #2, the stations that took advantage of the high priority token, but were not the one who set the reservation level, will emit new tokens at the same priority level as the one they seized.
Through this mechanism the priority of the token can rise and fall repeatedly as stations vie for network bandwidth. Priority and Reservation, if they are used, are set at the operating system or application level and are usually not apparent. All that can be said is that it's a rough life at priority zero!
Unfortunately, beaconing can occurr for lesser reasons than a cable break. A station with a loose connection on the receiver side (or with failing receiver circuitry) may paralyze the ring by beaconing before it finally falls of the ring. Network Analyzer tools can decode a beacon frame and identify the location of the failure, but most have to be running on the ring before beaconing starts. This is, in my opinion, one of Token-Ring's great strengths and failings. There is a wealth of diagnostic information available if you have the tools to read it, but an Ethernet card is much more likely to die quietly and only affect one user.
Beaconing
Beaconing is a behavior designed into Token-Ring as a diagnostic tool. In essence it is an unmistakable signal that a station on the ring thinks that something is dreadfully wrong. Generally, beaconing should only occur in response to major failures, such as a cable break.
The beaconing mechanism is quite simple. When a station detects a major failure in the network upstream from it, it will start sending out beacon frames. The beacon frame (a flavor of data/command frame) contains the address of the beaconing station, and the address of the beaconing station's Nearest Active Upstream Neighbor (NAUN). The station that is sending out the beacon frames knows the address of its NAUN from normal ring control traffic it received before the trouble started.
Beaconing stops all other traffic on the ring. The beaconing station will continue to send out beacon frames until it receives one of its own beacon frames from its upstream neighbor. This indicates to the beaconing station that the ring has been repaired and that data is now making its way normally around the ring. If you have a network protocol analyzer connected to the network you can capture and decode the beacon frames. Assuming that you have excellent record keeping and know the address of each station, you can quickly identify the failure domain (everything between the beaconing station and the NAUN) and take corrective action. In the Real World this corrective action usually starts with disconnecting the beaconing station from the network and seeing if things come back to normal. If another station starts beaconing, you might really have a cabling problem.
[ III ] FIBER DISTRIBUTED DATA INTERFACE
FDDI -- Fiber Distributed Data Interface -- was developed in the middle 1980s in response to the need for a high efficiency, high bandwidth, rugged network for LAN and MAN use. First commercially released in 1986 FDDI has three primary roles in the network:
- High speed, highly reliable network backbone for campus and metropolitan networks
- High speed, high efficiency network for computer room networks
- High speed network connectivity to the desktop for engineering and design workstations
FDDI is an optical fiber based network; it can use both multimode and single-mode optical fibers. A less expensive limited-range version of FDDI known as Copper Distributed Data Interface (CDDI) or FDDI-UTP is available for computer room and desktop connectivity. CDDI uses CAT5 UTP cabling. Unlike Token-Ring, which is always wired as a physical star, FDDI is frequently connected as a physical, as well as logical, ring. The table below shows the characteristics of FDDI and CDDI
FDDI fits into the OSI Model much the same as Token-Ring: its physical and MAC specifications are designed to hook into the 802.2 LLC sublayer. The primary difference is the FDDI station management functions (SMT) shown at the top and right of LLC, MAC, and PHY layers. FDDI's SMT is similar in function to the 802.1 management protocols.
In its classical implementation an FDDI network is made up of two counter-rotating rings. Each carries data in the opposite direction. One is the primary ring, carrying data when the network is in a normal condition. The other is the secondary ring which comes into play when there is a failure in the network. The graphic below shows a FDDI ring in both states. In the normal state (on the left) stations pass data from one to the next on the primary ring. In the trouble state (on the right) there has been a cable failure. The stations on either side reroute network traffic onto the secondary ring, completing the loop. This self-healing feature makes FDDI rings well suited to campus and MAN environments where reliability is a must. Equipment failures, in addition to attacks by the Cable Seeking Backhoe, can cause the secondary ring to come into service.
The classical FDDI network is a ring of "Class A" stations. That is, a network where each station has two attachments, one to the primary and one to the secondary ring (called a Dual Attach Station or DAS). With the introduction of FDDI hubs, a less expensive "Class B" station became possible. Class B stations have a single attachment to the primary ring (SAS). They do not have the self healing capability of systems with DAS connections. When a SAS station is not on the ring, optical bypass hardware within the FDDI hub routes the primary ring around the station's port. All CDDI connections are Class B SAS connections. SAS, either in FDDI or CDDI form offers a more economical means to connect stations to the FDDI ring. This is a popular option for computer room and desktop connections where redundancy isn't critical. The graphic below shows the flow of data on a network with a mix of Class A and Class B stations.
Token-Ring ETR merely speeds up the generation of a new token: it does not permit more than one data frame to be on the ring at any time.
Frame Format
FDDI has two types of frames; a General (Data/Command) frame, and a Token frame. FDDI data/command frames can vary in size from a minimum of 20 bytes (the 64bit Preamble is not counted) to a maximum of 4500 bytes. The two types of frame are shown below.
General Frame
Token Frame
The functions of the fields in an FDDI frame are, for our purposes, identical to those of a Token-Ring frame. Differences exist in the End Delimiter (ED) field. In FDDI the ED field is used to identify frames that are tokens. In Token-Ring that function is part of the AC (Access Control) byte. In addition to the indicating functions that are in Token-Ring's Frame Control (FC) byte, FDDI has two functions that are not. The functions that are in FDDI, but not Token-Ring are the bottom two in the list of indicating functions below:
- Whether the frame is a data or command frame
- If it is a command frame, what type of command is in the frame
- Whether the frame uses 16 or 48 bit addresses
- Whether the frame is part of a synchronous or asynchronous
transmission (part of FDDI's bandwidth allocation system)
[ IV ] ARCNET
ARCNET, the Attached Resource Computer NETwork, is of interest to us for four reasons. ARCNET networks are still in service, though their numbers are dwindling. ARCNET uses locally assigned station addresses. It is the only commerically manufactured token-bus network. And, it permits a wildly diverse collection of media and wiring topologies on the same network.
ARCNET was developed by the Datapoint Corporation in 1977. Standard Microsystems Corp (SMC) licensed the ARCNET technology from Datapoint, and in 1983 introduced the first ARCNET NICs. ARCNET has never been standardized by IEEE: Datapoint retains the licensing rights to ARCNET. Datapoint's close control over ARCNET has been both a help and a hinderance to the technology. It has helped in the there is one source for ARCNET specifications, and a single party with an overriding interest in maintaining full compatability between all ARCNET devices. It has hurt ARCNET's growth as some potential ARCNET customers have stayed away from what they perceived to be a "closed" propietary technology.
The ARCNET specification covers both bottom layers of the OSI Model.
ARCNET is a 2.5Mbps network, utilizing a 512 byte frame. Only ATM's 53 byte cell is smaller among commercial network technologies. A 20Mbps version of ARCNET -- ARCNET Plus -- has been developed, however it has never gained much popularity or acceptance. Had ARCNET Plus been available before the advent of 100BaseT, this story may have had a different outcome.
- RG-62U 90 Ohm coaxial cable
- Unshielded Twisted Pair
- Multimode optical fiber
ARCNET Addressing and Medium Access Control
In spite of the complex topologies you can construct with ARCNET, it is really a very simple network system. The administrator needs to keep track of only one thing: station addresses. Unlike NICs for IEEE standardized technologies, ARCNET NICs do not have globally unique addresses. Each station has an eight-bit address assigned manually by the administrator. Valid addresses are 1 to 255; address zero is reserved as the broadcast address. This limits ARCNET segments to no more than 255 stations. It also opens up the possibility for duplicate addresses to exist on the network. Your record keeping needs to be exacting with ARCNET.
When an ARCNET network is initialized, when a station leaves or enters the network, or with certain faults, the network undergoes a recon, or autoreconfiguration. Through the recon process each node discovers the address of the node with the next highest address. Each node knows its own address, the Source IDentifier (SID), and the address of the next higher node (NID). The NID of the node with the highest SID is the node with the lowest SID.
ARCNET utilizes a token passing MAC. The station with the lowest SID starts out by generating a token. This token is passed from station to station in order of the increasing SIDs. When it reaches the station with the highest SID, the token returns to the station with the lowest SID. This forms a logical cycle from lowest to highest. Unlike FDDI or Token-Ring, where the token progresses in an orderly circle, the token in an ARCNET network can pinball from one end of the network to another as it gets handed around in address order. Because of its token-passing MAC, ARCNET performance is deterministic, even if its slow data rate and tiny packet size limit overall throughput.
[ V ] LOCALTALK
LocalTalk was developed in 1983 by Apple Computer. Apple wanted a simple and robust network technology to build into its new Macintosh computers. LocalTalk shipped with the first Macs in 1984. It was a cornerstone of Apple's ease of use philosophy: LocalTalk is a "plug and play" network which requires no special skills to setup or administer in a home, small office, or school environment.
LocalTalk operates at 230.4Kbps. This is a minuscule data rate now, but in 1984 the average modem operated at 1200bps: it was fast enough. Originally LocalTalk operated on STP cabling, but several after-market manufacturers (foremost among them Pharallon) produced components to enable LocalTalk to run over UTP. LocalTalk is based on RS-422, a balanced serial interface. LocalTalk devices are daisy-chained from one to the next, up to 30 on a segment.
Apple's proprietary upper layer protocol is AppleTalk. AppleTalk can be used over Ethernet, Token-Ring, or LocalTalk. It implements the concept of "zones" (where each physical segment is a zone, connected to another by a gateway system) to permit stations to send traffic from one segment to another. Apple has moved away from AppleTalk and LocalTalk in favor of TCP/IP and Ethernet, though even new Macintoshes support the older protocols.
Like ARCNET, LocalTalk uses an 8 bit station address. Unlike ARCNET which requires central address administration and scrupulous record keeping on the part of the administrator, LocalTalk stations use automatic address configuration. Client addresses run from 1 to 127; server addresses run from 128 to 254. 255 is reserved as the broadcast address.
When a LocalTalk station powers up on the network for the first time it picks an address at random. It then sends out a query packet asking if any other station has that address. If no one objects, the station takes that address as its own. If another station does have that address, the new station simply picks another one and tries again. Once a station successfully assigns itself an address, it will try to use that address the next time it's powered up to save time. Servers and workstations are segregated because there are cases where servers and clients are treated differently. Servers, for instance, have longer to respond to duplicate address enquiries from other servers due to the fact that they may be heavily loaded and unable to respond as fast as a workstation.
LocalTalk and CSMA/CA
LocalTalk employs CSMA/CA -- Carrier Sense Multiple Access / Collision Avoidance. With CSMA/CA, stations send out a short packet called an RTS (Request To Send) after sensing the wire. Normally, the destination station responds with a CTS (Clear To Send), and the sending station transmits its data. In the case where two stations sense the wire at the same time, transmit simultaneously, and cause a collision, the frames that will collide are their RTS frames. When neither station receives a CTS from its destination within the allotted time (due to the collision wiping out the RTS packets), both stations will back off for differing lengths of time and try again. The time permitted between RTS, CTS, and data transmissions is shorter than the minimum carrier sensing time, so once a station transmits its RTS and receives a CTS no other station will attempt to transmit until the data packet has been sent. CSMA/CA still has collisions, but the algorithm limits collisions to the RTS packets, and avoids collisions of data packets.
[ VI ] CONCLUSION
Chapter Three rounds out our coverage of current network technologies. The chapter started with Ethernet, Token-Ring and FDDI, providing a detailed examination of Token-Ring, and a contrasting look at FDDI. ARCNET and LocalTalk were presented to familiarize you with the technologies should you encounter installations still using them, and to provide a contrast of technical methods with Ethernet and Token-Ring / FDDI. While Ethernet (10BaseT and 100BaseT) is the dominant network technology of the late 1990s, you should be familiar with all of the commericailly popular networks as the world is anything but uniform!
At this point in the text it is worth taking a moment to compare the technologies we've covered in terms of efficiency. Now that all three big names -- Ethernet, Token-Ring, and FDDI have 100Mbps implementations, we can make an apples-to-apples comparison. Every network technology has a point where its efficiency starts to erode. That point is measured against "offered load" -- how much data the stations on the network are wanting to transmit in a given period of time. Ethernet comes out at the bottom. Its throughput and efficiency starts to seriously degrade when network load gets over 30%. Token-Ring holds up well until network load reaches about 65%. FDDI, because of a more efficient implementation of the token passing MAC, bears up until about 85%, then it too starts to degrade. If you're wondering why we don't all have FDDI connections in our offices and cubicles, it is because there is a direct correlation between what you get and what you pay for it.
[ VII ] SELF CHECK
- How fast would a 1Base5 network operate? How long is the maximum
segment length for 10Broad36?
- What are the two primary differences between an Ethernet and an 802.3
frame?
- Describe how the active monitor on a Token-Ring network works to
remove endlessly circulating frames.
- Why does Token-Ring implement an End Delimiter (ED) in the data/command
frame? (Don't think about the bit used for indicating frame corruption;
that could go in the FS byte.)
- Does CSMA/CA (as it is implemented in LocalTalk) detect collisions
directly or indirectly?
- Which technology, FDDI or Token-Ring, supports having more than one
data frame on the ring simultaneously?
- What are FDDI's three primary roles in a network?
- What two requirements must be met for Early Token Release to be used?
- What is included in the failure domain indicated by a Token-Ring beacon
frame?
- A LocalTalk station remembers the last address it used when it is powered
down. Will this cause problems if the station is moved from one LocalTalk
network to another?
- Can a Token-Ring station with a priority of 5 seize a token with
a priority of 3?
- What happens in a FDDI DAS station when the downstream node fails? What
happens to a FDDI SAS station when the next SAS node on the ring fails?
- With Token-Ring, what happens to the ring when a station's lobe cable fails? When a patch cable connecting two MAUs is disconnected?
|
[ CH 2 ]
[ TOC ]
[ CH 4 ] |
|
1999, 2000 Shipman | Created 1-27-99 | Updated 2-4-00