Applications of Frame Relay

Article
10/27/2009

By Dr. Sidnie Feit

Chapter II-10 from Wide Area High Speed Networks, published by MacMillan Technical Publishing

After looking at frame relay architecture, technology, and protocols, you'd think you would be all ready to implement a frame relay network. In the real world, however, getting frame relay to work is not as simple as it sounds in a technology discussion.

This chapter presents some of the special problems IP, IBM SNA, and voice traffic pose for frame relay and describes the solutions that have been developed.

Frame Relay and IP

The TCP/IP protocol suite has become a widely accepted standard for network communications. IP, the Internet Protocol, is the component of the TCP/IP suite that is responsible for routing data to its destination. IP operates at layer 3, the network layer. (TCP operates at layer 4.)

IP is a best-effort delivery service that carries layer 3 protocol data units called IP datagrams from source systems to destination systems. Frame relay is very well-suited to carrying IP datagram traffic, which typically is bursty in nature. Frame relay and IP are a well-matched team—they work well together to make efficient use of wide area bandwidth.

Figure 10.1 shows the relationship between the IP and frame relay protocols.

The sections that follow present some of the ways that frame relay circuits are used within IP networks and explain inverse ARP, which is a shortcut that automates a key step in configuring IP to work with frame relay.

Figure 10.1: IP and frame relay layering.

Using Frame Relay in an IP Network

A frame relay circuit can simply be used as a replacement for a point-to-point leased line in an IP network. For example, Site A and Site B in Figure 10.2 are connected by a frame relay circuit instead of a more costly leased line. 199.17.28.200 and 199.17.28.201 are the IP addresses assigned to the router interfaces that connect to the frame relay virtual circuit.

Figure 10.2: Replacing a leased line with a frame relay circuit.

Virtual IP Subnets

Multiple IP routers can be connected into a frame relay configuration that behaves like a virtual LAN—or in IP terminology, a virtual IP subnet. An IP subnet is a set of systems (usually located on a LAN) that have some special characteristics:

Their IP addresses start with the same network and subnet numbers.
Any system can communicate directly with any other system in the subnet. Data will not flow through an intermediate router.

Figure 10.3 shows three routers that are connected by frame relay circuits. This is a fully meshed set of connections—that is, each system has direct connections to the other systems and hence can communicate directly with the other systems.

A set of fully meshed systems can be treated as a virtual IP subnet. In Figure 10.3, each interface is given an IP address that starts with the same network and subnet numbers. Note that even though there are two separate frame relay virtual circuits at each interface, each interface has been assigned a single IP address.

Figure 10.3: A virtual IP subnet.

In Figure 10.4, a new circuit has been set up between Router A and Router D. Router D is not fully meshed with the other routers, and the connection between Routers A and D is treated as a separate subnet. New IP addresses are assigned at each endpoint of the connection.

Thus:

Sometimes, a single IP address can be assigned to an entire frame relay interface.
In other cases, one or more DLCIs form a subinterface. Each subinterface is assigned an IP address. (It also is possible to leave the endpoint of a point-to-point connection unnumbered. However, this is not relevant to the present discussion.)

Figure 10.4: Adding a new IP subnet.

Packaging IP Datagrams

Figure 10.5 shows the simple IETF encapsulation that is used to carry IP datagrams. Recall that ISO has assigned the NLPID value X'CC to IP. The frame relay address field is followed by a 1-byte X'03 control field and the IP NLPID.

Figure 10.5: IETF encapsulation for IP.

Figure 10.5: IETF encapsulation for IP.

The section in Chapter II-6 titled "Frames with Unique NLPIDs" contains a listing of an encapsulated IP datagram (see Listing 6.1, "Network Layer Protocol ID Value").

Address Resolution Protocol (ARP)

Systems on a LAN transmit data to one another by wrapping the payload in a LAN frame whose header contains the layer 2 Media Access Control (MAC) address of the destination's LAN interface card. A system cannot communicate with a neighbor until it has discovered the neighbor's MAC address. This discovery step is carried out by means of a procedure called the Address Resolution Protocol (ARP).

Figure 10.6 shows how ARP operates for IP systems on an Ethernet LAN. Host A, which has IP address 172.16.1.40, wants to connect to Server B, which has IP address 172.16.1.1. Host A broadcasts an ARP query message asking the system that has IP address 172.16.1.1 to respond. Server B replies, providing its Ethernet MAC address.

Figure 10.6: Using ARP to discover a system's MAC address.

