cc/td/doc/cisintwk
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Source-Route Bridging (SRB)

Source-Route Bridging (SRB)

Background

The source-route bridging (SRB) algorithm was developed by IBM and proposed to the IEEE 802.5 committee as the means to bridge between all LANs. Since its initial proposal, IBM has offered a new bridging standard to the IEEE 802 committee: the source-route transparent (SRT) bridging solution. SRT bridging eliminates pure SRBs entirely, proposing that the two types of LAN bridges be transparent bridges and SRT bridges. Although SRT bridging has achieved support, SRBs are still widely deployed. SRT is covered in "Mixed-Media Bridging." This chapter summarizes the basic SRB frame-forwarding algorithm and describes SRB frame fields.

SRB Algorithm

SRBs are so named because they assume that the complete source-to-destination route is placed in all inter-LAN frames sent by the source. SRBs store and forward the frames as indicated by the route appearing in the appropriate frame field. Figure 25-1 illustrates a sample SRB network.

In Figure 25-1 , assume that Host X wants to send a frame to Host Y. Initially, Host X does not know whether Host Y resides on the same or a different LAN. To determine this, Host X sends out a test frame. If that frame returns to Host X without a positive indication that Host Y has seen it, Host X must assume that Host Y is on a remote segment.


Figure 25-1: An SRB network contains LANs and bridges.


To determine the exact remote location of Host Y, Host X sends an explorer frame. Each bridge receiving the explorer frame (Bridges 1 and 2, in this example) copies the frame onto all outbound ports. Route information is added to the explorer frames as they travel through the internetwork. When Host X's explorer frames reach Host Y, Host Y replies to each individually, using the accumulated route information. Upon receipt of all response frames, Host X chooses a path based on some predetermined criteria.

In the example in Figure 25-1 , this process will yield two routes:

Host X must select one of these two routes. The IEEE 802.5 specification does not mandate the criteria Host X should use in choosing a route, but it does make several suggestions, including the following:

In most cases, the path contained in the first frame received is used.

After a route is selected, it is inserted into frames destined for Host Y in the form of a routing information field (RIF). A RIF is included only in those frames destined for other LANs. The presence of routing information within the frame is indicated by setting the most significant bit within the Source Address field, called the routing information indicator (RII) bit.

Frame Format

The IEEE 802.5 RIF is structured as shown in Figure 25-2.

The RIF illustrated in Figure 25-2 consists of two main fields: Routing Control and Routing Descriptor. These fields are described in the summaries that follow.


Figure 25-2: A IEEE 802.5 RIF is present in frames destined for other LANs.


Routing Control Field

The Routing Control field consists of four subfields: Type, Length, D bit, and Largest frame. The fields are summarized in the following list:

-routing Descriptor Fields

Each -routing descriptor-routing descriptor field consists of two subfields:

Bridges add to the frame their bridge number and the ring number onto which the frame is forwarded. (The first bridge also adds the ring number of the first ring.)

Routes are alternating sequences of ring and bridge numbers that start and end with ring numbers. A single RIF can contain more than one -routing descriptor field. The IEEE specifies a maximum of 14 -routing descriptor fields (a maximum of 13 bridges or hops, because the last bridge number always equals zero).

Until recently, IBM specified a maximum of eight -routing Descriptor fields (a maximum of seven bridges or hops), and most bridge manufacturers followed IBM's implementation. Newer IBM bridge software programs combined with new LAN adapters support 13 hops.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Thu Jun 17 16:34:17 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.