CLCOR (350-801) Topic 1.1.c: Bandwidth, Regions, & Locations Theory

[Music] hey welcome back to the channel everybody this is kevin and this week's video is a sample video from the cl core video training series that i'm currently developing specifically we're going to talk about three things number one we're going to do a calculation of how much bandwidth is going to be required for a phone to place a voice over ip phone call number two we're going to take a look at a feature called regents and a region can influence the codec selection a codec is the coder decoder it can influence the codec selection within a site or between sites and thirdly we're going to take a look at a call admission control mechanism called locations and even talk about enhanced locations we'll take a look at the theory of all that in this video and as always if you enjoy the video it really does help the channel if you'll give me a like down below and subscribe so you don't miss any of our weekly content now join me in this fairly lengthy video where we're going to talk about bandwidth regions and locations in this video let's consider a design consideration how does the vein with used by our audio calls and our video calls how does that bandwidth impact an ipwan interconnecting a couple of sites now i focus on the ipwan because we're typically not concerned much with the bandwidth of audio and video calls within a site after all we probably have our ethernet switches interconnected with gig links or 10 gig links or even higher but it's between those locations where we typically have less throughput that we want to pay attention to the bandwidth being consumed by our audio and video streams first let's consider audio and the formula for calculating how much bandwidth total a voice call takes up is to take the total packet size and multiply that by the number of packets that we're sending per second and we multiply that by 8 because the packet size is in bytes and we want a bandwidth in bits per second so we multiply packets per second by 8 to convert bytes to bits now how do we find the total packet size well here's the formula for that the total packet size the name implies it's more than just the voice payload itself we've got some header information to account for we've got to add on the layer 2 header and the layer 3 layer 4 header we typically combine those in the calculation we add those headers on to the payload size what about packets per second up in that top formula how do we calculate that well different codecs are going to have different bit rates not including any overhead we're going to take that codec bitrate and divide by 8 that's going to convert bits to bytes in this case and we're going to divide that number of bytes per second that a codec is going to be using we divide that by the voice payload size and that tells us how many packets are we sending per second then we just plug and chug we put in the total packet size and the packets per second we put that into the voice call bandwidth formula now let's walk through these one at a time and see where we can find these values first consider the layer two header now here is a partial table this is not comprehensive but this gives you a good idea of common layer two overhead values if we're using ethernet that's going to add on 14 bytes of header and i know what you might be saying you might say no no kevin it's actually 18 bytes well in the calculation according to cisco's latest design document we don't count the checksum which is 4 bytes so yes i agree there's lots of literature out there that says the ethernet header is 18 bytes and it is if you include the checksum with the most recent design document from cisco says we don't include the checksum in this calculation if we're doing point-to-point protocol that's going to add six bytes and i said this was only a partial table if you want more information let me point you to that design guide it's called the srnd that stands for the solution reference network designs and cisco is continually updating and coming out with new srnds as they release new versions of the unified communication software but you can always go to cisco.com go slash srnd and just go to the most recent srnd that's where these values came from and you can see a more comprehensive table there so we can use a table like that to get our layer two header what about the combined layer 3 and layer 4 header well we're doing voice over ip so the layer 3 header is going to be the ip header and it is 20 bytes in size the layer 4 header as we're streaming voice we're going to be using udp a layer 4 protocol which is encapsulating rtp the real time transport protocol also a layer 4 protocol that's right we've got one layer 4 protocol rtp encapsulated inside of another layer 4 protocol udp and udp is going to take up 8 bytes and rtp is going to take up 12 bytes you add all those up and you get a total layer 3 layer 4 combined header of 40 bytes and this is if we don't try to do header compression on some types of links that we might have on the wide area network for example a point-to-point link this would not work on ethernet but let's say we've got a point-to-point protocol link and we're trying to conserve some extra bandwidth we can enable a feature called rtp header compression here's the logic imagine a router at each side of this link and i'm sending frames as part of this voice call and the router at the other end is looking at these frames coming in and they say these frames have a lot in common they all have the same source and destination ip address they all have the same source and destination udp port number they all have the same rtp payload type this is redundant information we're sending in every single frame so instead of doing that let's just make a copy of this 40 byte header inside the routers at each end of the link and then we can send a session identifier to say this is part of this voice call and this is part of this other voice call and we'll allow the router at the other end to say oh you're part of this voice call i've made a copy of your header with all the source and destination addresses in the rtb payload type i'm going to put that back onto these packets as i receive them as a result instead of every packet having a 40 byte combined layer 3 layer 4 header it has a 2 byte header it's a huge bandwidth savings and by the way i say two bytes because that's what cisco does by default but you can enable udp checksums to check for errors in your header and if you do that it goes from two bytes to four bytes but in almost all cases we assume that rtb header compression is going to take this 40 byte layer 3 layer 4 combined header and convert it into only 2 bytes at this point we know how to get our layer 2 header size we know our layer 3 layer 4 header size is probably going to be 40 bytes or if we're doing rtp header compression it's probably going to be two bytes next up let's consider the voice payload size and this is reference information this is not something that we necessarily calculate we look it up in something like the s r d and the number of voice bytes being carried inside of a packet that can vary based on our sampling rate if we take a sample every 20 milliseconds well that's going to generate more frames per second than if we take a sample every 30 milliseconds as an example but usually the default is going to be a 20 millisecond sampling rate and at that sampling rate we've got a voice payload of 160 bytes for both the g.711 codec that's an uncompressed codec and the g.722 codec if we're using the 64k version of g.722 it has a lower rate variant as well but we're assuming we're not doing compression there those have a voice payload of 160 bytes if we use ilbc that's the internet low bitrate codec that's going to have a voice payload of 38 bytes again that depends on the sampling rate but if we have a sampling rate of 20 milliseconds its voice payload is going to be 38 bytes g.729 that's going to have an even smaller payload only 20 bytes now at this point we've gone through every item in this total packet size formula but something else we needed to calculate was the number of packets that we are sending per second here was the formula for that we took the codec bitrate divided by eight to convert bits to bytes and we divided that by the voice payload size which we just saw let's take a look at those same codecs again if we're using a g.711 or g.722 the 64k version of that we already saw that it's going to have a voice payload of 160 bytes well the bit rate is going to be 64 kilobits per second and we would just take those two values of the bitrate and the voice payload size and we would plug those into the packets per second formula and typically we're going to be sending 50 packets per second now that we know how to come up with all the different values for our formula let's go through an example together here we're saying that the voice call bandwidth equals the total packet size multiplied by the packets per second times eight because we're converting bytes to bits there in this example let's assume we're using the g.711 codec and we're doing it over ethernet based on the tables i've shown you we know that the total packet size is the layer 2 header for ethernet 14 bytes again you could argue it's 18 but according to the latest srnd it's 14 bytes and we add that to the combined layer 3 layer 4 header which is going to be 40 bytes we're not able to do rtp header compression over ethernet so we know it's 40 bytes and to that we add the voice payload size and for g.711 we saw just looking it up in a table that's 160 bytes that means our grand total packet size is 214 bytes how many packets are we sending per second well that's going to be the codec bit rate of 64 000 bits per second for g.711 and we divide that bit rate by 8 to convert bits to bytes and then we divide that value by 160 that's the voice payload size now we've got all the elements of our formula and we're going to say that the voice call bandwidth is the total packet size of 214 bytes multiplied by 50 the number of packets per second multiplied by 8 because we're converting those bytes to bits and that's going to give us 85 600 bits per second or we could simply say 85.6 kilobits per second and one time i created an excel spreadsheet where i could just have columns and put all these different values in there and do some side by side comparisons it's very easy to do that if you just want to use these formulas to set that up in some sort of a spreadsheet but just as a reference for you here is a table showing you for various codecs in various layer 2 media what sort of bandwidth demand we can expect we just calculated that g.711 over ethernet takes up 85.6 kilobits per second we see that on this table what about iobc that's going to save us some bandwidth and it's going to take up 36.8 kilobits per second if we're trying to save even more bandwidth we could go down to g.729 over ethernet that's going to give us 29.6 kilobits per second and each time we go down a little bit in bandwidth we're typically sacrificing a little bit of voice quality and iobc is considered to be better quality than g.729 let's take a look at what rtp header compression does let's go down to the bottom two rows if we're using g.729 over a point-to-point protocol link and we're not doing header compression the ppp header is 6 bytes player 3 layer 4 header it's 40 bytes because we're not doing header compression the voice payload size is only 20 bytes and not including any overhead g.729 has a codec bitrate of eight kilobits per second it's going to give us a total packet size of 66 bytes we're sending 50 of those per second and that comes out to a bandwidth demand of 26.4 kilobits per second what happens if we turn on rtp header compression notice the bottom row instead of having a 40 byte combined layer 3 layer 4 header it's only two bytes we're not using a udp check sum so it's only two bytes and if you do the math it comes out to a bandwidth demand of only 11.2 kilobits per second we can more than double our call carrying capacity in that instance by just doing rtb header compression and on modern routers with modern cisco ios that puts a negligible process or burden on our routers that wasn't always the case but it is now and something we haven't mentioned is security there is a variant of rtp the real-time transport protocol that will encrypt our voice traffic if we want to do secure rtp that's going to add 4 bytes to the voice payload size now if you have this in an excel spreadsheet careful if you have the packets per second value being calculated based on your voice payload size it can throw your formula off so just know that by default you're almost always going to be using a 50 packets per second so you might just want to put that as a hard-coded value in your spreadsheet because otherwise it could mess your result up but let's say if we're doing g.711 over ethernet i would still say the packets per second is 50 but i would say my voice payload size was not 160 it would be 164 the extra 4 bytes because we're doing secure rtp and that's a look at how we can calculate our voice or our audio bitrates what about video well video is a little bit more challenging to pin down because it can vary widely depending on what equipment we're using and how the video sampling is being done and what quality we're okay with but let me give you just an example and you can look at the documentation for your endpoint to get more information specific to you or you could check out that srnd guide that i gave you the link to a moment ago but just as one example let's say that we're using cisco jabber here's a table that tells us how much bandwidth is going to be required for a specific resolution for example let's take a look at 720p resolution high definition that's a resolution of 1280x720 that's going to take up 1.3 megabits per second by our cisco jabber client and that includes not just video it also includes the audio portion as well and specifically we're saying we're using g.711 audio along with the video stream and the audio and video combined for 720p resolution on cisco jabber 1.3 megabits per second and now that we have a better idea of how we can calculate how much bandwidth is being used by a voice call and or a video call how can we control that how do we prevent an over subscription of that land link where we're trying to use too much bandwidth well cisco gives us a couple of tools we want to talk about regions and locations first of all consider regions a region is going to influence the codec that's selected between a couple of regions now here i have two regions one for hq called hq and one for branch office one called br1 and what i can do and we'll see this when we get into the configuration later on in the course i could say within hq i'm not concerned about doing compression i'm fine just using g.711 or the uncompressed version of g.722 i can say if a call is going from hq to hq we're staying within the region then i'll use g.722 or g.711 that's what shows up on the screen when you're selecting this and we'll see that later again when we get into the configuration here's what's not obvious though when i say yeah use g72 or g711 i'm not actually forcing one of those codex to be used i'm setting a bar or a threshold if you will i'm saying whatever codec the endpoints negotiate they are not allowed to negotiate a codec that will take up more bandwidth than these which would be 64 kilobits per second payload only but maybe my endpoints wanted to negotiate ilbc or g.729 g.729 only takes up eight kilobits per second well that falls under the threshold of 64k that i've set by specifying g722 or g711 so yeah if the endpoints wanted to use ilbc or g.729 they could definitely do that same thing within br1 if i'm going from br1 to another phone within br1 i'm not concerned about compression so i set that threshold at 64k by specifying those 64k codecs however where i'm most concerned about bandwidth usage is over that so let's say if i'm going between hq and br1 i'll set my threshold to the bit rate used by ilbc or g.728 and that's going to be assumed to be a value of 16 kilobits per second again i'm not forcing the codec to be ilbc i'm just setting that 16 kilobit per second threshold could i negotiate g.729 if that's what my endpoints preferred absolutely because the g.729 bandwidth of eight kilobits per second that definitely falls under the threshold of 16k set by ilbc or g.728 now what about video when we specify video in a region's configuration we're not saying here's the video codec such as h.264 no we're actually specifying a bandwidth amount however that amount that we put in for the video bandwidth that includes not just the video it also includes the audio stream however it doesn't accommodate for any overhead so let's say the video bandwidth was set to 384 kilobits per second well if you're using g.711 as your audio codec for that video stream we know that g711 takes up 64 kilobits per second so we would subtract 64k from 384k giving us a video bandwidth of 320k but we have not accounted for overhead and one design best practice that some people use is to add 20 to whatever bandwidth value you come up with to accommodate for that overhead and when you're setting up the video bandwidth you're going to have two different settings and we'll see this when we get into the configuration later in the course but there's going to be one setting for video calls that might be for cisco jabber or for your 8865 cisco iphones as a couple of examples but there's another setting for immersive video calls when you see immersive video calls think telepresence maybe we want to grant some extra bandwidth to those telepresence rooms regions that's going to help us preserve our ip weigh in bandwidth by influencing the codex selection between our sites however we don't want to over subscribe the ipwan even if we do all of our best effort to minimize the bandwidth usage if we place too many simultaneous calls over the ipwan it's not just the last call the call that broke the camel's back it's not just that call that has poor voice quality it's everybody because everybody is fighting it out for too little bandwidth so let's take a look at a feature called cac call admission control or cac and there is a cac feature built into cisco unified communications manager called locations and locations has been around for a while and we're going to take a look first of all at traditional locations and then we'll take a look at an enhanced version of locations but by default we have a location that's named hub none and let's say that's the location to which we assign our headquarters site it belongs to hub none and hub none should give you a sense that this was designed with the assumption we're using a hub and spoke topology let's say i have a location in louisville named louisville and i have a location in lexington named lexington and we can go in and configure these locations as having 512k going to louisville or 128k going to lexington in a case like this traditional locations work great we can start deducting bandwidth from this total every time we place a call and when we run out of bandwidth we say nope sorry you're going to be rejected and we might have some backup path selected we could set up something called aar automated alternate routing which might send the call out over the pstn to get over to louisville or lexington but here's where traditional locations start to break down a bit where we're not in a purely hub and spoke environment let's say i have an additional link going between louisville and lexington and that link has a bandwidth of 256 kilobits per second now we can look at this and say oh it would be more efficient to go from the hq site down to louisville and then over that 250 6k link over to lexington but traditional locations will not see that it will have no knowledge of that 256k link because it's not coming into the hub non location so if we try to go from hq to lexington we're going to take that direct path here's another instance where we might have a breakdown with traditional locations and that's when a location is a transit location let's say for example that i've got a link to orlando and through the orlando location i get to the tampa location and if i go into my locations configuration and say i've got a 128k link to tampa because that's the speed between tampa and orlando and i've got a 256k link between the hub non-location and orlando locations would not view that correctly locations would think that we could be using 128k going to tampa while simultaneously using 256k going to orlando that's not going to work because that 128k available to tampo that comes over the orlando link because of situations like these traditional locations can break down if we have anything other than a hub and spoke topology so how do we address this well the great news is there's now something called enhanced locations with enhanced locations it's a lot like ospf with ospf we assign a cost to each link based on bandwidth and we do a calculation to determine the shortest path in terms of cost to get from point a to point b well with enhanced locations we're going to specify weights based on bandwidth and here i'm assigning a weight of 40 to that 128 key link between orlando and tampa and a lower weight a more attractive weight of 20 between hub none and orlando and i won't read the rest out but you see the higher the bandwidth the lower the weight now based on this if i wanted to go from the hub none location to lexington i would look at the weight i would no longer take that direct path over the 120k link that has a weight of 40. i would instead say i'm going to go down to louisville that's going to give me a weight of 10 and then go from louisville over to lexington that would add on the weight of 20. so we would have 10 plus 20. that's a grand total weight of 30 if i go from hub none to louisville to lexington that's less than the weight of 40 if i go directly to lexington so that's the path i'm going to take from hq's hub none location to louisville to lexington and that's called the effective path and you might wonder when we're putting in these bandwidth amounts into our locations configuration which we'll see later on in the course are we including the overhead as part of that bandwidth or not well it's interesting we're going to consider some overhead but we're not considering layer 2 overhead well here's a table and again there are design documents that you can check out at cisco's website but this table shows us the link been with we would put into a locations configuration for something like g.711 80 kilobits per second we're including layer 3 and layer 4 overhead there but we're not including layer 2 overhead for one reason we're not sure what that overhead would be we don't know what the layer 2 media is and for video calls if you have a 128k video call that's the bandwidth you put in we're not adding any header on to that video stream and that includes both the video and the audio so that's enhanced locations and it does a great job of calling mission control one slight potential challenge we have though in order for this to work all of the servers in the cluster that are going to be placing these calls they need to have a service running called the location bandwidth manager the lbm service and in order for this lbm service to work by default we have to have a full mesh of connections every server running the lbm service has to talk to every other server running the lbm service and with three servers it's not a big deal but if we have a few more servers it might start to create some extra overhead that we just don't need so here's an option let's say for that communications manager server on the right we're going to stop running the lbm service and we're going to take the remaining two communication manager servers we'll continue to run the lbm service on them but we're going to say that they belong to this lbm group and instead of that server on the right having a full mesh of connectivity to all the other servers it just has to have a single connection over to the lbm group again not a big deal with only three communication manager servers but you can see how this would really help with scalability within a cluster and speaking of clusters what we've been considering is within a cluster what if we're trying to do locations based cac between clusters well we can continue to use enhanced locations check this out let's say we've got two clusters cluster a cluster b and we've got our communication manager servers running that lbm service but in addition to those servers belonging to an lbm group we can have one or more servers belonging to an lbm hub group now the function of a server in an lbm hub group is to talk to other servers in lbm hub groups so we're going to have the server in the lbm hub group for cluster a form a sip trunk with the lbm hub group in cluster b and we can educate our locations configuration about that sip trunk interconnecting our clusters so to wrap up this video we've taken a look at the bandwidth required for an audio call the bandwidth required for a video call and how we can preserve weigh in bandwidth between a couple of sites by influencing the codex selection using regions and how we can prevent over subscribing one of those links by using either traditional locations or if we have something other than a pure hub and smoke topology how we can perform call it mission control using enhanced locations both within a cluster and between clusters [Music] you

Channel: Kevin Wallace Training, LLC

Views: 2,820

Keywords: cisco, clcor, cucm, call manager, voip, voice over ip, voip bandwidth, 350-801, unified communications, #kwtrain

Id: rjxPxpzSfrE

Length: 27min 24sec (1644 seconds)

Published: Tue Dec 08 2020