Figure 68. Backbone LAN Configuration
Because of the potentially high concentration of traffic on the common backbone LAN, a LAN segment with stable performance characteristics and possible higher bandwidth than the individual segments may be required.
As explained in "Basic CSMA/CD Concepts" on page 16 and "Basic Token Passing Ring Concepts" on page 22, a 4 or 16 Mbps token-ring network may be a more desirable choice for a backbone LAN segment than a CSMA/CD LAN segment.
As an example, the backbone LAN in Figure 68 could be a 16 Mbps IBM TOken-Ring Network, interconnecting a mixture of IBM PC Network (Broadband) LANs and 4 Mbps IBM Token-Ring Networks.
Because of high availability, backup and/or capacity considerations, one might consider implementing a duplex backbone, as a mirror image of the first one.
6. Bridges
153
6.1.1.2 Additional Design Considerations for Bridged LANs
154 LAN Concepts
When designing a bridged LAN, one cannot ignore the bridge protocol
implemented in the bridge products themselves. Special attention may have to be paid to specific bridge parameters.
The bridging technique discussed in "Transparent Bridging" on page 155, does not allow concurrently active parallel bridges or parallel routes.
When using a source routing bridge protocol as presented in "Source Routing"
on page 158, one may want to consider a bridge parameter called single route broadcast or hop count, to prevent flooding of the bridged network with control frames during route resolution.
When selecting a particular configuration, the bridge performance itself should be considered in addition to the above factors.
Bridge processing within a bridged local area network adds some degree of overhead to the overall network throughput. The amount of bridge overhead depends on several factors, some of which are listed below:
• Frame size: as the size of the frame increases, the bridge throughput increases. Thus the largest possible frame size should be used, subject to the constraints of applications, memory or buffer management.
• Bridge Hop Delay: this is the elapsed time between the end of the receive stage for a frame entering the bridge, and the end of the transmit process for the same frame leaving the bridge through another port. Thi.s time is seldom more than a few milliseconds, increasing as the frame size and LAN traffic loads increase, but potentially more important when the interconnected MAC protocols are different or run at different speeds.
End-user perception of application delay mayor may not be affected by bridge delays. As a general guideline, with slower applications, such as those involving disk access or host access, bridge delays will not normally be perceived. Other, faster applications such as program loads or
memory-to-memory copies, may be impacted when the frames must cross one or more heavily used bridges.
The following factors minimize the impact of the above delays:
• Frames flowing through a bridge may be given a higher traffic priority than normal LAN station frames, thus reducing the probability of bridge
congestion due to token-wait time.
• Route selection (based upon source routing) where more than one path is possible; is based upon the fastest rather than the shortest path.
In normal workload conditions, bridge processing does not constitute a bottleneck in a bridged LAN environment.
The IBM bridge products provide performance monitoring information to assist in monitoring traffic flow and bridge performance. See "IBM LAN Bridges" on page 163.
6.2 Bridging
As introduced earlier (" LAN Interconnection" on page 46), two different bridging architectures and protocols have to be considered.
IBM included in its Token-Ring Architecture; see IBM Token-Ring Network Architecture Reference a bridge architecture called source routing, and
developed products implementing this approach. This approach has now been included in the IEEE 802.5 Standard.
In parallel, the IEEE 802.1 subcommittee was working on a MAC bridge architecture called transparent bridging, which currently has the status of a Draft IEEE Standard. As a requirement of the IEEE 802 committees, source routing must be capable of interoperating with transparent bridging at the MAC level.
6.2.1 Transparent Bridging
This section describes the transparent bridging protocol and its associated spanning tree algorithm as drafted by the IEEE 802.1 subcommittee.
In this bridge architecture, there is a clear distinction between the actual, physical bridged LAN topology and the simply connected active topology, which reflects use of a spanning tree algorithm. Figure 69 on page 156 shows the physical configuration of a sample bridged LAN as well as a possible active topology.
In an active topology, frames are forwarded through those bridge ports which are said to be in forwarding state. Other bridge ports do not forward frames and are held in blocking state. Bridges only connect LAN segments to which they have attached ports in forwarding state. A port in blocking state may be put in forwarding state, that is become part of the active topology, if bridge components fail, are removed or are added.
In an active topology, one bridge is known as the root bridge. Each LAN Segment has a bridge port connected to it, called the designated port, which forwards frames from that segment to the root (bridge). The bridge to which the designated port for a particular LAN Segment belongs is called the
designated bridge. The root bridge is implicitly the designated bridge for all the LAN segments to which it is connected. At any particular bridge, the root port and the designated ports, if any, are the ports in forwarding state.
As an example, bridge 1 in the active topology sample presented in Figure 69 on page 156 has been selected as the root bridge. Therefore it is the
deSignated bridge for LAN segments 1 and 2. Bridge 2 is the designated bridge for LAN segments 3 and 4, while bridge 4 is the designated bridge for LAN segment 5. This structure can be represented as a logical tree topology, called a spanning tree, as shown in Figure 70 on page 157.
6. Bridges