4. 12.3 Unified Communications Networks
In this video, we want to consider some of the components we might find in a unified communications network. And that’s a term that Cisco coined. And the implication is we can have not just voice over our network, not just voiceover IP in other words, but we could have voice and video. We might also have instant messaging. We could see if somebody is available to take a call or not. That’s presence information. There’s all kinds of things we can do besides just voice. So therefore we call it a unified communications network. And here’s a network that I was building for one of my unified communications courses that I teach and I thought we would use this topology to illustrate some of these different components.
Maybe we come in from the internet to a business and we come into a router just like we do with a data network. That router connects out to a switch that is going to connect to end stations perhaps. Well, one of those end stations might be something called a call agent. Now I’ve called this the CUCM Pub because I was doing this with Cisco equipment and CUCM stands for Cisco Unified Communications Manager and it’s a publisher because we can also have sort of a backup called a subscriber. But those are call agents. Think of a call agent as a PBX replacement. Remember a PBX, a private branch exchange that was one of those privately owned telephone switches that companies had and phones connected into that PBX.
Well here we can have servers acting as call agents and we can have IP based phones. That’s right, phones that actually have Ethernet ports in the back of them that we connect into the network. And they can register with these call agents. And these call agents, they’ve got call routing intelligence. They know how to get to another directory number in the company. They know how to get out to the PSTN, the public switched telephone network to go somewhere else in the world. But it’s not just the ability to call someone in a unified communications network that we need. We might want to leave a voicemail for somebody. We can have voice messaging systems such as the Cisco Unity Connection Server.
We might want to have applications that run on our smartphones or tablets, our laptops that will let us do instant messaging with our coworkers and also see if they are available to take a call right now or not. And maybe even use that application on your phone to set up a voice or video call. That’s what we can do with instant messaging and presence applications. And we can’t have physical IP phones that connect into an Ethernet switch. Or as I was saying, we can have an application that’s running maybe on a laptop that’s going to connect into a switch. And that application is going to let us have video and voice and instant messaging and presence. And the example I’m giving here is Cisco’s Jabber client.
And for a more immersive experience, we might have a telepresence room where we have these large high definition televisions sitting around a table. And we sit at the table, and there’s a high definition camera on us. And because of the size and the audio quality, it’s a very immersive experience where it feels almost identical to being in a meeting room with someone. It’s kind of amazing. And there are some other things that we might add on. For example, a lot of companies will need a firewall to protect them from the bad things on the Internet. And if somebody’s working remotely, working from home, for example, maybe they’ve got a Cisco Jabber client on their laptop. How can that Jabber client come in and register with one of those call agents? Because there’s a firewall in the way. Well, there are ways around that.
The Cisco Solution is something called Cisco Expressway. We can have a couple of expressway servers that allow us to go through that firewall. And in order for all this to work, it’s common for us to have a DNS server to serve the inside of our network and another DNS server to serve everybody out on the Internet. We still can connect from our router out to the public switched telephone network to get to everywhere we might want to get to in the real world. And we might have something called a unified border element, or some people call it a session border controller that’s going to join together a voice over IP call as an example in your network with a voice over IP call provided by some service provider out there on the Internet somewhere.
And the one I’m showing you on screen is called a cube, a Cisco unified border element. And that Cisco unified border element could connect again, an internal call with somebody out on the Ipwan and maybe connected to this Ipwan. We’ve got a remote office. Well, we can have another call agent at that remote office. Maybe it’s not as robust as the server that’s running back at the main office. Cisco has one called the Cisco unified communications manager express. That’s a call agent that runs on a router. And that could be the call agent for that remote office where we have connected IP phones, maybe the Jabber clients. We could even have a voice messaging solution at that remote site. Cisco solution is called cue for Cisco unity Express.
Now, these are just examples of some of the components that you might find in a unified communications network. And I’ve given you some Cisco specific examples because that’s the network that I built for my course. But other vendors have these types of components as well. And to show you this in action, let’s go ahead and take a look at an IP based phone and make a phone call between a couple of those phones. And it will be not just audio, but we can make it a video call as well. One of the most common elements we have in a unified communications network is an IP based phone. Now, this phone has a video camera on the top and in the back, it actually has ports, an ethernet port, which can connect into an ethernet switch.
There’s another ethernet port that might plug into a PC that would be in someone’s cubicle. That way, if they just have one ethernet port in the cubicle, their PC can daisy chain into the phone, and then the phone can go into the wall outlet. Now let’s go over and take a look. You see I’ve got some phones behind me. Let’s go take a look at a video call using a couple of these IP phones. Here we have a couple of IP based phones. This phone is directory number 2001. This is 2002. Let’s place a call between these phones. I’ll go off hook and I’ll dial 2002. You see it ringing. We’ll go off hook, and we have an audio call set up right now. But notice these IP based phones also are equipped with video cameras. So if I open up the lens of the video camera, we’ve can now see bi directional video between these two phones.
5. 12.4 Quality of Service (QoS) Fundamentals
In this video we’re going to consider quality of service or QoS. And QoS itself is not a single feature that we turn on or off, it’s a collection of features. And the best definition I’ve ever heard for QoS is that QoS is managed unfairness. We’re being unfair to specific traffic types, our low priority traffic so that we can send our high priority traffic first. We’re being unfair fair, but it’s strategic unfairness. And QoS can come into play when we have congestion in the network. For example, on screen we have a switch SW one connecting into a router at a gig rate and then that router is going out to the Ipwan at a fast ethernet rate that’s 100 megabits per second. But we’re coming into the router at 1000 megabits per second. We’ve got a ten to one speed mismatch.
So what does R one do? Well that interface on R One going out to the Ipwan, maybe it’s trying to send traffic out as soon as it receives it, but it’s coming in from the land faster that it can send it out over that faster than that link. So that router interface, it’s going to allocate some memory called a buffer or a queue and it’s going to temporarily store that traffic up in hopes that in a moment the band with demand is going to die down. Then we’ll take the traffic out of the queue and send it on its way. And the temptation is to think, okay, at the wan edge maybe I need quality of service, but within the land no, everything is running at a gig rate. I don’t need QoS there. Well maybe you do. Consider this topology here. We’ve got something like a server farm. We’ve got these three servers coming into switch SW two at a gig rate and we’re leaving switch SW two at a gig rate.
But if all three of those servers are simultaneously transmitting at rates approaching a gig, that’s about three gigabits per second of beamed with coming into that switch. And we can only leave on a single gig link. That’s a three to one speed mismatch. So the question is do you need quality of service? Well you need quality of service if you’re experiencing congestion, but specifically if you’re experiencing periodic congestion, if you’re congested twenty four seven you need more bandwidth. But if you just have times during the day when you’re congested, maybe that’s when quality of service can help you out. For example, there’s a network backup going on of an evening and some people are trying to use the network that might be just periodic congestion.
Or everybody arrives at the office about the same time of a morning, they boot up and maybe there’s a little bit of congestion then as they’re pulling down some data that might be periodic congestion that can be managed with QoS. But if you’re congested all the time you need more bandwidth and quality of service. I said wasn’t a single feature, it was a collection of features. Well, those features fall into one of three different categories not strict, less strict, and strict. Now, not strict. We call that best effort. And honestly, I even struggle calling this a quality of service category because it’s not really doing any reordering of packets. It’s FIFO. Fi f o. First in, first out. The first packet that comes into the router is the first packet that goes out. There is no prioritization.
So best effort is almost the absence of quality of service. Less strict is diff. Serve. That’s the category name that stands for Differentiated services. And that’s what we mainly do in today’s networks is we do differentiated Services, which comprises a collection of QoS tools. This is where we’re differentiating between different traffic flows and we’re treating those different traffic flows differently based on the business needs. There is a strict category and that’s called Int Serv, which is short for integrated services. And we say it’s strict because an application can reserve a chunk of bandwidth for the duration of that application. Even if that application is idle at the moment.
It doesn’t need the bandwidth as long as it has that reservation in place. It does not share. It says no, I reserve this. Nobody else can share it. DiffServ is a bit kinder with that. It’s more generous if it has a category of traffic that doesn’t need all of its allocated bandwidth, but somebody else does need it. Sure, we can share. Now let’s take a look at some of those different quality of service mechanisms, beginning with classification and marking. Classification is where we identify a packet as being a specific traffic type, and then we put it in a category and then we apply a marking. This is where we’re altering bits in that packet setter, or at layer two in that frame setter to identify the priority of that packet or frame. That way the next router or the next switch.
They don’t have to reclassify the traffic. They can very quickly, very efficiently look at that marking and make a decision based on that marking, like a forwarding decision or a dropping decision. And as a metaphor, I think of when I get on an airplane now, I fly Delta a lot and I’m not currently at a silver medallion status. I’m getting there, I’m getting close, but I’m not there yet. But imagine the day comes and after they call for maybe first class, they call for sky priority. And if I’ve earned that silver medallion status, I can go up to the gate agent and present my ticket.
But can you imagine me going up to the gate agent and they say, hello, Mr. Wallace, can you prove that you are a frequent flyer? Can you show us the boarding pass from the time you went to Orlando and Chicago and San Jose and Dallas and Austin and Paris? That would not scale very well, would it if I had to prove every single time that I really am a frequent flyer. So what does the airline do? They put a marking directly on the boarding pass that says something like sky priority. I show that marking and the gate agent knows that I get to get on the plane before people that have like a main one or a main two marking on their boarding pass. It’s the same thing with quality of service. We identify different traffic based on a variety of criteria and we can apply a marking to indicate its priority.
But classification and marking by themselves, they do not alter the behavior of traffic. We need something else to look at that marking and make a decision based on that marking. One such mechanism is a queuing mechanism. Remember when we were talking about Router R one trying to send traffic out on that fast Ethernet link even though the router was receiving traffic at a gig rate and it had congestion. I said that interface going out to the wan would store up packets in a queue or a buffer in hopes that bandwidth demand would die down and then we would take the packets out of the queue and send them on their way. But that queue, that amount of memory, it’s only so big, it’s only going to hold so many packets.
If it starts to overflow, then we start dropping all of the different traffic types coming in. There’s no room in the queue for anyone. So as a very basic example of queuing, what we can do is take that one queue space and let’s say that we divide it into a couple of sub queues. Maybe we want to put voice over IP in one queue and everybody else will call best effort. We’ll put them in another queue or another bucket. Now, imagine this. We get some voice over IP traffic coming in, we get a lot of best effort traffic coming in, a little bit more voice over IP, a whole lot of best effort then. And we start to overflow that best effort bucket because there’s been this data burst on the network. The good news is our latency sensitive of voice over IP traffic, we’re not dropping it. It’s got its own storage location and that bucket is not overflowing. So we can still send our voice over IP traffic, even though we might be dropping other traffic types.
That’s an example of taking that one queue and dividing it into just a couple of queues. And we often call queuing congestion management. And we can go in and give bandwidth allocations for different traffic types. However, there’s another mechanism called congestion avoidance. This is where we’re trying to prevent a queue from ever filling to capacity. Because if a queue does fill to capacity and it starts to overflow, we’re going to get some really ugly side effects. More than just dropping. Everybody trying to come into that queue, because with TCP communication, you might recall that there is a three way handshake.
If I want to talk to you using TCP, I send you a synchronization message, an syn or a sin, and you acknowledge that you send me an AC, and you want to talk to me as well, so you send me a sin and S-Y-N and I acknowledge that with an AC, so it’s a sin. Then you send me a sin AK, and I send you an AC. Then I’ll send you a data segment, and I wait for an acknowledgement. You say, all right, I got it. And I say, Well, I’ll send you two segments that seem to work out pretty well, and I wait for you to acknowledge those. And you do, and I say, well, let’s double it again. Let’s go to four segments. And then 816, 32, and so on, we grow our window size. And the larger the window size, the more efficient our communication, the less time we’re waiting around for that acknowledgment to arrive.
And the reason congestion avoidance is so important is that when that queue fills up and it starts to drop packets, each of those flows go into what’s called TCP slow start. That’s where we say, I did not get my Acknowledgment. Something must have happened to this packet. My window size must be too big, and I drop my window size back down. And that’s not a big deal if it happens to a single TCP flow. But if we’re overflowing that bucket, if everybody’s being dropped, then that’s called TCP synchronization, where everybody is simultaneously going into TCP slow start. And that leads to an incredibly inefficient use of bandwidth. So we never want to overflow that queue.
And the reason I have the live long and prosper Vulcan symbol on screen is this reminds me of my favorite Star Trek movie. It’s star Trek Two. The Wrath of Khan. You might remember, Ricardo Montaban was playing Con, and he’s damaged the Enterprise, and he’s going to blow his ship up, which is going to blow the Enterprise up, and the warp engines are down on the Enterprise. So Spock goes down into Main Engineering, and there’s a radiation leak, but he goes in there, he fixes it, but then he is poisoned by the radiation, and he’s dying very quickly. So Kirk, he comes down, and through the glass, he says, Spock. And Spock comes to the Glyce and says, ship out of danger. And Kirk says yes. And they go on to have this conversation where he’s asking, why did you do it, Spock? Why did you give your life to save the Enterprise? And Spock says and I paraphrase. Don’t grieve, Admiral.
It’s logical, with weighted red, that’s the congestion avoidance tool will often be using, and that stands for weighted random early detection. Spock says, with weighted red, the needs of the many outweigh the needs of the few. And then Kirk says, or the one. Now, what I mean by that analogy is this to prevent that queue from filling up and everybody being punished, we will randomly throw the occasional packets away so we don’t overflow that queue. And the deeper the queue gets, the more aggressively we start to throw those packets away. And again, the tool we commonly use is weighted random early detection. The weight means that we’re paying attention to the marking, but some devices use just random early detection where we don’t pay attention to the marking.
There’s another category of QoS mechanisms where we try to set a speed limit so we don’t exceed a certain amount of bandwidth for specific traffic types, like network gaming traffic as an example. And these two tools fall under the category of traffic conditioners and they are policing and shaping. Policing is a lot more harsh than shaping. Shaping says, I’m so sorry, if I sent you right now it would exceed the bandwidth. So please don’t go anywhere. Let me just store you in this queue and in a moment I’ll come get you and I’ll send you on your way when there’s enough bandwidth. Policing is not so understanding when somebody tries to break the speed limit.
Policing says you’re going to be dropped because you’re exceeding this speed limit. And the reason I have a bowl of soup on the screen, it reminds me of that Seinfeld episode where if you don’t order the soup correctly, the guy says no soup for you, come back one week. That’s what policing does. It says no bandwidth for you if you try to violate that speed limit and it literally says come back, it drops the packets. So TCP flows, they will retransmit the packets, they’ll have to transmit again. And those are a couple of ways that we can set a speed limit on our traffic. And finally we have link efficiency. And to be honest, this is not as big of a deal as it used to be when we had lower speed wan links in the past on the order of 128 Kbps.
This was a big deal where we’re trying to make the most efficient use of a relatively limited way in bandwidth. And as one example of a link efficiency mechanism, consider a triple tractor trailer. Now, I couldn’t find a picture of a triple tractor trailer to put on screen, but have you seen these on the road where you’ve got the, I guess you call it a tractor up front and you’ve got these three trailers behind it. That’s a large vehicle. Let’s imagine that you’re sitting behind one of these triple tractor trailers at a traffic light. You’re in your little tiny sports car and the traffic light turns green and the truck starts to go through the intersection. The first trailer goes through, the second trailer goes through, the third trailer goes through. Finally it’s your turn.
You’ve been delayed because you are behind a very big payload on a lower speed link, like 128 Kbps. If you have, for example, a little tiny voice packet like your little tiny sports car sitting behind a big data packet like the big truck, it can take too long for that data packet to get out of the interface and it could delay your voice and that could ruin your voice quality. Fortunately, there is a link efficiency mechanism called link fragmentation and interleaving, or LFI. Back to our metaphor with the truck. Let’s imagine that we took each of those three trailers and we put them behind their own tractor. Now, we had three separate vehicles on the road and we’re back there in a little tiny sports car. The light turns green. Well, we’re nimble, we’re agile, we can weave in and out and get through that intersection quicker.
Same thing with link fragmentation and interleaving. We can take that big data payload and we bust it up, we fragment it, and then, just like we’re shuffling a deck of cards, we can shuffle in our little tiny voice packets in amongst the now fragmented data packets. And as a result, the voice gets through the interface quicker. And that’s a look at a collection of quality of service mechanisms. We want to recognize and mark that traffic very early on so the next device can take action based on that. Marking that action might be to put that packet in a specific queue using a queuing mechanism. We might want to occasionally drop packets so that everybody doesn’t have to suffer. And we could do that with weighted random early detection. We might want to limit the bandwidth used by some traffic types. We could do that with policing and shaping. And finally, if we have a lower speed link and we’ve got big data payloads, we could break those up and then shuffle in our little tiny payloads. And those are a few QoS mechanisms.
