In this section we'll focus on the architectural elements that are truly relevant to designing and maintaining a frame relay network using a public carrier service.
Frame relay is first and foremost an interface, a method of multiplexing traffic to be submitted to a WAN. Carriers build frame relay networks using switches from vendors such as Cascade Communications, Cisco Systems/StrataCom, Northern Telecom, Newbridge Networks or Bay Networks. As a customer, your devices see only the switch interface, and are blind to the inner workings of the carrier network, which may be built on very high-speed technologies such as T1, T3, Sonet and/or ATM.
As of this writing, all major carrier networks implement permanent virtual circuits (PVCs). These circuits are established via contract with the carrier and typically are build on a flat-rate basis. Although switched virtual circuits (SVCs) have standards support and are provided by the major frame relay backbone switch vendors, they have not been widely implemented in customer equipment or carrier networks.
Your carrier programs its frame relay switches to allow your traffic to pass through the network. These are the essential parameters you must understand:
What do you pay for? Port speed is typically the most costly parameter to increase, though access rates can jump dramatically if new local loops are involved, such as a move from 56 Kbps to T1. Individual PVC fees are next costly. Once a PVC is established, the additional cost to increase CIR is typically small and can be done in small (4 Kbps) increments.
It's important to know that the carrier's backbone is shared by many users and possibly multiple services. To keep you (and everybody else) from sending more data than the network can hold, frames sent above your contracted rate may be marked as Discard Eligible (DE). DE bits are set by the carrier network, not your equipment. If your equipment receives DE-marked frames, this indicates that data sent at this rate in the future may get dropped. This may be an early indicator of traffic rates that you didn't plan for in the design of your frame relay WAN.
Frame relay equipment notices congestion when it sees frames marked with the Forward Error Correction Notification (FECN) and Backward Error Correction (BECN) bits. These merely indicate an overload within the carrier network, and are only of value in monitoring the carrier's health.
You might expect your equipment to notify end stations to stop sending data to keep additional frames from being discarded or hitting a congested network. In practice, however, this doesn't happen: Most routers, bridges and frame relay access devices (FRADs) do nothing when these bits get set. Instead, they expect higher layer protocols, such as TCP/IP, to know how to react implicitly to the packet loss.
Broadcasts over PVC-based networks such as frame relay create special problems. If the broadcast must go to multiple remote sites through PVCs assigned to a single access channel, your equipment is forced to pump it out over each DLCI in turn. As noted elsewhere, you'll want to minimize the use of broadcasts whenever you can.
