Permanent Virtual Circuit (PVC)

A virtual circuit references a nonphysical aspect of our Frame Relay communications. The users of the Frame Relay WAN connection see the connectivity just like it is an actual physical link or connection they have with the remote device. In reality, this link is not physical and there is no actual bandwidth allocated to a clear cut physical connection between the devices. This is often why we choose to represent the Frame Relay environment of the Service Provider as a cloud. Any path or particular technology can be going on within this cloud. A Permanent Virtual Circuit (PVC) has an engineer set up the endpoints of the circuit when a customer signs up. These are then typically left in place for the duration of the contract. With a Switched Virtual Circuit (SVC), the circuit is set up when there is a desire to communication. Notice that this is much like a phone call. CCNA focuses on the PVC because it is much more commonly used with Frame Relay.

Data Link Connection Identifier (DLCI)

This term is critical for you to understand fully. The DLCI is a locally significant number to identify the path you need to send traffic to in the network. Locally significant means that there it is only relevant for your local router. In other words, there could be the same DLCI used by another router somewhere in the cloud. An analogy for this concept that I love is like Gate Numbers at an airport. We are told that in order to fly to Madrid, Spain, we need to go to gate A10. This is only locally significant to us. We go to that gate, travel down the jetway, get on an airplane, and some time later, we are smiling in beautiful Spain. We do not care what gate number is in use when we arrive, or what gate number will be used in the future for our return trip. The only thing we needed to care about when we departed was gate A10. DLCIs are represented using 10 bits, so there are 2^10, or 1024 different DLCI addresses possible. Keep in mind that some of these are reserved, however. For example, DLCI 0 is used for Local Management Interface (LMI) signaling. A common approach for Frame Relay providers is to start DLCI numbering at 100, and to count by 5 or 10.

Local Management Interface (LMI)

LMI tells our local router that everything is just fine with the circuit or circuits operating over the interface. Should there be some type of problem that crops up in the WAN with this connection, Local Management Interface (LMI) will be the way our router finds out about it. There are three “flavors” of LMI that a Cisco router will support:

• ANSI T1.617a Annex D is the most common
• ITU-T Q.933 Annex A
• Cisco

The router will indeed try all three of these options until it finds a match with the Service Provider. We can help the router along by providing the flavor our provider uses.

Inverse ARP (InARP)

Inverse ARP is indeed an extension of the Address Resolution Protocol (ARP) that we have come to know and love in the CCNA. Using InARP, the local router will discover the network layer (IP address) of the remote device over the local DLCI that it already knows.

Committed Information Rate (CIR)

The CIR for a Frame Relay virtual circuit is the rate at which the provider agrees to accept data from the user. This value is measure in Bits Per Second (BPS). Can you send data above this rate because you are a really good customer? That will depend on details of your arrangement with the Service Provider. They might allow you to burst above this value at times.

Local Access Rate (AR)

This is the actual rate at which the port on our DTE device sends data. Now I bet you have an important question. What if our CIR is considerably less than our Local Access Rate? Well, thank goodness we have a wonderful invention called Frame Relay Traffic Shaping (FRTS) to ensure that we behave and send traffic at the required rate.

Forward Explicit Congestion Notification (FECN)

If the frame is being carried in the Service Provider cloud and there is congestion experienced, the DCE (most often a Frame Relay Switch) can set the FECN bit and send the frame forward in the cloud. This notifies the receiver that there was congestion experienced during the transmission.

Backward Explicit Congestion Notification (BECN)

If a DTE in the Frame network receives a frame with the FECN bit set, it can respond in a clever way. It can generate a test frame and set the BECN bit. It then sends this frame backward in the cloud to the original sender. This way the sender can be notified of the congestion, and (hopefully), slow down the rate at which it sends traffic. Congratulations, you have now taken an important step in mastering those pesky Frame Relay terminologies that you MUST know for CCNA, CCNP, and even for CCIE.