Introduction

There are essentially two kinds of bridges. The first type is a Source Route Bridge (SRB), which allows end devices to request a particular path through the network using a Routing Information Field (RIF) in the packet. In the default case, this type of bridge cannot forward any packet without a RIF. The second type is a Transparent Bridge, which hides all of that network detail from end devices. Transparent Bridges have no concept of a RIF. SRBs are commonly used with Token Ring networks, while Transparent Bridging is popular with Ethernets, where it is used by Ethernet switches.

Bridging between Ethernet and Token Ring networks requires a special hybrid of these two that is able to translate between not only the media types, but also the bridging types. The Remote Source Route Bridging (RSRB) and Source Route Transparent (SRT) bridging protocols were invented to solve this problem, particularly over WANs.

Data Link Switching (DLSw) and DLSw+, which is Cisco's enhanced version of DLSw, also solve these problems and comply with the same bridging standards. These protocols are capable of connecting Token Rings to Ethernets, Synchronous Data Link Control (SDLC) serial connections, and even X.25 networks. So there is really very little reason to worry about the older bridging protocols and methods anymore. If you are considering building a new network involving the System Network Architecture (SNA) protocol, there is no particular reason to bother with either SRB or RSRB. If you have an existing network involving these protocols, it would be wise to consider moving to the more modern and flexible DLSw or DLSw+.

Because DLSw creates bridges that are able to connect different (or similar) Layer 2 media together, it clearly has many applications beyond SNA, although that is the most common reason for deploying DLSw. It can also be used when bridging LAN segments for other non-routable protocols such as NetBIOS and Local Area Transport (LAT). And it can be used in conjunction with routing on the same interfaces so that some protocols are routed and others are bridged.

DLSw is an open standard protocol for bridging through TCP/IP networks. It was originally developed by IBM as a proprietary standard in 1992 and became an open standard with the publication of RFC 1434 the following year. Version 1 of the DLSw protocol was defined in detail in 1995 in RFC 1795, and updated to create Version 2 in 1997 in RFC 2166. This set of updates does not affect the underlying protocol, but rather extends its functionality. Meanwhile, Cisco independently implemented a distinct set of extensions to DLSw Version 1 and called the result DLSw+.

There are currently three different common versions of the protocol with different capabilities supported by different vendors: Version 1, Version 2, and DLSw+. Fortunately, all versions include a capabilities field that is used when two devices first attempt to make a DLSw connection. This allows them to agree on a set of common features. In most cases this results in good transparency of operation among different vendors. However, it is useful to be aware of what features will not be supported when interconnecting in this way.

Most of the DLSw+ enhancements allow for greater scalability and variety of transport mechanisms. For example, DLSw+ allows the transport mechanism to be Fast-Sequenced Transport (FST), Frame Relay, or High-Level Data Link Control (HDLC) protocols (as well as TCP/IP). This book covers only the TCP/IP version, however. Other DLSw+ enhancements, such as peer groups and border peers, improve scalability and allow you to build a large bridged network out of smaller groups of devices that pass limited amounts of information between them as required.

Service Access Points (SAP and LSAP)

The Logical Link Control layer, IEEE 802.2, defines Service Access Points (SAP) and Link Service Access Points (LSAP). These are conceptually similar to TCP port numbers in many ways, although it is important to remember that they operate at the Logical Link Layer (Layer 2), not the Transport Layer (Layer 4), as TCP does. They are simply numbers that a device uses when it wants to establish a connection to another device to run a particular application. The number specifies a particular application protocol. The packets establishing a connection specify both a Source SAP number (SSAP) and a Destination SAP number (DSAP). These are, obviously enough, the SAP numbers of the source and destination applications. Table 15-1 lists several of the most common SAP numbers.

Table 15-1. Common SAP numbers

Hex SAP number	Binary SAP number	Description
00	0000 0000	Null LSAP
02	0000 0010	Individual LLC sublayer management
03	0000 0011	Group LLC sublayer management
04	0000 0100	Individual SNA path control
05	0000 0101	Group SNA path control
06	0000 0110	IP
07	0000 0111	IP
08	0000 1000	SNA
09	0000 1001	SNA
0C	0000 1100	SNA
0D	0000 1101	SNA
0E	0000 1110	PROWAY network management and initialization
18	0001 1000	Texas Instruments
42	0100 0010	802.1 spanning tree protocol
4E	0100 1110	EIA RS-511 manufacturing message service
7E	0111 1110	X.25 over 802.2 LLC
80	1000 0000	Xerox Network Systems (XNS)
86	1000 0110	Nestar
8E	1000 1110	PROWAY active station list maintenance
98	1001 1000	Address Resolution Protocol (ARP)
AA	1010 1010	Sub-Network Access Protocol (SNAP)
BC	1011 1100	Banyan Vines
E0	1110 0000	Netware
F0	1111 0000	NetBIOS
F4	1111 0100	Individual LAN management
F5	1111 0101	Group LAN management
F8	1111 1000	Remote Program Load (RPL)
FA	1111 1010	Ungermann-Bass
FE	1111 1110	ISO network layer protocol
FF	1111 1111	Global LSAP

Cisco routers include the ability to filter based on LSAP numbers using access lists in the range from 200 to 299. Here is an example of the syntax of an LSAP access list:

