Frame Relay Communications

Now that you’ve taken a look at the key concepts associated with Frame Relay, let’s take a look at an example of how communication occurs across a Frame relay network. I am going to assume that the network is configured as shown in the figure below, and that Computer1 at the New Orleans location ultimately wants to communicate with Server3 in the Austin office. Both PVCs are configured as point-to-point links.

Figure: Example network used to describe the communication process across a Frame Relay WAN.

The steps below outline how an IP packet from Computer 1 will ultimately reach Server 3.

1. Through the ANDing process, Computer 1 will recognize that Server 3 is on a remote network. As such will ARP for the MAC address of its default gateway, interface E0 on the New Orleans router. The IP packet will be framed for Ethernet and sent to the router’s E0 interface.
2. After receiving the Ethernet frame, the New Orleans router will calculate the CRC to ensure it is not corrupt, strip off the header, and will pass the packet up to the Network layer. At this point, it will look in its routing table to see where it should forward the packet next. In this case, the destination would be 192.168.100.1, the router at the Chicago office.
3. Before forwarding the packet, the New Orleans router will obviously need to reframe it to travel over the Frame Relay network. In order to do this, it must identify the DLCI of the virtual circuit that connects to the Chicago location. Let’s assume that the router is configured correctly, and knows address 192.168.100.1 is accessible via DLCI 10. The router will reframe the packet, and forward it out sub-interface S0.10.
4. Ultimately, this frame will reach the switching equipment of the service provider. Because DLCIs are usually only locally significant, the DLCI number in the frame header may, in fact, be changed many times as it moves between the switching equipment of the service provider. You can’t tell for certain which mappings the provider uses to identify the virtual circuit within its own network. However, you do know that upon exiting the last switch before the Chicago router, its DLCI value should be set to 13, as per Figure 22.
5. Upon reaching the Chicago router’s S0.13 interface, the frame’s CRC will be recalculated, the framing striped off, and the packed will be passed to the Network layer. At this point, the Chicago router will consult its routing table, look at the destination address, and will determine that the packets destined for network 192.168.3.0/24 should be forwarded to address 192.168.200.2. I will again assume that the router is configured correctly, and knows that address 192.168.200.2 is accessible via DLCI 73. The router will reframe the packet, and forward it out subinterface S0.73.
6. This frame will also traverse the provider’s Frame Relay network through a variety of switches, where the DLCI information stored in the frame header may again change many times. Again, the final DLCI number in the header once it reaches the Austin router should be 75, as per our diagram.
7. Upon reaching the Austin router’s S0.75 interface, the frame’s CRC will be recalculated, the framing will be stripped away, and the packet will be passed to the Network layer. At this point, the router will search for the destination network address is its routing table, and will determine that the packet should be forwarded out interface E0. The router will ARP for the MAC address associated with Server C (if the MAC address is not already stored in its ARP cache), and once obtained, will reframe the packet for Ethernet and forward it out interface E0.
8. Upon receiving the Ethernet frame, Server C will identify the MAC address as its own, recalculate the CRC, strip off the framing, and then pass the packet up to the Network layer for further processing.

Obviously there are many steps involved when Computer 1 wishes to communicate with Server 3. You may be asking yourself why the company doesn’t simply add another PVC between the New Orleans and Austin offices. While entirely valid, the need for another PVC would largely depend on the volume of data that would be passed between these two offices regularly. Don’t forget that provisioning another PVC would incur additional costs, which may or may not be justifiable. In most cases, companies will configure PVCs between a branch office and a central location, rather than between branch offices directly. However, additional PVCs connecting locations (forming a mesh) does provide an additional degree of fault tolerance.