This chapter describes the Token Ring environment. It provides a brief overview of the token ring architecture, including a summary of the 802.5 Token Ring Standard (protocol), and a discussion of the software portion of Silicon Graphics' Token Ring implementation.
The 802.5 Token Ring Standard is a local area network communications protocol designed around the basic token ring architecture[1] . In this chapter, one section describes the basic token ring architecture, and another section describes the specifics of the 802.5 Token Ring Standard.
 | Note: The term “token ring” is frequently used to refer to the 802.5 Token Ring Standard and is not used for other protocols based on the token ring architecture. Within this document, the basic token ring architecture is referred to in lowercase letters (token ring) while the 802.5 Token Ring is represented in uppercase (Token Ring). |
This section describes the basic terms and concepts for communication protocols based on the token ring architecture.
The basic token ring architecture is designed around the two elements in its name: ring and token. The ring is a collection of hardware devices called repeaters (or attaching devices) that are connected by cable in a manner that causes the signal within the cable to travel in a circle or closed loop (ring), as illustrated in Figure 1-1. Each repeater has two signal paths (usually contained within a single cable connection): an input and an output. Repeaters read information from the cable on their input port and repeat what they read onto the cable on the output port. Each computer connects to the ring through a repeater. The computer's network adapter/controller board contains the repeater. When a computer is attached to the ring, it is referred to as a node or station.
Communication occurs when one station transmits a signal onto the cable through its output line, the signal passes along the cable to the next downstream station, and that station reads the signal through its input line. The signal travels in only one direction on the ring. Each signal goes all the way around the ring, returning to the originating station.
The token is a particular pattern (a special frame) that circulates the ring. It is an electrical or optical signal pattern when on the cable and is represented by a ones-and-zeros pattern. Each protocol based on the token ring architecture specifies a specific pattern for its token. The token is initially placed (transmitted) onto the ring by one specially designated station, and, as it moves around the ring, the stations read and retransmit it (one-by-one). This scheme ensures that only one token will exist on the ring at any point in time, as illustrated in Figure 1-1.
The token controls transmission onto the ring. If numerous stations were to transmit simultaneously, the signals would affect each other (meaning the data would be corrupted), and no communication would be possible. So, only one station, the station that is currently holding the token, is allowed to transmit its data. When a station has data to transmit (either user-application data in data frames or management data in MAC frames), it must capture or claim the token first. To capture the token, a station does not repeat the token pattern when it reads it from the cable; instead, the station puts its first data frame or MAC frame onto the cable. While the transmitting station holds the token, other stations can only read from the ring and retransmit what they read. When the transmitting station has no more data to send (or when its token holding timer expires), the station places the token back onto the ring, giving the next downstream station an opportunity to capture the token and transmit data. If the next station does not have any data to transmit, it passes the token along.
At any given time, a station on the ring can be in one of two basic states: sending or listening. In the sending state, the station has captured the token and is transmitting its own data or fill (or idle) patterns. (Fill is explained later in this section.) In the listening state, the station is reading information (the signal) from the ring and transmitting it back onto the ring with minor changes. This activity is referred to as repeating and is performed by the station's repeater. The repeated information may be the token, MAC frames, or data frames. When a station is in the listening state, it is not transmitting any data of its own.
The ring can also be in two basic states: idle and active. In the idle state, only the token (and fill) are on the ring and are being read and retransmitted by the stations on the ring, as illustrated in Figure 1-1. In the active state, data or MAC frames have been placed (or are being placed) onto the ring and are being read and retransmitted by the stations on the ring. Some token ring protocols allow only one data or MAC frame on the ring at a time; other protocols allow numerous frames to be on the ring simultaneously. Figure 1-2 describes the activities of an active 802.5 Token Ring.
When a data or MAC frame reaches the destination station, that station copies the frame and marks it as “seen” (the A bit) and “copied” (the C bit) before it repeats the frame back onto the ring. Note that the data frame is copied, not removed, by the destination station. The frame continues along the ring until it reaches the originating station, which recognizes the frame as one of its own, notices that the frame has been copied by the targeted receiver, and strips (removes) it from the ring. (See Figure 1-2 for a summary of this sequence for an 802.5 Token Ring.) This design ensures that undeliverable frames do not circle endlessly around the ring. When the transmitting station finishes (that is, has no more data to transmit or runs out of time), it places fill or idle patterns onto the ring until it regenerates (releases) the token, at which time the token is available for use by the next downstream station wishing to transmit data.
Each token ring station has a management module that detects and recovers from error conditions. Each protocol based on the token ring architecture specifies a behavior for its management entities. Some protocols assign one management entity to be the master or active one, while all other management entities are passive; 802.5 Token Ring uses this scheme. Other protocols, such as FDDI, are designed so that all the stations participate equally in ring management.
Each communication protocol based on the basic token ring architecture (for example, 802.5, FDDI) must specify an algorithm for determining the length of its token holding timer and its own rules for governing the release of the token, the use of fill, and the stripping of frames. Figure 1-2 illustrates the algorithm for 802.5 Token Ring when not using the early token release optimization.
This section describes design features and specifications that are specific to the 802.5 Token Ring (as compared to the basic token ring architecture described in the previous section). Detailed subsections cover the following topics: token release and frame stripping, ring maintenance, data prioritization, and early token release.
Table 1-1 lists some of the items that are defined by the 802.5 Token Ring Standard. These items are specific to 802.5 and not the same for other communications protocols (such as FDDI) that are based on the token ring architecture.
Table 1-1. 802.5 Token Ring Specifics
Item | Specification for 802.5 Token Ring |
|---|---|
see Figure Gl-6 | |
see Figure Gl-1 | |
see Figure Gl-4 and Table 1-2 | |
4 and 16 megabits per second (Mbps) | |
shielded and unshielded twisted pair and (in the future[a]) optical fiber | |
4500 bytes for 4 Mbps ring | |
method for connecting stations to ring | trunk coupling unit |
station states required for implementing the protocol | defined in the 802.5 Token Ring Standard |
rules for releasing token and stripping frames | |
method for managing and maintaining the ring | |
design enhancements | early token release (see “802.5 Early
Token Release”) |
[a] Some vendors already offer proprietary optical fiber for Token Ring, but the standard for this transmission medium has not been approved officially by IEEE. | |
The 802.5 Token Ring Standard specifies that the transmitting station must release the token when both of the following conditions have been met:
The station cannot complete transmitting another data or MAC frame before the token-release timer expires or the station has no more data to transmit, whichever condition occurs first.
All of the station's transmitted frames have returned, and the station has stripped them from the ring.
| Note: The early token release feature, described in the “802.5 Early Token Release” section changes these rules slightly. |
These rules ensure that each frame circles the ring at least once, thus giving every station the opportunity to copy frames sent to it, and make every station responsible for removing its own frames from the ring. Until the above two conditions are met, the transmitting station does not regenerate the token. As long as the token-holding timer has not expired, a station awaiting the return of its frames simply transmits fill. Once the token-holding timer expires, if the token cannot be regenerated, there must be a problem somewhere on the ring that will be handled by the Token Ring maintenance procedures.
The active monitor (explained in the next section) removes (purges) any frames that are not stripped by their creators.
The 802.5 Standard details how a ring must be maintained. Ring maintenance is needed to maintain order, keep track of control parameters, and overcome error conditions. Common error conditions include the following: the transmitting station does not regenerate the token (a condition called lost token), or a station stops receiving the signal from its upstream neighbor (a condition referred to as a break in the ring).
Each Token Ring station has one or more software modules that handle the 802.5 network management (NMT) and monitor activities. The NMT and monitor oversee low-level (MAC and PHY) behavior (such as insertion into the ring) and recover the ring when a problem occurs. Both NMT and monitor activities obtain information by sending and receiving special management frames (MAC frames).
The remaining paragraphs in this section describe how stations participate in ring maintenance during these stages:
start-up
normal operation
as active monitor
as standby monitor
when the station suspects problems on the ring
When a station starts, it inserts itself onto the ring by starting to listen to the passing signal. It then performs the following sequence of initialization steps:
Verifies that its MAC address is unique (using the duplicate address test frame).
Sets a special timer.
Obtains its upstream neighbor's MAC address (UNA) from a passing standby or active monitor present frame.
Watches the ring for evidence that there is an active monitor. Each ring must have one active monitor. (Active monitor duties are explained later in this section.)
If it identifies an active monitor, the station puts its own monitor into the standby state and begins functioning as a listening (repeating) station. This is the normal sequence leading to normal operation.
If the timer (set during initialization) expires without the station seeing evidence of an active monitor, there is a problem. The station begins the token claiming process (using claim token frames), during which it bids to be the active monitor. It is possible that other stations also have noticed the problem and also will be token claiming. The station that wins the bidding becomes the active monitor and places a token onto the ring. Only one station should be the active monitor; all the other monitors are in standby.
If a station becomes aware (during its initialization and insertion process) that it, or the ring, is dysfunctional or that its MAC address is already in use on the ring, the station's management module removes the station from the ring by transitioning to a bypass state where it is not inserted onto the ring at all.
During normal operation, each station that is inserted onto the ring has the following responsibilities:
Repeat all frames it sees and, when appropriate, modify special bits.
Copy frames for which it is the destination.
Perform appropriate monitor duties (either as the active monitor or as a standby monitor, as explained in paragraphs below).
Manage the priority mechanism.
If the station transmits frames, strip its own frames from the ring and regenerate the token.
The active monitor's responsibilities, over and above its normal operational duties, include the following:
Set the ring's timing.
Set the ring's latency buffer.
Advertise its continuing presence as the active monitor by generating active monitor present (AMP) frames at regular intervals.
Verify that it is the only active monitor on the ring. If it isn't, take steps to rectify this condition by becoming a standby station and token claiming.
Verify that the ring is a complete loop by monitoring the return of its own frames. If the ring is broken, take action to remedy the condition by becoming a standby monitor and beaconing.
Each standby monitor has the following responsibilities, over and above its regular station duties:
Advertise its continuing presence as an active station/standby monitor, using standby monitor present (SMP) frames.
Verify that an active monitor exists on the ring, and if not, take action to remedy the condition by token claiming (generating claim token frames).
Verify that the ring is a complete loop by monitoring the return of its own frames. If the ring is broken, take action to remedy the condition by beaconing (generating beacon frames).
When a station suspects a problem on the ring, it initiates token claiming and/or beaconing. These activities are explained in the following paragraphs.
In the token claiming process, one or more stations offer to become the active monitor. Token claiming starts when there is no active monitor. Token claiming ends when one of the stations becomes the active monitor. Whenever a standby-monitor station fails to see the token or an AMP frame within a specified period of time, the station initiates the token claiming process by generating a claim token frame (also referred to as a claim).
It is common for a number of stations to issue claims more or less simultaneously because they all noticed the problem. As the claim(s) circulates the ring, data transmission activity on the ring stops. Claiming continues until the ring is stable. The first claiming station to receive its own claim token frame and two consecutively matching upstream neighbor addresses becomes the active monitor. Its first activity is to purge all information from the ring, then issue a new token.
If a station detects an upstream break in the ring, it issues a beacon frame to notify all downstream stations that a serious problem has occurred. The problem may be in the reporting station's own reception port or somewhere upstream (for example, the ring cable, the lobe cabling, a trunk coupling unit, or the neighbor station's transmission system).
As with the claim frame, when a beacon circulates the ring, data transmission activity on the ring stops, and all stations participate in the ring recovery process. As each station sees the beacon frame, it goes into the listening state. Each station continues issuing beacons until it receives a beacon frame (either its own or another station's). Reception of any beacon indicates that the portion of the ring immediately upstream from this station is again intact; reception of its own beacon indicates that the entire ring is intact. If the beaconing station sees its own beacon, it begins token claiming; if it sees another station's beacon, it stops beaconing but does not token claim.
Token Ring maintenance is accomplished using a number of special frames, referred to as management or MAC frames. Some of the more important MAC frames are summarized in Table 1-2.
Table 1-2. 802.5 Token Ring Management (or MAC) Frames
Frame | Acronym | Description |
|---|---|---|
AMP | Issued by the active monitor to notify all the other stations of its presence on the ring. | |
SMP | Issued by each active station on the ring, except the active monitor, to notify the downstream station of its presence and its address. Each station obtains its UNA information from this frame. | |
DAT | Issued by a station during its initialization process to verify that no other station is using the same MAC address. | |
CL_TK | Issued by any station that detects the loss of the active monitor. Used to determine which station will be the new active monitor on the ring (a process called token claiming). | |
BCN | Issued by any station that detects a break in the network (for example, no signal seen on the ring for a period of time). | |
PRG | Used by the active monitor to clear the ring prior to issuing a new token. | |
Lobe Media Test | LMT | Used by each station during its initialization phase in order to verify the section of cable (lobe) that connects the station to the ring. |
The 802.5 Token Ring Standard contains a priority mechanism that results in higher priority data, from any station, being transmitted before any lower priority data, as explained below.
Each Token Ring frame (data, token, or management) contains two special fields for implementing the priority mechanism: priority field and reservation field. The priority field contains the ring's current priority setting; the reservation field contains a requested priority setting.
The priority field supports eight levels of priority. Any time a station captures the token, it is allowed to transmit data whose priority setting is equal to or higher than the token's priority setting. If a station has data with only a lower priority level, it must wait until the ring's priority setting is lowered before it can transmit its data.
When a waiting station has data with a higher priority level than the current setting, the station is allowed to increase the ring's priority level, thus locking out stations with lower priority data and increasing its own access to the ring. Raising the priority level is accomplished in the following manner:
First, the station indicates its desired priority by writing the level into the reservation field of any frame that it repeats. This action makes the statement “I want to transmit data at this priority level.” Stations can raise, but not lower, this requested value.
Second, when the station captures the token, it transmits as much data as it can in its allowed time (assuming that its waiting data is of a priority equal to or higher than the ring's current priority). If the station still has high-priority data left, it regenerates the token with a new higher priority level, equal to its data's priority level.
Raising the ring's priority in this way is called stacking. The new token cannot be captured by stations with lower-priority data, only by stations with equal or higher priority; therefore, it is likely that this station will have an opportunity to recapture the token much sooner than if every station on the ring were allowed to transmit.
When the station recaptures the token and finishes transmitting its high-priority data, it generates a token with a new ring priority. The new setting must be whichever of the following settings is higher: the priority level that was in effect before the station stacked the priority or the highest requested level seen in any reservation field since the station stacked the ring's priority.
After a station has increased the ring's priority and before it recaptures the token, other stations with equal or higher priority can capture the token and transmit data. They can even raise the priority level such that the original stacking station is out-prioritized and must wait for the level to be decreased. The reservation mechanism guarantees that the level will return to each station's requested level as soon as all waiting higher-level priority data has been transmitted.
The 802.5 Token Ring Standard provides an optional enhancement to the basic token ring design: early token release. This feature is available only for rings operating at 16 megabits per second (Mbps). Early token release allows multiple frames on the ring at the same time, thus increasing ring efficiency and use of bandwidth. On a 16-Mbps ring, stations that use early token release can coexist with stations that do not.
| Note: The PCI Token Ring board does not support the early token release feature. |
Stations that support the early token release feature generate the token immediately after transmitting their final frame, without waiting for the frame to return and be stripped. Since the transmitting station does not have to wait and the next station can transmit sooner (before all frames have been stripped from the ring), this feature can make the ring more efficient. Figure 1-3 illustrates early token release. In this example, notice that at position 4, two data frames exist on the ring simultaneously, and at positions 2 and 6 the token is on the ring while data frames are still circling.
Token Ring and Ethernet are similar and yet different. The design of both protocols supports the following:
use of shielded and unshielded twisted pair copper cable
multiple hosts transmitting and receiving over shared cable
There are also a great many differences between the two protocols. One of the main differences is the order and manner in which hosts access the cable. This difference affects network latency (waiting for access to the cable), use of bandwidth (data carrying capacity of the cable), and network management.
Ethernet hosts transmit more or less at will, without regard to any order, refraining only if they detect another station transmitting. Ethernet stations that have gained access to the cable hold onto their access only for the time necessary to transmit their data, unlike Token Ring, where stations generate fill (that wastes bandwidth) during certain periods of their access time. In addition, an Ethernet cable never has to be idle, as the Token Ring cable is when stations are passing the token.
The Ethernet scheme minimizes network latency and optimizes the use of bandwidth. When many Ethernet stations want to transmit simultaneously, two or more stations' signals can “collide” in their access attempts. No data is lost and no user-application retransmission is required, since the hardware automatically makes access attempts until it succeeds; however, a very small amount of lost (unused) bandwidth is associated with each collision.
Token Ring hosts transmit only when the circulating token arrives at their reception port and in the order they are attached to the cable (sometimes referred to as round-robin). Since no data can be transmitted while the token is on the ring, this scheme carries with it a set minimum latency (guaranteed latency), which results in some loss of bandwidth. This latency increases with the network's cable length and the number of attached hosts. On the other hand, no Token Ring bandwidth is lost due to unsuccessful access attempts.
Under light to medium loads (up to 50% of the cable's bandwidth), Ethernet performance benefits from its lower latency; under extremely heavy loads (over 85% of bandwidth) Token Ring performance benefits from its contention-free design.
Ethernet stations do not need to know about their ordering because they do not pass anything to the “next” station. In order to function properly, a Token Ring network requires that all attached stations be ordered sequentially. Because of this difference, Token Ring network management is more complex than Ethernet management. In addition, a small portion of the Token Ring's bandwidth is occupied by management frames.
Other differences include how fast the signal travels along the cable (the data rate or transmission speed) and how large each frame can be, as summarized in Table 1-3.
Table 1-3. 802.5 Token Ring Versus Ethernet
Protocol | Data Rate | Maximum | Access | Method for Obtaining Permission to Transmit | Method to
Acknowledge |
|---|---|---|---|---|---|
Token Ring | 4 | 4,500 | round-robin | capture token | C bit set in original data frame |
Ethernet | 10 | 1,500 | first-come first-serve, if cable is idle; random, if there is contention | listen to verify | none at Ethernet layers |
Token Ring sites can be equipped with a variety of cables and connectors; this section describes some of the more common ones. Table 1-4 summarizes common combinations of cabling and connectors, while Figure 1-4 illustrates them.
Hardware components exist for converting one type of connector to another (for example, an RJ-11 to an RJ-45) or for splicing one type of cabling to another (for example, type 2 to type 3). Consult an authority before installing any of these converters; the compatibility issues can be complex (for example, when converting an RJ-11 to an RJ-45 you must know whether the connectors are wired straight-through or cross-pinned).
| Note: Common telephone cabling, sometimes referred to as “flat cable,” “silver satin,” or “flat gray cable,” should not be used for adapter cables, trunk ring cabling, or lobe cabling. |
Table 1-4. Cables and Connectors in Token Ring Environments
Token Ring is a popular local area network (LAN) technology. The protocol has been standardized by the Institute of Electrical and Electronics Engineers (IEEE) and approved by the American National Standards Institute (ANSI) and the International Standards Organization (ISO).
802.5 Token Ring interoperability is provided through standard interfaces at the physical layer (PHY), medium access control sublayer (MAC), and logical link control sublayer (LLC) of the Open Systems Interconnection (OSI) reference model. Figure 1-5 illustrates the protocol services provided by the IRIS Token Ring product compared to the OSI and Systems Network Architecture (SNA) layers.
Additional sources of information about 802.5 Token Ring are listed in Table 1-5, with a brief description of the type of information each document provides.
Table 1-5. Additional Sources of Information
Document | Description |
|---|---|
802.5 Local Area Network Standard. | Official IEEE 802.5 Token Ring documentation specifying the protocol. Useful or engineers and communication designers, implementors, and writers. |
8802-5 Token Ring Protocol. | Official ISO 8802-5 Token Ring documentation specifying the protocol. Useful for engineers and communication designers, implementors, and writers. The technical content of this document is the same as for the IEEE document listed above. |
Handbook of Computer-Communications
Standards, Local Network Standards, Vol. 2. Published by Macmillan Publishing Company, New York. | Detailed descriptions, in layman's English, of many local area network protocols and technologies, including 802.2 and 802.5. Valuable for people planning, managing, and/or troubleshooting any LAN, including Token Ring. |
The IRIS Token Ring driver provides the communication path between the upper layers of the protocol stack (TCP/IP or SNA) and the IRIS Token Ring board, as illustrated in Figure 1-6. This section provides an overview of the IRIS Token Ring driver.
The services of the IRIS Token Ring network connection are used by the higher layers of the protocol stack, as illustrated in Figure 1-7. A Silicon Graphics workstation or server can be configured with one protocol stack (TCP/IP only) or more, for example, TCP/IP and SNA. The IRIS Token Ring driver provides the logical interface between the board and the network protocols.
The higher layers of the protocol stack can be from a number of different protocol families, for example, TCP/IP, Snoop Protocol, SNA, IBM's NetBIOS™, or Novell®'s NetWare®. Silicon Graphics' TCP/IP, Snoop Protocol, and SNA stacks are described in separate subsections. Figure 1-7 summarizes the driver's role as it relates to user-level applications, other operating system-level processes, and the IRIS Token Ring board.
The IRIS Token Ring driver has two main functions:
to inspect and pass incoming frames to the correct upper layer
to accept outgoing frames from the higher layers of the protocol stack(s) and queue them to the board
The IRIS TCP/IP protocol stack is the default, and required, protocol stack for a Silicon Graphics system. The IRIS Token Ring driver depends on a properly configured and functioning TCP/IP protocol stack. The TCP/IP stack (or IP suite) includes the following protocols, among others: Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message System protocol (ICMP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). The TCP/IP stack uses type 1 service at the data link layer (that is, LLC type 1, unacknowledged connectionless service).
Communication between the IRIS user applications (including IBM emulation products) and the IRIS Token Ring driver is through the BSD socket interface, as illustrated in Figure 1-6 and Figure 1-7.
The TCP/IP stack supports the following user applications (among many others):
The Network File System (NFS)™, which allows transparent file access between remote nodes throughout the network. NFS is discussed in detail in the ONC3/NFS Administrator's Guide.
The Network Information Service (NIS), which is a name and address lookup service (directory service) that provides a centralized network database to ease network administration. NIS is discussed in detail in the NIS Administration Guide.
Internet applications/utilities, including those listed below, all of which are part of the standard IRIX operating system. To obtain more information about these applications, use the man command.
telnet (1C), the user interface to the TELNET protocol that allows users to log on to a system within a remote network
ftp (1C), the Internet file transfer program that allows users to transfer files to and from remote networks
rcp (1C), the remote copy utility that allows users to copy files to and from systems throughout a site's networks
rlogin (1C), the remote log on utility that allows users to log on to remote systems located within a site's networks
IRIS products that emulate IBM SNA applications, such as IRIS 3270 Terminal Emulator and SGI 3770 SNA Terminal Emulator. These products rely on an SNA gateway (for example, the IRIS SNA Server product) to handle their connection to the SNA world (for example, their link to an IBM host).
IRIS user applications such as Showcase™ and IRIS Insight™.
User applications that have been ported to the IRIX™ operating system. Examples include FrameMaker®, Wingz™, and Z-Mail™.
The IRIS SNA protocol stack is an optional protocol stack. It includes modules to handle the Data Link Provider Interface (DLPI), System Network Architecture (SNA) streams, and UNIX STREAMS, as illustrated in Figure 1-7. The SNA protocol stack requires LLC type 2 (connection mode service). IRIS SNA Server is an example of a product that requires the SNA protocol stack.
Communication between the IRIS Token Ring driver and the IRIS SNA protocol stack is achieved through UNIX STREAMS and a Data Link Provider Interface (DLPI), as illustrated in Figure 1-7. The DLPI module provides SNA source routing support.
Figure 1-8 illustrates some of the configurations that can be achieved in an SNA environment. A tag of “IRIS IBM Ap” indicates the presence of any of the products that emulate IBM SNA-based applications.
The IRIS Token Ring board supports promiscuous (or capture-all-frames, CAF) functionality. This functionality is enabled by running an application that utilizes a raw protocol stack (for example, the BSD socket-based Snoop Protocol of the Raw Network Protocol family). Applications (for example, NetVisualyzer) that use the Snoop Protocol automatically download the CAF firmware to the IRIS Token Ring board when the application is started.
When operating in promiscuous mode, the IRIS Token Ring board does not filter the frames it sees on the cable; rather, it copies all the frames it sees and passes them to the upper layer applications. This functionality is useful for diagnosing problems on a ring. When CAF firmware is running on the IRIS Token Ring board, only LLC type 1 is available.
For more information, see the man pages for raw(7F) and snoop(7P).
| Note: The IBM host connections (for example, 3174 Local SNA Cluster controllers, 3172 Interconnect Controllers, 3725/3745 Communication controllers) that are tested and supported for use with Silicon Graphics' products are specified in the IRIS Token Ring Release Notes. |
The IRIS Token Ring driver can support up to eight Token Ring boards.
| Note: A particular system may have further limitations on the number of Token Ring boards, depending on the system's configuration. For example, the IRIS SNA Server product supports a maximum of four devices, which can be any combination of Token Ring boards and SDLC adapters. |
The number of supported link stations, service access points (SAPs), and memory buffers varies from board to board. For example, a board with expanded memory provides more support than one without this expansion. All IRIS Token Ring boards provide sufficient (not necessarily optimal) support for IRIS applications and can accommodate both workstation and server applications. See the IRIS Token Ring Release Notes for recommended configurations.
[1] The basic token ring architecture is used in a number of protocols, for example, FDDI Token Ring.