Token Ring Bridging
When IBM introduced Token Ring, they described an alternative bridging technique called source-route bridging. Although transparent bridging, as discussed in the previous section, works in a Token Ring environment, IBM networks have unique situations in which transparent bridging creates some obstacles. An example is shown in a later section, "Source-Route Transparent Bridging." Source-route bridging, on the other hand, overcomes these limitations.
Many networks have a combination of transparent and source-route bridged devices. The industry developed source-route transparent bridging for hybrid networks, allowing them to coexist. However, the source-route devices cannot inherently communicate with the transparent devices. Source-route translation bridging, yet another bridging method, offers some hope of mixed media communication. The sections that follow present all three Token Ring bridging methods (source-route, source-route transparent, and source-route translational). The switching aspects of Token Ring networks are described later in the section "Token Ring Switching."
Source-Route Bridging
In a Token Ring environment, rings interconnect with bridges. Each ring and bridge has a numeric identifier. The network administrator assigns the values and must follow several rules. Typically, each ring is uniquely identified within the bridged network with a value between 1 and 4095. (It is possible to have duplicate ring numbers, as long as the rings do not attach to the same bridge.) Valid bridge identifiers include 1 through 15 and must be unique to the local and target rings. A ring cannot have two bridges with the same bridge number. Source devices use ring and bridge numbers to specify the path that the frame will travel through the bridged network. Figure 3-4 illustrates a source-route bridging (SRB) network with several attached workstations.
Figure 3-4. A Source-Route Bridged Network
When Station A wants to communicate with Station B, Station A first sends a test frame to determine whether the destination is on the same ring as the source. If Station B responds to the test frame, the source knows that they are both on the same ring. The two stations communicate without involving any Token Ring bridges.
If, however, the source receives no response to the test frame, the source attempts to reach the destination on other rings. But the frame must now traverse a bridge. In order to pass through a bridge, the frame includes a routing information field (RIF). One bit in the frame header signals bridges that a RIF is present and needs to be examined by the bridge. This bit, called the routing information indicator (RII), is set to "zero" when the source and destination are on the same ring; otherwise, it is set to "one."
Most importantly, the RIF tells the bridge how to send the frame toward the destination. When the source first attempts to contact the destination, the RIF is empty because the source does not know any path to the destination. To complete the RIF, the source sends an all routes explorer (ARE) frame (it is also possible to use something called a Spanning Tree Explorer [STE]). The ARE passes through all bridges and all rings. As it passes through a bridge, the bridge inserts the local ring and bridge number into the RIF. If in Figure 3-5, Station A sends an ARE to find the best path to reach Station D, Station D will receive two AREs. The RIFs look like the following:
Ring100 - Bridge1 - Ring200 - Bridge2 - Ring300 Ring100 - Bridge1 - Ring400 - Bridge3 - Ring300
Each ring in the network, except for ring 100, see two AREs. For example, the stations on ring 200 receive two AREs that look like the following:
Ring100-Bridge1-Ring200 Ring100-Bridge1-Ring400-Bridge3-Ring300-Bridge2-Ring200
The AREs on ring 200 are useless for this session and unnecessarily consume bandwidth. As the Token Ring network gets more complex with many rings interconnected in a mesh design, the quantity of AREs in the network increases dramatically.
Note
A Catalyst feature, all routes explorer reduction, ensures that AREs don't overwhelm the network. It conserves bandwidth by reducing the number of explorer frames in the network.
Station D returns every ARE it receives to the source. The source uses the responses to determine the best path to the destination. What is the best path? The SRB standard does not specify which response to use, but it does provide some recommendations. The source could do any of the following:
Use the first response it receives
Use the path with the fewest hops
Use the path with the largest MTU
Use a combination of criteria
Most Token Ring implementations use the first option.
Now that Station A knows how to reach Station D, Station A transmits each frame as a specifically routed frame where the RIF specifies the ring/bridge hops to the destination. When a bridge receives the frame, the bridge examines the RIF to determine if it has any responsibility to forward the frame. If more than one bridge attaches to ring 100, only one of them forwards the specifically routed frame. The other bridge(s) discard it. Station D uses the information in the RIF when it transmits back to Station A. Station D creates a frame with the RIF completed in reverse. The source and destination use the same path in both directions.
Note that transparent bridging differs from SRB in significant ways. First, in SRB, the source device determines what path the frame must follow to reach the destination. In transparent bridging, the bridge determines the path. Secondly, the information used to determine the path differs. SRB uses bridge/ring identifiers, and transparent bridging uses destination MAC addresses.
Source-Route Transparent Bridging
Although many Token Ring networks start out as homogenous systems, transparently bridged Ethernet works its way into many of these networks. As a result, network administrators face hybrid systems and support source-route bridged devices and transparently bridged devices. Unfortunately, the source-route bridged devices cannot communicate with the transparently bridged Ethernet devices. Non-source-routed devices do not understand RIFs, SREs, or any other such frames. To further confuse the issue, some Token Ring protocols run in transparent mode, a typically Ethernet process.
Note
Source-route translational bridging (SR/TLB), described in the next section, can overcome some of the limitations of source-route transparent bridging (SRT). The best solution, though, is to use a router to interconnect routed protocols residing on mixed media.
Source-route transparent bridging (SRT) supports both source-route and transparent bridging for Token Ring devices. The SRT bridge uses the RII bit to determine the correct bridging mode. If the bridge sees a frame with the RII set to "zero," the SRT bridge treats the frame using transparent bridging methods. It looks at the destination MAC address and determines whether to forward, flood, or filter the frame. If the frame contains a RIF (the RII bit set to "one"), the bridge initiates source-route bridging and uses the RIF to forward the frame. Table 3-4 compares how SRT and SRB bridges react to RII values
Table 3-4. SRT and SRB Responses to RII
RII Value
SRB
SRT
zero
Drop frame
Transparently bridge frame
one
Source-route frame
Source-route frame
This behavior causes problems in some IBM environments. Whenever an IBM Token Ring attached device wants to connect to another, it first issues a test frame to see whether the destination resides on the same ring as the source. If the source receives no response, it sends an SRB explorer frame.
The SRT deficiency occurs with the test frame. The source intends for the test frame to remain local to its ring and sets the RII to "zero." An RII set to "zero," however, signals the SRT bridge to transparently bridge the frame. The bridge floods the frame to all rings. After the test frame reaches the destination, the source and destination workstations communicate using transparent bridging methods as if they both reside on the same ring. Although this is functional, transparent bridging does not take advantage of parallel paths like source-route bridging can. Administrators often create parallel Token Ring backbones to distribute traffic and not overburden any single link. But transparent bridging selects a single path and does not use another link unless the primary link fails. (This is an aspect of the Spanning-Tree Protocol described in Chapter 6, "Understanding Spanning Tree," and Chapter 7, "Advanced Spanning Tree.") Therefore, all the traffic passes through the same links, increasing the load on one while another remains unused. This defeats the intent of the parallel Token Rings.
Another IBM operational aspect makes SRT unsuitable. To achieve high levels of service availability, some administrators install redundant devices, such as a 3745 controller, as illustrated in Figure 3-5.
Figure 3-5. Redundant Token Ring Controllers
The redundant controllers use the same MAC address (00-00-00-01-02-03) to simplify workstation configuration; otherwise, multiple entries need to be entered. If the primary unit fails, the workstation needs to resolve the logical address to the new MAC address of the backup unit. By having duplicate MAC addresses, fully automatic recovery is available without needing to resolve a new address.
Duplicate MAC addresses within a transparently bridged network confuses bridging tables, however. A bridge table can have only one entry for a MAC address; a station cannot appear on two interfaces. Otherwise, if a device sends a frame to the MAC address for Controller A in Figure 3-5, how can the transparent bridge know whether to send the frame to Controller A or Controller B? Both have the same MAC address, but only one can exist in the bridging table. Therefore, the intended resiliency feature will not work in the source-route transparent bridge mode. When using the resiliency feature, configure the Token Ring Concentrator Relay Function (TrCRF) for source-route bridging. The TrCRF defines ports to a common ring. The TrCRF is discussed later in the chapter in the "Token Ring Switching" section.
Source-Route Translational Bridging
Unfortunately, not all networks are homogenous. They may contain a mixture of Ethernet and Token Ring access methods. How would you attach a Token Ring network to an Ethernet such as the one shown in Figure 3-6?
Figure 3-6. Bridging Mixed Media Access Networks
Several obstacles prevent devices on the two networks from communicating with each other. Some of the obstacles include the following:
MAC address format
MAC address representation in the protocol field
LLC and Ethernet framing
Routing information field translation
MTU size mismatch
Translational bridging helps to resolve these issues, allowing the devices to communicate. But no standard exists for translational bridging, leaving a number of implementation details to the vendor. The following sections discuss in more detail each listed limitation. The sections provide a technical and a practical explanation of why transparent bridging might not be the best option.
MAC Address Format
When devices transmit frames, the bit sequence varies depending on the access method. An Ethernet frame has a format of DA|SA|Type|Data. But when the frame enters the media, which bit goes first? In Ethernet, the least significant bit of each octet does. Consider, for example, a hexadecimal value of 0x6A. In binary, this looks like: 0110 1010 with the most significant bit (MSB) on the left and the least significant bit (LSB) on the right. Ethernet transmits the LSB first. This is called the canonical address format. Token Ring and FDDI use a non-canonical format, transmitting the MSB first and the LSB last. The binary stream looks like 0101 0110 and has a hex value of 0x56. A translational bridge sequences the bits appropriately for the receiving network type so that the devices will see the correct MAC address. A canonical source MAC address of 0C-00-01-38-73-0B sent onto a Token Ring segment must have the address transmitted in non-canonical format as 30-00-80-1C-CE-D0. If the bridge does not perform address translation, the Token Ring device will respond to the wrong MAC address.
Embedded Address Format
Similarly, MAC address translation may need to occur at Layer 3. Some protocols embed the MAC address in the Layer 3 protocol header. IPX for example, uses a logical IPX address format comprising a network number and MAC address. In TCP/IP, the address resolution protocol (ARP) includes the source and destination MAC address in the frame as part of the IP protocol header. Other protocols that embed MAC addresses in the Layer 3 header include DECnet Phase IV, AppleTalk, Banyan VINES, and XNS. Many of these protocols respond to the MAC address contained in the Layer 3 header, not the data link layer. A translational bridge must therefore be intelligent and protocol-aware to know when to modify the Layer 3 information to correctly represent the MAC address. This is, of course, an activity normally relegated to a router, which operates at Layer 3. If a new protocol that needs translational bridging is added to the network, the bridge must be updated to know about the translation tasks. Translational bridging must keep abreast of industry protocols to allow inter-communication between the differently bridged devices.
LLC and Ethernet Frame Differences
Ethernet-formatted frames use a DA|SA|Protocol_Type format that, when bridged onto an IEEE 802 formatted network, presents the problem of what to do with the Protocol_Type value. IEEE 802 headers do not have a provision for the Protocol_Type value. The SNAP encapsulation approach was devised to carry the Protocol_Type value across IEEE 802-based networks. Figure 3-7 illustrates a translation from Ethernet to Token Ring SNAP.
Figure 3-7. Frame Translation from Ethernet to Token Ring SNAP
The frame fields illustrated in Figure 3-7 are as follows:
AC (access control)
FC (frame control)
DA (destination MAC address)
SA (source MAC address)
RIF (routing information field)
DSAP (destination service access point)
SSAP (source service access point)
Control (LLC control)
OUI (Organizational Unique Identifier vendor ID)
Type (protocol type value)
RIF Interpretation
When connecting source-route devices to transparent devices, another issue involves the routing information field. The RIF is absent from transparent devices but is vital to the Token Ring bridging process. How then does a source-route bridged device specify a path to a transparently bridged device?
A translational bridge assigns a ring number to the transparent segment. To an SRB device, it appears that the destination device resides on a source-routed segment. To the transparent device, the SRB device appears to attach to a transparent segment. The translational bridge keeps a source-routing table to reach the Token Ring MAC address. When a transparent device transmits a frame to the Token Ring device, the bridge looks at the destination MAC address, finds a source-route entry for that address, and creates a frame with a completed RIF.
MTU Size
Ethernet, Token Ring, and FDDI support different frame sizes. Table 3-5 lists the minimum and maximum frame sizes for these media access methods.
Table 3-5. Frame Size Comparison
Media Access Method
Minimum Frame Size (Octets)
Maximum Frame Size (Octets)
Ethernet
64
1518
Token Ring (4 Mbps)
21
4511
Token Ring (16 Mbps)
21
17839
FDDI
28
4500
A frame from one network type cannot violate the frame size constraints of the destination network. If an FDDI device transmits to an Ethernet device, it must not create a frame over 1518 octets or under 64 octets. Otherwise, the bridge must drop the frame. Translational bridges attempt to adjust the frame size to accommodate the maximum transmission unit (MTU) mismatch. Specifically, a translational bridge may fragment an IP frame if the incoming frame exceeds the MTU of the outbound segment. Routers normally perform fragmentation because it is a Layer 3 process. Translational bridges that perform fragmentation actually perform a part of the router's responsibilities.
Note, however, that fragmentation is an IP process. Other protocols do not have fragmentation, so the source must create frames appropriately sized for the segment with the smallest MTU. In order for these protocols to work correctly, they exercise MTU discovery, which allows the stations to determine the largest allowed frame for the path(s) between the source and destination devices. This option exists in IP, too, and is preferred over fragmentation.
Catalyst and Translational Bridging
Catalyst Token Ring modules do not provide translational bridging. An external Cisco router or the Route Switch Module (RSM) operating in a bridging mode, however, does support translational bridging. The most reliable interconnection method between different access types, however, is routing. Because routers are protocol-aware, they reliably translate all necessary elements of the frame when converting from Token Ring to other network types.
EAN: N/A
Pages: 223