This section provides conceptual information on the following topics:

• Source route, source route transparent bridging, and source route transparent bridging gateway (SRTG) definitions

• IEEE 802.5 token ring frame format

• Source route transparent bridging gateway concepts

• Route discovery process using ARE or STE frames

• End system source routing

• Routing tables

This section provides definitions for source route bridging, source route transparent bridging, and source route transparent bridging gateway (SRTG).

Source Route Bridging

Source route bridging is supported on token ring, FDDI, and the following wide area networks: Frame Relay, ATM, ATM DXI, SMDS, X.25, PPP, and ISDN. Source route bridges connect token ring LANs and enable peer-to-peer and terminal-to-host communications across both LAN and WAN token ring networks.

When source route bridging is enabled, the bridge forwards packets based on a route determined by the end system from which the packet originated. The end system initiating the communication is responsible for dynamically determining and then maintaining information about the route to the destination. The source route information is contained within the frame and indicates the path through an extended network from the source to the destination. Because the end system and not the bridge determines the route, a bridge using source route bridging does not record or learn information about addresses on the surrounding networks in the same way that a transparent bridge does. The exception to this rule is on a Frame Relay, ATM DXI, SMDS, or X.25 interface, where the DLCI, VPI.VCI, SMDS, or X.25 address associated with the remote ring is learned.

Source Route Transparent Bridging

This feature is not supported on model 32x and 52x SuperStack II NETBuilder bridge/routers.

Source route transparent bridging is a combination of transparent and source route bridging. The bridge automatically determines whether a packet should be forwarded using transparent bridging or source route bridging. For example, if the bridge receives a frame with routing information, the bridge performs source route bridging. If the bridge receives a frame without routing information, it performs transparent bridging. Source route transparent bridging is used in topologies in which transparent end systems and source route-only end systems coexist on the same network; source route transparent bridging allows the transparent end systems to communicate with transparent end systems and source route-only end systems to communicate with source route-only end systems.

Source Route Transparent Bridging Gateway

This feature is not supported on model 32x and 52x SuperStack II NETBuilder bridge/routers.

With SRTG, you can connect a source-routed network to a transparent bridging network. The SRTG software provides a translation between source route and transparent bridging domains so that token ring network users can communicate with Ethernet network users using source routing; Ethernet network users can communicate using transparent bridging with token ring network users as though they were on the same LAN. Upon receipt of frames from a source route domain, SRTG translates them into transparent bridging frames and removes the source routing information fields (RIFs). The SRTG software also adds appropriate RIF fields to transparent bridging frames before forwarding them to a source route network.

You can configure your bridge to use transparent bridging only, source route bridging only, transparent and source route bridging simultaneously, or SRTG. When configuring parallel bridges, 3Com recommends that you configure both bridges in the same bridge mode, either source route or source route transparent, to prevent unexpected blocking of one type of traffic due to the Spanning Tree Protocol. For more detailed conceptual information about SRTG, see "Source Route Transparent Bridging Gateway Concepts" later in this chapter.

IEEE 802.5 Token Ring Frame Format Overview

Source route bridging requires that each end system in an extended network dynamically determines and maintains the routing information necessary to communicate with other end systems on remote rings in the network. Each frame transmitted by an end system contains the routing information a source route bridge needs to decide whether to forward the frame to an adjoining ring.

This section describes some of the fields in the IEEE 802.5 token ring frame (shown in Figure 43) that are important to a general understanding of the route discovery process. Only the destination and source address fields, as well as the routing information field are discussed; not every field in an IEEE 802.5 token ring frame is discussed.

Figure 43 IEEE 802.5 Token Ring Frame Format

Destination address field	This 6-byte field identifies the end systems that are intended to receive and copy the frame.
Source address field	This 6-byte field identifies the system from which the frame originated. This field also contains a routing information indicator (RII) bit, which when set to 1, indicates the presence of the routing information field (RIF). If a source route bridge receives a frame with the RII bit = 1, it forwards the frame based on the routing information contained in the route designators (see the description of the routing information field). If a source route transparent bridge receives a frame with the RII bit = 0, it forwards the frame based on the destination address using the transparent bridging method.
Routing information field (RIF)	This 0- to 18-byte field contains routing control information and route designators (RD). The routing control information identifies, among other things, the type of source-routed frame, for example, an All Routes Explorer (ARE), Spanning Tree Explorer (STE), or specifically routed frame (SRF).
	An ARE frame is transmitted by the source end system to every ring in the extended network. Because the ARE frame is forwarded by a source route bridge to every connected ring, the destination end system receives as many copies of the ARE as there are routes to it. ARE frames are originally transmitted with no route designators; as the frame is forwarded by source route bridges, route designators are added to the frame.
	An STE frame is transmitted by the source end system and forwarded only by designated bridges, causing the frame to appear only once on every ring in an extended network. STE frames are originally transmitted with no route designators; as the frame is forwarded by source route bridges, route designators are added to the frame.
	An SRF contains the specific route information that allows a source route bridge to forward the frame along a defined network path.
	The RD field contains up to eight 2-byte route designators (route descriptors) of ring and bridge number information that describe the path to a destination.

