Frame Relay Components

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

Network Consultants Handbook - Frame Relay
by Matthew Castelli

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

Frame Relay Components
Frame Relay WAN service comprises four primary functional components:

  • Customer premise Frame Relay access device (FRAD)
  • Local access loop to the service provider network
  • Frame Relay switch access port
    Link Management Interface parameters are defined here
  • Frame Relay VC parameters to each end site

Customer Premise FRAD
This device is either a dedicated FRAD, such as a Cisco XXX; or a router, such as a Cisco 26xx Series Router. Figure 15-3 illustrates a typical FRAD implementation.


NOTE:   A router with an integrated CSU/DSU acts as a FRAD/Router.

Figure 15-3: Frame Relay Access Device
Click image for larger view in a new window
(Click image for larger view in a new window)

Local Access Loop to the Service Provider Network
Local access loop is the physical wiring that interconnects the customer premise FRAD and the service provider networks Frame Relay switch access port. This local loop is typically a DS0, DS1, NxDS1, DS3 service, or some fraction of DS1/DS3 service (such as Frac-T1).

In telephony, a local loop is the wired connection from a telephone companys central office (CO) in a locality to its customers telephones at homes and businesses. This connection is usually on a pair of copper wires called twisted pair. The local loop system was originally designed for voice transmission only using analog transmission technology on a single voice channel. A modem is used to handle the conversion between analog and digital signals. With the advent of ISDN or digital subscriber line (DSL), the local loop can carry digital signals directly and at a much higher bandwidth than for voice only.

The local loop requires termination into a network interface unit (NIU) at the customer premise, and subsequent connection to the customer DCE device, usually a CSU/DSU. The DTE port of this CSU/DSU provides connectivity to the FRAD/Router. Figure 15-4 illustrates a typical local loop configuration.

Figure 15-4: Frame Relay Local Access Loop
Click image for larger view in a new window
(Click image for larger view in a new window)

Frame Relay Virtual Circuits

Frame Relay is a connection-oriented service, operating at the data link layer (Layer 2) of the OSI model. A DLCI is used to identify this dedicated communication path between two end nodes: origination and termination. This path, or VC, is a bidirectional logical connection across the wide-area network between two end node DTE devices.

Figure 15-5 illustrates a fully meshed (all sites with connectivity to each other) Frame Relay WAN, with DLCI assignments for each location.


NOTE:   Sometimes the originating node of a VC will be annotated as Site A and the terminating node of a VC will be annotated as Site B or Site Z.

Figure 15-5: Frame Relay WAN with Virtual Circuit and DLCI
Click image for larger view in a new window
(Click image for larger view in a new window)

DLCIs
DLCIs are used to identify the PVC that is provisioned to transport data traffic. DLCIs are of local significance, unless an agreement has been made with the network service provider to deploy global DLCIs. Local significance means that DLCIs are of use only to the local Frame Relay network device. Frame Relay DLCIs are analogous to an organizations telephone network that is utilizing speed-dial functions. The most common Frame Relay WAN deployment involves the use of local DLCIs because a network size limitation exists for the use of global DLCIs.


NOTE:   Global DLCI addresses are assigned so that each DLCI has universal significance, meaning that the DLCI number is pointed to the same destination (termination point) regardless of the origination point.

The concept behind global DLCI addressing is to simplify Frame Relay network addressing administration; however, global addressing has an inherent limitation in that no more than 992 DLCIs (1024 DLCIs less the 32 reserved DLCIs) can be used. In a Frame Relay network of more than 992 sites, global addressing will not work.

The use of global DLCIs requires that they each be preassigned. (Typically, the assignments are negotiated between the customer and the network service provider.) In addition, each DLCI can be used only once throughout the network. (If two sites had the same DLCI, the network would not know which termination site was the intended destination.) The Frame Relay switch within the network service providers network will have tables that route the traffic between each origination and termination pair.

