Traditionally, four networking suites are deployed using Frame Relay as the Layer 2 transport mechanism:

TCP/IP Suite

Novell IPX Suite

IBM Systems Network Architecture (SNA) Suite

VoFr

The following sections will discuss the application of these protocol suites across Frame Relay WANs and some of the special issues, challenges, and solutions that have been developed.

Frame Relay and the TCP/IP Suite
The TCP/IP Suite comprises two components: the IP operating at Layer 3 (Network) and the Transmission Control Protocol (TCP) operating at Layer 4. IP is a best-effort delivery protocol, relying on the transmission control mechanisms (that is, packet acknowledgement, sequencing) supported by TCP. IP datagrams, or packets, are routed from source to destination based on the address information found in the packet header. IP traffic is typically bursty in nature, making it an ideal network-layer protocol for Frame Relay WANs.

Figure 15-16 illustrates the correlation between the OSI model and an IP-over-Frame Relay implementation.

Figure 15-16: OSI Reference Model with IP/Frame Relay(Click image for larger view in a new window)

Virtual LANs (VLANs) and IP Subnets
Multiple IP FRADs or routers can be interconnected via a Frame Relay WAN in a configuration behaving like a Virtual LAN (VLAN), or an IP subnet.

NOTE: An IP subnet is a set of systems, or nodes/hosts, that share certain characteristics, such as the following:

Their IP addressing starts with the same network and subnet numbers.

Any system, or node/host, can communicate directly with any other system in the subnet. Data traffic in the same subnet will not flow through an intermediate router.

Figure 15-17 illustrates three routers that are interconnected by Frame Relay PVCs in a fully meshed configuration.

Figure 15-17: Frame Relay with IP Subnet(Click image for larger view in a new window)

NOTE: Fully meshed configurations enable every device in the system to directly communicate with every other device in the same system. Partially meshed configurations, generally known as hub-and-spoke, enable communication between devices with a central hub point providing the interconnection between end nodes.

A fully meshed Frame Relay network can be treated as a VLAN or a single IP subnet. As illustrated in Figure 15-17, three end nodes, each with an IP address assigned, are interconnected across the Frame Relay network via the Frame Relay interface on each FRAD/router. Each of these addresses shares the same network and subnet numbers, with only the host portion of the address differing.

It is worth noting that in this configuration, each Frame Relay interface is supporting multiple VCs with only a single IP address assigned to that interface, in a broadcast configuration. Another common Frame Relay configuration would have an IP address for each VC on the Frame Relay interface. This is enabled by the use of subinterfaces and will be discussed in more detail later in this chapter.

Figure 15-18 reflects the addition of a fourth router (Router D) with a different IP address from the rest of the subnet assigned to the Frame Relay interface. Router D is not part of the full mesh because it is only connected to Router B. Because Router D is part of a different subnet, new IP addresses are assigned to each endpoint of the permanent virtual circuit (PVC).

/

Figure 15-18: Frame Relay with Two IP Subnets(Click image for larger view in a new window)

In summary, the following rules apply when dealing with Frame Relay implementations using virtual IP subnets:

A single IP address can be assigned to the entire Frame Relay interface

When one or more DLCIs are used requiring the use of subinterfaces, each subinterface is assigned an IP address.

Address Resolution Protocol (ARP)
LAN systems transmit data to one another by wrapping, or encapsulating, the payload in a LAN frame whose header contains the Media Access Control (MAC) address of the destination's LAN host network interface card (NIC). A LAN system cannot communicate with a neighbor until it has discovered this neighbor's MAC address. The discovery method used is set by the procedures outlined in the Address Resolution Protocol (ARP).

To send an IP datagram to a particular IP address, the network driver must have a method to find out whether the IP address belongs to a computer on the network. If the IP address does belong to a computer on the network, the driver must know the hardware address of the computer to transmit the packet over the network. This is accomplished in Ethernet-type devices using an Internet protocol called the Address Resolution Protocol (ARP). This protocol is described in detail in RFC 826.

Figure 15-19 illustrates how ARP operates in an IP network. Host A, with an IP address of 198.24.5.1, wants to establish a connection with Server A, with an IP address of 198.24.5.100. Host A will broadcast an ARP query message across the medium asking the system, or host, with IP address 198.24.5.100 to respond. Server A replies to the ARP query providing its Layer 2 MAC address. In this example, the MAC address is 00-60-08-BF-4C-3E.

