Frame Relay Components, part 2

By Cisco Press | Jan 16, 2002 | Print this Page
http://www.enterprisenetworkingplanet.com/netsp/article.php/956221/Frame-Relay-Components-part-2.htm

Network Consultants Handbook - Frame Relay
by Matthew Castelli

Network Consultants Handbook -- Click here to go to publisher's site

Frame Relay Components (Cont'd)

As one would expect, determining the number of Virtual Circuits required for a network configuration is based on the number of end nodes, and the communication requirements, such as fully meshed (all-to-all), partial meshed (some-to-all), or hub-and-spoke (all-to-one), as illustrated by Figure 15-8.

Figure 15-8: Fully Meshed, Partially Meshed, and Hub-and-Spoke Networks
Click image for larger view in a new window
(Click image for larger view in a new window)

In a fully meshed network environment, the number of VCs required can be represented by the following formula:

where N is the number of end nodes in the network. This formula is sometimes referred to as the "N2 Formula" because it is derived from ((N2-N) / 2).

In a partial meshed network environment, the number of VCs required is not easily represented by a mathematical formula. You must consider many variables, the least of which is based on the determination of which end nodes require communication with which other end nodes. It is a fair assumption to estimate that the number of VCs required would fall between those of a fully meshed and those of a hub-and-spoke environment:

where N is the number of end nodes in the network and X is the number of VCs required to support a partially meshed configuration. The following formula can be used as an approximation to determine the number of VCs necessary to support a partial mesh configuration: , where N is the number of network nodes. This formula is useful from a network planning and cost-determination standpoint; however, because partial mesh connectivity is determined by application and user requirements at the end node, an exact number of partial-mesh VCs is almost impossible to determine.

In a hub-and-spoke network environment, the number of VCs required can be represented by the formula [N-1], where N is the number of end nodes in the network.

Figure 15-9 illustrates the number of VCs necessary to support fully meshed ((N2-N) / 2), partially meshed approximation , and hub-and-spoke (N-1) Frame Relay network configurations.

Figure 15-9: Graph of Approximate VCs Required by Network Topology
Click image for larger view in a new window
(Click image for larger view in a new window)

VCs often incur a financial obligation to the service provider. As Figure 15-9 illustrates, even relatively small networks can become quite costly very quickly based on the number of VCs alone. For this reason, hub-and-spoke network configurations are fairly common. As illustrated here, a 30-node network would require approximately 450 VCs in a fully meshed configuration, compared to the 29 VCs necessary to support a hub-and-spoke configuration.

To illustrate the potential cost savings of deploying a hub-and-spoke network over a fully meshed network environment, see Figure 15-10. As is reflected here, a difference of nearly 500 VCs exists between a fully meshed and a hub-and-spoke configuration. If it is not mandated that a fully meshed network be used, it is certainly more cost effective to design and implement a hub-and-spoke or partial-mesh configuration.

Figure 15-10: Difference Between Fully Meshed (N^2) and Hub-and-Spoke (N-1) Network Configuration
Click image for larger view in a new window
(Click image for larger view in a new window)

FECN and BECN

Congestion is inherent in any packet-switched network. Frame Relay networks are no exception. Frame Relay network implementations use a simple congestion-notification method rather than explicit flow control (such as the Transmission Control Protocol, or TCP) for each PVC or SVC; effectively reducing network overhead.

Two types of congestion-notification mechanisms are supported by Frame Relay:
  • FECN
  • BECN
FECN and BECN are each controlled by a single bit in the Frame Relay frame header.


NOTE:   A Frame Relay frame is defined as a variable-length unit of data, in frame-relay format, that is transmitted through a Frame Relay network as pure data. Frames are found at Layer 2 of the OSI model, whereas packets are found at Layer 3.

The FECN bit is set by a Frame Relay network device, usually a switch, to inform the Frame Relay networking device that is receiving the frame that congestion was experienced in the path from origination to destination. The Frame Relay networking device that is receiving frames with the FECN bit will act as directed by the upper-layer protocols in operation. Depending on which upper-layer protocols are implemented, they will initiate flow-control operations. This flow-control action is typically the throttling back of data transmission, although some implementations can be designed to ignore the FECN bit and take no action.

Much like the FECN bit, a Frame Relay network device sets the BECN bit, usually a switch, to inform the Frame Relay networking device that is receiving the frame that congestion was experienced in the path traveling in the opposite direction of frames encountering a congested path. The upper-layer protocols (such as TCP) will initiate flow-control operations, dependent on which protocols are implemented. This flow-control action, illustrated in Figure 15-11, is typically the throttling back of data transmission, although some implementations can be designed to ignore the BECN bit and take no action.

Figure 15-11: Frame Relay with FECN and BECN
Click image for larger view in a new window
(Click image for larger view in a new window)


NOTE:   The Cisco IOS can be configured for Frame Relay Traffic Shaping, which will act upon FECN and BECN indications. Enabling Frame Relay traffic shaping on an interface enables both traffic shaping and per-VC queuing on the interface's PVCs and SVCs. Traffic shaping enables the router to control the circuit's output rate and react to congestion notification information if it is also configured. To enable Frame-Relay Traffic shaping within the Cisco IOS on a per-VC basis, use the frame-relay traffic-shaping command.

Cisco also implements a traffic control mechanism called ForeSight. ForeSight is the network traffic control software used in some Cisco switches. The Cisco Frame Relay switch can extend ForeSight messages over a UNI, passing the backward congestion notification for VCs.

ForeSight allows Cisco Frame Relay routers to process and react to ForeSight messages and adjust VC level traffic shaping in a timely manner. ForeSight must be configured explicitly on both the Cisco router and the Cisco switch. ForeSight is enabled on the Cisco router when Frame Relay traffic shaping is configured. The router's response to ForeSight is not applied to any VC until the frame-relay adaptive-shaping foresight command is added to the VC's map-class. When ForeSight is enabled on the switch, the switch will periodically send out a ForeSight message based on the time value configured. The time interval can range from 40 to 5,000 milliseconds (ms).

For router ForeSight to work, the following conditions must exist on the Cisco router:

  • Frame Relay traffic shaping must be enabled on the interface.
  • The traffic shaping for a circuit must be adapted to ForeSight.
In addition, the UNI connecting to the router consolidated link layer management (CLLM) must be enabled, with the proper time interval specified.

Frame Relay Router ForeSight is enabled automatically when the frame-relay traffic-shaping command is used. However, the map-class frame-relay command and the frame-relay adaptive-shaping foresight command must both be issued before the router will respond to ForeSight and apply the traffic shaping effect on a specific interface, subinterface, or VC.

When a Cisco router receives a ForeSight message indicating that certain DLCIs are experiencing congestion, the Cisco router reacts by activating its traffic shaping function to slow down the output rate. The router reacts as it would if it were to detect the congestion by receiving a frame with the BECN bit set.

--
Our next segment from Cisco Press' Network Consultants Handbook will look at Frame Relay Virtual Circuit (VC) Parameters.