First and foremost, are we still dealing with a private connection here? It is, it is most certainly private in nature and we use it to connect up our dispersed sites. These dispersed sites have to have common ground and that common ground is, they all need to be able to connect up to the same Frame Relay provider. But if that is the case, then you would be able to use that Frame Relay provider to set up a private connection between the different sites and that's what we're doing here.
So in the following example, we'd have let's say headquarters (a hub) and then two spoke offices for this WAN connection. Is it possible, for other organizations, other companies to be utilizing this exact same Frame Relay cloud here that we are utilizing? Absolutely, and what they would have is they would have a different set of these tubes that we see overlaid on top of the Frame Relay WAN. And those tubes indicate permanent virtual circuits, but they're usually permanent with regards to Frame Relay. So the Frame Relay provider is a shared network provided by WAN switches and many different customers can have their own permanent virtual circuits, or PVCs, set up. And the provider separates out the data traffic into these PVCs and our PVC is not going to terminate with a separate customer, at least we hope so.
Do we care how the WAN is set up? We see those Frame Relay switches, also known as data communications equipment, or DCEs, when we're discussing Frame Relay. Do we care what is going on in there or do we care about our connection? Do we care about our connection from the data terminal equipment, or DTE, to that Frame Relay switch and then that overall PVC, what are we going to be focusing on here? We're focused on a few things, we're not focused on the configuration of the WAN switch itself, which is a very interesting thing that all Cisco instructors need to know, they must know, they must know it, and they have to prove that knowledge, in fact. But our focus from this curriculum's perspective is very much gaining Frame Relay connectivity and the first leg of that is connecting our router to the Frame Relay switch that is nearest to us. And our router in this case, is called the DTE. Now this is not in respect to the clock rate, okay. When we terminate a PVC, we are a DTE. If we have a WAN switch, which we can see here that is a DCE, so that's the first step. We got to get connectivity via a serial link with Frame Relay encapsulation up to the provider. And then, once that is established, then we look to making sure that the PVCs are in working status, and that would require the other sites to have successfully connected up to their point of presence Frame Relay switch, as well.
Frame Relay Terms
Before we can discuss the configuration and how we make that connection from our router up to that Frame Relay switch and ultimately create the PVC, we have to define terms. There are a lot of terms with the Frame Relay and the first one is local access rate. I see it listed three times here, but I see two different values, at our headquarters we have a value of T1 and over at our branch offices 256K. What is this local access rate?
Well let me ask you folks some questions here. What kind of connection do you think we're using to connect our router to the Frame Relay switch that is the DCE? What kind of cable? Is it Ethernet? Is it serial? Oh yeah, it is, you probably would think it is serial, that's what the jagged red line indicates, okay, so it's serial. Then what do we know about serial cables? We know that there's one side that does little bit more in terms of controlling the way that link operates that is designated by terms of the serial cable itself, the DCE end of it. These are called synchronous serial cables, if you want the full name of it and it is synchronized by the DCE.
So with that in mind, what do you think the local access rate, sometimes abbreviated LAR, what do you think that really means now? That would be our true physical speed, which would be the clock rate. The true physical speed set by the DCE on that link. So that's the local access rate and that also constrains how fast that site can use its Frame Relay connection. There could be like two PVCs running on top of that, they're going to be fighting for a pretty limited amount of bandwidth if we do, in fact, have a 64K local access rate. A much more likely scenario is to get a T1 or a fractional T1. Here's why, this is just a little bit of the background so you understand how this often works. A lot of times a telco provider would say, "I can give you a T1." Now does that T1 connect up to the Internet? Well that would be one kind of service. Does that T1 offer Frame Relay connectivity? That would be a different kind of service. And if you chose that, then, well you would be working in this world using your T1 for Frame Relay service, and you could also have a fractional T1, and it comes in fractions based on DS zeros, something we learned about, which is increments of 64 kilobits per second. So that's all the background here, just so you kind of have a more robust awareness of this.
What's the next term we have to know? Well something we've already mentioned and that was the tubes. What are the tubes we're focused on here that would be our virtual circuits? And specifically with Frame Relay, we're going to stick with the permanent virtual circuit type or PVC. The other type would be switched virtual circuit or SVC. So, just off the bat right here. What's the difference between a permanent virtual circuit and a switched virtual circuit? Well permanent is almost self-explanatory. Let's talk about switched, it's the opposite of permanent, which is temporary transient, not always on. And in networking, when we have not always on that usually means on demand, on demand triggered by packets that want to go to the other side. So we have in the standard itself switched virtual circuits. I'm not aware of any practical usage of that in Frame Relay, it is currently going on, here's why. It was never popular, and Frame Relay is now in its twilight in reality. So they're going to focus on getting the prime major functionality, which is absolutely PVCs. So we are not going to talk about SVCs, we're not going to see a config for them, nor if we ever taught them in Cisco for Frame Relay in the CCNA and CCNP tracks. So PVCs are where it's at and they are always on assuming that everybody is properly configured. So what is the purpose and the function of these PVCs now? Well I want you to focus on this physical topology. Notice, how we have our routers, the DTEs those would be the endpoints of a PVC, so a PVC starts at a router and ends at another router. So what is this PVC doing for us? It's defining where our traffic is going to flow.
Now when you think about the physical topology, notice what it looks like right now. For example, if traffic left router Y. It would go through different Frame Relay switches until it reached. Where? The other side of that PVC. So although, we show a 2, is it a straight through 2 that we're going to go from source to destination? No, it's going to go through the Frame Relay switches that it has to until it reaches the destination. So from a physical standpoint this is what we see, but from a logical standpoint, if traffic leaves router Y where does it have to go based on our PVC? Well these are sort of fixed rivers, canals for our traffic they're not going to these frames, are not going to breakout of these dedicated predetermined pathways established by the PVCs. So we have a few options if we want traffic from Y to X, we set it over the PVC between Y to X, pretty straightforward. But how would we get traffic from Y to Z? What do you think folks? How would we get traffic from Y to Z? Could we get it there? That's the first thing that should cross your mind - can we get it there? Hope so because this technology wouldn't be useful if we couldn't. Second, the way that we do it as we'd go from Y to X to Z so we'd have to cross two PVCs to get there. There are some consequences to taking an extra leg to our journey, but that's how the traffic flow would occur. So we need to manage our connection from our DTE to the DCE, the Frame Relay switch as well as that PVC. Is there anything out there for Frame Relay that will manage those connections for us and identify if there are any problems?
This is important folks, we're talking about a signaling technology for Frame Relay. Now their signaling technology is for all of the different connection types at Layer 2. In Ethernet one of them is fast link pulses, it's not all that glorious, you don't hear about it a lot, but it's there. In Frame Relay, the signaling is Local Management Interface, LMI. Now I want you to think about the name of that for a moment. LMI, I am telling you that is signaling, that is Frame Relay signaling and you need to associate those two things in your mind because when you read LMI after today and right now you'll look at that and go. What is that? I don't know what that is. Oh, it's the signaling, that's the thing you need to remember. And when you can remember that then you can understand how it plays its role here and the role that it plays is to do things like make sure those PVCs are working. It's the thing that is going to help us identify that Y and X have a working PVC and that X and Z have a working PVC, and it does a few other things we're going to learn about, but again LMI that's Frame Relay signaling.
Now earlier, when we introduced you to the local access rate, we mentioned that would be the true physical speed of that particular link. But, are we guaranteed that speed all the time with Frame Relay? I like guarantees, but unfortunately that is not our guarantee, except for the fact that we are guaranteed to never go faster than that. We're never going to be able to squeeze more bits on to that wire than we have local access rate for.
All right, so I can't go faster than my local access rate, but is there any guarantee to make sure that I will at least always have a certain amount available to me? Well it depends on your contract with the provider. Now we get into the world of how we negotiate with the provider and how that negotiation can result in different service levels with our provider. In all provider technologies, we have an agreement that states a service-level agreement (SLA). Now in the world of Frame Relay, we had a really early generation of that and it was on a per PVC basis. So don't think now the serial link itself; now we have to think about the guaranteed speed for the PVC and yes we can have that. We can have a guaranteed speed for each PVC and maybe they're not all the same, maybe you're like, well I need more throughput from Y to X than I need from X to Z. And so you're going to establish a higher guaranteed speed for one of these PVCs perhaps. What do we call that? We call that the Committed Information Rate or the CIR, for short. The guaranteed speed, okay. The word is a little weird, guaranteed. Is it possible that I could go faster, say I have a CIR of 32K, is it possible that I could go faster than that on a PVC?
Let me ask you this, is it possible for you to go faster than 65 miles an hour on the freeway while you're driving your car? It is and I have proven that. I'm not going to prove it to you folks, but yeah, absolutely. I can go faster than you know what people tell me I should be doing. So we can go faster, but if all of a sudden we experience congestion or problems on the network, then there has to be a way for us to make sure that everybody cooperates, everybody starts following the rules. So those frames that are traveling faster than they should be. Is there a way that we can mark them to make sure that they start cooperating or if they don't cooperate, we can get rid of them?
Yeah so the next term we want you to understand is something called DE, DE standing for discard eligibility. Now if we were to crack open the frame, relay frame header, Layer 2 header on Frame Relay it's going to have a bit, one bit and that bit says, is this eligible for discarding or not? And really there's more to it than what we're going to explain in this course, and more to it than we even care about. But the idea here is we can say, you know, what this is the first traffic to get pulled over. If you're going to pull anybody over, pull this one over first because I have exceeded my CIR and we understand that we're breaking the rules a little bit in a way that is predefined for us. It's prescribed to us that rule breakage, so we mark it, mark it with discard eligible and say, "You know what I understand. You might have to drop my traffic, hence the word discard eligible."
When you've been marked discard eligible, it's like receiving that warning ticket for speeding. You've been pulled over, you get your warning ticket miles and miles down the road, you get pulled over again, you've already had your warning. Now you're getting the real ticket or maybe you might get your car impounded. So essentially, at that point, the frame would be dropped off the network.
Now is there any possibility for communication here, along this PVC? For example, if there's congestion, is there any way to notify the DTEs at each end of that PVC that there is congestion? Two new terms for you - FECNs and BECNs and that is the way we call them. Anyways FECNs and BECNs, the CN of that is congestion notification, and the E is explicit, so I guess we are being explicit here. So we have forwarded explicit congestion notification and backwards explicit congestion notification. What this does is, it says, "Hey there's congestion on the PVC", and we can signal the sender and we can propagate that down to where the traffic ultimately trickles down. So that would be a forwards, so it can go in either way so that the two routers understand there's congestion.
Now if you're wondering why we care about this is we don't like to drop traffic, it is preferable to slowing down traffic than dropping traffic, okay, that's pretty consistent. Better to slow yourself down than to send, you have it drop, then have to wait for a request to retransmit and retransmit it again, okay? It's definitely more efficient. So these things can help us ratchet it down a notch, we can configure routers, in fact, to react to these, not like we do that often these days, but we could and so these are important terms. By the way, we're in a realm where you have to know these terms, I mean we've said a lot of different terms LAR, PVC, DE, FECN, BECN, did I miss any? And although if I said CIR, but that's definitely one also, oh, and LMI it's acronym soup.
So we spend a lot of time staring at this physical topology. As we said before, we really don't care about this physical topology here when it comes to Frame Relay, we care more about the logical topology, the connections those PVCs we have, between our DTEs.
Data-link Connection Identifier (DLCI)
So let's focus on that logical topology right now specifically, and look at how the traffic would flow. The flow of traffic is along the PVCs, you really have to understand that point. But now, there is one more term that we have to understand and that is data-link connection identifier, or DLCI. But before we define what the DLCI is, let's recall our discussions on Ethernet environments. So, if we were going to send data in an Ethernet environment at Layer 3, what do I have to put in the Layer 3 header? You have to have a source and a destination IP address because it's Layer 3 right?
At Layer 2, what do I need to put in that frame? Now we have two address fields in Ethernet. We got the source address field, we got the destination address field. And those help us identify the Medium Access Control, or MAC, address of the sender, MAC address of the destination, and I might've had to ARP for the MAC address of the destination based on the destination IP address. So in Ethernet, source and destination MAC address. So that is our Layer 2 addressing for Ethernet.
For Frame Relay, do we use MAC addresses? I want you folks taking a guess at this because we hinted at the fact that serial links do not have MAC addresses. When we're talking about the header types of Point-to-Point Protocol, or PPP, and High-level Data Link Control, or HDLC, no MAC address there, there is still the same kind of interface, serial, we don't have MAC addresses. So we're certainly not going to use something we don't have. So no MAC addresses, what do we have? A data-link connection identifier, or DLCI, the DLCI is our Layer 2 address. For what though? It's the main thing. For what? It tells us, which PVC to use to get to the destination we want to reach. The DLCI is local to that device and it's only important to that specific device. It chooses the PVC that a frame goes on to, chooses the PVC for the frame.
Well we need to know the DLCI inside and out in order for us to implement Frame Relay. If we don't have a solid understanding of the DLCI, there is no way we'll understand how Frame Relay truly works. And then when it comes to troubleshooting Frame Relay, those connections, those PVCs we have, we're going to struggle.