Source Route Transparent Bridging Gateway Concepts

These concepts do not apply to model 32x and 52x SuperStack II NETBuilder bridge/routers.

The SRTG provides translation between source route and transparent bridging domains so that token ring network users can communicate using source routing with Ethernet network users, and Ethernet network users can communicate using transparent bridging with token ring network users. Upon receipt of frames from the source route domain, SRTG translates them into transparent bridging frames by removing the source route information fields (RIFs). SRTG adds appropriate RIF fields to transparent bridging frames before forwarding them to the source route network.

Spanning Tree Considerations

Two different spanning tree schemes exist for transparent bridging and for source routing. In transparent bridging, the Spanning Tree Protocol (STP) ensures that only one active path between any two stations exist in the network. In source routing, STP selects the bridges to forward the spanning tree explorer frames.

When both source route and transparent bridging domains are connected using SRTG, multiple gateways may be installed in parallel, either by mistake or on purpose, creating loops in the network topology. To eliminate loops and ensure a single active path between two stations, SRTG fully participates in the transparent STP.

To ensure compatibility with IBM 8209 or 8229 LAN bridges, the spanning tree entity on 3Com SRT gateways generates Bridge Protocol Data Units (BPDUs) as STE frames with a destination address set to the group address and the RII bit set. As shown in Figure 44, SRTG detects and breaks loops when there are multiple paths between SR and TB domains.

Figure 44 Spanning Tree Loop Detection by SRTG

Source route bridge A forwards the spanning tree BPDUs according to the source route spanning tree path to bridge B and C without recomputing the spanning tree algorithm. Bridge B forwards the BPDUs to bridge D, which drops them because the port is in the blocking state. Bridge C forwards BPDUs to bridge D and the IBM 8209 bridge. Bridge D receives them but does not perform the spanning tree computation nor forward them because its other port is in the blocking state. When the IBM 8209 bridge receives the BPDUs, it detects a loop and blocks the source routing port.

When the source routing port goes into a blocking state, all types of frames (ARE, STE, and SRF) are not forwarded. This behavior complies with the transparent bridging behavior but differs from pure source route bridging. When the primary and secondary SRT gateways change their role due to topology changes anywhere in the transparent bridging network (a primary gateway becomes secondary and vice versa), stations using the existing path may experience session disruption. Using parallel SRT gateways does not provide load balancing but does provide a backup path if the primary SRT gateway fails.

Packet Handling between Domains

When a packet is bridged from a source route domain to a transparent bridge domain using SRTG, the source route field of the frame is removed as shown in Figure 45. The RIF of the originator is cached with the direction bit in the route control field inverted for use by subsequent return traffic.

When a packet is bridged from a transparent bridge domain to a source route domain using SRTG, the packet is forwarded using the associated routing information from the source route table if the destination is known. If the destination is not known, the packet is immediately forwarded as an STE frame. The SRT gateway acts as a surrogate source routing station on behalf of all transparent bridge stations and uses a virtual ring number (set with the -SR GatewayVRing parameter) for its transparent bridge domain. Whenever bridging packets from the transparent bridge to source route domain, SRTG adds the virtual ring number and its own bridge number to the source route information of the destination station retrieved from the source route table. From the point of view of a source routing station, the entire transparent bridge LAN appears as a single source routed ring as shown in Figure 45.

Figure 45 Virtual Ring and Frame Translation

Source Route to Transparent Bridge Domain Packets.

SRTG handles ARE, STE, and SRF frames as described in Table 22.

Table 22 Source Route to Transparent Bridge Domain Packet Handling

Frame Type	How Handled
ARE	An ARE frame with a group address (broadcast or functional) is forwarded onto the transparent bridge domain, but its source route information is not cached.
	An ARE frame with a specific destination address is forwarded onto the transparent bridge domain only when the destination address does not exist on the source route domain. If the source address is not found in the source route table, SRTG creates one. If the source address is found in the source route table, SRTG updates the old entry with the new route information if different.
	An ARE frame is copied as many times as available paths, and traverses all possible paths overriding the spanning tree configuration, causing SRTG to receive multiple copies of a packet if there are multiple paths. To prevent multiple copies from being forwarded to the transparent bridge domain, SRTG saves the source route from the first copy, considers it the optimal route, and discards the subsequent copies.