Suppose that an organization has deployed the speed-dialing scheme illustrated for reference in Figure 15-6 and detailed in the following list:

  • The CEO speed-dials 1 to talk with the COO.
  • The CEO speed-dials 2 to talk with the VP of Marketing.
  • The COO speed-dials 1 to talk with the VP of Marketing.
  • The COO speed-dials 5 to talk with the CEO.
  • The VP of Marketing speed-dials 7 to talk with the CEO.
  • The VP of Marketing speed-dials 9 to talk with the COO.

Figure 15-6: Telephone Speed-Dial Network
Click image for larger view in a new window
(Click image for larger view in a new window)

Table 15-2 provides another view of the Telephone Speed-Dial Network.

Table 15-2
Table 15-2: Telephone Speed-Dial Configuration Table

Site A Site BA -> B Speed DialB -> A Speed Dial
COO Marketing VP 1 9
COO CEO 5 1
CEO Marketing VP 2 7
CEO COO 1 5
Marketing VP CEO 7 5
Marketing VP COO 9 1

For the CEO to speak with the COO, the CEO will press speed-dial 1 on the telephone set. However, the COO will see speed-dial 5 on the telephone because that is the local speed-dial assignment given to the CEO, as the speed-dial 1 local assignment on the COOs telephone set is assigned to the VP of Marketing.

If the COO presses speed-dial 1, the VP of Marketing will answer the phone and speed-dial 9 will show on the Marketing VPs phone because that is the local assignment given to the COO.

This same concept applies to Frame Relay DLCIs; the DLCI assignment is locally significant. The distant-end of the VC is unaware of this number because it has its own local DLCI assignment to identify the distant-end node. This is illustrated in Figure 15-7.

Figure 15-7: Frame Relay Network with DLCI Assignment
Click image for larger view in a new window
(Click image for larger view in a new window)

In this example, for Los Angeles to send traffic to New York, the FRAD will map the network layer information, such as IP address, to the DLCI. In this case, the DLCI is 100. New York will see traffic arrive on DLCI 425 and will be able to identify within its Frame Relay mapping tables that this traffic has arrived from Los Angeles.

Table 15-3 provides a view of the Frame Relay network shown in Figure 15-7.

Table 15-3
Table 15-3: Frame Relay DLCI Table for Figure 15-7

Site A Site BA -> B DLCIB -> A DLCI
Los Angeles New York 100 425
Los Angeles Seattle 150 258
Seattle New York 685 367
Seattle Los Angeles 258 150
New York Seattle 367 685
New York Los Angeles 425 100


NOTE:   The show frame-relay map command can be used in Privileged Exec mode to view the mapping of network addressing to a DLCI.

NOTE:   To define the mapping between a destination protocol address and the DLCI used to connect to the destination address, use the frame-relay map interface configuration command. Use the no form of this command to delete the map entry.
frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco] 
[payload-compress {packet-by-packet | frf9 stac [hardware-options]}]
no frame-relay map protocol protocol-address

Table 15-4: frame-relay map Command Field Descriptions

Field Description
Protocol Supported protocol, bridging, or logical link control keywords: appletalk, decnet, dlsw, ip, ipx, llc2, rsrb, vines and xns.
protocol-address Destination protocol address.
Dlci DLCI number used to connect to the specified protocol address on the interface.
Broadcast (Optional) Forwards broadcasts to this address when multicast is not enabled (see the frame-relay multicast-dlci command for more information about multicasts). This keyword also simplifies the configuration of Open Shortest Path First (OSPF).
Ietf (Optional) Internet Engineering Task Force (IETF) form of Frame Relay encapsulation. Used when the router or access server is connected to another vendors equipment across a Frame Relay network.
Cisco (Optional) Cisco encapsulation method.
payload-compress packet-by-packet (Optional) Packet-by-packet payload compression using the Stacker method.
payload-compress frf9 stac (Optional) Enables FRF.9 compression using the Stacker method.
If the router contains a compression service adapter (CSA), compression is performed in the CSA hardware (hardware compression).