Host A maintains an Ethernet ARP table that records layer 3 IP address to layer 2 MAC address translations. Host A uses the server's response to add a new row to this table:

IP Address	MAC Address
172.16.1.1	00-60-08-BD-7D-2A

Server B also has benefited from the exchange of messages. The ARP request contained Host A's IP address and hardware address, so Server B also can add an entry to its ARP table.

ARP is not confined to IP and Ethernet. It is used to translate many different layer 3 network address types to many different layer 2 interface address types. The fields in an ARP message are shown in Table 10.1. Note that an ARP request has operation code 1 and the response has operation code 2. The desired (target) hardware address is set to X'000000000000 in the outgoing request.

The example shown in Table 10.1 relates to Ethernet and Ethernet hardware addresses. But note how flexible the ARP message format is. It was designed to be used with any type of hardware.

Table 10.1 Fields in an ARP Message

Field	Field Size	Ethernet Example
Type of hardware	2 bytes	Ethernet = 1
Type of layer 3 protocol	2 bytes	IP = X'0800
Length of each hardware address	1 byte	6 for Ethernet
Length of each protocol address	1 byte	4 for IP
Operation code	2 bytes	ARP request = 1;ARP response = 2
Source hardware address	As indicated	006008A124D1
Source protocol address	As indicated	172.16.1.40
Target hardware address	As indicated	In a request,000000000000
Target protocol address	As indicated	172.16.1.1

Inverse ARP

ARP allows a system to build a table that maps the IP addresses of systems on a LAN to the layer 2 MAC addresses of the systems. Inverse ARP, however, makes it even easier to build a table that maps the IP addresses of systems connected by a frame relay virtual LAN to the layer 2 DLCIs of the circuits that connect to the systems.

The routers in Figure 10.7 are interconnected by frame relay circuits and form a virtual LAN.

Router A needs to find out the IP addresses of its neighbors before it can forward traffic to them using the IP protocol. Router A also needs to match each neighbor's IP address to the DLCI that is used to reach the neighbor. That is, Router A needs a table of the form:

IP Address	DLCI Number
199.17.28.201	21
199.17.28.202	22

The left column holds the IP address of a neighbor that Router A wants to reach. The right column identifies the circuit that leads to that neighbor.

Figure 10.7: IP addresses and DLCIs for a virtual subnet.

An administrator could configure a table like this into each router manually, but it is a lot easier to let the routers build their tables automatically. The most efficient way to build this table is for each router to follow the procedure:

Send a message across each virtual circuit asking for the value of the IP address at the remote end.
Record the IP address and the corresponding virtual circuit DLCI in the table.

The ARP message format is reused for this purpose along with a modified procedure that is called inverse ARP. New operation codes have been defined to identify the inverse ARP request and response messages:

8 Inverse ARP request message

9 Inverse ARP response

Figure 10.8 illustrates an inverse ARP conversation.

Inverse ARP Encapsulation and Trace

Figure 10.9 shows how an inverse ARP message is encapsulated when it is sent across a frame relay network.

Figure 10.8: Inverse ARP request and response.

Figure 10.9: Inverse ARP message encapsulation for frame relay.

Figure 10.9: Inverse ARP message encapsulation for frame relay.

Listing 10.1 shows an inverse ARP request message.

Listing 10 Inverse ARP Request Message

Decode from WinPharoah

-------------Frame Relay Q.931 Format (ANSI T1.607)-------------

Direction = DTE->DCE

Address Field (2 octets) = 0451

DLCI = 21 (Assigned using frame relay connection procedures)

Address Octet 1

0000 01.. DLCI (High-order)

.... ..0. C/R - Command/Response indicator

.... ...0 EA - Address field extension bit

Address Octet 2

0101 .... DLCI - (Low-order)

.... 0... FECN - Forward Explicit Congestion Notification

.... .0.. BECN - Backward Explicit Congestion Notification

.... ..0. DE - Discard Eligibility

.... ...1 EA - Address Field Extension

Control field = 03 Unnumbered(UI)

---------------Multiprotocol over Frame Relay---------------

Network Level Protocol ID = 80 (SNAP)

--------------Sub-Network Access Protocol (SNAP)--------------

Organizationally Unique ID = 000000 Ethertype

PID = 0806 ARP

--------------Address Resolution Protocol(ARP)--------------

Hardware type = 15 (Frame Relay)

Protocol = 0800 (Internet IP(IPv4))

