Table of Contents

Background
DLSw Contrasted with Source-Route Bridging
DLSw SNA Support
DLSw Switch-to-Switch Protocol (SSP)
DLSw Operation

DLSw Processes

DLSw Capabilities Exchange
DLSw Circuit Establishment
DLSw Flow Control

DLSw Message Formats

Data-Link Switching

Background

Data-link switching (DLSw) provides a means of transporting IBM Systems Network Architecture (SNA) and network basic input/output system (NetBIOS traffic over an IP network. It serves as an alternative to source-route bridging (SRB), a protocol for transporting SNA and NetBIOS traffic in Token Ring environments that was widely deployed prior to the introduction of DLSw. In general, DLSw addresses some of the shortcomings of SRB for certain communication requirements---particularly in WAN implementations. This chapter contrasts DLSw with SRB, summarizes underlying protocols, and provides a synopsis of normal protocol operations.

RFC 1795 describes three primary functions of DLSw:

• The Switch-to-Switch Protocol (SSP) is the protocol maintained between two DLSw nodes or routers.

• The termination of SNA data-link control (DLC) connections helps to reduce the likelihood of link-layer timeouts across WANs.

• The local mapping of DLC connections to a DLSw circuit.

• Each of these functions is discussed in detail in this chapter. Figure 21-1 illustrates a generalized DLSw environment.

DLSw Contrasted with Source-Route Bridging

The principal difference between SRBand DLSw involves support of local termination. SNA and NetBIOS traffic rely on link-layer acknowledgments and keep-alive messages to ensure the integrity of connections and the delivery of data. For connection-oriented data, the local DLSw node or router terminates data-link control. Therefore, link-layer acknowledgments and keep-alive messages do not have to traverse a WAN. By contrast, DLC for SRB is handled on an end-to-end basis, which results in increased potential for DLC timeouts over WAN connections.

Although SRB has been a viable solution for many environments, several issues limit the usefulness of SRB for transport of SNA and NetBIOS in WAN implementations. Chief among them are the following constraints:

• SRB hop-count limitation of seven hops

• Broadcast traffic handling (from SRB explorer frames or NetBIOS name queries)

• Unnecessary traffic forwarding (acknowledgments and keep-alives)

• Lack of flow control and prioritization

Figure 21-2 illustrates the basic end-to-end nature of an SRB connection over a WAN link.

Local termination of DLC connections by DLSw provides a number of advantages over SRB-based environments. DLSw local termination eliminates the requirement for link-layer acknowledgments and keep-alive messages to flow across a WAN. In addition, local termination reduces the likelihood of link-layer timeouts across WANs. Similarly, DLSw ensures that the broadcast of search frames is controlled by the DLSw when the location of a target system is discovered. Figure 21-3 illustrates the flow of information and the use of local acknowledgment in a DLSw environment.

DLSw SNA Support

One of the advantages inherent with DLSw is that DLSw supplies broader device and media support than previously available with SRB. DLSw accommodates a number of typical SNA environments and provides for IEEE 802.2-compliant LAN support, which includes support for SNA Physical Unit (PU) 2, PU 2.1, and PU 4 systems and NetBIOS-based systems.

DLSw provides for Synchronous Data Link Control (SDLC) support, covering PU 2 (primary or secondary) and PU 2.1 systems. With SDLC-attached systems, each SDLC PU is presented to the DLSw Switch-to-Switch Protocol (SSP) as a unique Media Access Control (MAC)/service access point (SAP) address pair. With Token Ring--attached systems, a DLSw node appears as a source-route bridge. Remote Token Ring systems accessed via a DLSw node are seen as attached to an adjacent ring. This apparent adjacent ring is known as a virtual ring created within each DLSw node. Figure 21-4 illustrates various IBM nodes connected to a TCP/IP WAN through DLSw devices, which, in this case, are routers.

DLSw Switch-to-Switch Protocol (SSP)

SSP is a protocol used between DLSw nodes (routers) to establish connections, locate resources, forward data, and handle flow control and error recovery. This is truly the essence of DLSw. In general, SSP does not provide for full routing between nodes because this is generally handled by common routing protocols such as RIP, OSPF, or IGRP/EIGRP. Instead, SSP switches packets at the SNA data link layer. It also encapsulates packets in TCP/IP for transport over IP-based networks and uses TCP as a means of reliable transport between DLSw nodes. Figure 21-5 illustrates where SSP falls in the overall SNA architecture, as well as its relationship to the OSI reference model.

DLSw Operation

DLSw involves several operational stages. Two DLSw partners establish two TCP connections with each other. TCP connections provide the foundation for the DLSw communication. Because TCP provides for reliable and guaranteed delivery of IP traffic, it ensures the delivery and integrity of the traffic that is being encapsulated in the IP protocol, which, in this case, is SNA and NetBIOS traffic. After a connection is established, the DLSw partners exchange a list of supported capabilities. This is particularly vital when the DLSw partners are manufactured by different vendors. Next, the DLSw partners establish circuits between SNA or NetBIOS end systems, and information frames can flow over the circuit.

DLSw Processes

The overall DLSw operational process can be broken into three basic components: capabilities exchange, circuit establishment, and flow control. In the context of DLSw, capabilities exchange involves the trading of information about capabilities associated with a DLSw session. This exchange of information is negotiated when the session is initiated and during the course of session operations. Circuit establishment in DLSw occurs between end systems. It includes locating the target end system and setting up data-link control connections between each end system and its local router. DLSw flow control enables the establishment of independent, unidirectional flow control between partners. Each process in discussed in the sections that follow.

DLSw Capabilities Exchange

DLSw capabilities exchange is based on a switch-to-switch control message that describes the capabilities of the sending data-link switch. A capabilities exchange control message is sent after the switch-to-switch connection is established or during run time if certain operational parameters that must be communicated to the partner switch have changed. During the capabilities exchange, a number of capabilities are identified and negotiated. Capabilities exchanged between DLSw partners include the following:

• DLSw version number

• Initial pacing window size (receive window size)

• NetBIOS support

• List of supported link SAPs (LSAPs)

• Number of TCP sessions supported

• MAC address lists

• NetBIOS name lists

• Search frames support

DLSw Circuit Establishment

The process of circuit establishment between a pair of end systems in DLSw involves locating the target end system and setting up data-link control (DLC) connections between each end system and its local router. The specifics of circuit establishment differ based on traffic type.

NetBIOS circuit establishment parallels SNA circuit establishment, with a few differences. First, with NetBIOS circuit establishment, DLSw nodes send a name query with a NetBIOS name (not a canureach frame specifying a MAC address). Similarly, the DLSw nodes establishing a NetBIOS circuit send a name recognized frame (not an icanreach frame).

DLSw Flow Control

DLSw flow control involves adaptive pacing between DLSw routers. During the flow-control negotiation, two independent, unidirectional flow-control mechanisms are established between DLSw partners. Adaptive pacing employs a windowing mechanism that dynamically adapts to buffer availability. Windows can be incremented, decremented, halved, or reset to zero. This allows the DLSw nodes to control the pace of traffic forwarded through the network to ensure integrity and delivery of all data.

Granted units (the number of units that the sender has permission to send) are incremented with a flow-control indication (one of several possible indicators) from the receiver. DLSw flow control provides for the following indicator functions:

• Repeat---Increments granted units by the current window size.

• Increment---Increases the window size by one and increases granted units by the new window size.

• Decrement---Decrements window size by one and increments granted units by the new window size.

• Reset---Decreases window to zero and sets granted units to zero, which stops all transmission in one direction until an increment flow-control indicator is sent.

• Half---Cuts the current window size in half and increments granted units by the new window size.

Flow-control indicators and flow-control acknowledgments can be piggybacked on information frames or sent as independent flow-control messages. Reset indicators are always sent as independent messages.

Examples of adaptive-pacing criteria include buffer availability, transport utilization, outbound queue length, and traffic priority. Examples of how each can be used to influence pacing follow:

• Buffer availability---If memory buffers in a DLSw node are critically low, the node can decrement the window size to reduce the flow of traffic. As buffer availability increases, the node then can increase the window size to increase traffic flow between the DLSw partners.

• Transport utilization---If the link between two DLSw partners reaches a high level of utilization, the window size can be reduced to lower the level of link utilization and to prevent packet loss between the nodes.

• Outbound queue length---Traffic forwarded by a DLSw node typically is placed into an outbound queue, which is a portion of memory dedicated to traffic being forwarded by one device to another. If this queue reaches a specified threshold or perhaps becomes full, the number of granted units can be reduced until the queue utilization is reduced to a satisfactory level.

• Traffic priority---One of the unique capabilities of the SSP is the ability to prioritize specific traffic. These priorities are identified by the circuit-priority field in the DLSw message frame. By providing a varying number of granted units to specific DLSw circuits, the nodes can maintain different levels of priority to each circuit.

DLSw Message Formats

Two message header formats are exchanged between DLSw nodes:

The control message header is used for all messages except information frames (I frames) and independent flow-control messages (IFCMs), which are sent in information header format.

Figure 21-6 illustrates the format of the DLSw control and information fields. These fields are discussed in detail in the subsequent descriptions.

The following fields are illustrated in Figure 21-6 (fields in the first 16 bytes of all DLSw message headers are the same):

• Version Number---When set to 0x31 (ASCII 1), indicates a decimal value of 49, which identifies this device as utilizing DLSw version 1. This will allow future interoperability between DLSw nodes using different versions of the DLSw standard. Currently, all devices utilize DLSw version 1, so this field will always have the decimal value of 49.

• Header Length---When set to 0x48 for control messages, indicates a decimal value of 72 bytes. This value is set to 0x10 for information and independent flow control messages, indicating a decimal value of 16 bytes.

• Message Length---Defines the number of bytes within the data field following the header.

• Remote Data-Link Correlator---Works in tandem with the remote DLC port ID to form a 64-bit circuit ID that identifies the DLC circuit within a single DLSw node. The circuit ID is unique in a single DLSw node and is assigned locally. An end-to-end circuit is identified by a pair of circuit IDs that, along with the data-link IDs, uniquely identifies a single end-to-end circuit. Each DLSw node must keep a table of these circuit ID pairs: one for the local end of the circuit and the other for the remote end of the circuit. The remote data-link correlator is set equal to the target data-link correlator if the Frame Direction field is set to 0x01. It is equal to the origin data-link correlator if the Frame Direction field is set to 0x02.

• Remote DLC Port ID---Works in tandem with the remote data-link correlator to form a 64-bit circuit ID that identifies the DLC circuit within a single DLSw node. The circuit ID is unique in a single DLSw node and is assigned locally. The end-to-end circuit is identified by a pair of circuit IDs that, along with the data-link IDs, uniquely identifies a single end-to-end circuit. Each DLSw device must keep a table of these circuit ID pairs: one for the local end of the circuit and the other for the remote end of the circuit. The remote DLC Port ID is set equal to the target DLC Port ID if the Frame Direction field is set to 0x01. It is equal to the origin DLC Port ID if the Frame Direction field is set to 0x02.

• Message Type---Indicates a specific DLSw message type. The value is specified in two different fields (offset 14 and 23 decimal) of the control message header. Only the first field is used when parsing a received SSP message. The second field is ignored by new implementations on reception but is retained for backward compatibility with RFC 1434 implementations and can be used in future versions, if needed.

• Flow-Control Byte---Carries the flow-control indicator, flow-control acknowledgment, and flow-control operator bits.

• Protocol ID---When set to 0x42, indicates a decimal value of 66.

• Header Number---When set to 0x01, indicates a value of 1.

• Largest Frame Size---Carries the largest frame size bits across the DLSw connection. This field is implemented to ensure that the two end-stations always negotiate a frame size to be used on a circuit that does not require DLSw partners to resegment frames.

• SSP Flags---Contains additional information about the SSP message. Flag definitions (bit 7 is the most significant bit, and bit 0 is the least significant bit of the octet) are shown in Table 21-1.

• Circuit Priority---Provides for unsupported, low, medium, high, and highest circuit priorities in the three low-order bits of this byte. At circuit start time, each circuit endpoint provides priority information to its circuit partner. The initiator of the circuit chooses which circuit priority is effective for the life of the circuit. If the priority is not implemented by the nodes, the unsupported priority is used.

• Target MAC Address---Combines with the target link SAP, origin MAC address, and origin SAP to define a logical end-to-end association called a data-link ID.

• Origin MAC Address---Serves as the MAC address of the origin end station.

• Origin LSAP---Serves as the SAP of the source device. The SAP is used to logically identify the traffic being transmitted.

• Target LSAP---Serves as the SAP of the destination device.

• Frame Direction---Contains the value 0x01 for frames sent from the origin DLSw to the target DLSw node, or 0x02 for frames sent from the target DLSw to the origin DLSw node.

• DLC Header Length---When set to 0 for SNA and 0x23 for NetBIOS datagrams, indicates a length of 35 bytes. The NetBIOS header includes the following information:

  • Access Control (AC) field

  • Frame Control (FC) field

  • Destination MAC address (DA)

  • Source MAC address (SA)

  • Routing Information (RI) field (padded to 18 bytes)

  • Destination service access point (DSAP)

  • Source SAP (SSAP)

  • LLC control field (UI)

• Origin DLC Port ID---Works in tandem with the origin data-link correlator to form a 64-bit circuit ID that identifies the DLC circuit within a single DLSw node. The circuit ID is unique in a single DLSw node and is assigned locally. The end-to-end circuit is identified by a pair of circuit IDs that, along with the data-link IDs, uniquely identifies a single end-to-end circuit. Each DLSw node must keep a table of these circuit ID pairs: one for the local end of the circuit and one for the remote end of the circuit.

• Origin Data-Link Correlator---Works in tandem with the origin DLC port ID to form a 64-bit circuit ID that identifies the DLC circuit within a single DLSw node. The circuit ID is unique in a single DLSw and is assigned locally. The end-to-end circuit is identified by a pair of circuit IDs that, along with the data-link IDs, uniquely identify a single end-to-end circuit. Each DLSw node must keep a table of these circuit ID pairs: one for the local end of the circuit and one for the remote end of the circuit.

• Origin Transport ID---Identifies the individual TCP/IP port on a DLSw node. Values have only local significance. Each DLSw node must reflect the values, along with the associated values for the DLC port ID and the data-link correlator, when returning a message to a DLSw partner.

• Target Data-Link Correlator---Works in tandem with the target DLC port ID to form a 64-bit circuit ID that identifies the DLC circuit within a single DLSw node. The circuit ID is unique in a single DLSw node and is assigned locally. The end-to-end circuit is identified by a pair of circuit IDs that, along with the data-link IDs, uniquely identifies a single end-to-end circuit. Each DLSw node must keep a table of these circuit ID pairs: one for the local end of the circuit and one for the remote end of the circuit.

• Transport ID---Identifies the individual TCP/IP port on a DLSw node. Values have only local significance. Each DLSw node must reflect the values, along with the associated values for the DLC port ID and the data-link correlator, when returning a message to a DLSw partner.

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