STE	An STE frame with a group (broadcast or functional) address is forwarded onto the transparent bridge domain, but route caching does not occur. An STE frame with a specific destination address is forwarded onto the transparent domain if the target station is not on the same source route domain. When forwarding a unicast STE frame, SRTG creates a new entry if an entry is not found in the source route table and the target station is known to exist on the transparent domain. If a source route entry already exists in the source route table, SRTG updates the entry but marks it as temporary. Because routes learned from STE frames may not be optimal, they are overwritten by any subsequent SRF frame from the source station.
SRF	Regardless of the destination address, SRTG forwards any SRF frame to the transparent bridge domain when RIF indicates the virtual ring. SRTG checks the ring out number and if it matches the SRTG virtual ring number, the SRF frame is translated and forwarded to the transparent bridge domain. If the destination station is already learned, the SRF frame is sent to a specific port. Otherwise, the SRF frame is flooded on all source route and SRTG ports except the source port. If no source route entry associated with the source station is found, SRTG creates one. If an entry is found but is temporary, SRTG updates the old entry and removes the temporary flag.

Transparent Bridge to Source Route Domain Packets.

When SRTG receives a packet from transparent bridge domain, it forwards the packet using the associated routing information from the source route table if the destination address exists in the database. If the destination does not exist in the source route table, SRTG immediately forwards the packet in a STE frame to reduce possible excessive traffic. Whether the destination address exists or not, SRTG adds the virtual ring number configured for the transparent bridging domain to the RIF field retrieved from the source route table.

Frame and Address Conversion

This section focuses on LAN-specific media (Ethernet, token ring, and FDDI) and the different packet formats. Frame conversions are necessary because Ethernet supports two different formats: Ethernet Version II frame and IEEE 802.3 frame.

In a source route token ring network, there are two ways to form a packet. IEEE 802.2 (LLC) encapsulation is used for LLC2 and NetBIOS packets while other protocols, such as IP, use SNAP encapsulation. To ensure compatibility with IBM's 8209 implementation of delivering bridged packets to a target station in its expected format, SRTG keeps track of the encapsulation format of each Ethernet station.

Ethernet 802.2 Conversion to and from Token Ring 802.2.

Because both Ethernet and token ring supports IEEE 802.2 encapsulation, conversion of Ethernet 802.2 frames to token ring 802.2 encapsulation is a simple task. SRTG removes the length field and adds the RIF field when it converts frames from Ethernet 802.2 to Token Ring 802.2. SRTG removes the RIF field and adds the length field (padding may be required for small frames) when it converts frames form Token Ring 802.2 to Ethernet 802.2. These frame conversions are shown in Figure 46.

Figure 46 Ethernet 802.2 Conversion to or from Token RIng 802.2

LLC-based Token Ring Conversion to and from Ethernet II

To support the coexistence of both Ethernet II and Ethernet 802.3 frames on the same LAN, SRTG provides options in the -SR GatewayControl parameter to translate LLC-based packets to Ethernet II frames as follows:

• The destination service access point (DSAP) field in the token ring 802.2 frame must be a multiple of 4 (for example, 00, 04, 08, and so forth), except 0xBC and 0xE0, which are reserved for Banyan VINES and IPX, respectively.

• If SRTG is configured with the NoAutoMode setting, SRTG does not keep track of the encapsulation type of each transparent bridge station. The final encapsulation format is determined by the IeeeMode or EtherMode setting of the GatewayControl parameter. If it is set to EtherMode, Ethernet II encapsulation with type 0x805D is used. If it is set to IeeeMode, LLC-based packets are translated into the IEEE 802.3 format.

• If SRTG is configured with the AutoMode setting, different packet translation rules are used for known and unknown stations. For known stations, the IeeeMode | EtherMode setting is ignored and the encapsulation format learned for each station is used. For unknown stations, LLC2-based packets are translated based on the IeeeMode | EtherMode setting.

This resulting frame looks like an Ethernet II format. LLC data are not placed inside an 802.3 frame but placed into an Ethernet Version II frame whose type is specified as 0x80D5 and shown in Figure 47.

Figure 47 LLC-based Token Ring Conversion to and from Ethernet II

Maximum Frame Size

The maximum frame sizes used by Ethernet and token ring networks are different. To solve this frame length mismatch, SRTG automatically sets the largest frame size bit in the Route Control field to 1450 octets whenever it forwards frames to the token ring network (see Table 21). SRTG drops data packets from token ring or FDDI if the packets are larger than the Ethernet maximum frame size.