If the CSA is not available, compression is performed in the software installed on the VIP2 (distributed compression).

If the VIP2 is not available, compression is performed in the routers main processor (software compression).

hardware-options distributed (Optional) -- Specifies that compression is implemented in the software that is installed in a VIP2. If the VIP2 is not available, compression is performed in the routers main processor (software compression). This option applies only to the Cisco 7500 series.

software (Optional) -- Specifies that compression is implemented in the Cisco IOS software installed in the routers main processor.

csa csa_number (Optional) -- Specifies the CSA to use for a particular interface. This option applies only to Cisco 7200 series routers.

PVCs
PVCs are Frame Relay VC connections that are permanently established. PVCs are used for frequent communication between end nodes, such as file sharing, file transfer, and CAD/CAM imaging.

Frame Relay PVCs use DLCIs for Layer 2 addressing.

PVCs operate in one of two modes:

  • Idle -- Tconnection between end nodes is active albeit with no data transfer occurring. PVCs are not terminated or "taken-down" when in an idle state.
  • Data Transfer -- Data traffic is being transmitted between end nodes over the VC.
Even though PVCs are generally discussed as being full-duplex, PVCs are simplex connections, each with its own DLCI/CIR assignment.

The three duplex modes are as follows:

  • Full-duplex communication involves origination and termination points transmitting and receiving at the same time; this is two-way communication full-time.
  • Half-duplex communication is origination and termination points transmitting and receiving, but not at the same time. Only one flow of traffic is allowed across the connection; this is two-way communication, one-way at a time.
  • Simplex communication is origination or termination points transmitting or receiving; this is one-way communication only.

SVCs
Unlike PVCs, which are permanently established connections, SVCs require a call setup process. SVCs are temporary connections that are traditionally used when communication between end nodes is infrequent or sporadic, such as in Voice over Frame Relay (VoFr) situations.


NOTE:   Frame Relay SVCs use E.164 or X.121 addresses for Layer 2 addressing.

Whereas PVCs are permanently established, SVCs require a call setup and termination process, defined by the following process and functions:

  1. Call setup -- Establishes the VC between Frame Relay end nodes. This includes negotiation of VC parameters, such as CIR.
  2. Data transfer -- Data traffic is transmitted between end nodes (originating and terminating) across the VC.
  3. Idle -- Like PVCs, when the VC is idle (no data traffic) the connection between end nodes remains active and available for communication. However, unlike PVCs, which do not terminate the connection, an SVC will terminate the connection if it is in an idle state for a configured time period.
  4. Call termination -- The VC between Frame Relay end nodes is terminated, or "taken down."

NOTE:  

In bidirectional mode, both ends of a VC send and respond to keepalive requests. If one end of the VC is configured in the bidirectional mode, the other end must also be configured in the bidirectional mode.

In request mode, the router sends keepalive requests and expects replies from the other end of the VC. If one end of a VC is configured in the request mode, the other end must be configured in the reply or passive-reply mode.

In reply mode, the router does not send keepalive requests, but waits for keepalive requests from the other end of the VC and replies to them. If no keepalive request has arrived within the timer interval, the router times out and increments the error counter by 1. If one end of a VC is configured in the reply mode, the other end must be configured in the request mode.

In passive-reply mode, the router does not send keepalive requests, but waits for keepalive requests from the other end of the VC and replies to them. No timer is set when in this mode, and the error counter is not incremented. If one end of a VC is configured in the passive-reply mode, the other end must be configured in the request mode.

The command to configure end-to-end keepalive (Cisco IOS 12.0.5(T) or greater) is frame-relay end-to-end keepalive mode {bidirectional | request | reply | passive-reply}.

X.121 is a hierarchical addressing scheme that was originally designed to number X.25 nodes. E.164 is a hierarchical global telecommunications numbering plan, similar to the North American Number Plan (NANP, 1-NPA-NXX-XXXX).


--
Part 3 in this series will conclude the section on Frame Relay components.