Hardware address length = 2 byte(s)

Protocol address length = 4 byte(s)

Operation = 8 (InARP-Request)

Sender hardware address = 0000

Sender protocol address = 199.17.28.200

Target hardware address = 0451

Target protocol address = 0.0.0.0

This frame was sent on a virtual circuit with DLCI 21. The frame's header information includes

The frame relay address field containing DLCI 21
A control field with value X'03, meaning unnumbered information
A Network Layer Protocol ID field with value X'80, which indicates that a SNAP subheader follows
An Organizationally Unique Identifier value of X'00 00 00, which indicates that an Ethertype protocol identifier follows
And at last, the identifier X'08 06, which indicates that the payload contains an ARP message

The ARP message

Identifies the "hardware type" as 15, meaning frame relay.
Indicates that the purpose of the ARP message is to discover the translation between an IP address and a frame relay address. Here, the IP Version 4 protocol is identified by its Ethertype code, which is X'08 00.
Includes the frame relay "hardware" address: the 2-byte address field (X'04 51) which contains DLCI value 21.
States that IP addresses are 4 bytes long.
Carries an operation code of 8, which indicates that this is an inverse ARP request.
Provides the sender's own IP address, 199.17.28.200.
Shows a frame address field containing the DLCI at the sender's end of the circuit.

Filling in the target hardware address field does not actually serve a purpose, because the enclosed DLCI is a local value and would be meaningless to the receiver. Neither hardware address field is useful—they could be set to 0 in both requests and responses.

When the target, Router B, receives this message, it takes note of the DLCI value in the incoming frame's address field. The frame relay network has changed this value from 21 to 34. Router B extracts the sender's IP protocol address from the message and can create the table entry:

IP Address	DLCI Number
199.17.28.200	34

Router B sends back an inverse ARP response that contains its own IP address in the source protocol address field and Router A's IP address in the target protocol address field. Here again, the values in the hardware address fields are not relevant. Some implementations will fill them with zeros, while others will fill in frame relay address field values in a manner that looks rather odd. Consider Listing 10.2, for example.

Listing 10.2 An Inverse ARP Response

Hardware type = 15 (Frame Relay)

Protocol = 0800 (Internet IP(IPv4))

Hardware address length = 2 byte(s)

Protocol address length = 4 byte(s)

Operation = 9 (InARP-Response)

Sender hardware address = 0451

Sender protocol address = 199.17.28.201

Target hardware address = 0821

Target protocol address = 199.17.28.200

Router A will receive the response from Router B on DLCI 21. Router A can then add an entry to its frame relay ARP table. Router A also can send an inverse ARP request on DLCI 22, and will receive a response from Router C. This enables Router A to create the table entries:

IP Address	DLCI Number
199.17.28.201	21
199.17.28.202	22

There is a price for the convenience of using inverse ARP. A device only can identify that a frame contains an inverse ARP message if IETF encapsulation is used on the circuit.

Inverse ARP and IP Routing

The information that is learned via inverse ARP is very useful to IP routers. An IP router forwards data by looking up the data destination in a routing table. Suppose Router A in Figures 10.7 and 10.8 has a routing table that includes the information of the form

Destination	Forward via Router
172.16.1.0	199.17.28.201

To move an IP datagram toward destination 172.16.1.x, Router A looks in its routing table and discovers that the datagram should be passed to the router with IP address 199.17.28.201. Router A then can check the frame relay inverse ARP table to find the DLCI number (21) of the circuit that leads to the router whose IP address is 199.17.28.201.

Using Inverse ARP with Other Protocols

The preceding sections showed how inverse ARP is used for IP address discovery. However, inverse ARP does just as good a job at discovering the AppleTalk, Banyan VINES, DECnet, Novell IPX, and XNS addresses at the remote end of a frame relay circuit.

This is the benefit of the flexible ARP message format, which enables the sender to identify the protocol of interest and the length of the protocol address.

Frame Relay and SNA

For many years, IBM mainframes ruled the world of computers and IBM's Systems Network Architecture (SNA) ruled the networks. SNA no longer is the dominant architecture that it once was, but still remains very important.

Frame relay is attractive for use in IBM SNA networks because of its favorable pricing and its clean architecture, which replaces a clutter of lines and many separate, slow interface devices with a single wide area high speed interface.

However, some problems arise when SNA traffic is transmitted across frame relay circuits. SNA was engineered to run on top of reliable links and support predictable response time. Some extra effort is needed in order to mate SNA equipment with frame relay service, which tends to have variable, unpredictable response times.

Traditional SNA Network

Figure 10.10 depicts a traditional SNA network.

Figure 10.10: A traditional SNA network.

Components of a traditional SNA network include

Front-end processors—Offload the work of coordinating the communications between IBM hosts and thousands of remote devices.
Remote controllers—Located at remote locations, and connect to LANs and low bandwidth leased lines. They concentrate several sources of remote traffic onto one high bandwidth connection to a front-end processor.

Figure 10.10 includes some multidrop lines. IBM's multidrop technology makes frugal use of leased lines. Several devices are attached to the same leased line. A front-end processor or remote controller polls devices so they take turns in communicating across the line.

In fact, IBM's entire traditional wide area communications architecture is based on polling. A front-end processor controls when each of its connected remote devices can send and receive data.

When a front-end processor or other communication controller polls, it expects to receive a response within a preconfigured timeout. The timeout threshold usually is fairly low—a few seconds. If the timeout expires, the poll is retransmitted. Frame discards and late frame arrivals can disrupt SNA communications.

SNA Data Link Protocols

A reliable data link protocol is used on the links joining front-end processors to one another or connecting a front-end processor to a device on a multidrop line or on a LAN. Two reliable link protocols are used in an SNA network: Synchronous Data Link Control (SDLC) and Logical Link Control type 2 (LLC2).

Modern SNA networks also support end-to-end sessions that are set up using Advanced Peer-to-Peer Networking (APPN). APPN also relies on reliable LLC2 links. Figure 10.11 illustrates a network in which a mainframe, AS/400 hosts, and LAN systems are communicating via APPN.

Finally, IBM offers a High Performance Routing (HPR) extension to APPN that optionally can run without LLC2. That is, it can run without an underlying reliable link protocol. Retransmission and flow control are performed end-to-end by a higher layer protocol. HPR traffic that does not run on top of an LLC2 link can be transmitted across frame relay lines without encountering the problems that arise when a reliable link is used.

Figure 10.11: APPN communications.

SDLC and LLC2 Features

The IBM SDLC link layer protocol was designed for SNA leased line communications. SDLC has a number of features that cause problems when a leased line is replaced by a frame relay circuit:

SDLC is a master/slave polling protocol—A front-end processor or controller polls devices in turn to find out whether they have data to send and to deliver data to them. Polling traffic is heavy. Poll messages use up valuable bandwidth, and responses must be sent back within a strictly predictable time limit.
SDLC makes liberal use of control frames for flow control—A frame relay circuit that carries raw SDLC traffic will be cluttered with polls and control traffic.
Each SDLC information frame is numbered in sequence and contains a number that acknowledges received frames—After a preset number of frames has been sent, data transmission cannot proceed unless an acknowledgment from the partner is received.

SDLC is not used for peer-to-peer LAN communications. An SNA LAN frame contains an LLC2 header that holds the frame sequence number and the acknowledgment number. LLC2 does not have SDLC's polling overhead, but still has the overhead associated with reliable, ordered, flow-controlled delivery of data across a link.

Using Frame Relay Circuits in an SNA Network

In Figure 10.12, frame relay virtual circuits have replaced leased line connections.

Figure 10.12: Connecting SNA devices using frame relay circuits.

Treatment of SDLC over Frame Relay

Because of the heavy polling data and the problems that can be caused by intermittent delays in the frame relay network, sometimes SDLC does not perform well across a frame relay circuit.

Figure 10.13 shows a popular way to handle this. It requires replacing one link with three consecutive links.

The SDLC multidrop line is terminated at the FRAD, which polls the SDLC devices locally. The devices believe that they are talking to a remote front-end processor.

The data is repackaged using a format (defined in FRF3.1) that wraps LLC2 frames inside frame relay frames. The LLC2 link terminates at a remote router. This LLC2 link is totally under the control of network administrators, and its parameters can be set to match the delay characteristics of the frame relay circuit.

The far-end router can pass data to a front-end processor or host using a fresh LLC2 link.

Figure 10.13: Replacing one link with three more efficient ones.

Treatment of LLC2 over Frame Relay

IBM has defined a format for encapsulating LAN MAC frames that contain LLC2 headers within frame relay frames. This enables a single end-to-end LLC2 link to connect two computers that communicate across a frame relay network, as shown in Figure 10.14.

But, even though LLC2 is not as demanding a protocol as SDLC, frame relay delays still could cause trouble. Breaking one LLC2 link into three links, as shown in Figure 10.15, helps. Once again, this gives network managers the opportunity to customize the middle link to take wide area communication delays into account.

Figure 10.14: Encapsulating LLC2 frames.

Figure 10.15: Segmenting an LLC2 link.

Data Link Switching

When a frame relay circuit carries reliable link traffic, there is a substantial amount of extra overhead. One circuit may carry dozens of separate reliable links. Each is burdened with acknowledgment and flow control messages.

Figure 10.16 illustrates Data Link Switching (DLSw), which is one way to avoid carrying LLC2 links across a frame relay circuit. The LLC2 links are terminated at each router. Incoming data is sent across the wide area frame relay network via a TCP session. It then is forwarded across a fresh LLC2 link. DLSw actually works for any type of wide area connection. Its use is not restricted to frame relay.

TCP sessions support reliable data transfer, so the SNA traffic will not be lost. TCP adjusts well to sporadic delays, manages acknowledgments efficiently, and carries out flow control without using extra messages.

The disadvantage is the extra overhead caused by adding TCP/IP headers to the data.

Figure 10.16: Data link switching.

SNA, Frame Relay, and Standards

The only aspect of SNA transmission that has been standardized is the packaging of SNA data. The header formats that are used are described in the Frame Relay Forum document FRF.3.

The mechanisms used to manage delay, cut down on overhead traffic, and improve efficiency are left to vendor ingenuity. As a result, implementations differ greatly, and you usually need to have the same vendor's equipment at both ends of an SNA circuit.

Types of SNA Traffic

IBM's SNA protocol family is large and complex, and there are several different types of SNA traffic. We will start by examining some sample configurations.

Figure 10.10 displayed a traditional hierarchical SNA network with two mainframe hosts. The hosts are connected to IBM front-end processors that handle all of the communications with remote dependent devices (such as workstations and printers). Some of the remote devices are attached to a Token-Ring or Ethernet. Others are multi-dropped off a serial line.

Two different SNA protocol formats are used in hierarchical SNA. Mainframe data is sent between front-end processors using subarea Format Identification 4 (FID4) messages. Front-end processors exchange data with dependent devices using peripheral Format Identification 2 (FID2) messages.

IBM's APPN provides an alternative to the old hierarchical topology. APPN supports direct host-to-host communication. There are three types of SNA APPN messages. The original APPN used APPN FID2 messages across reliable links. A newer version of APPN supports IBM's High Performance Routing (HPR) protocol, which can run on top of an LLC2 link or without an underlying reliable link protocol.

Encapsulating SNA Traffic

Two different methods are used to encapsulate SNA data sent across a frame relay circuit. IBM has called these methods Boundary Network Node (BNN) and Boundary Access Node (BAN).

The BNN method uses SNA formats that are defined in Frame Relay Forum document FRF.3.1.
The BAN method encloses bridged LAN frames inside frame relay frames.

There is nothing new about the BAN encapsulation format. It simply is the SNAP format used to bridge frames that was described in Chapter II-6.

Boundary Network Node Formats

The general format for the extra header information added to a BNN frame that carries SNA data across a frame relay circuit was described in Chapter II-6. The encapsulation follows the pattern shown in Figure 2.4 of Chapter II-6, which describes the format when there is no assigned NLPID or SNAP. It consists of

X'03 + X'08 NLPID + layer 2 and 3 header types + protocol-specific data

The exact encapsulation format depends on the type of SNA message that is enclosed.

Figure 10.17 displays the BNN format that is used for SNA Subarea FID4, peripheral FID2, APPN FID2 traffic, and APPN HPR frames that include an LLC2 header.

Figure 10.17: SNA formats for BNN.

The fields include

A control field value of X'03
An NLPID value of X'08, which means that this protocol (SNA) does not have an official NLPID or SNAP value assigned to it
A layer 2 protocol identifier of X'4C, which means that an IEEE 802.2 LLC2 header will appear after the SNA code
A pad field with value X'80
A layer 3 protocol identifier of X'70, which means user specified (proprietary)
An SNA code that identifies the type of SNA data enclosed
The LLC2 header, which consists of a Destination Service Access Point (DSAP), Source Service Access Point (SSAP), and a 2-byte control field

Table 10.2 contains the list of the SNA codes that identify the various types of traffic.

Table 10.2 Codes Used with SNA Encapsulations

Code Point	SNA Usage
X'81	Subarea (FID4 SNA Headers)
X'82	Peripheral (FID2 SNA Headers)
X'83	APPN (FID2 SNA Headers)
X'84	Network Basic Input Output System (NetBIOS)
X'85	APPN with High Performance Routing (HPR)

The format in Figure 10.18 is used when HPR does not run over LLC2. Note that a user specific layer 2 ID of X'50 replaces the 802.2 layer 2 ID, X'4C, and there are no DSAP and SSAP fields.

Figure 10.18: Format for HPR without LLC2.

Note: Because much of today's NetBIOS traffic runs over TCP/IP, the NetBIOS encapsulation format has been omitted.

An encapsulated SNA FID2 protocol data unit is displayed in Listing 10.3. The frame was transmitted on DLCI 19. The NLPID value, X'08, announces that this is a frame for which there is no assigned NLPID or SNAP. The layer 2 ID, X'4C, indicates that an LLC2 header is enclosed, and the user (IBM) specified code X'83 indicates that the payload carries an SNA FID2 message.

Listing 10.3 Encapsulated SNA FID2 Protocol Data Unit

Decode from WinPharoah

-------Frame Relay Q.931 Format (ANSI T1.607)-------

Direction = DCE->DTE

Address Field (2 octets) = 0431

DLCI = 19 (Assigned using frame relay connection procedures)

Address Octet 1

0000 01.. DLCI (High-order)

.... ..0. C/R - Command/Response indicator

.... ...0 EA - Address field extension bit

Address Octet 2

0011 .... DLCI - (Low-order)

.... 0... FECN - Forward Explicit Congestion Notification

.... .0.. BECN - Backward Explicit Congestion Notification

.... ..0. DE - Discard Eligibility

.... ...1 EA - Address Field Extension

Control field = 03 Unnumbered(UI)

.... 0... - Poll/Final

---------Multiprotocol over Frame Relay---------

Network Level Protocol ID = 08 (Q.933)

Layer 2 ID = 4C (802.2)

Padding byte = 80

Layer 3 ID = 70 User specified layer 3 protocol

User specified layer 3 protocol information = 83

-------Logical Link Control Protocol 802.2 (LLC)------

DSAP = 12 Individual,

SSAP = 4 SNA

Control = 0A Information N(S)=5, N(R)=5, P/F=0

0000 101. - N(S)

0000 101. - N(R)

.... ...0 - Poll/Final

----------SNA Transmission Header (TH)----------

Byte Bit Content

0 0-3 Format ID = 0010 FID2

0 4-5 Mapping field = 10 First segment

0 7 Expedited flow indicator = 0 Normal

1 Reserved = x'00'

2 Destination address field = x'02'

3 Origin address field = x'00'

4-5 Sequence number field = 2

---------SNA Request/Response Header (RH)---------

(Remainder of SNA message)

BNN SAP Multiplexing

When a host needs to communicate across a frame relay network with systems attached to a remote LAN, the BNN header lacks an important piece of information. When the access device that connects the LAN to the frame relay network receives an incoming BNN LAN, there is no field in the header that identifies which LAN device is the frame's destination.

The SAP fields in the LLC2 part of the header usually contain fixed dummy values. Since they normally perform no useful function for data frames, these fields can be used to identify source and destination devices. This use of the SSAP and DSAP fields is called SAP multiplexing.

A SAP field is 1 byte long. However, some SAP values are reserved and there are only 127 numbers that can be used to distinguish sources and destinations within one virtual circuit. This means that many separate virtual circuits might have to be set up in order to reach systems on a large LAN.

Furthermore, the SAP numbers need to be configured manually, and this can turn into a big job. The BAN format discussed in the next section is a lot easier to work with.

Boundary Access Node Format

Recall that the BAN format is simply the SNAP bridged format shown in Figure 4 of Chapter II-6. BAN solves the problem of identifying LAN systems because the system's LAN MAC address is in the encapsulated LAN frame.

This solution is straightforward, but adds more overhead bytes to each frame than BNN does.

Vendor Contributions

Although frame relay and SNA are far from a perfect blend, vendors have implemented innovative solutions that prioritize SNA traffic and smooth over delay problems. The use of frame relay for wide area SNA connectivity is growing steadily.

Voice Over Frame Relay (VoFR)

Like other applications of frame relay, adoption of voice over frame relay (VoFR) has been driven by efficiencies that lead to cost reductions.

In the classic telephone network, a conventional digital voice call is encoded according to the ITU Pulse Code Modulation (PCM) standard and occupies a 64Kbps channel. A very simple alternative, Adaptive Delta Pulse Code Modulation (ADPCM), reduces the required bandwidth to 32Kbps. However, a variety of recently developed compression methods can drastically reduce the bandwidth required for a voice call to 16, 8, or 4Kbps—or even less.

It is highly efficient to send compressed voice over data circuits, and very natural to try to add voice to the frame relay service offering.

VFRADs

Adding voice to the mix of frame relay traffic has resulted in a new type of device—the voice frame relay access device or VFRAD. The name suggests that the device is devoted exclusively to voice traffic, but this is misleading. VFRADs can multiplex voice, fax, voice-band modem data, and ordinary data across frame relay circuits.

Figure 10.19 shows a very simple application of VoFR. An organization that has built a private leased line network between three sites to carry its telephone traffic (using multiple conventional T1 lines) can replace the leased lines with connections to a frame relay network. Using compression, the same number of calls can be transmitted with much less bandwidth.

Figure 10.19: Voice and fax over a frame relay network.

Alternatively, the organization can maintain the same bandwidth level that it originally had while increasing the number of calls that can be carried between the sites (via compression) or adding data traffic. In Figure 10.20, the sites are exchanging a mix of voice, fax, and data traffic.

Figure 10.20: Voice, fax, and data traffic across a frame relay network.

VoFR Relay Quality Issues

Time is a very important factor in delivering voice. Very long delays are intolerable, and variations in delivery time (jitter) cause distortions in the voice signal.

Unfortunately, occasional long delays and variability in delivery time are common characteristics of frame relay. Vendors overcome these problems using several mechanisms:

Voice traffic is placed in a high-priority transmission queue at the sending VFRAD.
The VFRAD fragments long data frames so voice traffic can be interleaved between chunks of data.
The receiving VFRAD stores incoming voice traffic in a buffer briefly and allows a few payloads to accumulate. This enables the VFRAD to deliver the voice in a smooth, undistorted stream.

These mechanisms are illustrated in Figure 10.21.

Figure 10.21: Controlling voice delivery delays and smoothing voice delivery time.

Frame Relay networks deliver the frames on a virtual circuit in the same order in which they are submitted to the network. A service provider cannot give special priority to voice frames that share a virtual circuit with data frames once the frames have entered the network. However, the provider may be able to offer a superior class of service to a selected virtual circuit. In this case, it makes sense to isolate the voice traffic onto a separate, high-priority circuit.

These mechanisms are very helpful. However, there is no guarantee that a customer will be satisfied with the quality of the voice traffic. The only way to find out is to thoroughly test a product across the frame relay network that will be used to carry voice calls.

VoFR Administrative and Maintenance Issues

Call quality is not the only issue to be considered when switching to VoFR. The effect of the change on current billing and accounting procedures needs to be considered.

The format of billing data may be very different, and current software used for accounting and charge-back might have to be replaced. The VFRAD product that is used needs to be chosen carefully, to make sure that it will be possible to gather the detailed information that an organization needs for charge-back.

A hidden cost of the switchover is that maintenance and troubleshooting will require an entirely new set of skills and equipment.

VoFR Technology and Protocols

The Frame Relay Forum deals with VoFR technology issues in implementation agreement FRF.11. A related implementation agreement, FRF.12, enables a sender to fragment big data frames into pieces that are reassembled by the receiver. Fragmenting big data frames allows voice and data traffic to be interleaved and avoids big delays in voice delivery. Currently, the agreements apply only to implementations on permanent virtual circuits (PVCs).

The sections that follow present an overview of VoFR technology, and describe the mechanisms introduced in FRF.11.

Subframes

Voice traffic normally is compressed into small chunks. These chunks need to be sent out promptly. However, the overhead involved in switching a huge number of tiny frames between locations would cut down on throughput. Since there may be many concurrent voice calls between a pair of sites, it makes sense to bundle payloads from several different voice calls into one frame. Each payload is packaged in a subframe.

Voice and data traffic can be carried between sites on separate virtual circuits, or multiplexed onto a single circuit. Although it may be easier to prioritize and control voice when it is isolated onto its own circuit, if data traffic peaks at a different time of day than voice traffic, a shared circuit may be very efficient. Furthermore, a single circuit with a merged CIR costs less than separate circuits.

If data and voice are sent on a single circuit, fragments of data can be packaged into subframes, too. Figure 10.22 displays several subframes that have been packed into a single frame.

Figure 10.22: Packing subframes into a frame.

Subchannels

Each voice or fax subframe in Figure 10.22 needs to be associated with a specific call. The receiving endpoint also needs to know where one subframe ends and the next begins.

The solution is simple. In order to make sense of the various streams of data that share a virtual circuit, the streams are organized into numbered subchannels. Up to 255 subchannels can be multiplexed onto a single frame relay circuit. Each subframe has a short header that identifies its subchannel. If a frame contains multiple subframes, then the headers of all but the last subframe also will contain a payload length field.

Subchannel Payload Types

Each subchannel carries a primary payload that is one of the following:

Encoded voice for a call
Encoded fax for a fax transmission
Ordinary data

In addition to its primary payload, a subchannel can carry auxiliary signaled payload information needed to support the subchannel. There are several types of signaled payload information, and each has been assigned a payload type number. Payload types and type numbers are listed in Table 10.3.

Table 10.3 Payload Types and Payload Type Numbers

Type Numbers	Payload Types
0	The primary payload for the subchannel. (Encoded voice, encoded fax, or data.)
1	Dialed digits.
2	Signaling information.
3	Fax data, when the primary payload already is being used for encoded voice.
4	A Silence Information Descriptor, which indicates the end of a talk spurt.

The numbers to the left are the payload type numbers. Note that a primary payload always has type number 0. This is the default payload type.

Subframe Format

The header of a subframe that contains a non-primary (and therefore non-default) type must include an extra field that indicates the type number. Figure 10.23 shows voice and dialed digits subframes within a frame, and indicates the fields that are included in each subframe header.

Figure 10.23: Subframes with headers.

The detailed subframe format is shown in Figure 10.24. Subchannel headers add extra overhead to every frame. Furthermore, every byte counts when sending real-time voice. The second or third byte is omitted when it is not absolutely needed:

If a subframe is the last (or only) subframe within a frame, then the length indication (LI) flag is set to 0, and the payload length byte (the third byte) is omitted.
The second byte in Figure 10.24 is needed only if the subchannel identification number is bigger than 64, or if the subframe does not contain a primary payload. If the subchannel identification (CID) number is less than 64 and the subframe contains a primary payload (which is the default type), then the extension indication (EI) flag is set to 0 and the second byte in Figure 10.24 is omitted.

Figure 10.24: VoFR subframe format.

Transfer Syntax

There are several commonly used voice compression methods, and each works differently. It is impossible to package all of them in the same way. This has been solved by defining a different packaging—called a transfer syntax—for each. Appendixes to FRF.11 contain transfer syntax definitions for voice encoding methods, including

Pulse Code Modulation (PCM) and Adaptive PCM
Conjugate Structure—Algebraic Code Excited Linear Predictive (CS-ACELP)
G.727 Discard-Eligible Embedded Adaptive Differential Pulse Code Modulation (E-ADPCM)
G.728 Low Delay—Code Excited Linear Prediction (LD-CELP Transfer Syntax)
G.723.1 Multi Pulse Maximum Likelihood Quantizer (MP-MLQ) Dual Rate Speech Coder

Note: The G.xxx identifiers are ITU standards numbers.

Formats for carrying dialed digits, alarm indications and channel-associated signaling bits (such as ringing or release of a circuit), fax, and fragments of ordinary data frames also are defined in Annex sections of FRF.11.

References

For more information about TCP/IP, see my earlier book, TCP/IP: Architecture, Protocols, and Implementation with IPv6 and IP Security, Signature Edition (McGraw-Hill, 1998).

Inverse ARP is described in IETF Request for Comments document 2390 (RFC 2930), Inverse Address Resolution Protocol.

IBM BNN encapsulations are described in the Frame Relay Forum document, Multiprotocol Encapsulation Implementation Agreement, 1995 (FRF.3.1).

An expository document titled SNA over Frame Relay was published by the APPN Implementers Workshop and is available at the Frame Relay Forum Web site.

Voice implementation issues are dealt with in the Voice over Frame Relay Implementation Agreement, 1997 (FRF.11) and in annexes to that agreement

About the Authors

Dr. Sidnie Feit is a chief scientist for the Standish Group, which provides consulting services to computer vendors and end users. She s an analyst, lecturer, writer, and systems architect with more than 29 years of data communications and information processing experience.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.

Click to order