Route Discovery Process

An end system (PCs and workstations) with source route support installed can dynamically determine the routing information it needs to communicate with other end systems on remote rings interconnected by source route or source route transparent bridges. The route discovery process consists of the exchange of messages between the source and the destination end systems. Because no current standard for route discovery exists, the method that the end system uses may be protocol specific; therefore, a general description of the end system route discovery process is provided with details about how the 3Com bridge/router participates in the route discovery process.

The end station sends an explorer packet (for example, a TEST or XID frame, or a protocol-specific frame, in an ARE or STE) with the destination address in the header. If an ARE frame is transmitted by the source system and the source route bridge receives it, the source route bridge adds its bridge number and ring number of the adjoining ring to the RD fields, and forwards the frame to all of its source route bridging interfaces. The next source route bridge repeats the same process until the destination system recognizes its MAC address in the destination address field of the header and copies the frame.

If multiple paths to the destination system exist, the destination will receive as many explorer frames as there are paths and must respond to each explorer frame. The destination system responds to the ARE (each and every one) by sending an specifically routed frame (SRF). The frame contains all the routing information needed to forward the frame back to the source. In fact, when the source route bridge receives an SRF, it forwards the frame according to the embedded source route information in the RD fields. When the source system recognizes its MAC address, it copies the frame and uses the routing information within the frame for all subsequent communications with that destination system.

If an STE frame is transmitted by the source system and the source route bridge receives it, the source route bridge adds its bridge number and ring number of the adjoining ring to the RD fields. The source route bridge only forwards the frame to the source route bridging interfaces that are not blocked because of the Spanning Tree Protocol, resulting in only one STE frame appearing on each ring. Each source route bridge in the spanning tree path follows the same procedure.

When the destination system recognizes its MAC address in the destination address field of the header, it copies the frame and responds to the STE by sending an ARE. The ARE frame is used so that all possible routes to the source can be found. On the return trip to the source system, the source route bridge forwards the ARE frame to all source route interfaces. When the source system recognizes its MAC address, it copies the frame (multiple responses may be received) and uses the routing information from the preferred ARE for all subsequent communications with that destination system.

When the 3Com bridge/router functions as an end system, it initiates the route discovery process by sending a TEST/XID STE frame. Upon receiving the frame, the destination system sends an ARE frame as described in the previous paragraph, except that the 3Com bridge/router caches the first ARE that it receives and discards all the other ARE responses.

End System Source Routing

Route discovery for end system source routing is supported on token ring and FDDI networks and wide area networks using PPP, Frame Relay, ATM DXI, SMDS, or X.25. Using end system source routing, the router acting as an end system can discover end systems not already present in the end system routing table. This is useful in situations in which the router receives a packet, but does not have a source route to the destination station on the source route network. If route discovery is enabled, the router determines the best route to the destination station by initiating a route discovery process and caching the discovered route in the routing table.

You normally use route discovery in configurations where the router is attached to a source route bridged environment. To enable routing in a source route environment, you must configure route discovery on the port directly connected to the source route bridged domain.

For any given port, you can configure the router to initiate route discovery for any combination of the following types of routing protocol packets:

• AppleTalk

• CLNP (OSI)

• DECnet

• IP (route discovery using an ARP packet)

• IPX

• VINES

You can also configure a port to initiate route discovery for DLTest packets.

Routes to a destination end system are discovered using LLC TEST/XID command frames. The route associated with the first TEST/XID response is cached in the routing table until its hold time has expired. Enabling route discovery allows end systems located in transparent-only, source route-only, or source route transparent environments to be reached.

Routing Tables

You can access the routing table of end system by entering the SHow -SR AllRoutes command. For complete information on this parameter, see the SR Service Parameters chapter in Reference for Enterprise OS Software.

A source route bridge forwards a packet based on a route determined by the end system from which the packet originated. Routes are discovered on ports where the -SR RouteDiscovery parameter is enabled for one or more protocol packets. The routes learned by the bridge are cached in a routing table.

The two types of routing table entries are learned (dynamic) entries and user-assigned (static) entries.

• Learned (dynamic) entries are entries that the router learns from route discovery packets received from communicating end systems. The learned entries are subject to dynamic changes or deletion at intervals determined by the -SR HoldTime parameter (the default is 15 minutes).

• User-assigned (static) entries are entries assigned using the ADD -SR ROUte command. The static entries can be changed or deleted only through the ADD or DELete commands. These entries also are referred to as permanent entries.