There are essentially two kinds of bridges. The first type is a Source Route Bridge, 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. Source Route Bridging is commonly used with Token Ring networks, while Transparent Bridging is popular with Ethernets, where it is used by Ethernet switches.
So 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 nonroutable 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 will only cover 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.
| SAP number | Binary | 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 Mgmt & 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 facility 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 the source and destination SAP numbers (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. Any place where 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.
| 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 only wanted to permit NetBIOS traffic, blocking 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 only follows 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).
Spanning Tree is a protocol that eliminates loops from a bridged network. It is important to remember that running Spanning Tree is optional, and not every bridge is configured to run this protocol. It is frequently not used, in fact, in DLSw+ networks because the protocol has the ability to do useful things like load sharing between links. Spanning Tree 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. The Root Bridge has an exhaustive table of MAC addresses, and it 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 is simply one that 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 each other 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.
Obviously this process can 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, and 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 only need to use the APPN code set 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.
We note in passing, though, that 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 only be necessary to support legacy SNA equipment