Figure 15-19: Host A ARP Discovery of Server A MAC Address(Click image for larger view in a new window)

Host A maintains an Ethernet MAC table that records the Layer 3 Network (IP) address with its associated Layer 2 (MAC) address. In this example, Host A's ARP table would look something similar to Table 15-9.

Table 15-9:Host A ARP Table

IP Address

MAC Address

192.24.5.100

00-60-08-BF-4C-3E

NOTE: The ARP table can be viewed from any host by entering the command arp at a DOS prompt:

C:\>arp

then it displays and modifies the IP-to-Physical address translation tables used by ARP:

ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr]
-a Displays current ARP entries by interrogating
the current protocol data. If inet_addr is
specified, the IP and Physical addresses for
only the specified computer are displayed. If
more than one network interface uses ARP,
entries for each ARP table are displayed.
-g Same as -a.
inet_addr Specifies an Internet address.
-N if_addr Displays the ARP entries for the
network interface specified by if_addr.
-d Deletes the host specified by inet_addr.
inet_addr can be wildcarded with * to delete
all hosts.
-s Adds the host and associates the Internet
address inet_addr with the physical address
eth_addr. The physical address is given as
six hexadecimal bytes separated by hyphens.
The entry is permanent.
eth_addr Specifies a physical address.
if_addr If present, this specifies the Internet
address of the interface whose address
translation table should be modified. If
not present, the first applicable interface
will be used.
Example:
> arp -s 157.55.85.212 00-aa-00-62-c6-09 .... Adds a static entry.
> arp -a .... Displays the arp table.

Server A, upon receipt of the ARP query, will place the MAC address of Host A into its ARP table.

Inverse ARP

Inverse ARP will be discussed here as it applies to IP networking and address discovery. Inverse ARP operates in a similar fashion for Frame Relay DLCI discovery for AppleTalk, Banyan VINES, DECnet, Novell IPX, and Xerox Network Services (XNS).

The motivation for the development of Inverse ARP is a result of the desire to make dynamic address resolution within Frame Relay both possible and efficient. PVCs and, eventually, SVCs are identified by a DLCI. These DLCIs define a single virtual connection through the WAN and are the Frame Relay equivalent to a hardware address.

Periodically, through the exchange of signaling messages, a network might announce a new VC with its corresponding DLCI. Unfortunately, protocol addressing is not included in the announcement. The station receiving such an indication will learn of the new connection, but will not be able to address the other side. Without a new configuration or mechanism for discovering the protocol address of the other side, this new VC is unusable. RFC 1293 defines Inverse ARP in more detail.

Whereas ARP enables a system to build a table mapping the LAN system's IP address to the Layer 2 MAC address, Inverse ARP is used to build a similar table mapping the connected system's IP address (by Frame Relay Virtual Circuit) to the Layer 2 DLCI on the connected system.

Figure 15-20 illustrates a four-node Frame Relay WAN, each site interconnected by a Frame Relay PVC.

Router B needs to determine the IP address of its neighbors prior to the forwarding of traffic across the interconnection. Router B also needs to map each neighbor's IP address to the DLCI that will be used to reach that neighbor. Router B essentially needs a table similar to Table 15-10.

Although this table could be built manually, it is far more efficient to let the Inverse ARP mechanism build it. Each router uses a simple two-step procedure to build this table. These steps include the following:

Each router sends a message across each connected VC asking for the IP address of the distant end.

The sending router then records the IP address and the corresponding DLCI into its tables.

NOTE: ARP is used when the Layer 3 address is known but the corresponding Layer 2 address is unknown, typically the MAC address. Inverse ARP is used when the Layer 2 address is known, typically the DLCI, but the corresponding Layer 3 address is unknown.

Inverse ARP and Routing Tables
The information learned via Inverse ARP is of significant use to IP routers. Using the network represented by Figure 15-21, suppose that Router D has message traffic to forward to Router A.

Figure 15-21: Four-Node Frame Relay WAN with IP Address and DLCI Assignments(Click image for larger view in a new window)