access-list 201 permit 0x0000 0x0D0D

The first hexadecimal number after the permit keyword represents both SSAP and DSAP. The first two hex digits are the SSAP, and the second two are the DSAP. The next field is a wildcard bit pattern. When the wildcard has a 0 bit, the corresponding bit in the SAP numbers must be exactly as it is in the given pattern, and any place where the wildcard has a 1 bit can have either a zero or a one.

The mask in this particular example is 0x0D0D. The hex number D has a bit pattern of 1101. So, the access list as written will allow any packets with either SSAP or DSAP values shown in Table 15-2.

Table 15-2. SAP values matched by the example ACL

Hex	Binary	SAP
0x00	0000 0000	Null LSAP
0x01	0000 0001	Unused
0x04	0000 0100	Individual SNA path control
0x05	0000 0101	Group SNA path control
0x08	0000 1000	SNA
0x09	0000 1001	SNA
0x0D	0000 1101	SNA

Such access lists are usually used to block unwanted local ring traffic such as NetBIOS or Netware, while permitting the SNA traffic. If, on the other hand, you wanted to permit only NetBIOS traffic and block all other protocols, you could use an access list like this:

access-list 202 permit 0xF0F0 0x0000

Explorers and RIFs

When a device wants to send a packet using Logical Link Control (LLC) protocols through a bridged network, it has the capability of source-routing this packet. This means that the end device is able to specify a particular network path. To do this, however, it first has to find an appropriate path. It does this by sending a packet called an explorer through the network. As this explorer packet passes through the network, each bridge adds information about itself to the packet and forwards it along. So when it finally arrives, it has a complete path description that the end device can use to build a RIF.

There are, in fact, two different kinds of explorers, called spanning tree explorers and all routes explorers. They both perform the same basic function of trying to map the best path to the required destination. The difference, however, is that a spanning tree explorer follows only one path, and the all routes explorer attempts all paths. When a bridge receives a spanning tree explorer, it forwards the packet along a single path defined by the Spanning Tree Protocol (STP).

STP eliminates loops from a bridged network. It is important to remember that running STP is optional, and not every bridge is configured to run it. It is not frequently used in DLSw+ networks because the protocol has the ability to do useful things such as load sharing between links. STP inherently prevents load sharing among the many different possible paths through a network by shutting down all paths except for one.

Note that STP is required on transparently bridged networks, however, because there is no RIF to control path selection. If you have multiple connections between transparent bridges, such as Ethernet switches, you must use STP.

STP ensures that there is one and only one active path between any two points by first electing a root bridge. This device is the logical center of the bridged network. When a bridge receives a packet destined for a device that is not on one of its ports, it simply forwards that packet toward the center. The packet may take several hops to reach the root bridge, which has an exhaustive table of MAC addresses and knows how to forward every packet that it receives. If it doesn't know the destination, it will duplicate the packet and send it out every path except the one it was received on, in the hopes of finding the destination.

A spanning tree explorer packet simply follows the STP path through the network to reach the required destination. An all routes explorer works similarly, but it follows all possible paths to reach the ultimate destination. At each bridge where there is a choice to be made between two or more possible paths, the bridge duplicates the packet and forwards it along all of them. So the destination device will probably receive several possible solutions. In general, it will pick the first one it receives on the assumption that this must represent the fastest path.

When the destination device receives an explorer packet, it turns it around and sends it back to the original source, retaining the routing information. Now both devices know how to request a path to one another through the network when they need to exchange information. When they send packets of application data, they will include a Routing Information Field (RIF) that specifies the desired path.

This process can obviously get messy if there are a lot of devices all trying to find one another at the same time. So DLSw+ includes some optimizations that allow routers to improve on the RIF discovery process. Every router contains a RIF cache of all of the remote devices that it knows how to reach. When a device on the local Token Ring sends an explorer looking for something the router already knows how to reach, DLSw doesn't need to bother forwarding this explorer through the network. Instead, it responds directly without having to consume network resources forwarding the explorer.

Cisco IOS Code Sets

One common misunderstanding that people have about DLSw+ is that to implement Cisco routers in a network using IBM's Advanced Peer-to-Peer Networking (APPN) functionality, you have to use one of Cisco's APPN code sets. This is not the case. The core DLSw+ functionality is included in the default minimal IP-Only IOS code set for all 12.x and most 11.x IOS levels. You need to use the APPN code set only if you intend for the router to take an active part in the higher layer protocols.

APPN is effectively the next generation version of SNA. Among many improvements, it makes the protocol routable for improved scalability. However, APPN still runs over the same lower layer protocols such as LLC2 on Token Rings and SDLC on serial interfaces. So, in most cases the router doesn't need to know whether APPN or SNA is used at higher layers.

The APPN code set is required only if the router needs to provide native APPN routing. In most cases, even networks using APPN within the mainframe and its Front End Processor (FEP), the bridging functions of DLSw+ are sufficient to provide all of the required connectivity.

The most recent generations of mainframe computers from IBM are capable of supporting TCP/IP and Gigabit Ethernet directly, so we expect that the future of mainframe networking will use IP rather than APPN. In this case, SNA and DLSw will be necessary only to support legacy SNA equipment.