Frame Relay Applications: Novell IPX & IBM SNA - Page 4

 By Cisco Press
Page 4 of 5   |  Back to Page 1
Print Article

SNA Data Link Protocols
Two reliable data link protocols are used for FEP/controller communication in the IBM SNA environment: Synchronous Data Link Control (SDLC) and Logical Link Control, type 2 (LLC2).

Modern SNA networks also support end-to-end sessions set up by the Advanced Peer-to-Peer Networking (APPN) protocol. Figure 15-24 illustrates an APPN infrastructure supporting communication between a mainframe, AS/400 hosts, and LAN systems.

NOTE:   APPN relies on LLC2 links.

IBM offers an extension to APPN that can optionally operate without LLC2: High Performance Routing (HPR). HPR can operate without an underlying [reliable] data link protocol. Retransmission and flow control is performed end-to-end by a higher layer protocol, similar to TCP within the TCP/IP protocol suite.

HPR traffic that does not operate on top of an LLC2 link can support transmission across Frame Relay links without encountering the issues associated with reliable links, such as SDLC or LLC2. An example of reliable link issues not found with HPR is an SDLC or LLC2 poll timeout.

Figure 15-24: APPN Network
Click image for larger view in a new window
(Click image for larger view in a new window)

The IBM SDLC protocol was designed for SNA-based networks and has a number of features that must be addressed when leased-lines are replaced by Frame Relay circuits. These features include the following:

  • SDLC is a master/slave polling protocol--An FEP or controller polls remote devices to ascertain whether they have data to be sent or received. SDLC polling traffic is heavy and consumes bandwidth. In addition, the FEP or controller must receive poll responses within a strictly predictable time limit, usually measured in a few seconds.
  • SDLC makes liberal use of control frames for flow control--A Frame Relay circuit that is carrying raw SDLC traffic will be congested with frequent SDLC polls and other control traffic.
  • Each SDLC information frame is numbered in sequence and contains frame acknowledgements--After a preset number of frames have been sent, data transmission will not proceed unless the sender receives an acknowledgement from the terminating partner (receiver).
  • SDLC is not used for LAN peer-to-peer communications--SNA LAN frames contain an LLC2 header that contains both the frame sequence and the acknowledgement numbers.
  • LLC2 does not have the polling overhead attributed to SDLC--LLC2 does have the overhead associated with reliable, ordered, flow-controlled delivery of data across a communications link.

Data-Link Switching (DLSw)
Data-link switching (DLSw) is a means of transporting SNA and NetBIOS traffic across a network using many different protocols. The original RFC 1434 described DLSw, but that RFC has been superceded by RFC 1795, which describes DLSw version 1. More recently, scalability enhancements have been introduced in DLSw version 2. Cisco has introduced some enhancements in its DLSw+ implementation that are backward compatible with both version 1 and version 2.

DLSw has the following advantages over SRB:

  • DLSw gets around the SRB 7-hop limit.
  • DLSw allows multiple connections across a network.
  • DLSw increases session response times.
  • DLSw provides flow control.
  • DLSw reroutes traffic around broken links.
  • DLSw removes the SRB heavy broadcast traffic.
Additionally, DLSw implementations provide SDLC to LLC2 conversion, eliminating the need for many Front End Processor (FEP) ports. DLSw supports RFC 1490, enabling LLC2 over Frame Relay and DLSw prioritization.

DLSw uses the Switch-to-Switch Protocol (SSP) in place of source route bridging (SRB) between routers. SSP is used to create DLSw peer connections, locate resources, forward data, and handle flow control and error recovery. TCP is used for DLSw encapsulation. A newer, standard version of DLSw is not restricted to TCP for encapsulation services.

The routers are called data-link switches. The data-link connections (DLCs) are terminated at the router, or data-link switch, so that the Routing Information Field (RIF) ends at a virtual ring within the router. Because DLCs are locally terminated, they can be locally acknowledged. This local acknowledgement means that the necessity for link layer acknowledgements or keeping alive messages to run across the WAN do not exist, minimizing session timeouts. Because the RIF ends at the peer router at each end, six hops can be added on each side of the virtual ring, thereby extending the network. With remote source-route bridging (RSRB), the RIF is carried all the way through the virtual ring, thereby limiting the number of hops. With DLSw, the virtual ring can be different in each peer because of the RIF termination.

Frame relay circuits that are carrying reliable link traffic incur a substantial amount of increased overhead. One Frame Relay circuit has the potential to carry several separate reliable links. Each link requires acknowledgement and flow control messages, which in turn require available bandwidth to carry the additional traffic.

The carrying of LLC2 links across a frame circuit can be avoided with the use of DLSw, as illustrated in Figure 15-25.

Figure 15-25: Data Link Switching (DLSw)
Click image for larger view in a new window
(Click image for larger view in a new window)

When DLSw is implemented, the LLC2 links are terminated at each router. Incoming data is transmitted across the Frame Relay WAN via a TCP session and is then forwarded across a new LLC2 link.

NOTE:   DLSw is not constrained to Frame Relay WANs; DLSw interoperates with any WAN technology.

The SNA traffic is preserved by the TCP sessions that support reliable data transfer. The TCP protocol, by its nature and design, adjusts well to sporadic transmission delays, efficiently manages acknowledgements, and carries out flow control without adding overhead to the communications flow.

Implementing DLSw has a disadvantage in that the TCP/IP headers add extra overhead to the transmitted data. This is generally worth the tradeoff compared to the overhead involved with the management of multiple independent LLC2 links.

This article was originally published on Feb 1, 2002
Get the Latest Scoop with Networking Update Newsletter