by Mark Sportack
Local Area Networks use frames to encapsulate data in a structure that contains all the necessary information required to ship it to its requested destination. This chapter explains the evolution and eventual standardization of frames. Each of the major frame types is examined in detail, as well as the mechanics of their creation and use.
A "frame" is a block of data transmitted on a network. The size and structure of the frame is determined by the hardware layer protocol that the network uses, for example, Ethernet, Token Ring, and so on. A frame is directly analogous to an envelope: Everyone can expect that a #10 envelope will be 4 1/8" x 9 1/2". Its payload, however, can vary considerably in size, content, urgency, and so on. Knowing the envelope's size also does not reveal anything about how it will be shipped to its destination. In a network, the mechanics of frame forwarding is called a protocol. Protocols also exist at Layer 3 of the OSI Reference Model. These wrap frames in packets and provide for their transport beyond the LAN. These protocols are described in Chapter 4, "Internetworking Protocol Stacks."
The envelope can, however, contain enough visible information to identify its originator and its intended recipient. This information is used to either forward the envelope to its intended recipient, or notify the originator that the envelope was undeliverable.
Continuing the analogy, once you know the size of the envelopes, you can begin to deploy an infrastructure for processing them in volume. Thus, standardizing envelope sizes is crucial to ensuring that the forwarding infrastructure can accommodate all envelopes, regardless of who manufactured them.
Networks are, essentially, a frame-forwarding infrastructure, and have the same need for standardization of frames. Standardization ensures that different network components made by different manufacturers can interoperate. These same standards also provide a common basis for the conversion of frame types between dissimilar network types, for example, Ethernet to Token Ring translation.
The body that has been responsible for many of the extant standards that support today's high-performance networks is the Institute of Electrical and Electronics Engineers (IEEE). This standardization work began in February 1980 when the IEEE launched their Local and Metropolitan Area Network Standards Committee, also affectionately referred to as Project 802.
The Committee is chartered with the creation, maintenance, and encouragement of the use of IEEE/ANSI as well as the equivalent Joint Technical Committee 1 (JTC 1) standards established by the International Standards Committee (ISO). The JTC 1 series of equivalent standards are known as ISO 8802-nnn. These standards are basically limited to Layers 1 and 2 of the JTC Open System Interconnection (OSI) Reference Model. Layer 1 defines the physical layer, that is, the media type and the manner in which data is placed on those media. Layer 2 defines the LAN's frame structure and frame-forwarding mechanisms.
The world's first LAN was Xerox's PARC Ethernet. This technology originated as an intraoffice, baseband transmission technology for interconnecting workstations. It was cobbled together by researchers at Xerox's Palo Alto Research Center (PARC) for their own use as an expedient alternative to floppy disks for sharing information. In other words, Ethernet was born a fairly crude and simple mechanism.
PARC researchers recognized that Ethernet would be transporting higher-level protocols like the Internet Protocol (IP), Xerox's XNS, and others. Each of these "client" protocols already had their own limitations on data payloads. Thus, rather than put too much effort into defining the hardware layer protocol, it was deemed appropriate to simply provide a two-octet Type field that identified the type of higher-level protocol that the frame contained. This let the more sophisticated client protocol determine overall frame sizes.
NOTE: An octet consists of eight binary digits (bits), regardless of what those bits signify. Beware of the data communications experts who use the less precise "binary term" or "byte" to describe such structures: they have been spending too much time with programmers.
Xerox's home-grown Ethernet lacked sophistication and relied upon client protocols to determine length of data fields.
As illustrated in Figure 3.1, the PARC Ethernet frame consisted of
FIGURE 3.1. Xerox's PARC Ethernet frame.
This protocol broadcast packets to all devices connected to the LAN. Consequently, all devices had to compete for available packets. A technique known as Carrier Sense, Multiple Access was used to facilitate this competition. Recovery of collisions, or other events that resulted in undelivered frames, was left up to the end devices and not handled by the network.
The commercial potential of Xerox's PARC Ethernet was recognized, and both its frame and protocol were refined to better suit a broader target market. This second-generation LAN, known as Ethernet II, became widely used. (Ethernet II is also sometimes referred to as DIX Ethernet, in acknowledgment of its triumvirate of corporate sponsors: Digital, Intel, and Xerox.)
Xerox, the owner of the technology and keeper of its "standards," assigned a two-octet type code to identify client protocols, such as Xerox's XNS, Novell's IPX, IP, and DECNet. These are higher-level protocols than Ethernet, and have different message size requirements. Unlike its predecessor, Ethernet II (illustrated in Figure 3.2), couldn't abdicate control over its frame length and still establish the timing needed to support a more sophisticated access method capable of detecting collisions. Thus frame size limits were defined.
FIGURE 3.2. Ethernet II (DIX Ethernet) frame.
As illustrated in Figure 3.2, the Ethernet II, or DIX, frame consisted of
It is important to note that, despite the definition of a minimum frame length, the Ethernet II standard continued to rely upon PARC Ethernet's two-octet Type field. The client-side transport protocols still had their own frame size requirements but Ethernet II used a more sophisticated access method than its predecessor. The new access method, known as Carrier Sense, Multiple Access/with Collision Detection, imposed fairly specific timing requirements.
Without getting too far into the Ethernet II protocol, this access method requires stations to check the "wire" to determine whether any other station is already sending data. If the LAN seems idle, the station is free to transmit. Unfortunately, transmission is not instantaneous over copper transmission facilities. Therefore, it is entirely probable that a station will begin to transmit on what appears to be an idle LAN only to be "hit" with an incoming transmission from another station nanoseconds after initiating its own transmission. This is known as a collision. Both stations will detect the collision, "back off" from transmitting, and begin anew after a brief delay.
The way Ethernet II enabled this was by controlling the time required for the worst-case round trip through the LAN. In a 10Mbps Ethernet, this round trip is limited to a maximum of 50 microseconds. Thus, a station would have to continue transmitting until after the worst-case round trip time had expired. This is enough time to transmit 500 bits. Dividing by 8 bits per octet means that packets would have to be a minimum of 62.5 octets in length for collision detection to work. Xerox rounded this up to 64 octets minimum frame size for Ethernet II.
Any frames whose payloads (which was still dictated by the higher-level transport protocol) resulted in an overall frame size of fewer than 64 octets, were padded with zeros by Ethernet II until the frame reached the minimum size. This solved the timing problem of collision detection, but forced each protocol to distinguish data from padding. The Ethernet II frame continued to rely upon the Type field to identify the higher-level protocol and, therefore, its data field length.
Although Ethernet II provided additional functionality intended to make the original Ethernet commercially viable, the only substantive change to the frame was to impose minimum and maximum frame lengths.
Xerox, the originator of Ethernet, retained the rights to the technology and, consequently, established and published its standards. This approach to standardization served its purpose: Ethernet became a commercially available product. Unfortunately, this approach to establishing and maintaining standards for commercial products is not extensible. A competitive corporation cannot be tasked with maintaining the standards for a commodity product. They will be motivated to act on their own behalf. Therefore, for Ethernet to become a truly successful commercial technology, the responsibility for standardization had to be ceded to a neutral entity.
In February of 1980, the IEEE launched its Project 802 committee to evaluate and standardize Ethernet as well as the other LAN technologies and protocols that were beginning to emerge. Their objective also included establishing the rules that would enable all types of LANs to easily pass data between them, and to separate the physical media from the LAN protocols. This would permit the implementation of the same LAN on different cable plants, without compromising interoperability.
The committee identified the elements required to support their goals and launched task- specific teams to accomplish them. These teams and their work efforts included
Though not a complete listing of the Project 802 initiatives, these five items adequately convey the intended benefits of their charter for standardizing Local and Metropolitan Area Networks. Each specification in this "family" can interoperate through unsophisticated frame conversions because they have a common foundation. This charter far exceeded the scope of Xerox's standards and, consequently, made Ethernet II obsolete.
The IEEE Project 802 organized its standards around a three-tier protocol hierarchy that corresponded to the OSI Reference Model's two bottommost layers: the physical layer and the data link layer. These three tiers are the physical layer, Media Access Control (MAC), and Logical Link Control (LLC). This is valid for all 802-compliant LANs. The MAC layer addressing specification allows for either two-octet or six-octet addresses. The six-octet MAC address is the standard and the two-octet address is rarely used.
As Figure 3.3 shows, the IEEE's 802 Reference Model differs from the OSI Reference Model in two significant aspects. First, 802 Physical Layer is a subset of its OSI counterpart. Second, the OSI's data link layer (Layer 2) is broken into two discrete components: Medium Access Control (MAC) and Logical Link Control (LLC).
Defining the LLC separately from the Media Access Control enabled interoperability of 802-compliant networks, despite differences in topologies, transmission media, and more importantly, media access methodologies. The LLC resides above the MAC and physical layers of the 802 Model. In this model, media access, transmission media, and topology are highly interdependent. Thus, part of the OSI's physical layer was defined as the 802's media access layer.
The LLC uses a subheader to embed the following fields in 802-compliant frames:
The Service Access Points, both Destination and Source, indicate which upper-layer protocol the packet is intended for. Protocols are assigned hexadecimal values that are displayed in the DSAP and SSAP fields of a packet.
FIGURE 3.3. Comparison of the OSI and IEEE 802 reference models.
The Logical Link Control (LLC) subframe, or header, is prepended to a frame's data field. Its three one-octet fields count as part of the data field's overall length. Figure 3.4 illustrates the structure of the LLC subframe.
FIGURE 3.4. LLC subframe structure.
The LLC provides addressing and control of the data link. It specifies which mechanisms are to be used for addressing stations over the transmission medium, and for controlling the data exchanged between the originator and recipient machines. This is done through the use of three LLC services:
These services are accessed through Service Access Points that are defined between the network and data link layers.
The first LLC service, unacknowledged connectionless service, is a minimal but useful offering. Frequently, Layer 4 protocols such as TCP, SPX, and so on are tasked with providing flow control and other reliability functions. Therefore, it makes sense to have a Layer 2 service that does not redundantly provide the same functions, albeit at a lower level. This cuts down on the communications overhead. Some applications, such as time- and latency-sensitive voice and/or video conferencing, may actually suffer performance degradation by having to establish and maintain connections at this layer.
The next LLC service, connection-oriented service, provides data link layer mechanisms to establish and maintain connections. This is extremely useful for simple and/or unintelligent devices that may not have Layer 3 or 4 protocols. Thus, they require the ability to provide these functions at Layer 2. This control function requires the link layer to maintain a table that tracks active connections.
The last LLC service, acknowledged connectionless service, is a hybrid of the first two LLC services. This service provides an acknowledgment of receipt without having any of the overhead of connection management. Less overhead directly translates into faster delivery. Adding guaranteed delivery creates a useful service whose applications are almost limitless.
These services tend to be selected per application, and are transparent to application users. As they are part of the 802.2 foundation specification, they are available to all 802-compliant networks and can be used in internetworking different 802-compliant networks.
As a means of providing backward compatibility with early, non-standardized versions of LANs, like PARC and DIX Ethernet, a subframe structure was developed to provide a mechanism for identifying the upper-layer protocol being transported. The PARC and DIX versions of Ethernet included a Type field in their frame structures. This space was later reallocated by the IEEE in their 802.3 standardized version of Ethernet.
The 802.3 Ethernet was a more sophisticated protocol than its predecessors and eliminated much of the original need for the Type field. Some higher-level protocols, however, relied upon this Layer 2 function. The need to provide compatibility with existing Layer 3 and 4 protocols necessitated the development of a subframe structure that could identify higher-level protocols. The result was the SNAP subframe, illustrated in Figure 3.5.
FIGURE 3.5. 802.2 SNAP frame structure.
The 802.2 specification also provides a Sub-Network Access Protocol (SNAP) frame structure. This frame builds upon the standard 802.2 frame by adding a five-octet field that contains a three-octet Organizationally Unique Identifier field, and a two-octet Protocol Type field.
The SNAP subframing is an extension of the LLC subframe and must be used with it. It can be used with any 802-compliant LAN.
Project 802 defined a standard basis for all Ethernet frame types. The frames are a minimum of 64 octets, and a maximum of 1500 octets in length, including payload and headers. The headers are used to identify the sender and recipient of each packet. The only limitation on this identification is that each address must be unique and six octets in length.
The first 12 octets of each frame contains the six-octet destination address (the intended recipient's address), and a six-octet source address (the sender's address). These addresses are hardware-level machine address codes, commonly known as MAC addresses. They can either be the unique "universally administered address" that is automatically given to each Ethernet network interface card (NIC) at its manufacture, or they can be customized upon installation. The automatically assigned type of MAC address is represented by six paired hexadecimal numbers, delimited by colons, for example, 99:02:11:D1:8F:19. The first two pairs of numbers are the manufacturer's ID. Each NIC manufacturer must apply to the IEEE for a unique manufacturer's ID and a range of MAC addresses.
Customized addresses are known as locally administered addresses. These addresses can be used to identify the room number, department, owner's voice mail extension, and so on. Using locally administered addresses can provide network administrators with vital information that can expedite trouble resolution. Unfortunately, they can also be extremely difficult and time-consuming to maintain.
802-compliant frames may contain a destination address of a single machine, or refer to a group of workstations with a common, identifying characteristic. Transmission to groups of related machines is known as multicasting.
Under normal operating circumstances, Ethernet NICs receive only frames whose destination addresses match their unique MAC address, or that satisfy their multicast criteria. Most NICs, however, can be set for promiscuous mode, which results in their reception of all frames on the LAN, regardless of addressing. This can pose a security risk for everyone else on the LAN, and a potential performance problem for the user whose machine is operating in that manner.
Although most of the changes from the previous versions of Ethernet that were made to the 802.3 standard were changes to the protocol itself, there was one other significant change to the 802.3 frame. The 802 committee needed a standard that was complete unto itself and not dependent upon the good behavior of other protocols. Therefore, they replaced the two-octet Type field of previous Ethernets with a two-octet Length field.
Having established minimum and maximum field lengths based on a worst-case, round-trip timing window (as previously explained, this was necessary for collision-detection purposes), it was no longer necessary to defer the determination of frame size to client protocols. Instead, the 802.3 working group redefined this two-octet field to explicitly define the length of a frame's data field, and moved protocol identification to the LLC. The structure of the frame is illustrated in Figure 3.6.
FIGURE 3.6. The IEEE 802.3 Ethernet frame.
The IEEE's 802.3 basic Ethernet frame replaced the traditional Type field with a Length field. The 802.2 subframe is used, instead, to identify the type of protocol, if this is necessary. Another change in the 802.3 frame from its predecessors was the requirement for the overall frame size to be between 64 and 1500 octets in length, from the start of the Destination field, through the end of the Frame Check Sequence field.
The preamble is a seven-octet string that precedes each frame, and allows the synchronization of the transmission. This is followed by the Start of Frame Delimiter (SFD). The SFD is fairly self-explanatory: It denotes the start of the frame for all devices in or on the LAN. The SFD is 11 followed by the repeating sequence of 1010101010.
The SFD is sometimes considered an integral part of the preamble, and not a part of the frame itself, thus bringing the preamble up to 8 octets in length. This represents another subtle distinction between the PARC and DIX Ethernet variants and the 802.3 standard. PARC and DIX Ethernets used a consistent, repeating 10101010 pattern for the entire eight-octet preamble. This was used for both synchronization and Start-of-Frame delimiting.
The next mechanism is the Frame Check Sequence (FCS). A mathematically derived value is stored in this field by the frame's originating computer. The destination computer also knows how to calculate this value and does so to verify the integrity of the frame. The frame may be damaged in transit in a variety of ways. Electromagnetic Interference (EMI), cross talk, and so on can all damage the packet without stopping its transmission.
Upon receipt of a frame, its FCS field is checked for damage through a Cyclical Redundancy Check. The destination computer performs the same calculation as the originating computer and compares the resulting value to the one stored in the FCS field. If the values are the same, the destination computer knows the data arrived intact. Otherwise, the destination computer requests a retransmission of the frame.
This basic Ethernet frame is used with either the 802.2 LLC subframe or the SNAP subframe.
The Ethernet LLC frame is a combination of an 802.3 frame and the 802.2 LLC subframe (see Figure 3.7). In this implementation, LLC adds three fields to the basic Ethernet frame: Destination Service Access Port, Source Service Access Port, and Control.
FIGURE 3.7. The Ethernet LLC frame.
An Ethernet LLC frame has the following structure:
The Ethernet LLC frame integrates the 802.2 subframe structures, or headers, and permits the identification of higher-level protocols that are the intended recipients of the frame's contents. This provides backward compatibility with earlier versions of Ethernet whose frames contained discrete mechanisms for protocol identification.
The total length of an Ethernet LLC frame must be at least 64 octets in length (excluding the preamble and the Start-of-Frame delimiter) to permit proper functioning of the CSMA/CD mechanism. Zeroes are added to the end of the Data field to ensure this minimum length. The upper limit is 1518 octets, including the preamble and the Start-of-Frame delimiter.
The Ethernet SNAP frame is a combination of an 802.3 frame and the 802.2 Sub-network Access Protocol's subframe (see Figure 3.8). In this implementation, SNAP adds a five-octet Protocol Identification Field. This field is inserted in the frame after the LLC header. It consists of a three-octet Organizationally Unique Identifier (OUI) and a two-octet Type field. These fields identify which upper-layer protocol the frame is intended for.
FIGURE 3.8. The Ethernet SNAP frame.
An Ethernet SNAP frame contains the following fields:
The Ethernet SNAP frame integrates the 802.2 subframe structures, or headers, and permits the identification of higher-level protocols that are the intended recipients of the frame's contents. This provides backward compatibility with earlier versions of Ethernet whose frames contained discrete mechanisms for protocol identification.
The total length of an Ethernet SNAP frame must be at least 64 octets to permit proper functioning of the CSMA/CD mechanism. The upper limit for an Ethernet SNAP frame is 1518 octets, including the preamble and the Start-of-Frame delimiter.
The IEEE also standardized a message format and protocol for a different, more deterministic, LAN known as Token Ring in its 802.5 standard. Token ring networks had existed since the mid 1970s and were largely an IBM-specific technology. The 802.5 specification is almost identical to IBM's Token Ring. In fact, the term "token ring" is used indiscriminately to describe both IBM's pre-standard product and IEEE 802.5-compliant products.
IEEE standardization was pushed by several large companies, including IBM (802.5 Token Ring) and General Motors (802.4 Token Bus). Token Ring offered a more timely and deterministic approach to networking than the 802.3 protocol, albeit at a higher per-port cost. Companies whose applications required timely delivery of data found Token Ring to be the only viable solution for their needs. Whereas the 802.3 protocol only assures that the packet has been successfully transmitted, it may require multiple transmission attempts. Therefore, it can't guarantee a timeframe for delivery. The token ring topology can, because of its deterministic, ring-shaped topology and orderly access method.
In an 802.5-compliant Token Ring network, a special frame (better known as, you guessed it, the "token"!) is passed from device to device, in sequence along the ring. It can only circulate when the ring is idle. This frame, shown in Figure 3.9, is three octets long and contains a special bit pattern. If the token is passed to a device that doesn't need to transmit, it may hold onto the token for 10 milliseconds, or longer if the default value has been changed. If this time expires and the device still doesn't need to transmit, it relinquishes control of the token, which is then sent on to the next device in the ring.
The IEEE's 802.5 Token Ring uses this token to control access to the transmission media. It contains Starting Delimiter, Access Control, and Ending Delimiter fields. The Access Control field contains eight bits, one of which must be inverted to deactivate the token and convert it into a Start-of-Frame sequence.
FIGURE 3.9. The IEEE 802.5 Token Ring "token" frame.
When this token is passed to a device that needs to transmit, that device seizes the token and inverts a bit value in its frame. This inversion gives that device permission to transmit and is recognized as a Start-of-Frame (SOF) sequence. The data to be transmitted, as well as other important fields, are appended to this modified token frame and put onto the network. As long as a data-bearing frame is traversing the network, no token is being passed.
It is possible to calculate the maximum time that can expire before a device will be able to transmit. This time can be manipulated either upwards or downwards by adding or subtracting nodes from the ring. Token Ring networks are ideal for any application that requires predictable delays.
Given the previous discussion about the mechanics of token passing, it is obvious that an 802.5-compliant device operates in only one of two modes: transmit or listen. A device that is listening simply forwards the token to the next device in the ring. If the token has been converted to a SOF sequence, a listening device checks to see whether it is the destination of that frame. If it is, it buffers the data and passes the still-modified token back to the originator of the frame that it received it from. The originator then has to acknowledge that the frame was sent successfully, convert the SOF frame back to a token, and put it on the network.
In transmit mode, as previously described, the device alters the token's bit structure to the SOF sequence and appends the necessary data and headers. This methodology, contrary to Ethernet, runs more efficiently under heavy traffic loads because transmission permissions are not chaotic like Ethernet's, and the frame is not limited to a maximum number of octets.
The 802.5 Token Ring frame structure consists of two parts: the token and the data frame. As previously discussed, the token's frame consists of three one-octet fields.
The token frame and the data frame are illustrated Figure 3.10.
FIGURE 3.10. The IEEE's 802.5 Token Ring frame structure with attached data field.
There are three one-octet fields in common between the token and data frames. These are the Starting Delimiter, Access Control, and Ending Delimiter fields. The Access Control field is the key to making a Token Ring work. It contains eight bits, one of which must be inverted to deactivate the token and convert it into a Start-of-Frame sequence.
When the token has been converted to a data frame, it consists of nine different fields and subfields. The first field is the Starting Delimiter, which identifies the beginning of the frame. Next is the Access Control field. This field tells 802.5-compliant devices whether or not they may transmit. This field also contains the bits for Token Ring's priority and reservation system. It is followed by the Frame Control field. This field stores the "type" bits that identify the transport protocol. This field is also used to differentiate between data frames and control frames.
The next two fields are the destination and source MAC addresses. Each one is a six-octet field. These MAC addresses conform to the previously described Project 802 specification, and are identical to those used in Ethernet networks. The data field for a token-based network varies in size from at least 0 octets, up to a maximum of 4099. The last field is the one-octet Ending Delimiter that identifies the end of the frame.
The IEEE's 802.8 specification is called the Fiber Distributed Data Interface (FDDI--often pronounced "fiddy"). Although it is widely regarded as merely a higher-speed Token Ring network, FDDI is fundamentally different in its topology, management, and even token and frame structures.
First, unlike Token Ring, which uses a priority/reservation access method, FDDI uses a timed-token protocol to regulate access to the transmission media. This results in a much more deterministic LAN and removes the need for an access control field in its frame.
The IEEE's 802.5 FDDI uses this token to control access to the transmission media. It contains preamble, Starting Delimiter, Frame Control, and Ending Delimiter fields, as shown in Figure 3.11.
FIGURE 3.11. The IEEE 802.8 FDDI "token" frame.
The FDDI data-bearing frame is structured as follows:
The IEEE's 802.8 FDDI frame is a maximum of 4500 octets in length, including data and all frame components.
Figure 3.12 illustrates the basic FDDI frame. It is usually implemented in one of two subformats: LLC or SNAP. Neither one, excluding the preamble, can be more than 4500 octets in length.
FIGURE 3.12. The IEEE 802.8 FDDI frame.
FDDI also supports LLC by building upon the 802.2 LLC layer (see Figure 3.13). The LLC frame is constructed by adding three fields to the 802.8 FDDI frame. These fields are the DSAP, SSAP, and Control fields.
FIGURE 3.13. The FDDI LLC frame.
An FDDI LLC frame has the following structure:
The IEEE's 802.8 FDDI frame can be supplemented with the 802.2 LLC subframe structures. This prepends the DSAP, SSAP, and Control fields onto the Data field.
FDDI also supports SNAP by building upon the 802.2 LLC layer of the FDDI 802.2 frame. The SNAP frame adds a three-octet Protocol Identification field and a two-octet Type field to the 802.2 LLC subframe structure (see Figure 3.14).
FIGURE 3.14. The FDDI SNAP frame.
An FDDI SNAP frame contains the following fields:
The IEEE's 802.8 FDDI SNAP frame adds a three-octet Organizationally Unique Identifier and a two-octet Type field to the FDDI LLC frame immediately after the LLC header and before the data. These fields are included in the overall length of the data field.
The IEEE 802.12 standard specifies a 100Mbps network that uses the demand priority access method (DPAM), an Ethernet or Token Ring frame format (but not both simultaneously), and a star topology. It operates over four pairs of Category 3 UTP, STP, Category 5, and fiber. There can be up to three levels of cascaded repeaters with up to 100 meters between the repeaters and the stations. The network may be up to 4,000 feet in diameter.
This specification provides SNMP compliance by using Management Information Base (MIB) variables that look like Ethernet MIBs and Token Ring MIBs. The 802.12 MIB is a superset of both Ethernet and Token Ring MIBs.
The access method is a demand priority scheme that is a round-robin arbitration method in which a central repeater regularly polls ports connected to it. This polling is in port order and is conducted to identify ports that have transmission requests. Once the need to transmit is established, the repeater determines the priority: high or normal. These priorities are designed to service time-sensitive requests before servicing "normal" requests for bandwidth. Any ports that are either not transmitting or have a pending transmission request generate an "idle" signal.
This signal is cleared by the repeater if that station is selected as the next in the priority sequence to transmit. When the port senses the silence, that is, the idle signal ceases, the port begins to transmit.
When this happens, the repeater alerts the other stations that they may receive an incoming message. The repeater then reads the incoming packet's destination address, looks in its link configuration table, and switches it to that destination address as well as any promiscuous ports.
The central, or "root," repeater controls the operation of the priority domain. This can include up to three levels of cascaded hubs, and allows interconnected repeaters to function as a single large repeater. The central repeater sends all traffic to each lower-level repeater. Each lower-level repeater, in turn, polls its active ports for requests after packet transmission.
No station is permitted to transmit twice in a row if other stations have same-priority requests pending. Also, at the central repeater, a high-priority request is not allowed to interrupt a normal-priority request if that request is already in progress. In a lower-level repeater, the normal-priority request is preempted, so that the high-priority request can be accommodated. To ensure that a request isn't completely ignored, any normal-priority requests that have been waiting longer than 250ms are automatically elevated to high-priority status.
Each of the frame types described in this chapter, and their supporting protocols, offer different combinations of performance parameters. Understanding the benefits and limitations of each frame type will help you better unleash the power of high-performance networks.
Ethernet, Fast Ethernet, and Gigabit Ethernet offer 10Mbps, 100Mbps, or up to 1Gbps transmission rate. This family of specifications uses different physical layers with an almost perfectly interchangeable media access layer. Some minor changes were necessary at this layer to account for the significant differences in the various media types that are supported.
Media access for these three specifications is through a chaotic contention method that does not scale very well. Performance may be boosted significantly by implementing these protocols through a switch. Switches decrease the size of the collision domains without affecting the size of the broadcast domain. In a per-port switched 802.3 LAN, the collision domain is reduced to just two devices: the end device and the hub port it connects to. This greatly relieves the scalability issues that plague "shared" versions of these specifications.
Token Ring offers 4 and 16Mbps transmission rates with somewhat predictable delays, due to its deterministic access method. Additionally, the token has priority bits that can be set higher to satisfy the more stringent network performance criteria of critical frames.
FDDI offers a 100Mbps transmission rate, and a self-healing dual, counter-rotating ring topology. FDDI can be considered a "Fast Token Ring" as it conducts token-passing in a deterministic fashion. This, and the requisite 802.1 and 802.2 characteristics, are all that these two networks share.
FDDI's clock rate and timed-access methodology distinguish it from Token Ring, and position it for different applications within the LAN environment. Its dual counter-rotating rings can automatically "splice" together logically to heal a broken cable. This provides an innate fault tolerance. The drawback to this is a sudden increase in propagation delay in the event of a cable break.
VG-AnyLAN provides for the accommodation of both Ethernet and Token Ring frame formats. The proposal appears to be highly media independent as it can transmit over four pairs of Category 3 UTP wire, Category 5 UTP or STP, or 62.5 micron fiber-optic cabling.
It also attempts to establish a middle ground between true baseband and true broadband communications by implementing a demand-priority media-access method. Essentially, it establishes a priority architecture that lets time-sensitive packets get needed bandwidth on demand. It lacks a native mechanism to actually reserve bandwidth, however.
VG-AnyLAN has two other potentially significant limitations. First, it requires four pair of wire. This may force 10base-T users to rewire their stations prior to migration. Therefore, even though it was intentionally designed for Category 3 wire, users may still find themselves unable to use existing wire if they do not have four pairs of Category 3 wire at each station. The second limitation is that it does not interoperate easily with "real Ethernet" because it uses a different media-access method.
Each of the LANs in the IEEE 802 family of standards has its own particular framing structure. This structure is based on a minimum level of commonality that can permit bridging of dissimilar network types. The 802 standards are well enough devised that, under normal operating conditions, a superficial understanding of the specifications themselves is sufficient for internetworking.
Details of the different specifications, however, can provide invaluable information about the inner workings of each specification. Though this level of detail isn't for everyone, it is available to anyone who needs them, for a nominal fee. This availability helps maintain the 802 frame types as industry standards, and permits the development of other technologies that need to interface at this level of the protocol stack.
To order the complete specifications for any of the Project 802 initiatives or standards, contact the IEEE's Customer Service department using one of the following contact mechanisms: PHONE: 1-800-678-IEEE from anywhere in the US and Canada, or 908-981-1393 from outside of the US and Canada.
FAX: 1-908-981-9667 TELEX: 833233 or mail to: IEEE Customer Service
445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331. The IEEE accepts all major credit cards for purchases. They can also accept purchase orders, provided that they are one of the following:
There is a $25 minimum charge, excluding shipping and handling, for such purchases. All payments must be made in US funds and drawn on a US bank. The IEEE reserves the right to change prices without notice and may be required to collect sales tax in certain regions. Thus, you should contact their Customer Service department before placing any order.
© Copyright, Macmillan Computer Publishing. All rights reserved.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}