 G'day viewers and welcome to computer networks. I'm David Weatherall and I'll be your host for these lectures and in this first segment We're going to talk about some goals for the course what you'll learn by going through it as well as some of the motivation for a Why you might care to study computer networks in the first place? So this picture here describes our usual view of the network You're all probably familiar with using clients computers that make use of the internet And you know that they talk to servers over the other side of the network What's much less visible what most of us really don't have a good sense of is what goes on in here inside the network And that is exactly the focus of this course So if we think about networking courses, there are roughly three kinds of topics which are covered At the bottom layer there are communications courses and these courses are all about how we use signals To carry information in bits across networks Building on this layer. There are classic networking courses such as those that tell you how the internet operates These courses are mostly about how packets are carried across networks And at a higher layer still distributed systems courses tell you about the different kinds of apps or applications Which can be built on top of networks and make use of their services The ground we're going to cover is here That is to say we'll provide you with our classic networking course Which talks about packets and the internet, but we'll also do a little bit of communications and distributed systems so that you understand How the network builds on communications? How bits are carried across networks and also the kinds of things that applications can do on the top of networks Okay, so we really have two main goals for you in this course and I'll go over each of them in turn Our first goal here is really for you to simply learn how the internet works And by that I mean for you to gain a deep appreciation of what happens for instance When you are browse the web what really goes on underneath clicking on our link is a fairly simple action But actually there's a surprising amount of machinery that exists below it to support that kind of operation And in the course of understanding how the internet works We're going to learn about many acronyms that you've probably already heard of things like TCP IP the DNS HTTP net VPNs 80 to 11 and so on and so forth many other acronyms too I expect that you've seen a lot of them and what we'll go over is we'll do much more than tell you what they mean We'll give you a sense of how they operate and what their purpose is and why they even exist in the first place So I'm going to go over each of those Points a little bit more and give you a little more detail So first of all in terms of learning about the internet, why would you care to learn about the internet? Well, there are several reasons. One is simply curiosity. You know the internet is a very important artifact You might be curious as to how it works Since it's an important artifact. It also has a big impact on our world. I'll go over each of these points in a little more detail That's what this little symbol. It means more coming And a third reason you might care to learn about the internet is simply job prospects There's a lot of growth these days in engineering and computer science related jobs for which networking There's an important component. So having a deep understanding of networking techniques and how the internet works can definitely be good for your job prospects Okay, so let's talk about our curiosity in the internet a little more The internet really had very humble beginnings. This is what it looked like around 1970 when it first started and at that time it was known as the ARPANET and you can see here Here is the you know original for node network configuration the topology look at that and Over time you can see that it quickly began growing to this other network in the middle and then to this slightly larger network as it grew Well, that was a while ago around 1970 here's something that's closer to where we are today this is a visualization of the internet in 2005 around 2005 and By this time the internet has turned into an everyday institution It's something that nearly all of us use we use it at work at home and while we're on the go Now actually no one knows what the internet looks like anymore at this scale This picture really is a visualization. That's based on just a data set that's been gathered to give a good approximation of what the internet looks like and you can see it looks more like It looks a little more like a star chart with millions of links in there So it's really quite an amazingly complicated extraction nowadays The another reason why you might get a learn about the internet is the tremendous impact that it has on our society So the internet is really an enabler here of societal change And you can see this in some of the ways that we already use the internet today The internet provides very easy access to large amounts of knowledge by systems such as Wikipedia Previously that knowledge could be very difficult time-consuming or expensive to obtain The internet allows us to construct to undertake electronic commerce with systems such as PayPal With a really very little friction so that we can buy and sell goods across the internet very easily nowadays And the internet's even changed the way that we meet people We've with various systems and the way that people interact through networks And the internet also provides us ways of communicating without censorship across even international borders So it's changed the way that people are able to communicate. This is really a huge impact It's having on the world, you know, we might add to this list Education because the internet now with systems such as Coursera is really beginning to have a very Significant impact on how we educate people As well as impacting society the internet is also having a large impact on the economies of the world Really you could think of the internet as an engine of economic growth and now these examples I've given you are all examples of business models that Didn't exist before the internet. They didn't really make sense without the internet So Google as you probably know Runs using a business model of advertising sponsored search This is something that's become possible because of the internet For other stores such as Amazon Amazon operates with a it's an online store, of course But it also operates using a long tail model where it's able to sell a very large number of goods It has an inventory which is much larger than you can really Fit in any one reasonable physical store for people to wander around so it's a different model Online marketplaces such as eBay enable buyers and sellers to come together quickly even though they're in very different physical locations And even more recently, there's a great deal of interest in crowdsourcing systems such as Amazon Mechanical Turk Which can allow many people spreading different areas to all contribute to one task In ways that which really weren't possible before so the internet is having a tremendous impact on the way we do business Okay, so that's a little bit about why you might learn about the internet Today the other course the outside the other main goal of this course is for you to learn the fundamentals of computer networking And that is to say to understand hard problems that computer networks need to solve and the design Strategies which have proven valuable for solving these difficult problems now It may be a little more difficult for you to appreciate why you would care to learn about the fundamentals of computer networks Why should you bother as opposed to learning about how the internet works today? Well, there are several reasons the fundamentals are going to apply to all kinds of computer networks We might talk about Wi-Fi a lot just because it's an in a network technology that many of you see and we might not talk About satellite networks for example, but many of the fundamentals we learn about computer networks will also apply to satellite network So you're learning a little extra you'll be able to transfer your knowledge to other kinds of networks Much of this material is actually intellectually interesting. There are some thorny problems for us to solve I'll give you an example of that in a moment and perhaps the most important reason you might care to learn about the fundamentals Is because of change and reinvention the internet is not static. It's continuing to change and evolve Understanding the fundamentals gives you long-term knowledge, which will help you understand the internet of the future Knowledge about the fundamentals is knowledge that doesn't get outdated over time Okay, so let's just talk about some of that in a little more detail This slide just talks a bit about some of the intellectual interest you can get from the fundamentals You know just as an example of a key problem in networking a key problem is Reliability if you're sending a message across the network to your bank It's not acceptable for that message to be altered so that the wrong message arrives and you think that was what was sent That wouldn't be good Similarly, it's not acceptable if there's some failure in the internet somewhere for that to prevent you from getting to your bank The failure is not really on the path Well, you know all of these things can happen messages can get corrupted as they go across the network So we're going to have to do something about that Failures well failures happen all of the time you need to it actually the internet is so large that some parts of it must have failed right now Yet we want the remainder to work seamlessly Well, how are we going to do this and provide reliability? Actually, if you think about it, it's quite a thorny problem every component in the internet can fail So we want to be prepared for that yet any mechanism we add to handle that can also fail because it's just more mechanism So you can see the catch 22 here Luckily some clever solutions have been devised and we'll learn about them during the course that provide fairly high kinds of reliability For instance, we'll learn about codes which can detect incorrect errors and also routing strategies Which can rattle around the failed components of the internet and Reliability is just my example the one I chose to talk about here There are other deep problems that we'll look at in networking during the course Another example one is about network growth and evolution Imagine trying to design a system to be able to accommodate Applications that you haven't even thought of yet and to be able to grow and get you know Thousand or a million times larger than the initial system. This is really hard Well, there are some there are some useful techniques that will come up with here And by the way the the numbers here these are section numbers in your text which you can consult There's no need to go off and do that for this slide here This is really referencing material that will cover throughout the whole course So don't don't jump into all of that yet just start with the introductory material Another difficult problem just to put another a last couple on the table is the allocation of resources such as network bandwidth That's really what networks are doing providing bandwidth to the different users But if you think about the internet many people are using it Users are coming and going as some people surf the internet or stop surfing the internet and so forth And we're going to need to design mechanisms which can handle all of this different churn and still do a good job of giving Whoever wants bandwidth the bandwidth that's available in the internet. This is this poses some difficult problems Security is also another difficult area It actually turns out to be very difficult to design an internet Which is very open and easy for everyone to use which is key for innovation And there's an important part of the internet yet at the same time is secure in the sense of being very difficult to abuse so that Malicious parties can't very easily undermine the actions of other parties. So there's a big tension here and we'll learn about some of the techniques Okay, but the other reason you might care about to know about the fundamentals is really the reinvention of the internet Now if you think about it, you realize that the internet is constantly being reinvented The internet is growing tremendously over time and there are also lots of technology trends Both of these changes are driving upheavals in the way the internet is designed and the way the internet is used So the upshot here is that today's internet is actually quite different than yesterday's internet in many respects Tomorrow's internet is going to be different again Yet for both of them the fundamentals are going to remain the same and they will help you understand What's possible in computer networks? That's why we want to tell you about them Just to go into that in a little more detail This graph shows you the growth of the internet in terms of the size and you can see here in the early 90s We start with all maybe a million hosts and up here. We've gone up to maybe a billion hosts. So Wow, look at that. That's a factor of A thousand growth in just the size of the internet Which is it, you know really pretty impressive growth If you come up with designs and you want them to be able to work through that evolution But more than that, we've also seen many upheavals in the Internet over this period and I've listed here just some of the growth and technology drivers Which are causing those upheavals you can see for instance when the web emerged This led actually to the creation of what are called content distribution networks to satisfy the enormous demand for getting the same web pages to many different people As the content of the network changed and we shifted to digital songs and videos There was an upheaval in which we shifted to and explored different peer-to-peer methods for sharing files As the cost per bit of sending information over the internet has fallen We've switched increasingly to voice over IP Calling so that functions which were traditionally part of the telecommunication network The telephone network have been incorporated into the internet this one. This one's about growth the growth many internet hosts This is actually driven a change where we're going to have to update all of the basic internet protocols And we're in a transition right now to IPv6 But you can see while this one's about growth pure growth many of the others aren't they really upheavals caused by Technology trends and changes in the way we use the internet and finally just to put out there Advances in wireless have led to many more mobile Devices and these devices stress the internet protocols in different ways that we'll see a little bit of during the course Okay, and finally just to close this segment I want to point out one thing which is not an explicit goal of this course and that's to provide you with IT job skills Such as for instance Cisco certification material to help you configure networks That's not because this is not an important skill It's because some of this material can change fairly quickly over time as new equipment comes and goes Was what we want to give you really is long-term knowledge Which will remain relevant in the future and help you understand the internet now That's not to say that this is purely an academic course However, much of the material you learn will really be very practical about how the internet works And we'll also experiment a little bit with some hands-on tools So you'll get a good sense of some real-world stuff. Okay, so on with the show G'day viewers in this segment. We're going to talk about the uses of network And that's because it's important for us to understand how the network is used if we're going to be able to design effective networks in the first place Okay, so as you know, we use networks in many different ways in pretty much all the places we go We use networks at work for different kinds of email and file sharing and printing At home for different kinds of entertainment listening to songs watching movies reading the news As well as messaging and shopping over the internet and we use it when we're on the go to Not just for calls and texts or playing games But also for accessing the different kinds of information services watching videos Consulting where we are on the map and so forth. So there are many different uses of networks and you are familiar with most of them But our point here is really not to focus on individual uses of networks But try and understand what these particular uses like YouTube and so forth Tell us about why these we build networks because that's going to help us build more effective networks in the future When we know what networks are trying to accomplish Well, I can give you several reasons why we build networks and we're going to now go through them in some of the following slides One of the first uses that might come to mind is simply for our communication between users This is a traditional usage of computer networks really from the get go and really from the from the telephone onwards You might think of using voice over IP sending telephone calls over the network These days we video conference as well as instant message and connect people via social networks But it's all about user communication The point here is that the computer network is enabling remote communication and A particular aspect of the network we would need to think about to provide remote communication is low latency If you really want interactive communication between people you need a fairly low latency network For that communication to be effective Another important reason that we build computer networks is for resource sharing That is to allow many different users to access the same underlying resource now the the classic resource which was shared was a Printer imagine in a company network instead of giving everyone an individual printer You put one on the network and everyone accesses it. They're sharing this resource. That's wonderful Today, maybe you're not sharing a printer so much, but there are the resources which you're still sharing Maybe it's a 3d printer today. Maybe we're all sharing Google search index or even we're sharing machines Which are in the cloud being used the idea here is that by performing this resource sharing we are Providing a more effective a cost effective way to access resources than providing dedicated resources per user. Just think of that Printer per user versus one printer per work group In fact, even the network itself which is providing a resource called bandwidth Even the bandwidth of the links in the network have been shared by different users over time and This sharing process is called statistical multiplexing is the name for it and I'll go over that next Okay, so statistic call multiplexing is a pretty big fancy name but all it really means is Sharing of network bandwidth between different users according to the statistics of their demand Multiplexing here is just the fancy networking word for sharing so statistical multiplexing just sharing bandwidth amongst users Where the statistics mean? Just you know when they choose to access the network and so forth The reason that this is useful that you want to do this is it turns out that users of the network are mostly idle Most of the time you're actually not using the network who your devices are not using the network And when you do use the network your traffic tends to be bursty. So it's occurring in just these little spurts of traffic So this means that we can combine the traffic of different users And in that way we'll get to something which is using the network really more of the time most of the time And we'll use that resource inside the network such as network bandwidth more effectively At least that's the theory And the key question for us is how does it help if we statistically multiplex users to get them? So let's just think about that and what I'll do is I'll go over a Simple example, this is you know a little bit artificial, but but it's mostly to convey the point So don't take this quite literally just take the big point out of it Let's consider for a moment users in an ISP network. Here's the ISP network here This network has a hundred megabits per second of bandwidth to the rest of the network the internet We haven't gone over megabits per second, but just think of that as units of bandwidth. So a hundred units of bandwidth Now each of the users here Wants to subscribe to five megabits per second That's how much bandwidth maybe you want at home to ensure that you can watch your videos But the statistical multiplexing bit of it is that each user is active only 50% of the time Actually, that's quite high many users might not be active that often, but let's just say 50% of the time at most That's when they're active Well, let's think about different ways to design this network Assume that we dedicate bandwidth to each user if we do that Then each user is always going to have five megabits per second of their own throughout the that ISP So they'll always have it when they need it. How many users can we then support? Well, we can support a hundred megabits per second divided by five megabits per second per user. That's 20 users Okay But if we think about this case where there are 20 users, let's ask for the sake of argument What's the probability that all of the bandwidth within the ISP is being used now? The kicker here is we're going to assume that all of the users are independent That's a little bit unrealistic, but it's good for thinking about this So let's just assuming that all of the users are independent This is a probability calculation. Some of you may not be familiar with it. Don't worry about it too much So there are 20 users. What's the probability that the first user is using their five megabits per second? That's a half. What's the probability that the second user is using their five megabits per second? That's another half and so on up to the 20th user a half If you multiply all of these together you get a half to the 20th power And that's just a little less than one on a million Wow, so there's only a one on a million chance That all of the users are going to be using the their bandwidth so that the ISP bandwidth will be used So actually a lot of the time bandwidth inside this ISP will be wasted Can we do better by using a little bit of statistic or multiplexing? Well, yes, and that's the point of this example Just imagine now that I'm changing the number of users that same ISP is serving and it's going to sign up 30 different users They're all going to act independently. What's going to happen? Well, this picture here this binomial calculation shows you the what is likely to happen if all of the users are independent and This graph here is showing you versus the number of users on the x-axis The probability that a certain number of users will be using the network on the y-axis Now it turns out that according to this there is only a 2% chance that you'll need that you'll have more than 20 users So that's this tail here more than 20 This is 2% Chance, it's not very much Actually, you can see the the most likely situation is where we'll have 15 users using the network. That's the highest probability This makes sense because there are 30 users and the probability for each of the users using the network is a half half of 30 is 15 That's why 15 is the most likely case. You can see the chance of using all 30 users here is very very low Boy, this is a this is 2 to the minus 30. This is like 1 in a billion now Many of you may not be familiar with the binomial calculations here If you're interested to learn more you can look up binomial probabilities on the web and learn a little bit about it The point here is that by going through calculations like this, which I would need to use a calculated to use We can see that if you have 30 users It's quite likely that the number of users within the network will be somewhere between 10 and 20 Well, if we're willing to go with that 2% chance that most of the time it'll be okay Then we reach this conclusion here We are able to serve more users with the same size network and those users are many of them are likely to be just as happy or almost as happy This gives us a gain because now we're serving 30 users in a network Which if we divided it up for users individually, we could only fit 20 This is sometimes described as a statistical multiplexing gain here and the gain here is 1.5 So we're 50% better off by doing this and we're able to provide network service more cheaply That's why you would want to do this. Now, of course the danger here is that depending on your model here We could get unlucky Actually, it's possible that more than 20 users would want to use the network Some of you may realize this. This is quite similar to airline overbooking Airlines often sell more seats than they have Actually inside their plane because they know that not everyone is likely to show up So if they sell more seats, well that will make their service more cost effective But every now and again someone Gets a little bit of an unfortunate surprise and they try and shift people to other flights Now here if we get unlucky and more than 20 users want to use the network Maybe the users will have slightly degraded service and I get four megabits per second instead of five And this might be okay sometimes So you can see the attraction of this idea that statistical multiplex on this resource sharing is Is in is important in the design of networks to make them cost effective Even though my example is a little simplistic Okay forging ahead another reason that we like to use computer networks is for content delivery Now particularly with the emergence of the web you realize that the same content is now delivered to many users This used to be web page nowadays. This is videos So these are actually really quite large objects a large amount of content the same exactly the same content is Delivered to many users and we find that with computer networks We can deliver the same information to more users more efficiently than sending a separate copy of that information to each user And we can do this by using what are called replicas inside the network. Let me show you how Okay, so here's a content delivery scenario. Let's just imagine that we don't use replicas first So we have our four users here over on the right-hand side and we have a source This is maybe this is where the video is and We want to send it to all of the users and as a measure of work. We're going to use network hops Sending the video across each individual hop of the network. Well, first of all the source sends information to the first user So one hop two hop three hops and we get it there now the source sends the same video to the second user The third user you can see where I'm going here and the fourth user The total number of network hops we've used or work. We've done is a four by three. That's 12 network hops in this example Well now let's use Let's send the content by these replicas Here's a replica node here. So the source is the same node here. This is where the video starts off Users are over here on the right, but we've also added this replica node right here So the way we're now going to send the same video to all of these users is to send it from the source Once to the replica that's nearby and then from the replica, which is deliberately placed close to the users We'll send one copy a copy to each of the users And guess what now we're going to take one two three four here to the individual users plus two hops here and here That's a total of six network hops So we've done half the work by arranging at the design of our content distribution And yet we've still got the same video to all of the users So with clever designs we can provide more efficient content distribution in networks another reason For building computer networks is to let not people communicate with one another But to let computers communicate with computers to interact with them in different ways actually we do this all of the time when you're making Buying something on the internet using e-commerce or making a reservation and so forth You might think of these as very human driven operations But once you give the go go ahead your computer or a remote computer are interacting to perform a transaction You want to take the human out of the loop a little bit consider things like high-frequency trading where computers are buying and selling Many different stocks very quickly over time These kind of operations are becoming more common where computers are interacting across the network and then the Internet the network computer network in this case Enabling automated information processing across a range of different parties. They're all coming together by the network And yet another interesting use of computer networks is for connecting computers to the physical world We can gather Sensor data at computers that are scattered around the network and then use the network to send that information to other places Or we can send commands across the internet to cause actuators to affect the real world So this is really what's going on with uses such as webcams Where you're observing gathering video about the internet mobile phones here are all about sensing Where you might gather data such as location and combine that with data across the internet to provide maps of where you are Yet another example in this case for actuation is something like a door lock Where you can remotely send commands to the door lock on your front door of your house So you open it up if a friend is visiting and you're not there This example is a use of computer networks is an example of a rich emerging usage It's starting now and we should expect to see a lot more of it over time Okay, well they're the different uses of computer networks and to round out this segment I want to talk about the value of connectivity and there's an interesting notion here Which is that the that large networks More valuable relatively more valuable than smaller ones So we have an inter impetus to combine small networks together into large ones And that's really what brings us something like the internet This argument for the the value that's inherent in connectivity was put forth by Bob Metcalf Sean on the right here Metcalf is one of the pioneers of computer networks He invented something called ethernet that we'll get to later one of the most successful local area networks of all time Metcalf posed this law around 1980 and he posited that the value of a network if you have n nodes in it That's the size of the network is proportional to n squared The implication of this statement is that a larger networks are a lot more valuable than smaller networks with the same number of nodes And so we're more likely to want to connect networks together to realize that value Let me give you a sense of the intuition for where this comes from You may be wondering what this n squared has to do with anything But imagine here in both of these pictures on the left hand side and the right hand side I have 12 nodes in a network now on the left hand side I have a larger network that has more connectivity. It's more valuable This network here is what's called a mesh actually It's a full mesh for 12 nodes here and each node is connected to all of the other nodes We think about the number of connections in it well from each node here. There are 12 of them We can connect to up to 11 other nodes. Here's one connection here This is it like a unidirectional connection from one node to another if we consider that then we have 12 times 11 That's a hundred and thirty two Different connections on the left hand side on the right hand side. We have two six node networks So inside one of these networks, we have six by five unidirectional connections. That's 30 Plus another 30 that's 60 So you can see that for 12 nodes here We have a lot more connectivity potential connections from one node to another node in the larger network on the left hand side Then on the right hand side And that's why larger networks are more valuable. Okay G'day viewers in this segment. We'll talk about the socket API the most widely used interface to write applications on the internet today Okay, so this figure is providing you with some context to remind you where we're at. We have applications Attached to hosts which are using the network the applications using this interface network application interface to talk over the network And this interface is really defining how applications can use the network The purpose of using this API course is to let apps talk to other apps So that's what apps want to do They just do this via the local host and this API should allow them to do this while hiding all of the details of what goes on In the in the network here in this cloud, which might be an ISP for instance How many routers there are and so forth in that cloud really shouldn't matter to the applications They just want to talk across the network So before we dive into the details, here's a motivating application a simple client server setup So on the left here We have a client which is sending this request over the network to a server the client is actually really a client app or a program running on the host the client hosts and When I say server I also mean the server app that's running on this host here Which is acting as a server the server app will receive the request and respond with a reply This reply could be anything it depends on our application the reply will go back to the client app That's running on the client host. This might be a web page for instance This is a very simple pattern However, it's a very important pattern because the basis of many different applications which you used on the internet today For instance, if you just consider file transfer Essentially the request is the name of the file that sent from the client to the server and the server app then returns the content of the file That's a much longer reply If we just consider the web browsing case the request that you're sending is a URL So you're sending the name of a particular page you would like and then the response from the server the reply from the server is the contents of that web page And yet another example is simply the simple echo program Where the client is sending a message and the server is echoing it back. This is very useful for test functionality Well, this is a key application pattern even though it's fairly simple. Let's see how you would write it Okay to write it we need some concrete API by which the applications writing on a host can interact with the network And that is the socket API It's providing us with a fairly simple abstraction that will let us use the network And as I said before sockets, that's the API which you use for essentially all internet applications So this is the one we really want to look at Sockets were devised long ago. They were part of the some of the early Berkeley Unix releases around about 1983 Since then sockets have become part of all major operating systems and Libraries to access them are present in all major programming languages Now all of the details vary a bit from one language to the other and one operating system to the other But at a high level they're all different socket APIs and they all look quite similar. They're just different enough in a few details Now there are two different kinds of network service that the socket API provides and The one we're going to look at is called streams This is a byte stream and it allows one application to reliably send a stream of bytes to the other application and vice versa That's that's all we'll really use to make our clients ever example. There is another kind of network service That's called datagrams where an application can unreliably send a message to another application We'll look at this much later in the course and you can ignore it for now Okay, so here's one more slightly deeper view of sockets Now we've said so here's the app And it's running on a host Here is the socket API is across here. That's the API between the applications and the network Sockets use a data structure that are called unsurprisingly a socket To let an application attach to the network So there's one socket that application is using an application needs at least one socket maybe more and here's another socket That the other application here is using Sockets also have numbers what's called a port number. This provides a form of addressing you can see on the left We have port number one on the left socket. The right socket is known as port number two These port numbers provide a form of addressing and that's what allows us to multiplex multiple different applications on the single host Because we can distinguish between them and here finally is the API this Table really shows you all of the main API calls that are used for sockets. So let's see what they are Well, the top one here. This is socket call is what's used to create the socket structure itself And that helps you create a new communication endpoint that an application can then use to access the network Okay, what about the rest? Well, there is a send call that is what an application uses along with its socket structure to send Information actually to send bytes reliably to an application elsewhere across the network Okay, and you won't be surprised to learn that there's also a receive call And this is a call which is used by the application at the other side to receive that information That's come across the network from the previous from the application that sent it So it's probably not surprising to you that we have a send and receive call. What's everything else? Well, all the other calls have to do with setting up and managing connections When we're talking about streams, they're really analogous to a telephone call before you can simply send information across the network You need to be able to set up a connection much like making a telephone call to connect and make sure that there's someone at the Other side is waiting to receive the information So the connect call here is used by one side to establish a connection to another side These three calls above it bind listen and accept these are calls that are used on the incoming side to get ready and to accept an incoming call and Finally the last call in this table is the closed call Well, that's what you do use to release a connection and hang up if you like when both sides are finished So let's go into a little bit more detail and see how we would actually use seconds Now I'm drawing a time sequence diagram here We have a vertical line for the client first host on the left-hand side another vertical line to the server on the right-hand side Time runs down this page. So let's see what happens over time. Well Actually, the first thing we need is some phase when we connect The two different to the client to the server they connect and then Client is going to be able to send a request and we want the server to respond with a reply And after all of that much later on we can close The connection both sides can close the connection and we're done So let me tidy that up a little bit and you can see this is the sequence of interactions that happen And I've numbered them in the order in which they would happen on both sides So connect request reply and disconnect and you can also see the The direction in which messages are going I've also dotted the connect and disconnect because these are really control Operations things that we just have to do to support the mean data transfer in the more solid line The data transfers what we really want the network to do Well, let's go into this in a little more detail by writing down the different kinds of Socket API calls which are used to cause this to happen. So what have I got to do? Well, actually one of the first calls I need on both sides is a socket call This is really to set up our socket structures and what would we do? Well, the client's going to connect Okay, hopefully you can read that the client connects and To make that happen on the server side. We need to go through a sequence of calls. We need a bind except sorry, sorry listen And accept in that order Bind is really so when we connect we're going to want to connect to a certain Server host on a certain port bind is really establishing an address for the communication endpoint and listen and accept then prepare the socket to Accept connections from the other side and accept is the call which actually results in a connection being made from the other side Once all of that's done. What are we going to do now? Well, we're going to send our message that will cause this request to go over That's what we want to send we'd better call receive on this side to be able to receive it After the request has gone across we're going to want to call send on The server to send back a response what the response is is up to all of the code on the server It could do anything it could read a file off the disk for instance to get the message to send back But we're ignoring that because we're just focusing on the use of the network API on the other side We'll need to receive call and then much later on both sides can call close So this is the sequence of socket calls which you used both the client and the server to cause this interaction to happen So let me clean this up Here we are and you can see what I've done now is I have numbered the calls in the secrets in which they will happen Okay, so let's go through this and you'll note that I've also added a star here star indicates blocking calls where the program makes the call and the program is then halted by the operating system until something happens and On the network side and you know the other network operation completes and then the program gets the result and can continue So here's the sequence of operations on the left hand side. We call a soccer Okay, on the right hand side We call a soccer and then we go through the bind listen and accept now interestingly here except is labeled number four So it looks like we accept the connection before we make it with step five That's because Except is a blocking call except tells the network to wait for and accept a connection So it's just like telling someone maybe to go and sit by the phone and wait for it to ring Connect on the other side is going to be someone making the call which will cause it to ring Eventually when it causes it to ring later down here The program on the server side will continue Once the server side has picked up the phone with this accept call What would you didn't do next? Well, if you were if you just picked up the phone Here actually what the program is going to do is it's going to call receive which is another blocking call This is really the receiving side simply waiting to receive information Later sometime you'll call send. This is after the connectors come back and we'll call sent and That will cause this a request to go over the network the receive called someone is waiting for it They will then receive it now. They'll work out what to do and eventually they'll go back and send it Of course on the other side once we called sent your program has sent the information away It's going to be received by someone on the other side of the network sooner or later But without waiting for that you can go ahead and call receive Which now simply tells you on the other side of the network to now stop talking and instead listen and wait for someone On the other end to say something Eventually you receive the message. That's the reply. We've all been hoping for then you can get that and display your web page whatever you want to do and After that we can then go ahead and close and we'll close on both sides So you can see here. I've shown the sequence of calls and and note which ones are blocking because that's sort of affecting the order and the timing of the execution in the program Okay, so this is really using the soccer all that remains is For me to take these two sides and divide them so that we have separate client and server programs And here is the client side as we just go through that and you can see the calls as we go down We start with the soccer now. There's actually something that you hadn't seen before something called get adder info This is really just some translation mechanism. You might have wanted to connect to a host called www.example.com on port 80 say this might be a web server Well, the network calls the socket calls don't take these high-level addresses. They take things like IP address numbers network addresses So get adder info is translating between high-level names and network addresses So it's doing some of that bookkeeping Now and then we have the sequence of calls in the same order and we go down here and we We really go through just all of the steps that I've previously outlined to execute the client program Sending the reply receiving the message and doing whatever we want with it So what about the server? Well, the server goes through the same things. It creates a socket. Here's another get adder info To really for the same name a reason to translate between names and any addresses that are needed Then we go through the buy and listen and accept calls as before Now then we have the usual waiting for a quest sitting back through apply and eventually closing Often however, this portion will be in a loop That's because the client program might exist to make a single connection and get the information back But often the server will be a long running process It will be running it will wait for a client to connect and it will service that request Then it will wait for the next client to send a request and service it and so forth so there'll often be a loop structure in this program and That's it. Now we have our client and our server path I want to point out if you're writing this as code. There's lots of detail that I've omitted here Both in terms of all of the parameters in a program and see your Java or Python or anything You like as well as all sorts of other code to handle error conditions that could arise if everything doesn't go smoothly But this is the heart of the program and you can by using this pattern begin exploring your own clients over programs So now we know something about how to write an application and use the network Good day viewers in this segment. We'll use a program called trace route to peek inside the network and see some of its internal structure So this picture gives us the context for where we were before You can see that using the network service API sockets is what we looked at applications talk to each other across the network Now the network service API hides all of the details here of what's inside the network So we can't really see by using it What's inside the network how many routers we go through what ISPs whether it's a short path a long path all of this sort of stuff Now this is actually good because we don't want you when you're writing an application to have to know all those details All right programs that depend on any of those details The higher level of abstraction is useful for us, but you might be curious to know what's actually going on inside the network So in this segment, we're going to use a program called trace route Which will let us peek inside the network trace route is a very widely used command tool It's maybe the number one go-to tool of sysadmins to sort of debug the network and find out what's going on inside it It runs on virtually all operating systems You can see it's often called trace route on Linux or Unix systems and on Windows It's trace route with a RT at the end there trace route was developed by someone called van Jacobson Well here about him a little more one especially when we get to TCP congestion control He was one of the pioneers of computer networking as the internet grew up And the transfer tool we're going to look at it works by using the Network to network interface. I'll call it really the IP protocol the internet protocol Which describes how different hosts and routers talk to one another it uses this program in sneaky ways that we'll get to later For right now for the purpose of this segment You don't really need to understand how trace route works It's really just a program that will run and reveal a little bit of information about what's inside the network Okay, so here's how trace route works trace route probe successive hops in order to find the network path Between a host that's doing the program probing that's over here on the left and a destination host That's on the right-hand side So this might be some remote web server and you want to find the path the network path between your computer and your remote web server What trace route does is it sends a packet towards that remote host? Only a single hopping to the network and then causes the network to send a message back or apply back Then it sends a packet to hops into the network unless it's a response from there in three And unless it's a response from there and so on and eventually it sends it almost all the way Unless it's a response and finally in the last time the packet will reach the remote host which will then send a response And we'll know that it's arrived at the remote host all of these responses in the middle as they As we get a response from routers in the middle of the network This gives us information about what those routers are the number of them and the sequence in which they're organized and tool over here Eventually we get a packet back from the remote host and we know that we've seen the whole path through the network So that's roughly how trace route works Here's a picture where I've just cleaned up some of those I cleaned up some of that figure And as I say we're going to more of the details about how trace route uses IP to do this later on But for now just suspend disbelief and imagine you have this tool that you can run. So let's see how it works I'm actually in Barcelona right now So let's try and find out what path is used in the network as I send packets from here to the web server at the University of Washington Let's enter a command and we'll enter a trace route Trace route to dot dot dot u dot dot edu and see what happens I'll hit return and trace routers away. What it's doing is it's sending its packets to probe successive hops You can see the the very left most number is the hop number It actually sends out three entries for every hop and the first numbers of the timing So you can see initially it was very fast within a millisecond within within my house But as we got further away From my house and further out into the network the times got larger up to a couple of hundred milliseconds Now on the right-hand side You can see the names or Identifications of all of the routers both the IP addresses are given as well as some of the names there and we can Take some hints from the names and work out somewhat about where the packet is going Some of those names have telephonic are in it So it looks like it goes through the telephonic a network and it looks like it goes through the level three network You can see San Jose there as well as Seattle later on and eventually it arrives in some computers at Washington Some on hop number 17. We see stars back The network actually wouldn't return any information for what was at hop 17 Something must have been there But whatever it was it wasn't telling us because it's not required to implement trace route Okay, so now in this slide. I've taken the same information as from our example before and just laid it out a little differently to try and show you the path between my computer and The destination that I was probing here. I call it Even though in the trace right at the end we actually saw that the name of this that That name was an alias for this other computers named up to one dot cac dot Washington dot edu Now I'll point out here that the ISP names and places in the middle are just educated guesses based on the information you turn from trace route gives the IP address and A translation into a host name from which we're making guesses about the ISPs So we could see that after one hop we were still inside the home network here We came back and this was quick for the first three hops or so We're inside some network called TD not for exactly what that is you could Google it I think that's some internal telephonic a network Actually, I'm guessing the end of that was probably we're still in Barcelona from the VCN here that stage It looks like we went through a network the telephonic a network for hops It looks like we entered it or shortly after we entered it We went to New York City and the round trip time here had gone up to about a hundred milliseconds That's maybe consistent with Barcelona to New York City. We're no longer just in Barcelona We've gone further afield but after four hops or so it looks like we emerge in another network this time called level three Sorry, they're level three and it looks like we enter that network in San Jose and then go through the level three network for six hops By this time the the round trip time is rising you can see here I think it rose to about 180 milliseconds. This is just an estimate once again as We went from New York all the way through the network to San Jose So now we're on the west coast of America We're getting close to Seattle, but we took six hops through level three and at that stage We arrived somewhere in Seattle and we actually went through a network called the PNW giga pop You wouldn't necessarily know what this is again. You could maybe Google it I happen to know that's the Pacific Northwest giga pop Which is an exchange where different networks come together in Seattle and this network then routed us on to the UW network By now by the way the round trip times gone up beyond 200 milliseconds and within three hops within UW We arrived at the final destination So you can see that trace right gives us a lot of information here Really there hints there. They're not always unambiguous The trace right is giving us a lot of information about the path that your packets take through the network So you can try this yourself and find out the path to some destinations throughout the network G'day viewers in this segment. We'll talk about protocols and layering and this is the most important idea There is for the structuring of networks Okay, so networks need some form of modularity to manage all of their complexity If you think about it, there are many different functions that you know exist in networks And I've listed some here setting up all kinds of connections finding the path through the network reliability All sorts of things to do with how fast you can send information depending on how many users there are and what network you're going through security Management of the network so that you can easily add new hosts as it changes and so forth That's a lot of complexity all of this by the way underlies the simple action and clicking and getting a web page back So there's a lot of mechanism underneath to make that happen Well, what we need is some form of modularity Which will help us manage that complexity and allows us to reuse a lot of network functionality across many different settings That is exactly what protocols and layering give us Protocols and layering are the main structuring methods which are used to divide up the functionality of networks So the way protocols and layering work is that each instance of a protocol Now you might think of this just as an object being an instance of a class for example It talks virtually to its peer protocol instance, which is on a different host elsewhere in the network But the catch is to talk virtually to that peer instance The protocol is only allowed to use the services of a lower layer protocol on the same host That all sounds a little mysterious. Maybe so let me just try and draw a diagram to explain that Okay, so let's see here is a protocol instance. I'll write X to mean this is an instance of protocol X now This protocol instance wants to talk to another protocol instance X on some other machine to do that it will use The rules of protocol X it will only exchange messages of protocol X and so forth But I've dotted this line because there's no direct communication path between here These are different machines these protocols So how do they talk they use the services of a lower layer protocol in this case protocol Y and Protocol Y is similarly going to virtually talk to its peer an instance a protocol Y on another machine Using protocol Y so X will are locally on a machine use only the services of Y Let me clean this up So here is a he's a Maybe a little bit of a clear diagram what you should take away from this is that so here's one host by the way If I just draw here node one here's another host node two So on this diagram the layers the layering is happening vertically as each protocol instance talks the lower layer protocol instance And the lower layer talks back to the upper layer when things receive from the other side the protocols are designed horizontally They're really specifying the form of into interaction into connection between the two different systems Of course, I still haven't really gotten to the bottom of this picture because we don't know how protocol Y Really communicates you see the virtual communication, but what's going on? Well, this is what's going on the same thing happens again the protocol Y communicates using the lower layer protocol And when you do all of that you get what's called a protocol stack. So here is a protocol stack and Here it's just listed layer five through four three two one down to the bottom What's going to happen at the bottom? Well at the bottom where it's labeled physical medium This is really just a wire or something like a wire such as a fiber optic cable This is the medium which carries whatever message is electrical signals from one side to the other and then layer one is going to interpret That as a message so by acting in this form We've got a higher layer protocol such as layer five being able to virtually communicate with its peer instance here Without really knowing what's going on anywhere below layer four Well protocols and layering are everywhere you've probably heard of many different protocols, even if you didn't realize there were protocols I'm thinking of things like TCP IP 802.11, Ethernet, HTTP, SSL, DNS and many many more Some of which will come across in this course. They're all protocols We can even just to show you how some of these things fit together Let me draw you an example protocol stack and for this example We'll choose a web browser on your host say and let's just assume that you're wirelessly connected to the internet Okay, so now let's see here would be your browser That's really an application That's using the network Now the browser well if it's a web browser I happen to know that the web protocol is HTTP It doesn't matter if you don't know this we're going to cover all of these protocols by the end The browser or implementation will actually often include an implementation of HTTP HTTP in turn runs on top of TCP IP These are the common internet protocols and if you're on a wireless host this TCP IP will be running on 802.11 and then the wire comes out of here I'll draw it as a wire But in this case the link really is wireless so it would be no physical wire But we can still draw it like this to show the connectivity Here we are I've cleaned it up once again. So this is the protocol stack that would be used for this particular instance Okay, well, we're not quite done with protocols yet There's still more mechanism that I want to tell you about we said that layers or Layered protocols are layered one on top of the other but we didn't really talk about how this layering is Manifest or implemented. Well encapsulation is the mechanism that used to affect protocol layering So the way it works here is that the lower layer wraps all of the higher layer content It's going to have to add its own information control information for delivery throughout the network To understand how this really works the analogy that we'll use here is that I'm sending a letter through the postal system What you do is you write your letter good old-fashioned letter You write it with a pen then you seal it in an envelope the envelope is like the lower layer Header information it contains all of the addressing and so forth when you pass it to the post office in that form The post office only then needs to use the lower layer information on the envelope to get the letter to the other side And at the other side the envelope is extracted Sorry, the letter is extracted when you open the envelope Actually, there are probably even other lower layer protocols in here letters going to the same destination Maybe all bundled together so that they can be rooted, you know in an airplane or a truck all at once and so forth So this is what's going on with encapsulation We can draw some pictures to show you what would happen with our example protocol stack here if we send messages through it So let's see what happens. Well at the top HTTP. We're just going to start with a message Okay, now HTTP will pass it down to the lower layer. What will happen at the TCP layer? Well, here is the HTTP message The TCP layer will add well actually I should draw it like this. It will wrap it and Add its own control information at the top. It'll then pass it down to the IP layer Here that blob is what will happen the IP layer will wrap it and at its own header That will then pass it down and guess what will happen again There it is the 80 to 11 layer will wrap it and add its own header Wow, this is a little tricky to draw boxes inside boxes. So I'm going to clean that up for you And here here you are look carefully at all of those different boxes I made it all of the inside detail just because it was too much for me to draw But you can see the messages on the wire begin to look more and more like an onion And that in fact the lower layers are out of most you might think the higher layers should be out of most But the lower layers are out of most because of the way it's constructed going down that protocol stack Here's the same view as I go. I've shown both the sending and the receiving protocol stack So we go down that protocol stack and you can see, you know, what happened as we expected here Now this is the interesting bit This is what actually you would see if you were to look on the wire of a network and to see a message going by It would be like this and this is the beginning. This is the start over here On the receiving side, you can simply go through the reverse process The 802.11 layer looks inside it and extracts this bit And sends this up to the higher layer and so forth and we continue. So that's encapsulation In fact, actually normally we'll draw encapsulation much more simply I showed it as really drawing a layer around The higher layer payload to encapsulate it but often encapsulation will simply proceed by having each layer at its own Control information to the front. So TCP there will add a layer in front of HTTP IP We'll add a layer in front of TCP and so forth and 802.11 will add this layer in front This is a simple form of layering just adding a header in front But this is often what's used in practice for many of the protocols we'll look at In fact, this is just how we'll think of it layering practice can be more complicated than this For instance, you might have trailers as well as headers trailers Information control information which is added at the end And the information that's in the middle may be transformed in reversible ways such as encryption or compression Such that you might not be able to see it literally instead of simply leaving it alone But we can just ignore this for now and think in terms of our simple model here And actually there's even more complications. Sometimes you might use excuse me what she's called segmentation and reassembly This is when a long message from higher layer is divided into many smaller message shorter messages at the lower layer Just because the longer message didn't fit through the network as is But wait, there's more. There's one other thing I've got to tell you about layering and then we're mostly Done with the mechanics of layering and we can see how what we get out of layering Okay, well when a packet comes in down here at the lower lower layer We've got to work out What protocol instances are inside it? Your computer is probably running many different protocols that are used by many different applications Now if what came in is really part of our web application We knew from before the protocol stack was this it was let's say it was Ethernet TCP and HTTP But how do we know to follow this path through the graph and not for instance this other path Ethernet IP UDP DNS? This other part is a real part It's something that's used for a DNS traffic to translate host names to IP addresses Well, how are we going to do this? Think about it for a moment. Let's see if you can work out the answer Okay, you ready? Well, this is what we would do In fact, what must happen is that each layer includes inside it Some control information to identify the higher layer. So as the packet comes in here We know it's Ethernet here simply because Ethernet all messages on this network are Ethernet if it's an Ethernet network say But the Ethernet header will have a little bit of information that says go this way to IP In Ethernet, this is actually called the Ether type value Now then as IP processors IP will look inside its control information. There'll be a little bit of information It's actually the IP protocol field which says go this way to TCP and inside the TCP header There'll be a port number which says go this way, which will happen to be HTTP This information in each protocol layer is what's called a demultiplexing key because it helps us undo the multiplexing and And go back up the right route Okay, well now let's see how we can gain some advantages from layering now that we've gone over its mechanics Layering the key advantage it gives us is information hiding and through that reuse So imagine we have our browser and server application here a good old web browser You could run it on a protocol stack like this Well, we're all the browser notices that it's talking to HTTP here But let's say you happen to run HTTP on the protocol stack TCP IP and Ethernet Okay, Ethernet is a you know typical wide enterprise network You could certainly run the same web browser on a different protocol stack Let's just say we want to run it on TCP IP and 802.11 because this is a wireless host Wonderful the web browser doesn't actually know or care What's what it's running on at the lower layer and this is a tremendous advantage because we you know It'd be terrible if we had to write our web browser differently depending on all of the details of the protocol stack What by hiding information we're getting a lot of powerful reuse out of it There is cleaned up. Oops. I chose the size differently doesn't matter And we can also gain further advantages You can use this information hiding to interconnect different kinds of systems So imagine over here. We have the browser. It happens to be running on an 802.11 network Well, the server well that happens to be running on an Ethernet network Doesn't matter with our protocol layering system. This is what we can do Here we'll have the 802.11. It must talk to a pure 802.11 box It's similar in IP layer So we will use this 802.11 box to terminate the packet the 802.11 layer pass it up to the IP layer Which can then pass it across or keep up within the IP layer It's maybe a better thing to say and pass it down to an Ethernet layer In the same way that over here we passed an IP packet down to an 802.11 layer This Ethernet layer is then able to virtually communicate with another Ethernet layer Protocol and everything is okay We've managed by using protocols and layering to interconnect web browsers and servers running on different kinds of networking technology So this is what protocol layering is all about as it means to connect things Know that to do that we needed to Have something like a single layer here which provided connectivity all of the way across And this is what IP does frequently in the internet It's the basis for being able to connect everything with different kinds of media type below and different kinds of applications and protocols above Here's that same picture cleaned up a little bit. What I've done also is down here. I've drawn a picture Just of the message as it would appear on the network. You can see we started with the HTTP message and we added these headers Now I've shown in pink here. This portion is the portion which is not touched as it's carried across the network I've left the IP piece unshaded a bit because the IP processing happens in here So the IP control information front may be altered And similarly we can see as we go across actually this 802.11 will be taken off And this Ethernet portion here will be added as we go on the other side But all of the information in the middle that we cared about the tcp and htcp will be passed unaltered And this is what is providing us with virtual communication Between the browser here and the server here. So that's protocols and layering Just to round out our notion of protocols and layering. I'll tell you that there are some disadvantages to layering It's not all roses Here are two disadvantages the first disadvantage is that layering adding more modularity adds a little bit of overhead If we knew for instance that our protocol stack went htcp, tcp, ip and ethernet Maybe we could devise a custom header Which had all of the necessary functions in one and it would be shorter So we definitely lose a little bit of efficiency Often this is a minor concern if you're thinking of large packets the overhead of layering is small It's a small number of percent Now on the other hand so that was this adding overhead a bigger concern probably is that layering hides information We said that our web browser now doesn't know whether it's running over a wired or a wireless network. Well you know That allows us to run the application. It's true But your application might care whether it's running over a wired or a wireless network because really they're quite different On a wireless network the bandwidth is much more variable and you could be changing locations all of the time This is something that an application would like to know. So information hiding is a disadvantage of layering Okay, but the point is now you know about protocols and layering the key mechanism that used to structure computer networks Good day viewers in this segment. We'll talk about reference models, which give us a way of organizing protocols Okay, so now we know about protocols and layering good for us But what we still don't really know is which particular function Should be implemented in which protocol if you think of a function such as finding a path through the network for routing Should that be implemented in a higher layer protocol or a lower layer protocol? We don't really know yet So this is the key question And it's it's a major question for designing any network. It's it's probably the largest question Well, there are actually no definitive answers because which uh layer in which layer to place a particular function Is a matter of experience as people design networks But we do have something which will help us out the reference models. I'm about to describe providers with guidance to tell us Which layer it is uh, you know often valuable to place particular functions So here is a one famous reference model. It's called the osi seven layer reference model Now, um, this is a principled international standard effort It's all about providing a reference model that will allow systems to be interconnected Systems made by different people that is different manufacturers to be interconnected in a way such as the law work It's been tremendously influential. It was actually put together by You know a standards body in this is probably all the 1980s But even though it's hugely influential, it's not really used in practice Um, oh well. In fact, I'm not even going to tell you what osi stands for because you don't really need to know Okay, I'm just kidding. I'll tell you open systems interconnection is what it stands for just in case you're asked Um, but this standard is really an influential one rather than what's literally used in practice Let's go through it. You can see that there are these seven layers here at the lowest layer is what's called the physical layer The function of this layer is all about being able to send bits across some physical medium like a wire So that's going to involve sending signals The layer above that the data link layer is about sending units of information here They're called frames, but the point is they're not mere bits. They're now closer to the message we care about On top of that is the network layer. That's about sending packets across multiple links It sounds suspiciously like the data link layer But its scope is broader now we might talk about sending packets across multiple networks as in the internet On top of this is the transport layer which provides different kinds of end-to-end delivery services Such as reliable delivery, for instance On top of this then are another couple of layers that are a little different The session layer manages task dialogues. It says here what that really means is bringing together many different Components that are used in a related way together So that they can be manipulated as one For instance an application might use many different connections across the network All in service of the single application The presentation layer is about different representations for information Different file and image and video Formats for instance Because many applications can communicate using different kinds of formats for the same inherent content And finally above that is the application layer and that's really what we think of as applications They provide whatever specific functionality is needed by users So this is the osi 7 layer model and you're going to want to remember all of the different layers of that model But i'll tell you now what we mostly use in practice And particularly in the internet of course is something called the internet reference model This is a full-layer model. It's based on experience In fact in some ways it's the opposite of the osi model The internet began to be built and you know whoever implemented pieces that worked while that's what became the internet The model was really Fashioned out of it abstracted out of it later on just to try and clarify what was going on And it really drew on many of the ideas from the osi Model which had a brilliant model, but no implementation of protocols that anyone really care to use So you can see that there are some differences compared to the osi layer model We really omit some of the layers and the instead of a network here it says internet The internet layer is the key replacement for the network layer and the internet layer is all about the ip protocol So if I was to number this going from the bottom up We start with the link layer. Its purpose is to send frames these units of information across links I'll call this layer two and one Because really compared to the osi model it's often performing both of those functions On top of this the internet layer is really a replacement for the network layer three You'll often hear network and internet in the same breath in terms of layering The transport layer is then layer four. It's providing services on top And people might talk about layer seven as the application layer That's what it was in the osi model layer seven and you can see here We're missing the presentation and session layers, which actually are not normally present in a layered structure Presentation and session functions are useful notions But they're often provided by libraries and they might not be explicit in the protocol layer protocol structure that's used in networks So here we have it. We have the internet reference model Let's go a little further and look at what we can do with this model Actually, I mostly want to relate it to the protocol you might have heard of Now again, just to clarify a reference model is a framework for describing what protocols perform what kinds of functions It's not actually the protocols themselves So we need to put different protocols in different layers and you might devise new protocols in your career Who knows so what kind of protocols go where well at the internet layer? Guess what? It's the ip protocol is the main instance Of a protocol at the internet layer that we're going to use in the internet Transport layer protocols you might have heard of TCP and there's something else called UDP Which transfers information without reliability without reliability. Oops. My writing's a little off there These are two protocols which are used here now on top of that are various applications Applications here really things that use the services of the network We might have HTTP that's used for the web other things RTP is used for real time SMTP is used for email transfer and maybe something even like DNS And there are plenty of others. I'm just sketching a few examples here Okay below IP. We have different kinds of link technologies Which are used to combine different systems. This is you know different kinds of physical medium So if you like that, we're going to use to connect different nodes. So we might have uh, while it's 3g cellular Ethernet I'll write DSL and cable just this different kind of physical as that you plug into and even 802.11 Okay, let me clean some of this up a bit I mostly chose the same protocols. That's good Now I've drawn it in this fashion to show you that IP here Is the narrow waist of the internet because uh, if the if we always use IP as a standard reference for the uh For the for the network layer position here as we do in the internet then we're able to Use a diversity of different technologies below and a diversity of different applications above And we can change any of those new link layer technologies or any of those new applications and transport protocols And we would expect to be able to interoperate across all of these systems because we have a common layer in the middle IP Which is the narrow waist of the internet is providing connectivity between all of the diversity below and all of the diversity above So this is really this narrow waist using IP is at the heart of innovation in the internet Okay Let's see. Oh, here's the other thing you might be interested in and this is just where on earth all of these protocols come from um, we We will see many examples of protocols in this course and there are many more that are out there Which are used in practice that we won't even have time to go over. So who's making all of these protocols? Well, the answer is different standards bodies are making these protocols And the reason they're making it what they really care about is interoperability They're making a standard so that different manufacturers of a device that performs some functions such as playing video over the internet Will be able to operate with one another. This is good for all of them Because it increases the size of the market You don't want to have incompatible technologies that do the same thing. It promotes standards wars So, uh, the focus here on these standards is on interoperability In fact, the focus is not usually on how to do a good job of implementing this standard at all That's really left to companies and whoever can do a better job there has a competitive advantage So this can lead to strange things being left out of standards actually Because information that's going to help you do a good job in terms of performance need not be specified So I can show you some examples of different standards just to tell you about it There are different bodies here in the telecommunications area There is a body called the itu the international telecom communications union specifies a lot of telecommunications standards Examples here are things for like our adsl your dsl link used at home the mpeg 4 standard Which is used to compress audio and video and widely used is actually the itu standard These are standards are often called letter standards. You can see the g dot and the h dot that's actually the The official name for that stand is not called a dsl. It's called g dot 992 for instance There's another body the iEEE the institute for electrical and electronic engineers Um, and this body produces standards in the communications areas by different working groups The most famous of its working groups is the iEEE 802 working group project 802 And that's produced many standards of which you're probably used and are familiar with We all know uh, ethernet and wi-fi at least you've probably heard those terms This is actually 802.3 and 802.11 standard. This is why wi-fi is sometimes called 802.11 That's the name of the standard for wi-fi whereas wi-fi is just the the common garden variety name Then there's a body called the itf the internet engineering task force This body produces internet standards And these are sometimes called rfcs or requests for comments So there are many different rfc numbers and they specify standards that you might have known that you might know about For instance, uh, here's a an rfc for the dns There would be other rfcs for things like tcp and ip for instance And finally i'll mention the w3c the worldwide web consortium that produces web standards not surprisingly So things like the html5 standard and the css standard This is about the content over the web actually the protocol that's used across the internet http is specified as a part of an rfc Okay, so now you know a lot about standards Um, I what I want to do now just to finish out this unit is to talk about something else we get from reference models And that is the structure of the reference models often gives us some names and terminology just to talk about networks In fact, a lot of the names we use to describe units of data take their names from the layering If we're talking about units of data at the physical layer Well, typically we're talking about bits is what we're going to call information at the physical layer If we're talking about the link layer, we'll often be talking about frames of information The network layer is where packets exist And the transport layer a unit of information the transport layer is actually called a segment And there's a generic term for applications and everything above that's message So different layers technically have different names for groups of information Nonetheless, I want to point out that packet Is can either be used in a very specific way meaning the network layer precisely Or we'll often use this in just in a general way as a form of convenience to refer to a unit of information That's going over the network. It might more properly be called a frame or a segment But often just for the sake of convenience I'll call things a packet and you'll have to work out from the context whether it's actually a frame or a segment Layer based names are also used for devices in the network Now here I have a device that's called a repeater or a hub It works like this and you see this picture shows that it performs processing at the physical layer But it does not touch information at any higher layer You might also have heard of devices called switches A switch operates at the link layer So you can see here that it connects different instances of a link typically with the same technology And that's how they can be connected together Whereas a router operates at both the it operates at the network layer So it's able to take in and connect Instances of different links. So this might be 802.11 and this might be ethernet And this is how the router was able to connect different network technologies By connecting at a higher layer the network layer And we can go up even higher Here we are there's a variety of terms just for things that operate inside the network to Provide connectivity and relay messages between devices yet they look more highly than the network layer So they might look into the transport layer or even the application layer These are variously called proxies or middle boxes or gateways They're actually strange devices in the middle of the network Not at hosts hosts of course need to process these layers. I'm really talking about devices in the networking Now the reason this is all important these names are important that you understand your layer diagrams Is all of these boxes just look exactly like this. I mean, they're just different kinds of boxes You might be able to recognize a particular kind of router a switch if you're used to working with them But if it's something you haven't seen before and it's a box You don't really know what kind of processing it implements inside it If you can find out well these diagrams And these particular names tell you the kinds of processing that can exist within different kinds of boxes And finally to finish out this segment on layers I want to tell you that layers and with our reference models are really a guideline They're not strict. In fact, you might have multiple protocols operating at the same layer And there may even be cases when a particular protocol is difficult to assign to a layer It might not neatly fall into our different kinds of layered framework here In fact, this is a lot of the the complexity in the fun of networks That you might have protocols that don't neatly fit in here So don't just assume that because something sits on top of a network layer protocol It's a transport layer protocol. That's not necessarily the case Nonetheless, our overall layered framework will prove valuable just for thinking about the functionality and roughly what's going on at every layer Okay, good day viewers. In this segment, we'll cover a very brief history of the internet So you can see here, I've shown you a rough timeline for the internet And it goes from say, let's call it 1970 to today. So we're spanning more than four decades here And over that period of time I've drawn three main phases that I'm going to talk about as the internet having gone through an ARPANET phase An NSFnet phase and really the modern internet and web as we know it today Throughout those phases the internet has grown enormously. In fact, from every phase to the next we have about a factor of a thousand growth Which is just huge. So from the end of the ARPANET from a thousand Through to a billion hosts today. And this is all very rough. We can go into more detail As you'd like from many resources you can read to find out a little more about this Okay, so let me tell you a little bit about each phase So in the beginning there was the ARPANET. The ARPANET was a network that was built and sponsored by the U.S. Department of Defense It was the precursor to the internet. So it became the internet. This network was motivated for resource sharing Obtaining access to some, you know, early and relatively powerful for those days computers from offices at different locations It was actually launched with just, you know, a modest four nodes in 1969 And during the ARPANET phase it grew up to be hundreds of hosts And in fact during this phase one of the first killer apps in the internet emerged. It was email This was not what the network was intended for. It was intended for resource sharing But email which was written just a small handful of years after the ARPANET was born Became very popular as people used it to exchange messages During this time, there were several key influences. So I've shown here some key influences Leading up to the creation of the internet. And one of the key influences here is what is called packet switching Packet switching is something that was pioneered by Donald Davies in the UK and Len Kleinrock in the United States amongst others And packet switching was really interesting. It's really just the notion of packets and sending through networks is what we would think of today It's interesting because it's quite different than the circuit switching which was used as part of the telephone network at that time The whole notion was to organize information in small units of packets through which they were sent through the network And this could be much more efficient for connecting computers together than using telephone circuits, which may be good for people Because computer traffic is very bursty. So we might sometimes have many packets, but often there'd be no packets So dedicating a whole circuit would be wasteful Whereas if we use packets We'll get the advantages of statistical multiplexing that we talked about in terms of getting better use out of the links So this was one key influence. Another key influence was that of decentralized control From the early efforts of Paul Barrett who produced various designs That emphasized decentralized control in those days the telephone network was organized very hierarchically So that if you took out a high-layer node, you would really paralyze a lot of the network Being able to create networks where control was fully decentralized so that if you blew up a portion The rest of the network could continue to function There's obviously something that was very appealing To the military at the time and so this is often why you hear the internet the arpanet is being created to withstand a Nuclear war in which a portion of it was lost. But really this is just one of the influences leading up to it As the arpanet took off in the very early internet Another key influence became paramount and that was internet working Internet working here was pioneered by vint surf and bob kahn shown here in their pictures Internet working is all about connecting different networks together into a single larger network Surf and kahn pioneered it fairly early on in the arpanet starting in like 74 And this later became the tcp and ip protocols So really the key idea of internet working is that we we have different network technologies One way you can build a big network is by getting everyone to use the same technology mandating it But surf and kahn realized that this was infeasible already. There were packet radio network satellite networks And the arpanet. They're all different kinds of technologies there surf and kahn instead Proposed to use a higher layer of interconnection to a level of indirection If you will to combine all of these different networks together And they solved the problems which are required to be able to internet work these technologies For this achievement, they're popularly known as the fathers of the internet and they've received many awards for this Okay, so here's a early geographical map and a network topology map for the arpanet comes from around 1978 You can see by now the arpanet is growing up a fair bit. Although by today's standards, it's still a very small network For all of these different Circles these these are different kinds of nodes. They were known as imps. This was the name for the early router I think that's imp is an internet message processor And the links between things. Well, here's a link here They ran at 56 kilobits per second. So you can see we've got a network here, which is growing up As it grew up and now we passed on to I guess thousands of different nodes As it grew up the nsf Are commissioned a network which played a key role and this was called nsf net The arpanet really connected people who are doing business With the u.s. Department of Defense and there are many other players who didn't have a contract with the u.s Department of Defense who wanted to be able to connect using this interesting newfangled technology And so the nsf built a network which would allow all different kinds of educational institutions Universities to connect to this network Initially this network connected Supercomputers at different sites together But eventually it connected many different sites and it became the backbone for all internet traffic Effectively replacing the arpanet It's during this period. This was a tremendous growing up period this period of a decade or more It's during this period that the classic internet protocols as we know today emerged all of tcpip The dns and the sockets api emerged around 83 quite a year I guess And internet routing in the form of bgp That's a protocol we'll get to later in the course took a little longer to emerge in the modern form that we recognize But it was around by 93 During this period also there was tremendous growth and interest in computing and networking technologies The personal computer was really coming into its own and personal computers appeared Or computers appeared and then became personal computers first really on campuses educational institutions for research As they became effective they made their way into businesses and eventually in the form of personal computers into home So it's not just personal computers computing, but networking technology ethernet The most popular form of local area networking emerged In this period too, and it took off like wildfire allowing all of these early computers to be connected And so the result is that by about 93 we had maybe a million hosts that were all connected together as part of the internet It's growing up Here's the architecture of this early internet When the nsf net was in use and you can see this picture here is really it's meant to just be very Simple and hierarchical the nsf net here is the backbone What that means is if the two customers in different places want to communicate with one another A local customer network might be a university network would send packets up to its regional network Which would send packets to the nsf backbone network which would send packets down Which would carry packets I guess across the country and deliver them to the right regional network Which would carry packets to the right customer network and we would achieve connectivity Now the early nsf network backbone you can see here just the speeds it used It started off with 56 kilobit per second links fairly quickly it upgraded to 1.5 megabit per second links And then to 45 megabit per second links. So the network was really growing quite fast in terms of speed as well as in terms of size Well after a decade or so of all this growth and the popular technologies in computing and networking We arrive at the birth of the modern internet Which contains the internet and the web as we know it today is really a continuation Of what was started here and this was around the the early 90s. There are two major changes I want to point out to you compared to the earlier structure Now the the first is that after around 95 Connectivity was no longer provided by the single nsf network backbone Instead connectivity is provided by large isps There are several different large isps handfuls of them And they are providing connectivity to people across the wide area And they're also competing with each other as business So there are now multiple players at that top level And the way we're making sure that packets get everywhere Is that all of these different players these large players Interconnect at IXPs internet exchange points so that they're able to exchange traffic and get it anywhere on the internet And later large content providers also come along and connect into these isps isps So that they can distribute content all over the internet So that's one change the way we route across the internet And and the architecture of the internet and another big change is really the web The web which was pioneered by this man over here Sir Tim Berners-Lee Emerged it burst onto the scene really because it took off so rapidly It emerged around 93 And it really took off in terms of traffic and it caused a lot of interest in the And the internet everyone wanted to get on it The growth led to the formation of what are called content distribution networks to be able to efficiently distribute all of this content Naming became much more of a concern and this led to the establishment of the body called ICANN The internet corporation for assigned numbers in names later on around 98 The content has continued to evolve ever since Most bits now actually video that's going over the internet just because videos are so large And most of the traffic is Soon to be going over wireless networks And probably from mobile devices not quite yet But it's skewing rapidly in this direction and really the new kinds of content are driving the internet That's where we are today and i'll skip all of the the later You know facebook and everything because i'm sure you're more familiar with the evolution of these particular companies in the internet ecosystem Really it's the web and the continuation of the web that they're providing And finally i just want to show you the modern internet architecture So this picture here is to contrast with your Previous picture of the nsf network backbone. You can see here. I have the IXPs is the point of interconnection And different transit providers. Here's a transit provider. This is like a big isp connect to different isps IXPs and content providers Also connect to the IXPs So what you might have now is that you might have the case that uh content is going from here Through an IXP to a transit provider and then down to a particular customer um, or we might uh be sending traffic From this customer here if this customer wants to get traffic to the other customer We might go up through the transit network And then we might go through to the transit isp Then we might go to an IXP and be routed to another transit provider Who we would then send traffic down and let's say now we're going to this customer So you can see they all fit together in a rather different architecture with no single backbone up at the top That's the defining characteristic of today's internet architecture. Okay G'day viewers in this segment. I'm going to tell you how the rest of the lectures in this course are organized But first congratulations are in order You've now learned about the key concepts of protocols and layering which you use distraction networks So that means that you can read diagrams like this and understand for instance that here are two hosts That are using wireless connectivity to talk to one another And you've also seen uh, how the internet protocols are organized in frameworks such as this internet reference model This model in particular I want to point out the narrow waste of the internet, which is IP and how it allows a diversity of different link technologies to flower As well as a diversity of different applications to be used on top of the network Well in the rest of the course, we're going to use this reference model that's shown below So you'll see that we mostly follow an internet reference model We actually do a little more. So if we go through this model, we start at the physical layer Which is all about sending bits using signals We're going to do a bit more of this layer than you would usually see in the internet And then we move on to the usual link layer to send frames across links the network layer To send packets across multiple networks the transport layer for different types of end-to-end delivery including Reliability and the application layer for all manner of programs which make use of the network So as well as doing a little more on the physical layer then you would get in your typical internet reference model We're also going to talk about some of the alternatives to IP So I won't always be very internet specific sometimes I'll show you other ways of doing things which may or may not be popular in practice The idea is here to give you a good sense of how networks Not only how the internet is used, but how networks can be designed as might be valuable to know in the future Our progression of lectures is going to work through these layers really from the bottom up So we'll start here at the physical layer and you'll learn about wires and fiber and wireless Then we'll move on to the link layer where you'll learn about protocols such as ethernet and 802.11 Which used to connect all manner of hosts at the network layer. We'll learn about our IP is really the main example as well as technologies like nat and routing in the internet with protocols such as bgp Then we'll look at the transport layer the tcp and udp protocols mostly And then all manner of protocols which make use of the network applications such as hgtp dns and cdns After that we'll follow up with a little more detail on some subjects which span multiple layers And I'm thinking in particular our quality of service and security All of these top topics cover more than one layer. They don't neatly fit into any of them And all the way through this will be an upper division college level course So there's definitely a lot of material. This is the sort of course that you can be proud of accomplishing For the textbook The textbook is computer networks the fifth edition either the us or the international edition is just fine And throughout all the all of the lectures i'll note the section numbers that the lecture corresponds to in the text Now this text is optional but recommended. So this means you don't have to buy it if you don't want to That's just fine. We've done our best to make all of the lectures And the homework self-contained so that you can go through them by yourself and you can learn a great deal about networking But you may occasionally need to look things up on the web if you want a little more detail Because it's unusual for these college level courses to run with no textbook at all For those of you who do have the textbook Read it on the indicated sections browse through them and look at them to gain More explanations for a greater level of depth and detail on the concepts we cover This is very helpful if you want to do well in particular on the homeworks and the exams I'll also point out extra topics that you might be interested in and you can read about in the text But we just don't have time to cover in this course And you can also use it. There's a lot of reference material in it. Okay. Well, I think we're good to go G'day viewers in this segment. I'm going to introduce the physical layer So here's where we are in the course. This figure shows a layered protocol diagram And you can see out of all the different layers, we're going to start down the bottom with the physical layer And then through the rest of the course, we're going to work our way up to the application layer Now the physical layer is all about how we use signals to represent bits So that we can convey bits across a physical channel or a simple link from one end to the other So you can see here if we just consider a wire as an example of a physical layer We've got here bits going in on the left, binary digits That's the message we want to send and bits coming out on the right. That's wonderful That's what we wanted to get out the same bits But of course if you were to look in the middle of the link here if you were just to cut the link You wouldn't see these bits anywhere What's carried across a physical channel like a wire or a wireless or fiber optic Is an analog signal, so we're going to need some way to represent digital bits with those analog signals That's really the heart of the physical layer So to understand how this whole process works, we're going to go through several topics First of all, I'm just going to talk about the different kinds of media and their properties So this is where we'll learn just a little bit about different kinds of wires, wireless media, fiber optics and so forth Then I'll talk about how signals propagate over these different mediums This will introduce us to concepts such as bandwidth, attenuation of signals and so forth And equipped with all of this learning, then we'll build on top of that and really get to the heart of the physical layer And that is how to represent bits using signals, the kinds of signals which will go over these physical channels These schemes are sometimes called modulation schemes, how to encode bits So this is what we'll look at and finally in the physical layer, we'll talk about some fundamental limits Which constrain how well any real physical channel can do and this will give you some sense of the bounds that are possible So those are all of the topics we're going to cover now by the time we've covered them you'll understand how the physical layer works and We'll also have gained a will help to have realized a simple abstraction for a link or physical channel And that abstraction actually is all that the higher layers are going to need most of the time when they use links That's really following our layered protocol model. We're learning about the internals inside a layer But the layer is going to expose an abstraction to the higher layers, in this case the link layer and beyond to use So this simple model is really all in some sense that the higher layers need to know about links And here is the some of the key bits of that model written down here So I have here's my Simple link or physical channel. This is a wire. I'm sending the message across it You can see it's it's going over here and there are just a couple of key parameters here There is the rate That's r The rate might sometimes be called by different names the bandwidth the capacity the speed It's really the the rate in bits per second at which a message can be sent onto this channel And the other parameter is the delay. It's the delay D in seconds And that delay is the amount of time it takes for the signal to cross the physical channel So it's related to the length of the signal now. There are other properties of physical channels that are important and will sometimes be ahead and we should understand One good example is whether a channel is broadcast Wireless links tend to be broadcast for instance on a broadcast channel when a message is sent by receiver It is received simultaneously by all Sorry, when a message is sent by sender it is received simultaneously by all receivers That are within range of that sender Other kinds of media like wires for instance, they're typically not broadcast They just go from one sender to one receiver And we may also sometimes care about whether a link has a very high or a very low error rate Media such as 5 have very low error rates So when you send a message across it if it's engineered well Nearly all of the time you'll get the message intact at the other side Other kinds of media such as wireless channels have higher rates. So Wireless messages will quite often be garbled And we're going to have to of course eventually we'll get to mechanisms to deal with that and fix that so you're not going to send bogus bits onwards Well actually given that simple model we can already start to do some useful things So for instance, we can already compute the message latency and that is really The latency or the delay to send a message across a link. Let's think about what this delay is Now it actually turns out that it's really composed of two different components two separate components First of all, there's something that we call the transmission delay here And this is really the time to put this message made it that's m bits long onto the link sending it out at a certain rate So that delay that component is really m divided by r. That's all it is The second component is what's called the propagation delay Once bits get on to the wire, they have to go from the beginning where they just entered the wire to the other side Now it takes a finite amount of time for signals to propagate down the wire that's related to the length in fact, the propagation delay Is given by the length Divided by the speed at which signals propagate in the media and for most wires and fiber optic media Two-thirds of the speed of light is a good example For um for wireless, maybe the speed of light close to the speed of light is a is a better example But basically it's the light divided by the speed at which signals propagate in that medium And we'll refer to that as d's because we'll often be given the delay in seconds rather than as a length measurement in feet So if we combine these two things we have that the latency to send a message over a link is m divided by r plus d Well, let's see a little bit of an example of that. Oh, sorry before we have an example This is this is just a cleaned up slide With a little more detail that you can go over in your own time Well before we go over an example I'll briefly just talk about some of the metric units that we'll use here and elsewhere in the course You can see this table just lists some of the common prefixes We'll use kilo mega and giga for a thousand million and billion And uh million micro nano for a thousandth Millionth and billionth these are all standard uh terminologies standard notation rather And in addition we'll generally stick with powers of 10 to describe rates So that means that one megabit per second will be a billion bits per second But we'll occasionally use powers of two when we're talking about quantities of only storage So for instance one kilobyte a second is going to be 2 to the 10 or that's 1,024 bytes This is just sort of following standard practice Storage quantities are often expressed as powers of two whereas rates tend to be powers of 10 And you'll also see we tend to use a capital B for bytes in a lot of case B for bits Okay, so on with a couple of examples Well, I've got two different cases for us to compute the message latency First of all here, let's consider dial-up sending a very telephone mode. This is an old style Use of sending bits of information over the telephone network So the rate there was 56 kilobits per second is a fast mode of 56,000 bits per second And we'll just talk about a delay of five milliseconds So that's we're sending from your computer to another computer fairly close by maybe in the same city So what's the latency going to be? It's going to be equal to m divided by r plus d. Well, first of all I'll do the plus d because that's easy. We've got five milliseconds plus m divided by r I've got 1250 bytes I'm going to multiply by 8 to get that to bits and I'm going to divide by 56 times 10 to the 3 bits per second and what's that equal to? Well, if you do the math you should find that it's equal to about 184 milliseconds Wow, well, that's kind of interesting and it's interesting because the delay here is Not a dominant term the in fact it's this last part here Which contributes greatly to the message latency. That's where nearly all of the latency is coming from So simply the time you get a message on a wire can be A key factor in the latency Let's see another example a different scenario Now I'm talking about sending information across the country and you've got broadband access by cable or dsl at home So let's say a cross country will collect 50 megabits sorry 50 milliseconds And the rate you've got 10 megabits per second is what you've got from your provider So let's compute our latency again. So I've got 50 milliseconds plus m divided by r. So that's 1250 times 8 divided by 10 times 10 to the 6 bits per second Well, that's 50 plus this is 10 to the 4 divided by 10 to the 7 That's going to be 10 to the minus 3 which is actually a millisecond. So this is 51 milliseconds Okay, well interesting so in this example nearly all of the delay is coming from the propagation delay to send the message Across the country the transmission delay component is almost nothing because we have a reasonable speed So here you can see I just clean this up a little more and the point that I want you to take away is that Either a long link or a very slow link Both of these can contribute to the latency of sending messages across the link Now and also often in practice one of the delay components is going to dominate So if we have reasonable rates We'll generally tend to worry about more about the propagation delay For instance if we're talking about sending messages across the country at a reasonable Rate, you won't even need to compute the transmission delay because it'll be too small to add significantly to the message latency Okay. Well, so we've done message latency. Great. This model turned out to be kind of useful But wait, there's more I'd now like to tell you about something called the bandwidth delay product It is a kind of an interesting realization To to think that messages actually take up space on the wire So it's as if some messages a volume of bits is actually stored inside a wire when you're using it to send a message You've sent it from the receiver yet sender yet. They haven't reached the receiver This quantity the amount of data in flight is called the bandwidth delay product And the formula for computing it is this It's to simply take the rate at which you're sending bits into the wire or other media And multiply it by D the propagation delay before those bits get to the other side. That gives us the volume You might measure this in bits Or in other units for convenience like in terms of fractions of messages or packets just depending how you set the units for your calculation And what you should find this is the bandwidth delay product will be very small for things like local area networks Where we're like a wi-fi But it can be large if we're talking about networks where both the rate is high and the delay is high These are sometimes called long fat pipes imagine a gigabit per second link which goes across country for instance Well, let's do an example to get the hang of it here We're going to look at sending data across australia looks like from perth to sydney So i'll assume here that the uh, the rate is 40 megabits per second So you've got a good maybe fiber connection from your isp and you're at home And the delay for signals to propagate across the network across that link is 50 milliseconds for across country So let's see the bandwidth delay product now is equal to 40 times 10 to the 6 Times 50 milliseconds. So that's 50 times 10 to the minus three putting that together we have 2000 times 10 to the minus sorry 10 to the three Um, and that's in bits. So if I convert that to bytes, we'll have 250 Kilobytes the 10 and 3 being a kilo kilo kilo. So 250 kilobytes Wow, well, here's just a cleaned up version of that the point I want you to take away is that that's actually quite a lot of data that happens to be stored inside the network Uh, pretty good picture. Um, actually, it's like a small novel if you just consider all of the text and all of that is just hanging out in the network Okay, so now we put our model to use and you have some introduction to the physical layer We'll go into the physical layer topics in the subsequent lectures Today viewers in this segment, we'll talk about different kinds of media wires and so forth This is material at the bottom of the physical layer Okay, so there are three kinds of media Which are very common that we'll talk about wires, Viroptic cables and also wireless is a kind of medium for propagating signals The issue with all of these kinds of media is that they propagate signals These signals carry bits of information In this segment, we're just going to talk about these basic types of media and get a little bit of a feel for them Then we'll move on to understand how signals that which carry the information are propagated across these media So the first kind of media we have is just a wires twisted pair wire That's your garden variety wire. It's quite common This is the kind of wire which runs to your house for your telephone Assuming you still have a wired telephone Um, you will also probably seen it in enterprises. This cable shown here the category five utp stands for unshielded twisted pair That is a common ethernet cable You can see in here that there are four pairs of twisted pairs The twisted pairs each one is literally two wires twisted around The signal is carried as a voltage differential across those wires And they're twisted just to help reduce the interfering IF signal that's radiated At least they reduce the Radiation of that signal and by reducing that we reduce the interference between adjacent pairs of wire Another kind of wire here is shown in the picture in the middle. It's a coaxial cable It's also fairly common used to be used to carry video signals still is for a cable to your home This is a these kind of wires generally have better performance than twisted pairs Meaning that they're able to carry Faster amounts of data higher data rates longer distances because of their physical properties You can see here. It's built instead of just twisting a couple of pairs of wire It has a metal core in the middle and that you can see here and also an outer conductor Around here around the edge instead of the two wires And it's put together in a nice way Both the twisted pair and the coaxial cable you'll see the round there the most common kinds of wire And they're designed for communications. There are many other kinds of wire We might use too one interesting kind that you could just have a look at is a household electrical power lines These are starting to be used for instance to carry information around your home just by reusing the existing infrastructure We can do that nowadays. You can read a little about it in the text if you'd like A different kind of media is fiber or fiber optic cables A picture shown here just of the operation of a fiber The fiber is here in the pink Now a fiber is really just a very long thin pure strand of glass The way it operates is when you shine light in from a light source That could just be a laser or an LED a light operating diode The fiber is so thin that the light bounces around it doesn't come out of the fiber It bounces around until it gets to the other end and then it goes out and you can detect it with some kind of instrument a photo detector Fiber compared to wire is able to transfer enormous amounts of bandwidth very high data rates over very long distances This is because it is Well fiber because of its physical properties allows very wide ranges of frequencies through And it also attenuates signals very little because very pure light just tends to zap right through it So signals can go for a long way before they're attenuated There are just like Different kinds of wire. There are different kinds of fiber. The two most common varieties are what is called multi mode and single mode Multi mode is the cheaper version. So it's good for shorter lengths Maybe links that are less fast single mode is the more pure higher quality version In as a single mode fiber light can only go straight down the middle because it's so thin And single mode fibers can be used to carry signals up to 100 kilometers or so Just like the wires. There's a lot of construction here. This portion in the middle. This is actually the fiber The rest is just all the padding and packaging that goes with it the cladding and the jacket And then over here. There is a bundle with three different fibers in that in that one cable And the third kind of media that we'll look at is wireless Wireless is fundamentally different than wires and fiber optic in one important respect And that's because and that is that the sender is radiating a signal in many directions It's radiating across a region So the signal rather than being confined to a wire or to a fiber optic cable radiates in many different directions This has an advantage that it can reach potentially many different receivers at the same time to everyone in the vicinity But it also Causes a sizable complication for using wireless systems That nearby systems Sorry nearby signals, which have been transmitted on the same frequency can interfere with one another at the receiver This picture shows the setup here. We have a laptop in the middle. So this is the receiver And you can see that there are two transmitters I've shown one is a little closer So there's a fairly strong signal that arrives at this laptop The other one is further away, but its signal still propagates and reaches the laptop So this laptop receiver will receive two signals at the same time two single superimposed on one another So it will be somewhat jumbled Now because these signals Interfere we need to be careful and coordinate the way the wireless spectrum is used Guess how we do that? Well, here's one answer Look at this chart. This is quite amazing. This is the united states frequency allocation chart I don't expect you to be able to read all of that The the key issue here is that this chart Shows how regulation is used to manage the different parts of the spectrum Different frequencies are used for tv stations radio stations police communications aircraft as well as computer networking So the government regulates who's allowed to use what frequency you can't just use any frequency you like In fact, just these small circled regions are the ones which are used for a wi-fi computer networking There are also some other 3g Frequencies, but but only very small portions of the spectrum are actually used for for data communications Even within these circles. It's just a small portion The portions of the spectrum that are used for Wi-Fi are actually fairly interesting in terms of a story They are the frequencies that we like for data communications tend to be in the microwave band from hundreds of megahertz up to several gigahertz now That's where you'll find wi-fi as well as 3g cellular network communications Wi-fi is actually transmitted in the what's called the ism Band you can see here this figure just shows different frequencies And frequency goes up to the right So this is frequency And some portions of the frequency were reserved As part of these ism bands they're shown here wi-fi actually uses portions of these bands And I think 1985 the FCC decided to allow anyone to use these bands without a license So you don't have to buy an expensive license as tv stations and and mobile network providers providers cellular network providers do That's why these uh these bands became unlicensed. These were actually the the junk bands garbage bands just left over with a lot of Interference and so forth they were considered undesirable But in these circles people began to use them for our computer networking. That was part of the intention Now, um, this means that you know within this area many different computers may be using the wi-fi So they will have to coordinate themselves since the government's not doing it for us By exclusively allocating us a frequency But these bands have been a major success as you know by the the prevalence of wi-fi today There's been a huge amount of innovation in different kinds of computer networking technologies using just this tiny niche of the spectrum We'll learn more in the next lecture about how signals propagate through different kinds of media G'day viewers In this segment, we'll talk about how signals propagate over wires and other kinds of media This will take us one step closer to understanding how to send information across wires Okay, here's the context. I think you've all heard me talk about this before many times So on the left and right we have computers which are really just sending bits That's what we want at least from our links But across the link they're sent as analog signals. We know that we've talked about different kinds of media Now this means that we're going to need to represent bits as signals To do a good job of that we need to understand what happens to these signals as they propagate across media That is our focus in this segment Well, one of the first things we need to know Is that our signals in time can also be represented in a frequency space Here's our signal over time on the bottom left. You can see i'm just tracing over here. Here's this signal This is how we used to thinking of a signal is going up and down and changing over time Now it turns out that that signal can be represented equivalently so you can map back and forth Uh to a representation that describes the amplitude and also phase Of different frequency components that are at harmonics This first frequency component is a fundamental wave that oscillates maybe over the time period of the whole signal here This second one label two the second harmonic Means to add a component which oscillates twice as fast And with a higher amplitude then we're going to add another component Which oscillates three times as fast with a smaller amplitude and so forth If we sum up all of these different Oscillating frequencies then believe it or not we'll get this equivalent signal on the left this equation here Now i'm just going to write okay to forget I want to show you this equation this equation sort of tells you how all of the different components Of the frequency harmonics can be summed up to provide the original signal But you don't need to remember the details of that the important point for you is to remember that this mapping exists This is actually a tool called for your analysis, which is widely used in electrical engineering So any of you who are sub studying that subject you can expect to get a lot more depth About our frequency space representations The key issue for us is what happens to different frequencies as you send a signal across a media Like a wire As you lower the bandwidth there's a pronounced effect As you lower the bandwidth this means that uh fewer and fewer frequencies can get through only the lower frequencies Which oscillate less quickly so you can see here in this in this box lost I've taken the signal from before and i've scrubbed out all of the frequency components Over eight times the fundamental This means that the components that I have left can only make transitions less rapidly The effect is that our our signal which used to be this beautiful square signal that i'm drawing over here Has become more rounded It's become this signal that we have left here y Well because when we threw away those higher frequency components we lost a lot of the sharp corners As you degrade further as we lose more bandwidth you can see that the signal here on the left comes even more rounded It's barely recognizable and as you go down further Well, I can't even really make out that signal whether it was a one or a zero By the way, here's a question for you out of these three, um Uh Different channels which provide different amounts of bandwidth and effects on the signal a b and c. Which one do you think's good for data communications? Think for a moment The answer is probably likely to be b is best. Why? Well, because we can usually make out whether the signal is a zero or a one It's high here zero zero One one zero if those are the original values which were sent and we can recover them at the other end Then we've done a good job of using that bandwidth. We actually didn't need the high fidelity signal Um in a sense we were wasting bandwidth now Of course if you had an analog application like uh listening to a stereo you want the high fidelity signal or it will sound terrible Okay, so this last bit that we learned that fewer frequencies Degrade the signal by making it transition less rapidly and getting more routed is key to understanding what Happens to signals as they pass over a wire In fact, I can now tell you That there are roughly four rough effects here that happen as the signal propagates across a wire First of all, it's delayed because it takes a little while for the signal to propagate as we heard before So a fraction of time will pass Next the signal is attenuated You know over a wire signal might go from meters through to kilometers And the electrical signal that's going to come out the other side will be smaller in magnitude than what you put in Because some of it will be lost some of the energy will be lost The signal will also be attenuated or more rounded because not all frequencies will be passed through A wire tends to pass frequencies well up until our cutoff frequency And after that frequency the signals are fairly highly attenuated They're mostly lost as in our example And finally some noise is going to be added to the signal just thermal noise In the receiver, you know, that's the sort of thing that you can't get around And if the signal is very small this noise will end up causing errors I'm going to show you pictures of these effects in just a little while. We'll make them up Before I do that. I just want to point out the information in the box here Interestingly, the EE in the CS community have different ideas of what BAMWIT actually is In terms of the EE community BAMWIT is literally the width of the frequency band So on a frequency diagram The some of the diagrams from before we saw a range of frequencies the width the frequencies are wire passes is its BAMWIT So it's measured in hertz In the CS community BAMWIT is regarded as the information carrying capacity of a link It's given in bits a second, megabits per second. We might talk of that as BAMWIT These two quantities are really related because if you have more EE BAMWIT You'll be able to get a link which sends information more quickly It will have more CS BAMWIT, so they're certainly related But they're not quite the same thing So you need to be careful who you're talking to to understand what they mean Okay, so let's see those effects Imagine that the signal on the left is sent What's going to happen to it? Well, one of the first effects is that it will be delayed, but we're not going to picture that because I can't draw a time delay Then it will be attenuated. What will that look like? Well, a smaller version Of the signal will come out the other side Now the BAMWIT will be limited because we go through a wire and the high frequencies won't be passed What will that do? That will make it more curved. So we'll get something that might look more like this And then finally We show here that noise is going to be added. What will that look like? Well instead of being smooth the signal may go or something like this It's still rounded, but it has all of these jaggies on maybe Because there's a little bit of noise you can see here the amount of noise is small So I can still see the signal very clearly If the signal had been greatly attenuated then the noise would be a larger component of it Okay, so what about fiber? Well, I don't have much to add about the transmission mechanisms over fiber Rather the important differences in sending signals over fiber compared to wires Had to do with the physical characteristics of fiber This graph here this figure Shows you the attenuation That's on the vertical axis against our frequency or wavelength as I'll get to in a minute On the on the horizontal axis And you can see here two properties of fiber which make it very interesting to carry signals First is the low attenuation attenuation. There is given in decibels per kilometer But basically the attenuation is very low And this means that you can send signals a long long long way through fiber before they're greatly attenuated many miles Up to a hundred miles maybe The other and that's quite different than wires Now the other characteristic here is you look at the band in which the attenuation is lowest And there are these colored bands here at different frequencies Which are used for to transmit signals over fiber. Actually, I keep saying frequency But by convention the horizontal axis is given in wavelength here wavelength is equal to is inversely related to a frequency So the wavelength is equal to the speed of light divided by the frequency So that way you can relate the two of them Now in these bands first of all you see these bands if you do the computations You'll find that they run at very high frequencies So we're not able to send signals literally we need to use a carrier signal at higher frequencies to send information And I'll get to that in a sec to give you the intuition and more over the width of these bands if you compute it in terms of Hertz it's very large. We're talking about many many gigahertz of bandwidth that's available to transmit signals Over fiber in windows of lower attenuation That great bandwidth translates into being able to send information at very high rate many many gigabits per second This is where the high capacity of fiber comes from Okay, and wireless what about sending signals across wireless links? Well, uh, the principal difference compared to wires or at least one key difference I want to point out to you is that we need to send signals over wireless links using a carrier rather than directly Here's a good old baseband signal the signal We actually want to send that encodes the ones and the zeros that signal can't be sent directly out an antenna for physical reasons You need a very very large antenna and a lot of power and so forth So instead higher frequencies carrier frequencies are the frequencies which propagate over wireless channels And we need to use a carrier frequency to send information. What does that look like? Well, um, it's not as complicated as it sounds Uh, the carrier is simply a signal which goes up and down rapidly at a certain frequency the carrier frequency And what we can do is change characteristics of it here. I'm going to change its amplitude And you can see what I'm trying to do there is change the amplitude to convey just that shape of the signal We wanted to send so by looking at the uh, the envelope of the signal I'll be able to work out what kind of information it is we're sending And uh fiber also carries information uses a carrier signal to carry information because we're sending at higher frequencies than a baseband Okay, here is a second characteristic of wireless for us to look at and that is that wireless signals Ittenuated rapidly as they travel away from the source of the transmission So here I have a diagram which shows you the signal strength And the vertical axis Against distance spatial distance. We'll just consider a line on the horizontal axis and I have two points of transmission Tx for transmission here at a and b Now for each of them, uh, we transmit it with a certain power level and the signal falls off rapidly as we go away And this attenuation Is proportional to one on the distance squared The signals are going to be attenuated at least this rapid lesion move away from the source You might wonder where that one on distance squared comes from Well, it's physics if you think about the the formula for the surface area of a sphere, you know As the signal expands a real volume of space that sphere Has a surface area of 4 pi r squared So the area of the sphere is increasing as the radius squared that translates into the energy Unit area if it's the same energy decreasing At at least one on the distance squared and it's at least that because other mechanisms Can, uh, cause the wireless signal energy to be lost now. Don't worry about that If you don't need to really understand that that's just if you're curious The point I want you to take away is that wireless signals attenuate quickly At least most rapidly from the source the signal energy goes down very quickly And a third characteristic of wireless, which is important to us and this is unlike wires to where, you know In wires the signal trans uh travels directly down that wire and you know, whatever we put on the wire We sort of get out the other end Well in wireless many people can be transmitting in different locations and if they transmit here, we have our three transmitters At A, B and C If they transmit on the same frequency their signals will attenuate here's their signal attenuating but they can overlap spatially And this leads to a phenomenon called interference at the receiver Let's just imagine for the moment that we have the receiver at another location Right here. I'll call this d if you like What does dc? Good grief. I'm just trying to write dc's What does dc? Well at this particular location We can see that there are Signals from all three transmitters are present at different amounts of attenuation. So actually d will see a strong signal from c And that that's this up here high here and down here. We have weaker signals. I'll just say a weak weak signal from a And b Now d will see all of those signals together Um, you know, it would be nice if they were all separated, but that's not the way it works You see the superimposition of all of these signals. Actually, this means that d may have a lot of trouble disentangling them In fact, it may be able to cleanly separate out to receive none of these signals individually because they're all messing up one another And finally the last characteristic actually maybe not quite the last characteristic But we're almost getting there that I'll tell you about for wireless is what's called spatial reuse And that has to do with this phenomenon of interference So we talked before this is the same diagram as the previous slide and I said that, you know, if we were at point d Uh, well, we would see all of these signals overlapping But if you look at the uh, the decay of these signals, you should be able to see, you know Over at least about let's say this band and this band Here I should be able to send Uh, we within these regions I can receive the signal b without the signal from a interfering if I simply look at a point here I get a fairly strong signal for b And I get no signal that I've shown here for a a signal continues to propagate and attenuate But below about this level here I just haven't drawn it on the graph because we consider it too weak to be picked up similarly over here You can see that within this region here anywhere within the region that i'm showing here A signal can be received and the signal from b is not strong enough to really Be noticed and hence interfere with that in a noticeable way. This means that we can reuse frequencies At these two transmitter locations a and b. However, if you consider c is c A signal been transmitted. Well, if we try and receive it at, you know, a point in the middle here Actually, we get strong signals from both b and c and the interfere as we as I've described in the previous slide So that means for these two signals c and b No reuse You can't cleanly reuse the same frequency at these two transmitters because they're closer together And their signals will interfere So the notion of spatial reuse is that if the transmitters are far enough apart Spatially we'll be able to reuse and transmit information on the same frequency Okay. Well, you can see how wireless is getting kind of complicated I'm going to stop telling you about wireless effects in just a moment. I really want to make two Two points and then, you know, one more one more effect There's always one more to show you about wireless And this is really to give you a sense of the complexity. So wireless is by far the most complicated Medium in which signals propagate compared to the case of wires and fiber Really for two reasons there are all, you know, the same basic electromagnetic effects But two reasons here are getting us one is that wireless propagation is very complicated because it depends on the environment We're no longer just going down a wire. We're propagating in a complicated environment So there are buildings that can get in the way and shadow signals You know trees our signals can bounce off all sorts of things including the ground The signals can be divided and recombined in interesting ways And this makes wireless propagation a very complicated phenomenon because of the environment And the other reason that wireless propagation is complicated Is that many of the key effects depend significantly on the frequencies Signals at different frequencies propagate in different ways to use an analogy light is a very high frequency So it propagates in a very directional way like shining a torch sound is a very lower much Lower frequency phenomenon and it does things like it goes around corners You can hear people even when they're in another room So a different frequency there can be related to very different physical effects For us some of the physical effects which will be most important will be those that happen in the microwave band That's what's used for 802.11 and you know 3g cellular and so forth And in a particular effect that i'm going to tell you about is multi path We should care about multi path other than that and the other effects I've told you about i'm just i'll leave it at the wireless propagation is complicated But we won't really have to worry about any more than the effects. I've already told you about Multi path is important for us to understand because it has a big effect on communication systems Multi path occurs because in the microwave band signals bounce off objects This means that they can take multiple paths between a center and a receiver on the left here I have a transmitter and on the right I have receivers Tx and rx Now let's just look at one receiver up at the top here The signal from the transmitter is going to be sent out in all directions Some of it might go directly to the receiver Another bit of it might go in a different direction, but bounce off a filing cabinet is the classic thing And also arrive at the receiver The receiver will then see two different signals that arrived over multiple paths These signals will be superimposed so they will add Let's just say That we had one signal like this And another signal which was also going up and down just as fast When we add them We get this strong signal. It's not faded Now suppose that just because of the position of the reflector the path The same thing is going to happen down at this other receiver It's going to get a direct one-on-one by this reflector But now say that the path from this other reflector has a differently it will And in this case the phase of the signals is going to be a little different So I'll receive one signal just like this is before And the other signal Oh gosh, how can I draw this? I'm going to offset It's the same thing. It's just shifted The result when you add these things together is that these signals mostly cancel And you get a faded signal here This is called multipath fading The effect is very difficult to deal with because it can change over very small distances As I move just you know, maybe even a few centimeters my signal might go from fine To mostly gone This effect is also frequency dependent The result is that in wireless channels often you're in data communications often your signal is really quite messed up Um, it's missing portions of it because some frequencies were lost We then need to handle it with fairly sophisticated communication methods If you're interested in learning more you can look in your text in particular There's a method that you'll hear about quite a lot called OFDM that's used We're not going to have time to go into OFDM in this course G'day viewers in this segment. We'll talk about modulation or how to represent bits of signals Okay, so here is the setup you must know this setup quite well by now We have our computer on the left sending bits to a computer on the right Across a link, but of course across the link. We can't send bits literally we send analog signals So we need to work out some way to represent These bits with signals. I've said that many times you must be wondering how exactly we do it That's called modulation and that's the topic of this lecture Let's dive right in. Here is a simple modulation scheme It's the one that you would think of first. I think if you were just trying to come up with one on your own We will simply use a high voltage to represent a one and a low voltage to represent a zero This is a modulation scheme called NRZ for non-return to zero the names for archaic reasons. Don't worry about it We can work through an example. You see I have a sequence of bits here And I'm going to draw the waveform underneath. So for a zero we've got we have a low voltage down here Then I'm going to go up to a high voltage for a one Down to a zero up for a one one one one zero one zero zero zero zero zero one zero Oops looks like I've got a little bit of noise on there Must must be just the way a waveform would look Let me clean it up so you can see it a little more There it is. That's one kind of simple modulation Now there are many other schemes which are variations on this which which can be used in practice For instance, we could use more than two levels to two signal levels to represent bits If I just look at the if we group the bits that we sent Two bits at a time we could send More different levels if I go over those bits. I think the sequence was zero two three three One from the bits before if I use four signal levels, it would look something like this. This will be zero. This will be well level one two three and four To represent zero through three. So I'll start low Then I will go up two levels Then I will go to the top level top level and down to the not quite the lowest level There we are that would be using four levels The schemes which are used in practice are very much driven by engineering considerations for how you get this to work I'm going to talk about one of those considerations, which is called clock recovery So for clock recovery, here's an example of the problem. Imagine that we have this nRZ signal here Here it is a one And then a zero a zero a zero a zero lots of zeros big long run of zeros If you are the receiver you see this signal But you don't see the bits of course your job is to work out what the bits are So it's clearly a one and then how many zeros is it? After a while it gets very difficult for the receiver to accurately work out the transition points between one zero and the next We could imagine that you'd have a very accurate clock, but that turns out to be expensive Instead what you would really like are frequent transitions in the signal itself So that you could help work out the timing of the signal at the receiver Now there are several different ways that you might go about this In your text you can look at there is an example of something that called Manchester coding That is a coding where there is a transition built into every signal either a zero or one They all include a transition a waveform which has a transition Another approach is something called scrambling You could exclusive or your data with a pseudo random signal Which makes it highly likely that you'll get transitions You can look at these designs for fun Instead what I'm going to do is tell you just about one form of modulation that's used to help with clock recovery And that's called 4B5B Now the idea here is that we're going to map every four data bits Into five code bits which are then sent as a signal And we'll do this in a way where we won't have long runs of zeros So here are some examples taken from the table. Here's an input of four bits 0 0 0 0 And if we want to send those four data bits, we're instead going to send the five code bits 1 1 1 1 0 At the receiver we'll map back from code bits to data bits. So we'll know what we were talking about There are 16 entries here in the table. They're not shown. They're omitted But you know just to save space, but you could imagine there's a whole table full And if we follow this mapping you'll find that there are most three zeros you can get in a row So we won't have long runs of zeros anymore Great Of course, if you're if you've been thinking ahead, you realize that you can have fairly long runs of ones We haven't done anything to prevent long runs of ones So to prevent that being a problem We can use a kind of coding where we invert the signal level on a one and keep it at the same voltage level for a zero This form of coding is called NRZi where the i stands for invert. We invert on one And it's also shown in your text. I'll give you an example And here in our example, I've reproduced the table of 4 b 5 b for a reference or just some of it You can see the message bits. I want to send they start with 1 1 1 1 Okay, let's look that up in our table. You can see over here on the left that should go to 1 1 1 0 1 I'll write that in 1 1 1 0 1 Next we have four zeros that goes to 1 1 1 1 0 1 1 1 1 0 And finally we have 0 0 0 1 which in our table goes to 0 1 0 0 1 0 1 0 0 1 So those are the bits we actually want to send using an NRZi signal. How do I send that signal? Since this signal Inverts on a one and stays the same as a zero. I'll show that transition in the middle Of a bit time here So if I just arbitrarily start at the bottom for a one Then the one will contain an inversion And then for the next bit there's a one. It's another inversion of the signal level one and inversion Zero I stay the same one invert Invert Keep on inverting Stay the same for a zero zero Invert on the one zero zero zero invert on the one And that is the waveform that I would send I would then be able to see the transitions get enough transitions at the receiver to find the bit boundaries and You know then go back from my code words to my data bits and everything would be good I would have sent bits of information across a link Or here's that example for you just cleaned up a little bit so you can see it better Now what I've told you about so far Turns out to be what's called baseband modulation how you would literally send a signal over a wire. That's great. You can do that When we talk about wireless or fiber though, we want to send information not by putting a signal directly in the medium But by encoding it on a carrier signal, which is operating at a higher frequency The reason for this Is that um only higher frequencies are going to pass well through the media Well, we might want to divide up the medium in terms of frequency bands to permit multiple people to use it So we need to work out how to send information on higher frequencies Um, it might sound a little tricky modulating a carrier. It's not so bad. Let's see Here we can work through an example So first of all, let me show this is just the carrier The carrier is just a signal which is oscillating here at some desired frequency This could be around 2.4 gigahertz for 8 to 11 For instance Now to modulate it we can change it in several ways. We can change the amplitude. That's how far up and down it is I maybe I should draw here the amplitude is how far up and down it is The frequency is how fast it wiggles. We can have it. We all quickly or a little bit more slowly And the phase is where it is in its cycle We could change the phase from up down to maybe uh down up would be studying would be different phases Let's see an example So here is passband modulation An example of it we at the beginning I show you the baseband modulation signal It's just our old nrz signal I'm tracing over just so you can see that it just simply goes from zeros to ones And back as it encodes bits Now our first Passband modulation is going to modulate the amplitude of a carrier So you can see here the carrier is not shown directly just the modulation is And you can imagine this a carrier going up and down just as before but its amplitude has been changed Its amplitude is zero For some of the initial bits here and then its amplitude is one When it's oscillating up and down with that amplitude with that magnitude Alternatively here is another kind of uh Number two a different kind of passband modulation frequency shift key You can see now that I oscillate rapidly for a one This is a one and I oscillate more slowly for a zero And finally we have phase shift key. This signal looks a little more difficult to see But in essence I'm using a waveform which starts by going up and then down Although this would occur more rapidly there would be many cycles In each um in each bit time That will represent a one and a signal that starts by going down and then later up so it's out of phase With the other signal will represent a zero With these schemes I can now represent information on carrier signals which are in frequencies of our choice Real wireless modulation schemes are considerably more complex than I've shown you in in these examples In fact, uh, you know, you can take a whole communications course to understand some of this by In detail. Nonetheless, what we've covered gives you the basics of how we send information bits of information with signals over across either Wide or wireless links We'll move on next to error recovery Good day viewers in this segment We'll talk about some of the fundamental limits for how quickly information can be sent over a physical channel or link So when we build communication links often we like them to have high performance to run as quickly as possible So it's useful for not to know just how fast it's possible to build a link In this segment, I'm going to talk about two different results the night quiz limit And the Shannon capacity as you can see these are fairly early results They've been known for a long time. They give us limits on what it's possible to achieve So the real systems which are built are going to operate within these limits These different results are expressed in terms of the key properties of channels which we might care about The properties that are used are the bandwidth b That's important because the amount of bandwidth limits how quickly the signal can make transitions up and down and hence convey information And the signal strength s and the noise strength n These are as measured at the receiver How strong a signal they receive at the receiver? As you might imagine The relative strength of the signal compared to the noise Limits how many different signaling levels we can distinguish more signaling levels will let us send more information Let's see the results. So the first result I have for you is the nyquist limit This is for a noiseless case where we're just ignoring noise The nyquist limit tells us that the maximum symbol rate is 2b A symbol is simply a waveform which is used to convey information It might represent one bit more than one bit if you have multiple signal levels or even less than one bit in some cases So a symbol is a waveform that stands for bits Nyquist tells us that if we have a bandwidth of b We can signal symbols at a rate of up to 2b here. I've shown just a simple waveform Say that's the highest frequency we can send that kind of code two different bits per Per transition there an up and a down a one and a zero I've shown here Now if we also have different amplitude levels if we have v different signal levels That would be log to the base two of v different bits For instance, if you have four signal levels that will allow you to convey two bits with each level Eight signal levels three bits and so on putting these two terms together nyquist tells us That the maximum rate we can send information across a noiseless channel is 2b Multiplied by log to the base two of v bits per second where v is the number of signal levels Let's move on to the the other result which we'll care about the really the end result here This result is due to Claude Shannon Shannon was a giant of early computing In 1948 he put together a treaty called the mathematical theory of communication This was a landmark paper that put forth many of the key concepts and helped Found a field called information theory. It told us really what information was all sorts of things Shannon as well as making fundamental contributions to communications also made contributions to digital computing and security He was a quite an amazing guy. He also had fairly wide-ranging interests This picture shows an electromechanical mouse he built Uh, the mouse there are magnets underneath the mouse runs on this maze You can reconfigure the maze and the mouse will learn how to solve it and this was a long time ago. So it was quite amazing Shannon's capacity tells us the maximum information carrying rate of a channel And it does that by considering the noise Now the number of different levels we can distinguish signaling levels at the receiver Is going to depend on the relative strengths of the signal That we receive That signal is actually s plus n the signal plus the noise at the receiver The strength of that signal compared to the noise If it's large If that ratio is large we'll be able to distinguish many different levels in the picture here You can distinguish maybe four different levels. So if I have a if I receive something here Maybe I can know that it's most likely that a one was sent Because if I sent a one the noise would only have moved it up and down by a bit And so one is probably what was sent. On the other hand if I receive something here It's probably the case that I sent a zero Uh, keep in mind that these this noise is a random process The arrow here is only a depiction of how big it is on average So at any given time the noise could be larger And we may have some errors that are caused when our assumption is wrong We'll have to deal with them later The signal-to-noise ratio, or s divided by n Is typically expressed on a log scale because it can take on a wide range of values So if for instance we have a signal-to-noise ratio of 1,000 That's often written Using our little formula here, we express it on a log scale By taking log to the base 10 of the ratio and multiplying by 10 That's often written as 30 dB log of 1,000 is 3 multiplied by 10, you get 30 There are many other common SNR values in decibels that you might come across So as you might imagine 100 goes to 20 dB 10 goes to 10 dB 2 is a common value and that goes to 3 dB And so forth Okay, arm, arm, arm, arm, arm, arm, arm Okay, arm with this understanding of the signal-to-noise ratio We can talk about the Shannon capacity This is a limit for the information carrying capacity of a channel The limit, the capacity is given by the bandwidth Our factor from before multiplied by log to the base 2 Of 1 plus s on n Where s on n is the signal-to-noise ratio This bit in parenthesis, you might recognize this Is what we receive s plus n divided by n That's really s on n plus 1 This bit, log to the base 2, is converting to bits And then we're multiplying by the bandwidth The Shannon capacity is really quite fundamental for a channel Shannon showed that it is possible to transfer information reliably over a channel Up to that rate, but no higher This was quite revolutionary at the time When there always seemed to be errors on channels And the only way you could get rid of them was by sending a stronger signal Shannon really told us that in theory there exist codes So that you will be able to send information reliably across channels Up to a certain rate Even for whatever signal-to-noise ratio you're sending in So just to wrap up on this segment I'm going to give you a little perspective on wired versus wireless links We've now seen pretty much everything we need for the physical layer Aerocoding is a big subject that I'll get on to next But we've seen how to modulate signals and send information across links Yay! We're well on our way There is a big difference, however, between wires and fiber and wireless I would characterize it this way With wires and fiber, you can often engineer the parameters You can fix the bandwidth you're using by the quality of the wire And the signal-to-noise ratio You might send a certain value in and say the cable can be no longer than 100 feet This means that you can fix the data rate On the other hand, wireless is quite different You might be able to fix the bandwidth you're using as part of the design of the system But the signal-to-noise ratio will vary greatly It says here, up to a factor of 60 dB You do the math, that is a million That's a lot That might be the difference between signal strength and being close to an access point And 80 to 11 access point And receiving information quickly and being far away on the very edge of reception But still being able to use it Given this wide variation The signal-to-noise ratio is going to vary a lot We can't design the system for the worst case Or it will always run at a rather slow rate Instead, the name of the game in wireless Is adapting the data rate to the conditions you find So just recapping For wires and fiber, we engineer the system To give us a certain data rate that we expect and spec For wireless, we need to adapt to the SNR And finally, just to put some of these things together I can now give you an example Let's talk about a link that many of you know about Maybe you're using right now DSL or Digital Subscriber Line This is a widely used technology for providing broadband internet to homes There are many different variants of it And they run at tens of megabits per second DSL reuses the twisted pair telephone line that goes to the home So here's the local telephone exchange And there might be two different lines that go to the home Now, it turns out that the telephone is only using the bottom four kilohertz of this wire But the wire has a bandwidth of up to two megahertz We can reuse the higher portion of that bandwidth Which is currently unused to carry data That's exactly what DSL does Because it's been refitted to the existing telephone wire Rather than designed from scratch It has some of the characteristics of wireless too As you might imagine this close house If I'm close to the exchange I might get a high SNR Compared to if I'm a long way away The signal might be weaker and I might get a low SNR Because the signal is attenuated by the time it's got there When I've got a low SNR I might get a rather small data rate Compared to the other house Which could get a fast data rate over DSL This is why when you want to buy DSL Sometimes your provider will tell you That you're a long way away from the exchange And they can only sell your plan that goes this fast Or that you're lucky you're close to the exchange And they can sell your plan which runs at the maximum rate Here are a few more details for DSL DSL because it is sending at frequencies above the voice band Uses a former passband modulation I'm not going to go into all of the details That's sort of a whole course It does use a technique called OFDM Which turns up many times in communication systems You can read a bit about this in your text if you're interested Just for fun DSL divides the frequency band To provide separate bands for upstream and downstream communication You can see here that it uses four kilohertz The voice, that's not much And then it divides it into different portions For the upstream and downstream DSL, or actually the picture here Shows the frequency plan for ADSL2 Which is a fairly garden variety version of DSL It allocates more bandwidth to the downstream version Than the upstream version That more bandwidth is going to translate into a high number of bits per second The ADSL stands for asymmetric This asymmetry is deliberate To allow you to download information from the internet faster than you can send it The modulation that's used inside these bands Varies both the amplitude and phase of the different carrier signals It's called QUAM You don't need to remember that though If you're now all of the different signals in here They all can send information at different rates If you have a good portion of this band You're fairly close To the exchange you've got a good quality signal You might get a high SNR And you might be able to send it up to 15 bits per second Sorry, up to 15 bits per symbol So that's a lot of different amplitude and phase levels Two to the 15 at least to convey that number of bits On the other hand you might have a different band Part of the frequency which might be bad Not working very well This one's nice and solid let's say And the other one's not working very well This particular part of the band might give you a low SNR In which case you'll only use it to send one bit per symbol So this is how you can get different rates over DSL Okay well we've now seen a lot about the physical layer And shortly we'll move on to the next topic of error coding G'day viewers In this segment I'll give you an overview Of the topics that we're going to cover in the link layer Okay we're moving on We've now done what we need to on the physical layer We know how to send bits over a wire And we're moving up Through the link layer is our topic next Our picture here has changed This picture shows you the scope of the link layer Now that we have a bit stream The scope of the link layer Is focused on how to send messages Across one or more connected links These messages are called frames at the link layer And so you could also think of them as packets of the frames at the right word But they're going to have a limited size And they're going to build on the abilities of the physical layer So we'll no longer be talking about signals Just bits Here's a layering diagram Let's just recall how layering fits in with this The network layer shown at the top here Is sending a packet down to the link layer What happens at the link layer? You're meant to remember this By the way I'm going to draw it in But I hope you remember this The link layer will take the packet That packet is a payload there And then it will encapsulate it and add a header Actually as part of encapsulating it Often you add a header But in some cases Particularly at the link layer You may also add a trailer That unit will then be passed down to the physical layer Where it will go across the wire Come up the other side You'll have the same structure And the packet in here We'll just put H and T The packet will be unwrapped and passed up And because of that We're virtually communicating messages From one link layer protocol instance To its peer protocol instance on the other side Via the services of the physical layer This packet in here is going through unchanged And here I just cleaned it up a little bit So you can see the picture You might also be wondering Where all these different layers are implemented So I'm going to draw a diagram that just shows you The typical implementation of layers On a computer You might have applications programs Which run at user level Supported by the operating system And underneath the operating system Is the hardware itself The applications Here we are Are implemented typically at user level They're just programs which run on computers Within the operating system We'll then typically have the transport And network layers And we'll also have some of the link layer The link layer typically straddles The operating system and hardware Some of it's implemented in the operating system In the lower part of drivers Often there's some hardware support for the link layer On a NIC network interface card Which is inserted in your machine And then the physical layer Well that's hardware at the bottom Here's a slightly more cleaned up version Of that picture Or close to that picture It doesn't show the transport layer there Because that's not involved in this particular picture But don't worry about that So in our exploration of the link layer We're going to cover several topics This week we'll talk about framing Which involves how to delimit messages The beginning and end of messages And we'll also talk about error handling How to detect and correct errors Because of noise at the physical layer That'll occur and we want to be able to deal with them Later on in the following week We'll talk about yet more topics in the link layer As we work out how to retransmit And handle packet loss How to deal with multiple people Using the same channel as in 80211 And how to even build small networks By combining different links with switches G'day viewers In this segment we'll talk about Framing messages which are sent across the link layer So the need for framing arises Because the physical layer delivers a stream of bits We've worked hard with modulation To turn signals into a stream of bits But of course a stream of bits is not really what we want We would like to be able to send a sequence of messages Called frames across the link layer So we need some way to delimit The start and end of those messages That's what framing is all about In this segment we'll look at different methods Which can be used for framing First of all we'll look at a byte count method This is really a motivational method Just to get our hand around some of the different issues Then we'll look at byte stuffing Bite stuffing is a method which is used in practice And finally we'll look at bit stuffing Just to show you an alternative That's actually an older method Now I do want to point out That all of these methods Impose a framing structure on top of any bit stream You could use them in systems you design In many real low-layer links However the physical layer and the link layer Are implemented together And the physical layer often helps the link layer framing By providing signaling about the boundaries For instance by using physical air symbols That can't otherwise occur to indicate the start of frames So we're not looking at those methods Okay so our first method Bite counts What would you do if you wanted to impose a framing structure on a bit stream Here's a brilliant idea We'll just start the beginning of each frame with a length field That length field will tell us how long the frame is That way we'll know where it ends And where the next frame begins It's a simple method It's fairly efficient And hopefully it's good enough What could possibly go wrong Well, here we can see an example A byte counts I'll just show you here The first byte here is five So that says this frame is five bytes long One, two, three, four, five So if we hop beyond that We'll get to the start of the next frame And so on You can see, oops, almost missed that We're hopping down And we'll hop past Great, there's a simple scheme There is a problem with this scheme though As you might guess And the problem is this If we ever lose synchronization Because of an error For whatever reason A side crashing and restarting Then it is very difficult for us To find the start of frames once again We really have no way to resynchronize And we could be lost forever Here's an example First of all, we've got a nice byte Where we're in sync It says five, we go to here This byte is an error It should have been a five or something If we interpret it now as a seven We're going to overshoot And interpret something else As the beginning of another frame After that, we will happily invent fictitious frames Here, one byte Okay, the next one must be here Two bytes The next one must be here Four bytes One, two, three, four We must be here Sorry, here Seven bytes Where somewhere, somewhere else But we've lost synchronization And we can no longer work our When frames start and end Bite stuffing is a better idea That allows us to resynchronize The idea with byte stuffing Is that we will use a special character Called the flag byte To indicate the start and end of frames Here it is here We put down a special character That we can look for To know where frames start and end Of course, to do this We're going to have to do something With flag bytes Which might occur In the middle of a payload As real data We'll have to escape Or stuff these flag bytes With an escape character To, it's like quoting Material to indicate That it's not really the real flag There's a small complication here too If we introduce a special character Like an escape code We'll also have to escape the escape code Because there might be escapes In the real data Here's an example of byte stuffing The rules here Every time you see a flag in the data Replace it with the sequence escape flag An escape flag And every time you see escape Replace it with escape escape That's it So we can fill out this example together On the other side you'll have a Then there's a flag We better escape that ESC flag B Similarly if we have an escape inside the data ESC ESC B You could have an escape flag But if that's actually the data And we want to stuff it You will have to escape the escape Then you will see a flag character As a literal and you'll escape the flag And similarly Let me escape The two escapes So, and the receiver is going to Reapply the same rules in the other direction Whenever it sees an escape in the data It's going to take it out And replace it with the following character If we use this scheme It has the virtue that any unescape flag Is now the start or end of a frame So we can use this method To quickly re-synchronize If there's ever any error to find the start of frames All we have to do is look for that unescape flag Which doesn't exist here You can see all the flags are actually escaped So they're not real Okay, there's also another kind of stuffing You can do stuffing at the bit level Here's how that would work So we will call our flag sequence Six consecutive ones The rule we'll use at the transmitter Is if you ever send five ones in the data Sender zero Just in case the sixth thing was going to be a one On receive you're going to do the opposite If you ever get a zero After getting five ones Throw it away because it was added by the sender This is quite a simple scheme Actually, this scheme came before byte stuffing If you do an analysis You would expect that this scheme actually has slightly less overhead Nonetheless, it's more complicated than byte stuffing Because we might have to deal with messages with, for instance, 193 bits And we would rather deal with whole octet or byte numbers So byte stuffing is what's used in practice Oh, we have an example here we can go through So let's just quickly do a little bit of bit stuffing Zero Here's the data I'm going to copy it down That's two ones in a row Then a zero Oh, no problem Here we've got one, two, three, four ones in a row Now five ones problem You have to insert a zero Now we continue The next one I'll count as one, one, two, one, three ones Four ones, five ones, zero Now we're up to here Two ones, three, four, five ones, zero Then one, one, zero, zero, one, zero No problem Here are the characters I've inserted by stuffing This slide just cleans it up a little bit I mean, I've already told you how it compares In terms of maybe being slightly more efficient But being more complicated and not worth it in practice Now that we've seen how framing works I can give you an example of a real protocol PPP is what the protocol is called It stands for the point-to-point protocol It's fairly widely used in the internet To carry IP packets to frame them Over any kind of bit stream, byte stream transport For instance, PPP is used to carry IP packets Over sonnet optical links You might not know what sonnet optical links are Don't worry too much These turn out to be the big fat pipes That run at min gigabits a second Which are used by ISPs in the middle of the backbone Here's a little more on how PPP works First we have the protocol stack here You can see the IP layer here is going to produce packets And hand it down to the PPP layer Which is acting as the link layer and providing framing The link layer is then going to run over the sonnet layer That's the physical layer here And once we've got a little bit of a physical layer Eventually it'll go out that optical fiber On the right hand side It shows us some of the encapsulation And just some of the real world wrinkles That you run into here The IP packet is encapsulated inside a PPP frame That's pretty much what we expect But the PPP frame might actually be split Across two sonnet payloads It's a sort of real world complication That networking protocols are full off If we focus on the PPP bits Since that's our focus for this video Then we find that PPP frames Frames the packets it gets from the IP layer Using byte stuffing That in a way that's quite similar to what we've described Here's a picture of the frame The payload is what comes down from the IP layer And you can see to that The PPP layer adds some of its headers And control information And also some trailers And then the outer layer is the framing With our flags In fact the flag character here is 0x70 And we'll also have to escape this character If it incurs inside the IP packet That's inside the payload And we'll do that using 0x70 Is the escape character There's one slight twist here though That's a little interesting It's in the details But I think it's interesting So I'm going to tell you Here's the rule for byte stuffing To stuff or unstuff a byte You add or remove the escape character Just as we've seen And you also X or the byte Which follows the escape character With 0x20 Now if you expand all of those bits And look at that hexadecimal notation You'll find what that does is toggle the fifth bit So for instance If I have 0x70 in the data 7e If I stop that I will get 0x7d The escape character And then I'm going to X or 7e With 0x20 That will flip the fifth bit And I'll actually get 5e I've just changed the value of 1 bit Similarly If you stuff 0x7d Then what you'll get is 0x7d The escape character And then I X or 0x7d With 0x20 And I will get 5d And at the receiver I'll do the reverse I'll simply X or whatever Comes after the escape character With 0x20 And that will turn it back Into the 7e that we wanted The virtue of using this scheme Is that we've completely removed Occurrences of the flag character 0x7e From the contents of the frame So now we can just search The byte stream for 0x7e And when you see it You've got the starter frame It can't occur inside the frame Because we've modified it in some way By using this convention Okay well now you know about Real link layers And how framing is done G'day viewers In this segment I'll give you An introduction to the error codes We're going to use C To detect and correct errors Our topic is how to handle The different errors that occur At the physical layer The problem in essence Is that some bits in our messages At the link layer are going to be Received in error Because of noise at the physical layer This is unacceptable In that we can't send a message Across a network And have a different message Arrived at the other side And think that was the real message You wouldn't be very happy If this happened every time You sent messages across the internet For example So we will need some way To handle these errors There are a few alternatives That we'll look at It's possible to detect Some of these errors Using codes Well we'll look at this later It's also possible to Correct some of these errors Using codes You'll receive a message And not only realize That something's not quite right With it But be able to take a good guess About what message was actually sent And finally it's possible To after you've detected Maybe that there's a problem Retransmit a message Which was in error And has otherwise been lost We'll look at this option later And first of all Just talk about error codes These kinds of error codes Are a reliability Function And we'll also see As we go through this course That reliability is a concern That cuts across all of the layers Every layer will generally do its part To improve the reliability of the system At the link layer We're mostly concerned with bit errors That might occur and what to do about them At higher layers We might be concerned With the recovery actions and so forth Okay so the problem here Is that Noise Can flip some of the received bits You can see the signal I sent in above Just one of our good old fashioned NRZ coded Zero one signals I'm going to draw a slightly noisy version of it It's a zero The signal is kind of wandering And then a one And then a one A few zeros And a one But you can still make it out On the other hand If the line has been long And the signal is very attenuated Relative to the noise We might have something That's much more messed up What is this? Well this looks like Zero one one zero I don't know what this is This could be a zero Or it could be a one Maybe that's a zero zero I don't know what this one is either Let's make that even a little more messy Just so it's clear That there's a lack of clarity there In this case We may end up making decoding errors And think that we got a one here When we received a zero Or vice versa These are the errors that we would like to handle Observe that in our case In this scenario The receiver maybe doesn't even know there are errors It's just got the bits It's decoded them Some of them might be bad It doesn't know that yet How are we going to deal with these errors? To handle them What we will need to do Is add structure to the message By adding some redundancy Only by adding some kind of redundancy and structure Will we be able to recognize That the message doesn't look quite right That something is wrong with it With error detection With error detection codes We add a little bit of structure in the form of check bits We add these check bits to the message In these check bits Will then let us detect an error at the receiver Whether an error When an error is coded On the other hand We could pursue error correction codes In these schemes We'll add check bits also But usually more check bits So that at the other side We can look at the structure of the message See that something's wrong And take a good guess As to what the message was Thereby correcting some of the errors The key issue for us Is how we're actually going to do this It sounds kind of hard This is actually a very interesting topic Don't you think? How are we going to structure these messages With codes So that we can solve this problem Not only that But for a good code We would like the code to be able to Detect lots of different kinds of errors Not just single bit errors But maybe situations when Two bit errors occur in a packet And so forth We'd also like to do this with Few check bits Every time we send a check bit We're using the channel for something Other than the real data we care about So we're adding more overhead So don't use too many of them We'd also like to do this With a scheme that involves Only modest computation At the sender and receiver If we can We're generally willing to use A bit of computation What will really help But this is computation that has to go on You know line rate At the sender and receiver So it's adding complexity to the system To warm up to some of these codes We'll start with a motivating example So here's a simple code That we could use to handle errors Got a brilliant idea You're ready for it Here it is Send two copies It's just an error If they're different I hope no one's patented that Okay, so here's our example Here is the message Zero one zero And we're simply going to send Another copy We'll send it again Back to back zero one zero Great Actually let's not rush out And patent it Before we think about How good this code is First we could ask Well, how many errors Will it detect or correct The number of errors it can correct Is zero It can't correct anything Suppose for instance That you know we had received A one on the very end Instead of a zero Well now you can see These two things don't match So we know something's wrong But you don't know which bit is an error That this one was flipped Rather than this one You just know there's a problem With some of them How many errors can it detect Well, I don't know I guess it could detect up to three errors If there were errors in different bit positions But here's the key issue The key issue is not how many errors it could detect In the you know for very arid messages But rather the minimum number of errors Which are required Which are able to make the code fail Suppose that I also flip This same bit in the same position They match Our check will say there's no errors But all I've done is added two errors With two errors this code can fail So it's not a very good code really Not only that I guess but to get that level of protection I spent 50% of my link On overhead for error correction Error detection And I didn't really get a lot of error detection out of it Two lousy bit errors And the scheme could fail And tell me I've got a message that's right When in fact it's wrong So we want to be able to do better than this We want to be able to handle more errors With less overhead We're going to look at some real codes Which are used To do this That can detect and correct errors In stronger ways than that motivating example These codes are basically going to be Different kinds of applied mathematics In general you won't go out and invent a new code You'll look one up and you'll use some well-known Existing codes which are being checked and debugged Which have been optimized by mathematicians essentially These different codes though They won't be able to handle all errors All of the codes are built to handle some level of errors Not an arbitrary level of errors It can't be done And it's also the case That these codes focus on accidental kinds of errors Rather than malicious errors As might occur when an adversary is trying to trick you It is possible to come up with error Detection schemes which work for malicious traffic These are called secure hashes This is a cryptography subject And we'll probably mention them briefly When we get to security at the end of the course But right now I'm just focused on regular error Detection and correction codes For errors in the physical layer To use error codes Just diving into the next level of detail Here's the overall structure We're going to send code words A code word is going to consist of the D data bits That's the actually the message bits that we want to send And then to that we're going to add these check bits We talked about Our different check bits This there is a vast literature on error codes And the kinds of codes I'm going to talk to you about Just so you know They're called systematic block codes Block codes mean they operate on a block of bits at a time Systematic means you append the check bits Rather than rewrite all of the data bits Those terms will help you If you're trying to read other literature And see where these schemes fit in The way the codes will be used at the sender Is that the sender will be given the data bits D from the higher layer And it will then compute the check bits The check bits here are strictly a function of the data So they're computed by a little routine as a function of the data Well then append them And you send them into the network towards the receiver And you're away The sender has done its job On the other side The receiver will receive from the network This package of D plus R bits There could be errors in this bit In these bits Let's just say there's an error in the data here Maybe I'll do an X in the data here What the receiver will do Is it will take the data bits And it will recompute The check bits from that data There is a function of the D data bits And it will see if they match the R-bits The R-bits that it received They should match If they were both computed from the same data They should match If everything's okay If they don't match Then it's an error In the case where I put an X here We will get an error Because our R should be Hopefully we've got a good code different from our R-dash Observe that one thing that's difficult about the codes here Is that the error could also be in the check bits Suppose actually my data was fine In the errors in my check bits This procedure will still tell me there's an error There is Not an error I really care about Because my data bits are okay But I have no way of knowing that Simply that there's an error somewhere in the D plus R bits And that's because the bits that go over the physical layer Don't distinguish check bits from data bits The check bits are not magical They're sent over the channel And so they're subject to errors Just as much as the data bits This is what makes error codes Very tricky and interesting to look at Here's a little more intuition as we think about How to design some of our codes Okay we have D data bits and R check bits In this picture I'm trying to draw just the space Of some of these different designs If we look at all of the code words How many code words are there? Well a code word is D plus R check bits So there are two to the D plus R Different possible code words that could be sent And received actually That could be received on the other side There are two to the D plus R possible Incoming sequences of D plus R bits But actually the code words The really correct code words that get sent How many of them are there? Well we know that they're D plus R bits long But there are only actually Two to the D different bits Because the R bits are computed As a function of the data So there are only two to the D possibilities Well that means if I randomly pick a code word From this space Anywhere from this space It's quite unlikely to be correct In fact the chances of it being correct Would be something like one over two to the R That's what you get when you take two to the D And you divide it by two to the D plus R One over two to the R gets fairly small As R gets large If you have a 16 check bits for instance You've got a one in 65,000 chance Of accidentally picking a code word What we would like to do when we design code words Is make it so that errors Essentially make it likely that we will pull A random sequence of bits out of this space That will not be a valid code word Then we'll be able to work out That something's gone wrong and try and correct it Much of the early work in this space Was done by Heming By Richard Heming He was a pioneer of some of the early codes There's actually a very nice paper he wrote in the 1950s This one Arrow Detecting and Correcting Codes You could look for this web and read it Sorry this paper on the web and read it It's really very readable And it develops in a very elegant way Something called Heming Codes Which we'll look at Heming did all sorts of work on codes and other things He was one of the great early pioneers You could also find on the web A talk he gave on You and Your Research Which is part motivational on advice That's often quoted Okay so here are some of the concepts That Heming came up with Which we need to know to work with error codes He came up with a concept of the Heming distance The distance by itself is The number of bit flips you need to change Oh it says D1 to D2 This should really be full code words D plus R1 to D plus R2 Now let me give you an example of a code Suppose when we have a data bit of 1 I'm going to send 111 Triple repetition code Just send the same data three times Seems good, got to be better at sending it twice For 0 I'm going to send, you guessed it, 000 What is the distance So this is the complete code set here That we just 0 and 1 are the only messages So 111 and 000 are the only code words Valid code words which could be sent Of course any sequence of 3 bits could be received What's the distance between these two code words The distance is the number of bit flips To turn one of these into the other So it's 3 We need 3 bit flips Now the Heming distance of a code Is the minimum distance between Any pair of code words that are in the code In this code there's only one pair of code words The code word for 1 and the code word for 0 The distance is 3 So the Heming distance of this whole code Is also 3 Seems fairly simple so far But we'll use it in just a moment Okay, so one of Heming's results Was that if you want to do error detection If you have a code whose distance is D plus 1 Then it is able to detect up to D errors always That many errors if they occur You are guaranteed to be able to detect it Let's see an example For the code I just looked at We have D plus 1 is equal to 3 Therefore you guessed it D is equal to 2 So that says with my triple repetition code I should be able to detect up to 2 errors Here were the two code symbols That are valid that we could send the two code words Let's just write down what you can get if you make 2 bit errors Well I could get 0 0 1 Yeah that's an error because that's none of those things We haven't changed one into the other I could get 0 1 0 I could get 1 0 0 I could get 0 1 1 I could get 1 0 1 or 1 1 0 That's all I can get by flipping 2 bit flips from any one of these things And none of these are valid code words So I'll always be able to detect it Of course if I make 3 bit flips I can change one of these valid code words Into another valid code word And I won't be able to detect that But with only 2 bit flips I will Here is another of Hamming's result And this is for error correction The result here is that if I have a code of distance 2D plus 1 Then up to D errors can be corrected By mapping them to the closest code word If we assume that there are a few enough errors Then that can be done Let's give an example again Here we have the Hamming distance Is 3 for the code So that was 2D plus 1 is equal to 3 D is equal to you guessed it 1 This means we should be able to detect up to 1 Sorry we should be able to correct Up to 1 error unambiguously with our triple repetition code Let me write down just an example error 0 1 0 That's the sort of thing you could get as an error What should we map it to? I think we would map that to 0 0 0 Now if there's only been 1 error It had to be this not 1 1 1 What if we got 1 1 0 Well we could correct that If we knew that there was only up to 1 error To 1 1 1 That's the code word to which is unambiguously closest So that's what must have been said If only up to 1 error had occurred If more than 1 error could occur in this scheme All bets are off You know if 2 errors had occurred Then this code word The second received sequence could have actually been all zeros But this is why with Hamming's bound This error correction code is only good for circumstances In which there can be up to a single error G'day viewers In this segment we're going to talk about specific schemes That can be used to detect errors in packets We talked previously about errors occurring in packets Because of noise at the physical layer In this segment we're going to go over some specific schemes Which can be used to find those errors When they do occur to detect them And we will look at three schemes in particular Parry really mostly for motivation Followed by checksums and CRCs With the latter two are used fairly widely in practice I'd point out also that detection by itself won't fix errors But it will allow us to fix errors by combining detection With a mechanism such as retransmission And we'll look at retransmission later Well let's start with our first simple error detection scheme Parity or the parity bit Parity works as follows You take d data bits and then you add one check bit The parity bit and that check bit is going to be the sum of all the other d bits That sum will have to be done modulo 2 Because we've only got one bit left over to put on And by the way this is equivalent to XORing all of the bits together Here's an example Let's just say I have 1, 0, 0, 1, 1, 0, 0 There's a 7-bit sum of data to send If I then want to add parity to it An 8th parity bit The parity bit for the case of even parity Will be the sum of all of the data bits modulo 2 I've got 3 of those modulo 2 I get left back a 1 instead of a 0 So we add a 1 This is the parity bit Great That's essentially parity And you can check the computation at the receiver You would go through and add them all up again Except for the parity bit You could see if they're equal Or you could just add everything together Including the parity bit And you should get 0 out by design How well does this parity code work? Well, if you recall our concepts of error codes We can sort of begin to think about it First of all, we can ask What's the distance of this code? How many bit flips do I need to make? What's the minimum number to turn any one code word Into another code word? Well in this case If I flip any one bit The parity sum will be wrong But if I flip another bit Then I can get to a place Where the parity sum would be right Even though the data has changed So the distance of this code is 2 Given a distance of 2 How many errors are we able to correct? Well, the answer to that is 0 You don't correct anything If the parity is off You get to see if there's been one error But we don't have enough distance here To be able to correct anything What about detecting errors? How many errors are we guaranteed to detect? If the distance is 2 We're guaranteed to detect up to one error So that's all the parity is good for In terms of any guarantees Now for errors So it's not that strong For errors larger than a single bit What happens is going to depend On the structure of the computation For parity, if you think about it Actually it has this nice property That it will catch all odd numbers of errors Where an error is changing a 0 to a 1 Or vice versa If the first error will be caught by parity The second error will cancel out That parity bit won't be caught That was why it's distance 2 But the third error will bring us back To the situation Where there's a problem with the parity check bit Once again So we've detected all odd numbers of errors But not all even numbers of errors Here's a stronger alternative And one that's used in practice Much more widely today The idea here is in a checksum Is to sum up data Much as we did with parity But instead of using a single bit We're going to sum up the data In terms of n-bit words And use an n-bit checksum Or n-check bits For example TCP, IP and UDP They all use a 16-bit checksum This checksum is going to provide Stronger protection than parity We'll find out later It's really not that strong But it is stronger than parity I'll give you one specific example And that is the internet checksum This is the particular kind of checksum That's used in TCP, IP, UDP And other internet protocols Here's the definition of the checksum The checksum field is a 16-bit Ones complement of the ones complement sum Of all 16-bit words Oh my goodness That sounds very confusing It's not that confusing once you get used to it Essentially what it's saying here Is that you sum up all of the data 16 bits at a time And then you negate it So you come up with the negative sum The catch here Is that all of this arithmetic Is done with ones complement addition And it's done that way To give a better distribution Of our data over the 16 error bits Ones complement notation Is a way of describing binary numbers Such that the ones complement Or flipping all of the bits of a number Gives us negative form So for instance, if I have 001 The ones complement version Or the ones complement a bit clip of that Is 110 So this is one And this other bit one is negative one In ones complement Ones comp The computers we use Perform addition Where all of the binary numbers The integers are represented In twos complement form To get twos complement You do ones complement and you add one So for instance this negative one 110 If I add one I would get 111 This is actually negative one In twos complement The hitch With using ones complement addition On a twos complement or regular computer Is that when you add up numbers In ones complement form If any of the bits overflow Into the carry field You need to take them back And add them to the low order bits That's probably a lot more than you wanted to know Or bargained for Hearing about ones complement addition It's really not that bad though So let's have a look Here's an example we're going to work through We're going to calculate an internet checksum The first thing you do When you want to send data Is you arrange the data of the packet To be sent in 16 bit words to sum up That's these four values that I've shown here That so the packet if you like read 00, 01, F2, 03, F4, F5, F6, F7 And I've just laid it out In these 16 bit words to sum Now we're going to add these together We'll actually put a zero in the checksum position here Just so we can have the same algorithm On the receive side And we're going to add all of these things together What do we get? Uh oh This is making me work hard Okay, uh let's see When we add up these numbers We get 10, we get 16 So that's actually um Is that right? Okay, so 16 is We get a zero here And we carry the one Here we'll end up with F And we'll carry the one Now we have 11, 12, 13 13 in hexadecimal is a D And here we have three Fs Which are all added up F stands for 15 in hexadecimal What we're going to get is 20 we're going to 2 And what's left over will be a D Now so we've got that sum Of course this left bit here Is overflowed from the 16 bit position So what we're going to do is Take that back And add any carryover back So we'll just take those higher bits D, D, F, 0 We'll add the 2 The 2 is moved down here When we do that we get D, D, F, 2 Okay now our final step Is to negate by complementing This value And then we'll get the checksum So we want to negate all of those bits Okay let's negate D If you remember If I do the binary representation Representation of D D is actually 8 19, 11, 12, 0, 1 That should be 13 When I bit flip that Flip I'll get 0, 0, 1, 0 Or 2 So when I negate that I'll get 2, 2 Bitflipping F is all 1 So when I flip all of that I'll just get a 0 And when I flip 2 I'll get a D So 2, 2, 0, D Will be the internet checksum And we will then take that value Replace it where we used all zeros And then send those 5 Including the checksum 16 bit words out into the network Okay it's all cleaned up here And thankfully I ended up with the right answer Now let's look at the receiving side What's going to happen Actually exactly the same algorithm happens We just want to make sure that we get 0 out When we've negated everything at the final end Let's work through it It should be the same steps Here we arrange the message in 16 bit words The checksum is there It's the last word It's non-zero Because it was calculated on the other side Now we add it So what do we get? Well before we have 16 plus D So that will be D We'll carry the 1 1 ff That will be We'll end up with an f And we're going to carry a 1 here 10, 11, 12 Oh guess what It's what is it there 13, 14, 15 So we have an f And we're left here with ff, ff2 So when we add that together to D We'll get 2f Okay now of course we've carried over So we've got to take this high thing And add it back So we'll just do this some ff, fd plus 2 What do we get? We get ff, ff Oh this is looking good When we complement that We get 0, 0, 0, 0 That's correct The checksum passes No error was detected in this packet And it's cleaned up here You can see I've highlighted it as good I already knew I got the right answer Because it came out as zeros So that's how checksums work What we need to ask though Is whether they're any good How well does this checksum work At detecting errors We could begin by asking What's the distance of this code Actually the distance is not so impressive This is a sum So if we want to get the same sum You can imagine just having errors In two bits of the data In one place we'll add a certain value Like maybe 16 to a 16-bit word And in another place we'll subtract a certain value Like 16, the corresponding value from a word Or maybe we'll add the 64-bit position Or so forth But the point is We could make two corresponding errors And fool this sum So the distance is only two Well rats This means that as before The number of errors we can correct is zero This is just error detection Not correction So we're not trying to correct anything But the maximum number of errors That we are guaranteed to detect Is actually one Two bits can fool this checksum Well has this gotten any better It has gotten better So if we think about larger errors What's detected here is going to depend On the structure of the code We will actually find all Bursts Burst errors Up to 16 So it's a 16-bit checksum A burst error is just a sequence of errors In a row Or a window of errors Where in that window Errors occur Maybe there are Maybe some bits in the middle are not flipped But over that window A small window in space The error occurs It's a burst error So it's an advantage here That if those errors occur In bursts of 16 or less And there's just one in the packet We're going to detect it Because if you think about it Those 16 bits can only be affecting One 16-bit world Or two adjacent ones In different places So they can't cancel out If there are much larger errors In fact if we just make up random data Then we will detect random data too Random with probability One in two to the 16 If we just make up data Random data Then there are six Since there are 16 bits There are two to the 16 Different possible checksum values So there's only one in a two to the 16 chance That the checksum will actually match the data So this is much stronger than parity So we have got quite a lot By going from checksums to parity It's really much stronger But it's not as strong as we would like things to be in practice For the same number of bits We can do even better with codes Which are called CRCs Or cyclic redundancy codes The way a cyclic redundancy code works Is you take n bits of data And then you generate k check bits So that when you add them together The n plus k bits are evenly divisible By what's called the generator C I can show you an example here with numbers So let's just say we're working with decimal digits The number I want to send is 302 And I'm going to send a one digit check So I'm going to send a message 302 Something We just want to work out what that something is We want to choose a something So that the whole number Including the end is evenly divisible By our generator here Which is just going to be the number three Well one thing I can do is I can just start with 302 Let's just add a zero at the end And let's just look for the remainder When you divide it by three That's equal to what Well the 3000 falls away 320 That goes 18 So we're left with two The remainder is two And you can see Since three minus two is one I'm just one short Have been evenly divisible So all I need to do is put a one here 3021 And send that That is evenly divisible by three And so I've computed that My check digit there should be a one The catch for CRCs Is that we need to do all of this Based on the mathematics of finite fields The binary sequences here represent polynomials So in fact this binary sequence here Represents this polynomial You can see there's a zero there For x to the zero or one There's one x to the one No x to the twos One x to the three One x to the four No x to the fives No x to the sixth And one x to the seven Boy this could be complicated What this really means If we're going to do a complication Ourself Which is a little horrible and grungy But we'll try and work through it Just so you can really get to the bottom of it Is that if we're going to do these CRCs ourselves We need to work with binary values And our arithmetic will be done modulo two So the same procedure for a CRC is as follows You take the data bits And really we're mimicking here What we did with our decimal digit example You take the data bits You extend them with k zeros Then you do a division by this generator value Once you do that You look at the remainder to see what it is Keep that ignore the quotient from the division And using this remainder You adjust the check digits By the remainder So that they will be evenly divisible The received procedure Is to simply divide the whole thing Including the check the CRC bits at the end The check bits at the end And once you've divided it Checked the remainder is zero If that's the case There'll be no errors in the packet Okay, let's try and work through this Here's an example We have a sequence of data bits here You can see I've written them Over here And we're going to divide by our generator Which is one zero one one That's the divisor here The first step And I have four check bits The first step is to add four zeros to the end Since I have four check bits Now I'm going to do a long division Wow, this might take a little while Let's go with our divisor and write it out So we're going to take away one zero one one Oh sorry, good grief No it's a one zero zero one one When we take that away what do we get? One minus one that's a zero that's gone One minus zero is one zero zero zero One minus one is zero zero minus one Sounds like minus one Which is actually one in modular to addition Okay, now I could write up the top Just that the quotient goes here For instance I got a one here when I divide it But we're not going to keep this anyhow So I'm going to ignore it I'm going to keep going on now taking things away So now we're down here And we're going to take values away I'll move down what we got here There's a one So again I want to take away one zero zero one one Boy we're in luck That's the same thing here So this is all going to go to zeros or zeros And now what we're left with is down here I'm going to copy down these digits Now I'll continue subtracting one zero zero one one from this And I'll get zero one one zero one And I've got another three zero zero zeros here Do it again one zero zero one one When I subtract that I get one zero zero one zero zero One more subtraction one zero zero one one Cancel cancel cancel cancel cancel I'm left with here one zero And that's the final remainder What I would like to do then is take that remainder And use it to modify the bits that are transmitted I would like to send zero minus that I would like to add zero minus that value So that it'll be evenly divisible What will end up happening is that Well basically because this is all modulo two End up putting this value zero zero one zero from the bottom Zero so these were zeros up here And then the checksum bits that we'll send out Sorry the CRC bits that we will send out will be zero zero one zero That's a little messy let me clean that up And you can see yeah here it is And at the bottom there is the transmitted frame You can see it's the data bits And now we computed our CRC to be zero zero one zero Great here there's also a little more information Like the quotient which gets thrown away And I've shown some other steps here Which were omitted in the middle Just so you can work through that And check it all if you would like At the receiver you do the division And you should get zero We'll skip that in the interest of time As with checksums Let's think about CRCs for the moment And just ask what kind of protection we get from them The kind of protection is going to depend on exactly What generator we used Now unlike the other schemes We're not really going to be able to work this out for ourselves CRCs are based on these mathematics of finite fields People have calculated over the years Good properties of different generators And in fact there is a standard CRC Which you'll see almost everywhere Even though better ones exist these days There's a standard CRC It's defined to be this number That's actually a polynomial If you write it out But this CRC is used on Ethernet Wifi all sorts of places This CRC I'm just going to tell you the properties Since we can't really work them out From first principles ourselves The hamming distance of this CRC is four This means it will detect all errors up to And including triple bit errors So any three errors One, two or three errors you're covered Four errors there must be some way to get around it It will also detect like parity Any odd number of errors In addition it will detect or burst up to k bits in error Where k here for a 32 bit CRC That would be 32 bits And it's also stronger than checksums In that it's not vulnerable to systematic errors Check sums because it's simply a sum If you were to do something like Insert a lot of zeros inside a packet You wouldn't alter the sum You wouldn't pick it up With a CRC if you move data around Or add zeros or splice things together You will pick it up And finally to wrap up Let's talk about error detection in practice CRCs the strongest form we saw Are very widely used on all sorts of different link layers They're used in Ethernet and NATO 211 as I mentioned They're also used over your DSL link Cable links and so forth They're an industry standard Check sums, you'll also find a fairly widely used in the Internet By all of the Internet protocols TCP, IP, UDP and so forth Compared with CRCs though While they're simpler to compute, they're weaker And I would hazard to guess That if the Internet were being designed today Stronger forms of checksumming would be used Finally there's parity Which says it's a good motivating example For us to work through But it's little used in practice Because we can usually afford More sophisticated schemes for error detection G'day viewers In this segment we'll talk about codes Which can be used to correct errors In messages received across links So the context for this segment Is the same as the previous two Which is that we know That messages can be received with errors Caused by noise in the physical layer What we would like to do in this segment Is devise codes So that we can look at the structure of the message The bits we receive And from those bits work out Not only did an errors occurred But guess what the message was Which was actually sent So this goes a step beyond Codes for simply detecting that an errors occurred And we will go through the example of hamming codes They're one of the simplest Realistic error correcting codes And then I'll mention other codes Which are used in practice Finally we'll talk about Why you might use detection Rather than correction Since it seems as if you could come up with codes For error correction Then you would want to use them Rather than detection Because they're stronger But it's not quite that simple Okay Well to get the ball rolling here Let me remind you why error correction is hard Now if we had reliable check bits That you could send To go with the data bits Everything would be much easier You could send that reliable information And use them to describe the structure Of the message and narrow down Where the error was in the data But of course there can be problems In all of the check bits In fact the error could be in the check bits As well as the data bits The data might even be correct That would be all we would care about If the error was in the check bits That would maybe throw us off We would think there was an error Even though we actually wouldn't Necessarily care about it Going a little further Just suppose for the moment That we could construct a hamming code With the distance of three That means that we would need at least Three single bit errors To transform a valid code word To any other valid code word If we then have a single bit error That will be closest to a single Unique valid code word So if we can assume And here's one of the key assumptions If we can assume That the errors we will see in practice Will only be either zero or one bit Then we can correct errors By mapping whatever bits we received To the closest valid code word This argument also generalizes To work for correcting D errors If you have a hamming distance of 2D plus 1 Here's a diagram That helps us visualize this intuition You can see here in this code The pink circles represent a valid code word So the data bits and the check bits match Whereas the gray circles here They represent an error code word Where you've got a bunch of bits in But the data and the check bits don't match This code has a hamming distance of three Because we need to go at least three hops Which is changing three bits To get from any valid code word To any other one Here's another one Now let's look around A This circle This is the code words Which are within a single bit error of A What we will do for correction Is when we get in a code word Such as this one here We will say This is closest to A So therefore I'm going to correct that By saying A would be sent You can see that that must be the case If we got either zero or one error Because there's no other way That we could have got from a valid code word To be so close to A This slide just cleans it up a little bit So you can see it a little more clearly Okay so hamming codes Give us a way of constructing this code With a hamming distance of three And also an easy decoding method Which will allow us to do the correction And move to the closest valid code word In a hamming code There are parametrized families So if you pick a K for a number of check bits Then you can look out in How many data bits go with that Using the expression two to the K Minus K minus one If I have K for three for example Then I will end up being able to Send up to four data bits The way a hamming code is constructed Is you take all these bits in the code word together And you lay them out Putting check bits In any position P there is a power of two Starting your numbering from one The check bit In the position P Is then a parity sum Over all of the positions Which have a P term In their binary values When you write them out Okay that's all big mouthful Let's work through an example To see how it goes Okay now here we have some data The data is zero one zero zero We're going to use three check bits So we have seven bits all together They're shown at the bottom here Let me just write in The parity bits Or check bits and the data bits Parity will be in positions That are powers of two So that's one Two And four These are going to be the check bits The data then will go elsewhere So if I write the data in Left to right I've got a zero One zero one Now let's compute some of these parity sums Check position one Covers Sorry the check bit in position one Is going to cover all other positions Which have a one in their binary expression That's going to be one three five and seven That's P one We can ignore the one itself Because there's nothing in it yet We're going to add it the three The five And the seven Zero plus one plus one is equal to zero We'll put a zero in here Check bit two Is going to cover positions with two bit In the turned on in the binary expression That'll be two and three and six and seven The parity sum here two and three is zero Six and seven is zero One that's equal to one So we'll put a one here Parity bit three Is going to cover positions Where there are is a four in the binary expression So that is four five six and seven So if we add those together One and zero and one we get a one So I'll write a one here This then is how we constructed a code word For that particular data in the hamming Code with four data bits and three check bits And that will then get sent out the wire Okay here's a cleaned up version of that And I think we have our Parity sums are right Do we know one zero one Oops no I didn't Flip back one plus zero plus one that is a zero So parity bit three in the fourth position here Should have been zero Okay now we have that right Moving ahead the hamming code gives us a way to decode these codes What we do is we proceed by recomputing all of these check bits Using the same parity sums Now including the check bit parity value itself Because there's a value in there We then take those check bits and arrange them as a binary number And look at the value this value is called the syndrome This value will tell us the position of an error If it's zero there's no error If it's another number like three for instance Then the bit in position three is wrong And we should flip it to correct the value Wow it's pretty cool that this works out This was all worked out by Richard hamming And you can read about it in this paper that I mentioned In a previous segment So we're going to try and work through an example Okay here is the code word just that we had from before With all of the parity sums computed Let's uh let's recompute the parity bits Parity bit one we're going to add positions one three five seven And that's equal to zero parity bit two We're going to add two and three And six and seven That's a zero Parity bit four we're going to add positions four five six and seven That's a zero plus one plus a zero plus a one And guess what that's a zero Our syndrome is zero zero zero So there's no error Yay Then our data is what we get If we take everything but the check bits We see it is zero in position three One in position five zero one in six and seven Here's a cleaned up version On the other hand we might actually have had an error during transmission We want to correct it that's the whole point So let's check to see that this method actually works Parity sum one we add up positions one It's a zero three five and seven We get a zero parity bit two We add up positions two and three And six and seven That is a one Parity bit four we add up positions four five six seven That is also a one Okay, what's our syndrome then The lowest order digit is parity bit one In position binary at the least significant bit That's a zero ahead of that we have a one and a one Or six the binary representation of six This means that there is an error in position six Or which we can see is right So we're going to flip that The data that we get then is a zero A zero a one sorry a zero and a one A zero and a one That's what and that's what the real data should be Yes and we can see here that it's correct After we've flipped the bits Now the bad news here is that the error codes for correction Which you use in practice are generally much more complicated Than the Hamming codes Hamming codes are useful but they're fairly simple Some codes which you widely used in practice are convolutional codes They tend to take a stream of data and they output a mix of bits at all positions This mixing process makes the output bits less fragile They're decoded with what's called a Viterbi algorithm Which has the advantage that it can use the confidence Information from the bit values from the physical layer So we can know if some signal was really high and it really looked like a one Or if it was close to 5050 and maybe it was a one This turns out to be useful There's another kind of error code Which is widely or which is becoming widely used in practice And that is the low density parity check code Low density parity check codes are based on the mathematics of sparse matrices And they're decoded iteratively using what's called a belief propagation algorithm This is the same algorithm which is used in machine learning All comes also comes up in communications Their state-of-the-art codes today and they're increasingly being widely used An interesting side note is they were invented by Robert Gallagher One of the pioneers of network on the theory side As part of his PhD thesis in 1963 And then they were promptly forgotten for more than 30 years Put aside until they were computationally more viable Because they do involve a fair amount of computation And now those codes are all of the rage I can also talk briefly about error detection versus correction Let's consider a hypothetical example What would it be better to use? Error detection or error correction for a particular example It's going to turn out that which one we want to use is going to depend on the kinds of errors The patterns of errors we're going to correct But suppose you have bit messages which are 1,000 bits long And you have an average bit error rate or BER of 1 in 10,000 That means on average one bit will be an error out of 10,000 bits over a long-term average What should we use? Detection or correction? What do you think? How would we even go about working this out? Really we would like to use the scheme which has least overhead That will be a measure of goodness But it turns out that we can't work it out yet We actually need to know more about what kinds of errors would actually occur So I'm going to posit two different models The first model for our errors is the random 1 in 1,000 bits are erred at random Well this means sorry 1 in 10,000 bits are erred at random This means that any message is likely to have 0 at most 1 errors Most of them have 0 Now to do error correction To handle about 1,000 bits If you go through some of the hamming expressions from before You'll find that you need about 10 check bits to be able to correct a single error So the overhead here per message is how we'll work it Would be simply 10 check bits 10 bits On the other hand that's for error correction On the other hand suppose we used error detection In this case we would need only let's say 1 check bit To detect that there's an error Because we could use a simple parity bit if we're going to have 0 or 1 bits wrong But then of course if there was an error And this will happen maybe a tenth of the time If messages are 1,000 bits and we're going to have an error every 10,000 bits or so Then a tenth of the time we're going to have to retransmit that message And we all have to send 1,000 bits to retransmit it And this is a rough approximation But this is going to get us close enough The overhead there will roughly be 1 check bit plus 1,000 bits A tenth of the time that's 100 Just call it 101 check bits Wow well that's a lot of overhead So we would be paying a lot of overhead to detect those errors For the random error case where errors occur It seems to be better to use error correction On the other hand here's a different model Let's assume that errors come in births of 100 Well in this case Rather than having one in every 10 packets Likely to contain an error We're likely to have not one in every 10 But one in every 1,000 packets have an error Or maybe two out of every 1,000 If those 100 bits are spread across two packets So errors are going to be rarer In terms of packets or frames But when they occur boy it's a big error If we use error correction You've got to send the correction on every frame Just in case it's in error How many bits would we need? I don't know how many bits you'd need to correct An error that's that large 100 births of 100 bits Let's just say you need at least 100 bits of error correcting code To be able to correct 100 bit errors Probably a lot more What about for error detection? Well we would like to be able to detect Something that's gone wrong Even when there are 100 bits in error How many bits to do that boy we need? I'm not sure Maybe something like 32 Because then we would have the probability Of 1 on 2 to the 32 That something's gone wrong That's quite small That's basically 1 on 4 billion Of missing an error If there's a nice random error So 32 might do it there Plus of course If you actually do get an error You'll need to retransmit it So we'll need to send 1,000 bits again But we'll only need to resend these bits 2,000ths of the time So we're going to need our overhead here It'll be 32 plus 1,000 divided by 2,000 So 1,000 divided by 1,000 times 2 So that's 2 That's about 34 bits You can see that the overhead here Is mostly error detection code Not the retransmissions So in fact for this case Error detection turns out to be better To summarize that point Error correction is most useful When the errors are expected It's the normal case Or as an interesting aside They're also useful when there's no time To do a retransmission Because you need information to live it quickly Error detection on the other hand Is usually more efficient When errors aren't the expected case So sending long error correcting code Information would just send more bits Which are wasted Or when errors are large When they do occur Because in that case You would need an awful lot of error correcting code bits To be able to deal with them And finally Let me tell you a little bit about error correction practice We find that error correction Is heavily used in the physical layer Usually with advanced codes Like the low density parity check code That's becoming common Older convolutional codes In fact widely used in practice But LDPC is going to be the code of the future For all sorts of uses Wi-Fi Digital television Fourth generation cellular And so forth And that's because errors are expected The normal case in the physical layer And we'd like to throw some machinery at correcting them On the other hand Error detection is widely used With retransmission techniques Above the physical layer So in the link layer and above In the transport layer too This kind of mechanism Is really about dealing with residual errors Once the physical layer has got a lot of them down We'll also see much later on perhaps That correction is also used in the application layer When it's used in this context It's often called forward error correction This usage also has a different kind of error model Usually at the application level If you're correcting errors You know when you've lost bits Maybe you would lose a whole frame And stripe your information across multiple frames And want to correct it This error model is called a narration model But previously we didn't know If there was an error Which bits there were in Now here you know that there's an error in a bit And you don't know what it is This is actually very close to the setup That's used for codes that you might have heard of Like read Solomon codes Which are used widely in CDEs, DVDs and so forth So that if you were to lose some information on the disk Due to a scratch or something You could correct the Use an error correcting code To work out what the information was So that's error correction Now you know something about how to Correct, detect and correct errors In messages that are sent across the network Good day viewers In this segment I'll give an overview of the link layer To remind you where we are in the course Okay so here's our layered protocol stack And if you recall We've already done the physical layer We've talked about that Now what I'm going to do is Finish off the link layer Which builds on top of the physical layer To be able to send frames Individual units of information Across a link between computers Now we've already covered some of the Different techniques and problems And solutions that you find in the link layer In particular I've already talked about framing Which is the ability to delimit the start and end of messages So we can send complete units of information Called frames across a link And we've also talked about error detection and correction Which allows us to handle some kinds of errors As information is sent across links When you put these topics together We've actually seen quite a lot of the link layer For instance they allow us to construct A DSL link That's something that many of you might be using right now To access the internet from home And we can understand the techniques Which make a DSL link work What we're going to do now Is go beyond that and cover these three topics To round out the link layer These are actually three pretty exciting topics The first topic is that of retransmissions Which allows us to handle links where loss is quite common This is the case for many kinds of wireless links Such as 802.11 Without a mechanism such as retransmission Many frames would be lost as they're sent across the link And the network as a whole would become inefficient So we're going to want to retransmit information To get it safely across that link The second topic we'll cover in this unit Is multiple access In the links we've looked at so far There are two ends and one end just sends frames And they arrive at the other end But sometimes you can have multiple parties All of whom want to access the one link Just think of an 802.11 network Where many different clients, maybe more than two Maybe ten want to talk to the same AP That's a single wireless link And we need some multiple access scheme To coordinate the way in which these different users Will use the link We'll talk about classic ethernet schemes And also 802.11 will appear again And in the third topic To round out the link cloud Talk about something called switching Switching allows us to use boxes called switches Unsurprisingly To combine individual links together Into something that really looks like a much larger happy link That connects a host to all of the other hosts On the switch network It's used to build something called modern ethernet Actually by the time we've seen all of these units We'll know quite a lot about how to build networks For instance, we'll know a lot about how 802.11 networks work And we'll also know a lot about how modern switched ethernets work These are the garden variety wired networks that you find If you go to any enterprise or campus and so forth And ask to look at the network Okay, so let's get on with it G'day viewers In this segment we'll talk about retransmissions As a strategy for handling errors Okay, so just as a bit of context We have two general strategies Which we'll use to correct errors in networks The first strategy is to detect that an errors occurred Say with an error detecting code And then retransmit the information across the network We've already seen the error detecting code So now we're going to focus on the retransmission Half of this strategy The overall strategy goes by the name of ARQ Somewhat archaic name It just stands for automatic repeat request But we can just think of it as retransmissions The second strategy is to correct errors with an error correcting code Send enough information as part of the message That the structure can be checked And any errors that occur on the way can be corrected We've already looked at how this strategy works As part of our exploration of BellinClayer And I'll give you just a little bit of context On reliability in general before we jump into retransmissions An important question for us to consider Is where in the stack we should put reliability functions Well we have a whole stack here Should our reliability functions for dealing with errors Got the physical layer The link layer The network layer The transport layer or the application layer What do you reckon? Five different choices The answer Is essentially that reliability functionality Should go everywhere in the stack Reliability is one of those key issues for networks Networks have to be able to deliver information reliably And to support that each layer will do its part The key issue here really is How each different layer should contribute to the overall reliability What we will find is that at the low layers of the protocol stack Like the physical layer Error handling functionality will mostly be there to mask errors As we saw with an error correcting code This is often as a performance optimization Looking at retransmissions at the link layer is again about masking errors If retransmissions occur as in Wi-Fi The higher layers like TCP will never know that there's been a loss They won't have to worry about it The error will be masked And this will generally improve performance On the other hand All the protections we like at the low layers Won't stop things going wrong at the higher layers Maybe a sending application Can't connect to the right receiving application Can't find the right path through the network Or a message is received which is unexpected on the other side No amount of scrubbing the bits as they go over To detect and correct any transmission errors Will handle these scenarios So the higher layers of the protocols Will also need their own functionality to handle reliability This functionality is mostly then concerned with correctness And usually recovery actions Rather than performance and masking errors So that's reliability in general Let's go on to ARQ ARQ is used in Wi-Fi And we'll also see it in TCP It's used where errors are expected Or they're common enough And they need to be corrected In Wi-Fi it's because it's wireless And there's a lot of loss So packets might be lost In TCP it's because packets might be lost In the network due to congestion We'll cover TCP later Now we're really just talking about the link layer But much the same mechanism is used The rules for ARQ are fairly simple At the receiver All you have to do is automatically acknowledge correct frames And what an acknowledgement means Is that you will send a short packet From the receiver back to the sender This short packet is called an act Short for an acknowledgement The sender, the rules of the sender Is simply that you automatically resend the frame If you have not received the act After a certain time period This is called a timeout So a timeout essentially means That the sender hears no act Within a certain timeout If that's the case The sender will automatically resend Here we can see how ARQ works Let's just go through some examples This is the normal operation case And this is a, well, no packet loss No frame loss occurs And this is a new kind of diagram for us This is a time sequence diagram The sender and receiver are both shown as vertical lines In this diagram time runs down the page So I'll trace over the action on the diagram Two things really happen here The sender sends a frame to the receiver Here we go The arrow slopes downwards Because sending takes some time So time passes to send this message across the network But at any rate the receiver receives the frame And it sends its own message and act Back to the sender to say, yep Got a good packet there This act is received before the timeout period passes So the sender doesn't need to resend Everything's good The frame has been transferred across the network And no retransmissions are needed Here's the loss and retransmission case The frame is sent Something happens Doesn't make it to the receiver correctly After a certain amount of time passes The sender says, hey, what's going on here I know something must have gone wrong And it automatically resends the message To the receiver This time the message gets through The receiver sends an act back And I guess that is before another timeout passes That being the case Both sides are happy This could go on if the more frames were lost The sender would repeat again and again and again Now there are a couple of things we might note about this diagram First you might actually wonder how it is that a frame can be lost inside a link I mean what happens? Does the signal just get tied and stop propagating? No, the signal continues to propagate Two things could happen The frame could make it to the other side But an error could be detected Because some of the bits were corrupted When this happens It's normal for the receiver to throw the message away And not take any action Because it's uncertain what the correct message is So this could look like a message disappearing Even though it really reached the receiver However, it's also possible that the receiver will not even see the message This could happen if the transmission error is severe enough That say the framing was affected In this case the receiver might not even find the starter frame So it might not even detect that there is a frame there This would look like a frame has been lost inside the network A second thing to note is you can see why ARQ In the simple form here is normally done by having the sender automatically Resend a message It's difficult for us to have the receiver send a message to the sender saying Hey, you know, could you send that again? Here the receiver doesn't even know that it's missing a message It didn't even hear something So it's in no position to request it again Even if it did The ARQ is just another frame It could get lost So the sender might not hear the message to resend So this is ARQ ARQ looks fairly simple as a mechanism Once you get it, you just automatically resend But you know, a funny thing about network protocols Is that there can be some quite subtle interactions And that's also the case with ARQ We'll find this a lot for network protocols With ARQ there are two non-trivial issues that I'm going to talk about The first is this timeout What should the value of the timeout be? We've got to pick something How long should it be? And the second is actually a more serious issue About how to avoid accepting duplicate frames as new frames If the sender sends three frames Three different frames across the network One, two, three Maybe with some retransmissions We would like the receiver to receive the same set of frames In the same order One, two, three It's no good if the sender sends three frames From a higher layer It passes them over the network And the receiver thinks that four frames have in fact been sent across the network This could really muck with messages if they were transformed In some ways they went across the network We don't want that to happen In fact, what we want to happen for ARQ Which we also usually want for many protocols Is we want performance in the common case All right, so performance is linked to the common case But we want correctness always No matter whether our performance is good or bad We want this protocol to be correct So let's look at these two issues Timeouts Okay, well the value of the timeout is one of these Not too big and not too small kind of issues We don't want it to be too big Because if it is too big We'll sit around twiddling our thumbs for a long time The link will go idle and we'll be wasting network resources If it's too small The ARQ will be on its way But we'll panic a little early And we'll go ahead and resend a packet or a frame This is also a waste because we could have sent a new frame Now, coming up with a value for this timeout Is fairly easy on the LAN In the case of most links And that's because for a LAN like a Wi-Fi There's usually a clear worst case In the case of Wi-Fi, for instance You know about how big the network can be So you can work out the maximum propagation delay Wi-Fi also has rules that are a sender Sorry, a receiver needs to send an act within a certain time period So we can usually bound pretty well when an act will come back And that's the case for most links However, timeouts are actually much harder When we're talking about sending across the internet as a whole And timeouts in the case of ARQ being used at the TCP level And this is because there's a lot of variation In the amount of time it can take to use a path across the internet You could be sending next door or to the other side of the world There can also be variation due to other traffic effects on the internet So it's very hard to predict We'll revisit this topic later For now, we'll mostly ignore timeouts and pick a value that's about right Just to make the performance good Okay, duplicates is a more thorny issue Let's see what happens if an act is lost Okay, here's our frame being sent The act comes back, the act is lost What's going to happen? The sender will not see anything And so after the timeout period, the sender will send the frame again The receiver will see it and send an act Great, looks good Except What happens at the receiver here? We get another frame The receiver has no real way of knowing what this frame is Is this a new frame? As far as the receiver knows, it might well be If that's the case, the sender will think it's sending one frame The receiver will get two frames and the network has gone astray Here's that diagram cleaned up Similarly, what's going to happen if the timeout is early? Here's our frame being sent Our act coming back, but just a little late The timeout goes off here So we will send the frame again And the receiver will receive it and send an act Again, what's going on here? As far as the receiver is concerned We've got another frame here A second frame, this is probably the next frame It's a new frame, but it's not Because of the spurious timeout And that diagram's cleaned up Okay, we need to fix this problem To ensure that the retransmission mechanism is correct To do this, it turns out that it's required That both frames and acknowledgments carry sequence numbers The sequence numbers, we're going to check them As part of our protocol, the receiver To make sure that we've got the right frame And the protocol is operating correctly Now, it turns out that in the protocol I'm showing you Where the sender's only sending a single frame at a time And resending until it gets through We only need a flag, a single bit To indicate two different states or two numbers To distinguish the current frame that's been sent From the next one That's going to be sufficient The name of the protocol in this case Is called stop and wait Let's see it in action So our two states with a single bit We're just going to call them zero and one We're going to alternate packets And number them zero and one, zero and one So here's how it would work This is a frame F for frame We'll call this one zero So I'm going to get an act for that I'll call that A zero Okay, the sender will now advance to the next frame It will send F of one And we'll act A of one You can see here at the receiver First of all we get frame zero And now down here we can see this is frame one We have some way to distinguish these two So here's this cleaned up And you can see I've added the timeout Just to show it's the normal case Let's look at some of the problematic cases from before Here's the ACLOS case So what's going to happen when we have ACLOS? Well after the timeout The sender will resend Now since it's a resend It is sending frame zero The receiver will act Act zero Here The receiver received frame zero Now it is receiving frame zero again So the receiver is clear That this is a resend Yes, got that one right Always comforting Okay, the other case A spurious timeout The timeout goes off a little early We'll send frame zero We're going to act Frame zero The receiver Here it got number zero When here it can see it is a resend Wonderful You'll also note over here The sender is going to get another ACLOS for frame zero Oh okay, that's fine I guess that's what it expects since it's sent two The receiver Sorry, the sender here does not actually know whether here is first ACLOS It probably thinks this ACLOS could be in response to the second time it's sent It's just got a very short timeout For all it knows the first frame was lost And the second frame got through and produced this ACLOS It can't really disambiguate these cases And it doesn't matter A protocol is correct in either case Even though the sender and receiver Don't necessarily know what's going on That's all of the subtlety and the design of the system So here's a cleaned up version of that figure And now you've seen stop and wait ARQ and all other rules And this is basically the protocol This is how it works And you've seen the different cases Before we finish I do want to tell you about one limitation of stop and wait Stop and wait allows only one frame to be outstanding from the sender at a time That is the sender tries to deliver its frame Resending it until it's there Before it moves on to the next frame That is effective for a LAN And it's used in Wi-Fi But it's not effective for networks That have a high bandwidth delay product That's what BD is Let me just write that Bandwidth delay And the reason for this is Because with a high bandwidth delay product Many packets could fit on the network at one time But with stop and wait we'll only send one Let's see an example Here we have a picture of a network Where the rate is 1 megabit per second And the delay is 50 megabits per second That means that the round trip time Or the time taken to send a frame across And receive a reply is going to be 2D Or 100 milliseconds How many frames could we then send a second? We could send 10 frames a second And if you imagine a frame is roughly 10,000 bits That's about 100 kilobits per second Hmm, that's not so great considering we've got a megabit per second link 10 times as fast What would happen if we raised the bandwidth to 10 megabits per second? The rate of the link Well actually you wouldn't be able to send any faster With stop and wait you can only send up to 10 packets a second over this link So the maximum throughput you can achieve Is 100 kilobits per second No matter how fast the rate is Wow, that's not so good The generalization of stop and wait Which handles this problem Is called the sliding window algorithm The sliding window algorithm allows up to W frames to be outstanding What we want to do is set W, the number of frames outstanding To be roughly twice the delay Expressed in packets Twice the delay is also called the RTT Where RTT stands for round trip time That's a useful thing to know And if that's the case, as you can see from the figure here We'll have multiple packets in the network going across and the X coming back And this traffic will keep the network busy This is what we will use when we get to the transport layer in TCP Because the bandwidth delay product is higher than it is for most links like a Wi-Fi And when we get there we'll see various options For handling the way we number frames, X and so forth But there's no need to go into all of that now We'll look at that later And for now you know how ARQ and retransmissions work with stop and wait G'day viewers In this segment we'll talk about multiplexing schemes Which allow the bandwidth of a link to be shared Okay, so recall that multiplexing is just the fancy network word for sharing The classic scenario is sharing the bandwidth of a link amongst the different users I'm going to talk about two different methods Which you use to do that Time division multiplexing and frequency division multiplexing Here we go Okay, so in time division multiplexing this is simply sharing over time Different users take turns on a fixed schedule at different times So you can see here we have traffic coming in from three users on the left And a portion of the traffic is taken from each of those users in turn So this diagram is showing the evolution over time Of how the users are sharing one link or a channel You can see one user here in the pink user two gets to send some information at the beginning Then the user has to wait and gets to send no information while users three and one send And later user two will get to send again, gap And then later user two will get to send again And this is our regular schedule that we follow There may be a very small gap between these transmission times These transmission times called the guard time just to allow for a transition from one source to another Conversely, in frequency division multiplexing The user shared the channel by transmitting simultaneously on different frequency bands So this picture shows the way the channel is divided in frequency Each of these users has about the same amount of bandwidth to send The middle user, the bandwidth profile is shown in pink And you can see that for all of these users they have about the same bandwidth requirement To share according to frequency division multiplexing We just shift the frequency band on which the user is transmitting to a different portion Of the overall channel The width of the frequency band describes the amount of or limits the amount of the data rate With which the user can send Moving this band round in absolute frequency space Does nothing to the data rate It keeps it the same As we add all of these different transmissions together onto the same wire You can see here that we have three channels in three different frequency bands Which correspond to the original transmissions So now we're sharing the channel in frequency space That might be a little strange to get your head around So let me just draw the time evolution of how we're sharing the channel With TDM if we just consider one user What's happening is that user gets to send at a high burst They get the whole channel Like user 2 gets to send all of its bits at the whole channel rate Then they get no bits per second for a while while other people send When it's their turn again they get to send at the very high rate Then no bits per second High rate No bits per second High rate and so forth So their evolution of their bit rate over time looks something like this On the other hand with frequency division multiplexing All users are sending in parallel At their lower bit rate on the channel By simply dividing the channel into different frequency bands So the same user will have a bit rate like this It's continuous but at a slower rate Time division multiplexing and frequency division multiplexing Are simply alternative ways to divide the resources of a link Neither one is inherently better Neither one provides for more capacity They do have some trade-offs You can see here in time division multiplexing It's a little more complicated in the sense that we require synchronization Of where to send This is just one user so the other users have to fit into these time gaps In the middle On the other hand with time division multiplexing When you get to send You're sending the information at a faster rate So if the information arrives from an upstream link Just at the beginning time, just here Well the delay will be lower because it will go out at a faster transmission speed So there are maybe a few minor trade-offs But there's no inherent difference in the capacity we're getting Here's that cleaned up version of that diagram So time division multiplexing and frequency division multiplexing Are typically used in telecommunications To statically divide the bandwidth or the resources of a link They're well suited for cases where traffic is continuous And there is a relatively fixed number of users So classic scenarios for using these techniques Would be with for example, television or radio stations These stations might always transmit You could allocate them a different frequency band They can all send in parallel on their different frequencies And the spectrum is used effectively This is good With cellular systems such as the GSM Is a second generation cellular system One of the most popular cellular systems still deployed today Is we transitioned to 3G cellular systems Calls in GSM are allocated on different frequency bands So we're using frequency division multiplexing to divide the spectrum Within each different frequency band Time division multiplexing is used to give many different calls A slice of that band at different times So these methods can be combined However, there's a problem for the kinds of traffic we would like to handle Network traffic And the issue is this Unlike a radio station or a TV station Which is constantly putting out a signal Network traffic tends to be very bursty It's described as an on-off source If you just think for a moment about your own network usage At home you might be looking at a web page Surfing the web So you're demanding that the network send lots of packets To download the page Then you'll read the page While you're doing this Of course you won't be using the network at all perhaps You will be imposing no load on the network So there'll be a short pause Then you might do something And there's a burst of activity again and so forth In short, the load in data communications networks Of a particular user Usually varies greatly over time If I just make up Here are different users User 1 and User 2 These are completely hypothetical as examples Here's a profile for user 1 Maybe this is the different rate At which they send traffic over time Sometimes they're very busy Sometimes they're not so busy They're not doing much And User 2 We could see they might look like this Okay, that's just an example What does it mean? Well, it means that methods such as time revision multiplexing And frequency division multiplexing Which are geared towards continuous traffic For a fixed number of users are not very effective To serve these users well in the network We would need to allocate a bandwidth level here R Which corresponds to the amount of bandwidth they'd need When they actually need the network If we have to pick one level We want to pick this level If we picked a much lower level Then they wouldn't have enough bandwidth When they actually wanted to use the network But of course the difficulty with this level Is we're wasting all of the bandwidth I'm shading in the portion here Which is not being used at any given time That's a waste This is good bandwidth We'd like to get something out of it Instead, well there's an alternative That we would like to get to When we multiplex network traffic And that is We would like to multiplex network traffic According to the demands Which every user is placing on the network And we can do this with what is called Multiple access schemes We would really like For these users to share a link Whenever they want to send packets They get to send packets And all of their packets are mixed up On the link according to their demands To do this We would get the gains of statistical multiplexing Remember from early on in the course We talked about sharing based on statistics As being a way to pack more users Into a given amount of bandwidth You can see that here In that I have the two users They both need bandwidth R But if I combine their signals I might get a load line Like this green line Which I'm drawing over Well, the amount of bandwidth We need to support that Is going to be some level I've called here R dash The main site is that R dash Is likely to be somewhat less than 2R So by using less than the bandwidth We would need if we handled these users Individually with TDM We should be able to serve them Both of them as effectively This is what we want to happen We don't know how to do this yet TDM and FDM don't do this Instead multiple access protocols Share this link at a fine By dividing the bandwidth finally over time We're going to look at these multiple access protocols In the next videos We're going to look at two families Of multiple access protocols One is this class of Randomized multiple access protocols Where nodes randomize their attempts To access the medium Essentially they're going to try And access it whenever They've got something to send This is good for low load situations And I'll tell you now This is what's used For a Wi-Fi editor 2.11 We'll also look at an alternative Just so you can see Some of the pros and cons This alternative is called A contention-free multiple access protocol In this family of protocols Nodes take turns In a well-defined order To access the medium So it shows you just A different way you can do things It's better where you need Much more control over The quality of service you'll get Okay, well let's see These two different kinds Of multiple access protocols Today viewers In this segment We'll talk about Randomized multiple access Control protocols Okay, so that's a mouthful of a phrase Randomized multiple access control But the topic is a fundamental one And also an important one In computer networking The issue is simply this We have multiple nodes A set of nodes Who want to share a link How do they do it? When they have traffic to send Who gets to send when? This is a scenario That comes up in Wi-Fi For example When you might have multiple access Sorry, multiple laptops And they would all like to talk To the one access point How do they decide Who gets to send when? We've looked previously At multiplexing schemes Called TDM and FDM Which divide up the link In terms of either time or frequency They're well suited For continuous traffic But not very well suited For computer networking Where the traffic is bursting So in this segment We're going to start looking At alternatives To do that We'll use the simple model That's shown here Where we have The multiple computers Just all attached to a single wire So if we wire them together They can all talk over that wire And we have the multiple access problem Of deciding who gets to use the wire when Now, like many networking issues Protocols This actually turns out to be Quite a subtle issue In many ways The designs you come up with Can have strange effects Strange side effects One of the key things Which makes this hard Is that it is a distributed system All of the different nodes there Get to see what they can see Locally attached to the wire So they can send and receive messages To other nodes But they have no overall view Of what's going on in the system And there's no one in charge There's no special party If there's someone in charge Like you or I And we can look at this network And see what's where We can organize things fairly easily But we're now trying to solve A multiple access control protocol Without that central view That's what's difficult Okay, so the schemes we'll explore Are a family of Randomized multiple access control protocols What does this mean? It simply means that they use Randomization to handle Some of the difficulties Like collisions When multiple nodes Try and send at once Randomization Or randomized Multiple access control protocols Are the basis for Classic Ethernet This is one of the most Successful networking technologies Of all time That we'll learn about And before we dive into it I'll remind you of the central problem here Which is that we want sharing While the data traffic is bursty In this figure, for instance These nodes of these nodes The middle one looks like it's asleep The one on the right Maybe occasionally sending A bit of traffic But not much The one on the left is very busy If we use TDM or FTM To divide the link up Into three different parts The one on the left Would only get a third of it The other ones aren't Really using their share What we would like to do Is statistically multiplex These demands So that the one on the left Could use most of the wire While the middle one's asleep And the right one's not using it much So let's see how that works Well, our story For randomized multiple access control protocols Actually begins in the Hawaiian islands In the late 1960s In this setting A new kind of way Of multiplexing a link was developed Rather than use TDM or FTM This new protocol was devised By a guy called Norm Abritsom The setting here was That we have all of these different islands Hawaiian islands They have a wireless link The islands want to send to one another They're distributed How do they decide Who gets to send when And let's not use Simple TDM and FTM Here's the protocol Like many things It's a very simple idea It works like this The Aloha protocol When a node has traffic to send Guess what, it just tries to send If you send successfully You're going to end up Getting an acknowledgement back Of some form I won't go into all of the details here And then that means Everything's okay It was received If you don't get a knack That means there's been Some collision Maybe two nodes Have tried to send it once So all you do Is you wait around In the amount of time And try again That's it A very simple protocol What could possibly go wrong Here's how it works Just as a bit of a diagram You can see we have Five different users here And they're all sending packets over time If we follow the protocol They'll all just send When they have traffic to send Now if more than one of them Sends at the same time The signals will superimpose We won't be able to receive it Correctly There's a collision And it's lost So you can see here Several packets Are involved in a collision Over this time We know Some portion of the packets Have been transmitted At the same time And also over here However Even though Some of these frames are lost Many of the other frames Get through Okay So is this a good idea Or a bad idea You can think about that For a minute And I'll tell you the answer Actually It's a pretty good idea on the whole Or at least a reasonable one It's a dead simple scheme It's fully decentralized There's no central point of control Here that can fail Or is required for the system And it works quite well Under circumstances of low load Where the link is not busy Most of the time Now for many networks Low load is actually A common case We might have many computers But often they're really Not doing anything much With the network At least they used to Before we have all of these background processes Under low load Well If the network's mostly not being used And someone has a packet to send They can just go for it It works So it's relatively effective Under low load Of course The problem is When you really want to use it And multiple people want to send Which is basically a problem It's not efficient then You'll get collisions You can actually do some Randomized analyses Of this And if you dived into all of the details You'd find that The most efficiency you could get In terms of The fraction of the link That's successfully used To transfer packets Topps out at about 18% So we've wasted More than three quarters More than four fifths Of this link Its capacity That's not so good You can actually come up With some improvements here If you slot time So all packets begin On regular boundaries It turns out that you can double The efficiency from 18% to 36% And the reason for that is Now collisions are all or none You no longer have a packet Or a frame that's mostly made And then at the very end Someone just clips the end of it And the whole thing is ruined But rather than look at that We're going to look at Other kinds of improvements To turn this into A much more effective protocol And the place that I want to get to Is so that you understand The design of something called Classic Ethernet Ethernet was invented By Bob Metcalf In the, let's see, in 73 The early 70s here It became really the most popular Land, local area network Technology of all time So in the 80s and 90s It was very common to see Ethernets deployed in buildings And it worked like this Essentially all of the different Computers here were wired To the one cable which sneaked Around the building And connected all of these together It was, you know, usually A 10 megabit per second cable Somewhere near the beginning All the nodes really have to do Is solve the multiple access control Problem and then they can All talk to one another So to do that We're going to improve on Aloha in several ways Let's look at those improvements The first way that Ethernet Improves upon Aloha is With a technique called CSMA The carrier sends multiple access This simply means that a node Should listen to the medium To see if it's busy before It sends its frame It sounds like rather An obvious technique But it's not quite so obvious In the sense that it's easy To engineer with wires And so Ethernet does it In a wide context But it's actually more involved In the case of wireless As we'll get to in the Subsequent lecture Okay, so our technique is now Simply to listen Before we send packets And the question I have for you Is whether this is in fact An eliminate collisions completely Let's think about it for a minute If every node listens before it sends Will this eliminate collisions? Why or why not? Well actually it doesn't Eliminate collisions completely Now many people When post with that question Will say well it's still possible If two nodes send instantaneously To have a collision If they send it the same instant Even if they send it slightly different times A collision is possible And the reason for this The intuition is that it takes time For these frames to propagate Along the medium So for instance Here's what could happen Well actually it's possible For both of these nodes Here's one on the left We have our three nodes In a network This node to listen Let's see is there anything here No and start sending a frame At the same instant in time This node can listen Is there anything here No and start sending a frame Now this can happen Because it takes a finite amount of time For the frames to propagate From one end to the other And cause a collision In fact that time To propagate is D Our delay Here's a picture of that You know once again Just the two nodes both Here does idle both send There will be a collision It just hasn't happened yet So it turns out What we're really saying here Is to remember the bandwidth delay product Which is a measure Of how much information Can fit on the network CSMA carries sense multiple access Is a good defense against collisions Only when this bandwidth delay product is small And by small I mean Less than one packet Much less than one packet If that's the case Well if there's much more than one packet You can see in this picture The kind of thing that can happen Someone can send Their packet can be on the medium A collision will happen much later If it's much larger than one packet You're still sending And your packet time is sufficiently long That the interval during which A collision can happen Is small relative to a packet time So collisions are less likely Or less damaging Because they only occur During a smaller window of time The second improvement That Ethernet uses on top of LOHA Is to use collision detection Not only do we listen Before we send or talk But if someone else is talking Or using the medium at the same time Then we stop sending We detected there's been a collision And we abort our own collision In Ethernet The way you abort a collision Is you send a jam signal Just to say to everyone Well stop You know there was a problem And then you can see Transmitting your frame Now again this sounds Like a fairly easy technique It works well enough with wires It's a little harder In the wireless context So here in our picture Both nodes have detected a collision And they're both going to issue a jam signal It's actually a little more complicated Than I've been making out When there is a collision You would like all nodes That are involved in the collision To realize that a collision has occurred Otherwise a node could send its frame Think that everything is fine And not realize that the frame Never got there because of a collision If there is one and all nodes know Then they can take action in the future Such as retransmitting their frame So this leads us to think about How every node is going to realize That a collision has happened And again a key factor here Is the propagation delay of the medium There is a window of time During which a node can Detect a collision You would hope that if you send And someone else is sending You know right away But because of the propagation delay It can take a finite amount of time Here's the scenario This node starts sending It signal propagates down to the other end Of the wire Now that takes about d seconds Well just before the signal gets here This other node decides to send a packet Just an epsilon before It starts sending and immediately It's going to detect a collision But its signal is going to take You guessed it Another d seconds To return to the other end And it's only when it returns to the other end That this node here will see That there is another signal on the wire And detect a collision That's then taken up to 2 d seconds To detect a collision In Ethernet or with CSMACD The technique that used to detect collisions We ensure that all nodes know That a collision has occurred By imposing a minimum frame time We require nodes to send frames So that the minimum frame Takes at least 2 d seconds to send That way you'll still be sending the frame For the time interval During which you could detect a collision Or if there was going to be one You'll know that a collision occurred The node can't finish before the collision Is what it says here Which is a good way to put it If you do the math for an Ethernet Depending on the bit-rate And the maximum length And hence the d The amount of time things can propagate You can work out that the minimum frame For an Ethernet is 64 bytes This means that actually If you wanted to send a packet With a one character in it Or a short message like ok The minimum message size That you're going to send Is 64 bytes regardless If you try to send something small It will be padded out And finally there's a third issue In Ethernet as we move away From Aloha And that's the issue of persistence This is a good illustration actually That these protocols In a simply random access protocols Where you just send Can sexually they sound very simple But there can be very complicated Interactions between different nodes When everyone independently Follows all of these rules And persistence is one illustration of that So the persistence issue Is simply the question of What one node should do If it senses that another node Is using the medium Obviously it's going to wait And not send right away Or that would cause a collision But how long should it wait That's the question So what do we do now Ok well I have a brilliant idea The node here on the left Should simply wait until The other node is finished And then go for it That's the simplest solution I can come up with I like simple Generally we like simple designs But in the end It sounds good What could possibly go wrong Well you might have guessed Something can go wrong Here's the problem that you get If you use that scheme Where you know that Senses the medium Busy waits for that sender And then sends immediately Actually that is a good design If you are the only node That is waiting on the medium For someone else to finish Because then you go right away But what if there are two Or three or four different nodes All of whom wanted to send And they are waiting for another node to finish If they send immediately They will all collide In fact we have really Created a problem here With this rule of wait Till someone finishes And then go for it In that the node that is sending Is almost acting as a perfect Synchronizer for the other nodes It's lining up all of their Transmission so that A collision is guaranteed If there is more than one of them This is not good It's also more of a problem With more load Because the more load The more likely it is That more than one node Will be waiting to send So that you will get collisions And the more collisions there are The more nodes will have to Resend their frames To try and get them through So we'd like to do something about this Well if we shouldn't send right away How quickly should a node send The difficulty here Is that it depends On the number of queued senders If there is only one sender That's queued up and waiting to send It should send right away If there are two senders You would like each of them to send With probability about a half So that on average Only one of them would go right away And the other one would wait That would be good On the other hand If there are ten senders You would like each of them to send With probability about one in ten We would expect that way That only one of them Is likely to go That way we'll make sure The network's used But there's unlikely to be a collision Which we'll waste that bandwidth In general If there are n queued senders Then you'd want each to send With a probability of one on n That's what we would like to happen But since this is a distributed system And the load is changing Dynamically over time This node Or any of these nodes here Does not know what n is What is n If you knew what it was You'd be able to send With probability one on n But at any given time A node doesn't know what n is Well, it's a clever heuristic Which is used in Ethernet To solve this problem It's called binary exponential back-off And it's a technique That's probably useful In a lot of other contexts Where you're trying to adapt To a certain level of load Binary exponential back-off Cleverly estimates The one in n probability And it does this By starting and optimistically Assuming after a collision That, well, since we're a collision At least two people were involved But it will assume There was only two of you And so every node That's going through this process Will say, okay, I will Wait only zero or one frame times That's two options So I'm going to send right away With roughly probability a half Is roughly what it corresponds to Not exactly, but roughly If you collide again You say, well, whoops Maybe there were actually More than two of us I'm going to try again This time I will send My retransmission chosen randomly Over a four-slot time So that's like sending With probability one on quarter A quarter for every time slot Roughly If you collide again You say, wow Well, maybe there are actually More than four of us I'm going to double The number of slots I'm going to wait for That's eight slots now I'll send with probability One on eight, roughly And so on So what binary exponential Back-off is doing Is it's doubling the interval For which you're waiting Over with each successive collision Now as you know This exponential growth and doubling Gets quickly very rapidly So even if you needed to wait For, you know If a hundred nodes were containing all at once Binary exponential back-off Will get you there relatively quickly All you would need to go through Is, you know, six or so different collisions Six or seven different collisions And you'll get up there fairly quickly So in practice Binary exponential back-off Is very efficient It's able to adapt Over a large different operating range And this is a property We very much like to see In our network protocols We would, you'll often hear the word Scalability in networking We would like to design network protocols Which work when the number of nodes In the network is very small But they also work well When the number of nodes In the network is very large That way as our network grows There should be no problem Binary exponential back-off works well When there are very few nodes Because it optimistically starts By assuming that there's No one much around And you can send rapidly But it also works well If there are a large number of nodes Because by doubling this back-off It very quickly gets to About the right operating point Okay, so when you put All of these improvements together We have Classic Ethernet Recall, Classic Ethernet Was this hugely popular Land technology for connecting computers This shared cable Snaked around the building You connected the computers to it They could all talk There's some details here Just to relate to our physical layer talk It was a 10 megabit per second cable It's a coaxial cable The signals were sent here Using baseband signaling Now the key for Ethernet Is this multiple access control problem And the solution that Ethernet uses Is one persistent CSMACD With BB Wow, that's a mouthful But we've seen everything That you need to understand this So Ethernet uses Carrier sense multiple access That's this bit where you listen Before you talk And it further uses collision detection So that if two people start Sending it once They realise there's a collision And stop So that we don't lose Too much efficiency The stations, the nodes Using the Ethernet are persistent They're what's called one persistent Meaning that if someone else is Sending they wait for a moment And then they send right away They try and send right away Well we know that can cause collisions If people queue up So Ethernet also includes Binary exponential back off To adapt the persistence So that everything works And there we have this technology I'll tell you just a little bit More about it And to do that What we'll do is we'll look At the structure of frames That are sent across the network It's often very helpful for protocols To look at the format of their messages Because we can see The different functions that are included The different information That's in these messages And that helps us understand The different functions of the protocol One thing that you'll immediately see If you look at an Ethernet frame That we haven't talked about before Is it has addresses on it It's also a destination address We didn't need this when we were talking About a link where You know sender is connected to a receiver Because whatever was sent It just went down to the other end For our multiple access scenario We do need this Because there might be several laptops Around an APing If there is a frame in the air Who's it for And who did it come from Ethernet includes this kind of addressing The destination address Actually goes first here That's the first thing that is sent out Because remember here to the left Is this is what is transmitted first So this means the destination address Comes first Everyone can look at it And see if the packet The frame I should say is destined for them There is a whole frame format here We can see some of our framing concepts What we learned before really is useful The frame begins with a preamble here To identify it That's actually a bit of a signal From the physical layer To help with our framing problem The frame ends here with a What's called a checksum This is used in a generic way The checksum is actually this CRC32 Or a 32 bits cyclic redundancy check So that's a check that's used for error detection If you remember all of that That will allow us to work out If something's gone wrong Now interestingly here There are no acknowledgments Or retransmissions Ethernet because it's sent over A wire is usually fairly reliable The CRC is just there in case Something goes wrong to weed out errors But mostly there won't be any errors If there are errors This means since they're not handled by Ethernet Other than collisions That is something that might be thought of As an error that is repaired by Ethernet But anything else that's caught by the CRC Well that will just have to be handled By the higher layers And we'll see some of that much later Okay and before we wrap up on Ethernet There's one important thing That I want to remind you about And that is we've just looked at classic Ethernet Now it turns out that modern Ethernet The kind of Ethernet that you'll see In any building today Does not use this multiple access control protocol It's really based on switches That's these boxes here So there is a twisted pair For instance cable That connects every different computer To a different port on the switch And the connectivity is happening Inside this switch This is called switch Ethernet Or modern Ethernet The difficulty is that everyone will call Both of these things They're all just Ethernet Which can be very confusing But again we've studied classic Ethernet Which is how the Ethernet evolved And it's all about multiple access control Ethernet as you'll find it in buildings today Is this switch form of Ethernet That we'll look at a little later G'day viewers In this segment we'll talk about Wireless multiple access protocols And yes this is it This is Wi-Fi What we've been waiting for So let's find out how it works Okay so our setting here Is the same as the setting That we looked at in the previous lecture We have multiple nodes They just want to share a link How do they do it In this setting however The nodes are wireless Or the link is wireless And the nodes are using that wireless link So we have four different laptops here They're talking to an AP They just need to decide when to send Now to understand the way The protocols work in this setting What we're going to do is build On the schemes we used in our simple wired model So all of that Carriers since multiple access stuff That was more useful than just For classic Ethernet We'll use it as a foundation To understand how 802.11 works today Well the first thing that You might ask is Why wouldn't we just use Some of the protocols we've seen before That were used for classic Ethernet And the reason for this Is that the wireless case Is more complicated than the wired case I say surprise here Because this always seems to be The case for wireless The way signals propagate Across the wireless medium Is much more complicated Than sending signals down a wire And that seems to have all sorts Of implications for how you design The rest of the protocols For a wireless system In our case Just thinking about multiple access There are a couple of issues here One issue is that Nodes can have different coverage areas When you send down a wire If everyone's attached to the same wire You expect that everyone on the wire Can hear all of the messages That's not the case with wireless The nodes might be A fair distance apart And so they might not be able To hear one another clearly This will mean that our schemes Such as carrier sense Don't work very well The second complication is That nodes can't easily hear One another while sending There can be enormous differences In the power level between A signal that's sent and received The received one can be so much weaker That it's difficult to hear both signals At the same time So it's difficult to detect collisions So we'll have to come up With alternatives to that The bottom line here You can see in that The figure at the bottom Is just to remind you That wireless 802.11 does not operate According to CSMA CD We have to improve it So let's see how we do that Well first we've got to go into These two issues The first issue is the different coverage areas Here's what's going on In the figure here We have four different nodes A, B, C and D And they just spread out over space Now the wireless signal is broadcast And as it's broadcast It propagates over an area It's attenuated It can be received By receivers As long as the signal to Noise ratio is high enough And that's just within a region So here it looks like A can send to a neighbor B That's adjacent to it But A's signal can't be received by C It's too far away The signal's grown too weak It can no longer be received Similarly for B, C and D And this leads to Different coverage areas You can see the radio range here Is indicated as just enough To get from one node to the next But not a lot further B by the way When it sends The signal will be received by A But also by C Because that's also within radio range Different coverage areas Lead to problems And one of the classic problems here Is something called hidden terminals When you think it's okay to send Because you can't hear someone Yet interfere and still results So in this figure We have a hidden terminal situation When A and C are hidden terminals When sending to B Let's see what happens Now A and C When they want to send They cannot hear one another's transmissions This means if they use something like carrier sense They would listen And they would hear no one and say Okay, the medium is not in use It's fine to send However, if they both send at the same time Both of their signals receive at B Are received at B Or arrive at B simultaneously Those signals are mixed Superimposed on one another The result is a jumble Two people speaking at once So B cannot separate these messages And receive them It's a collision And we would like to avoid this Because we've just wasted Some of the resource of the link We could have used it To deliver a real frame Instead we got a collision And neither of the frames gets through The second problem that arises Because of different coverage regions Is something that's called The exposed terminal problem Now exposed terminals are a situation When you think you have interference Because senders can hear one another But actually there is no interference At the receivers So you would really like to send Multiple packets at the same time Here B is sending to A So B is sending to A there And C is sending to D And in this situation They are exposed terminals They're exposed terminals Because B and C can hear one another When they're sending It looks like their signals will collide here However C signal doesn't propagate All the way to A There's no problem here So A will be able to receive B signal cleanly Similarly B signal doesn't propagate to D So D will be able to receive C signal cleanly When this situation occurs We would like to take advantage of it When B and C send at the same time Because we'll get more performance out of the network We can send two friends concurrently And get them both through the network The second problem The second complication for wireless Had to do with the inability to detect collisions And that's really because With wires we can engineer the relative strengths Of the transmission and reception signals So we can work out if both are going on At the same time There can be a tremendous difference Between the power levels of the sent signal And the received signal Which might be a million times weaker This makes it very difficult To process them both at the same time So essentially when you're sending You're shouting and you're deaf You can't hear if someone else is talking With wires We're able to detect collisions And because of that we can abort The transmission and this greatly lowers The cost of collisions Takes only a very short amount of time It happens Everyone sees it's happening They stop sending Then we can recover With wireless These two nodes are sending But neither node can hear one another So the collision goes on for a long time This wastes more of the link It's more inefficient So that's why it's a problem So now we need to solve these problems We know that wireless is more complicated than wired What can we do about it We know about a possible solution Which is quite influential And that solution is something called MACA I think it stands for multiple access With collision avoidance You don't need to remember that MACA is actually not quite what's used in 802.11 802.11 users are a refinement of MACA But going over MACA will give you A sense of just how these issues Can be handled if you're designing protocols And it'll help us understand What 802.11 uses The idea in MACA Since we have these problematic scenarios Instead of simply sending The frames directly and maybe encountering them We're going to use a short handshake Between the sender and receiver To find out what's going on And make sure it's okay Here are the rules for MACA With that short handshake Step one here The sender simply Sends a small frame Called a request to send That's very short Packet It sends that request to send to the receiver The request to send Also includes a frame length So it tells you how big a frame The sender wants to send to the receiver next The receiver, when it gets this Replies with a clear to send That's simply Another short packet saying Okay, yep, you know Coast is clear, I'm expecting your frame Go ahead, fine We've just sort of added a bit of preamble And then after all of this The sender simply transmits the frame That's it The interesting part however Is that nodes That heard the CTS stay silent While the sender transmits the frame They can do this because The RTS and CTS including information About how long a frame is So the nodes that hear the CTS know How long to be silent And this is the key addition Of MACA that's going to solve The problems, we'll see how in a minute It's true that The RTS and CTS are just Sort of like short frames And as we send them we could run into Some of these same problems But the RTS and CTS are much shorter Relative to packets They might be a hundred or a thousand times smaller And in this case The collisions since they're a lot shorter Are just less likely so we're running to Fewer problems So let's see how MACA solves some of these First of all hidden terminals Let's suppose that A wants to send to B And C is a hidden terminal that might interfere Okay first of all A sends the RTS Here it is To B That should be received Now I've shown that Next step B is going to reply with the CTS to A To say okay go ahead B sends the CTS to A Great Of course that transmission Which will also be heard by C Right Now C At this stage will say oh boy I didn't hear a request to send You know so maybe Well since you didn't hear that You didn't know anything was going on But luckily C did hear a clue to send So C knows that something is about to go down Even though it didn't hear the request to send Here's that picture Cleaned up so you can see C is now In a state of alert With the wireless Now A simply sends to B C because it heard this clue to send Differs or just waits For this time period to pass So that the transmission from A to B Would be successful Great we solved hidden terminals What about exposed terminals Now A is going to Sorry B will send to A And C will send to D And we want them to both be able to send in parallel Step one Request to send to A C sends a request to send to D Now of course B's request to send Will also Propagate to C And C's request to send Will also propagate to B Neither of those nodes will probably hear the request to send Because they're transmitting at the same time So they can't also receive Next step We've got the request to send there Will also send a clear to send A gets the request to send Intended for it And it's going to reply to B with a clear to send Saying yep go ahead Similarly D is going to send It's clear to send to C and say yep Go ahead Now observe that The clear to send from B doesn't make it to D B only hears one clear to send Everything's good Similarly for C So they both get just one clear to send And This tells them both that they can both go ahead Here's what happens The diagram is cleaned up According to the protocol They've heard their clear to send And there haven't been any problems With either of these messages so everything's good So now we simply send B sends to A C sends to D At the same time Because we're in radio range The signals from C propagate to B The signals from B propagate to C So the situation around B and C Is a mess with superimposed signals This doesn't matter though Because what really matters Is what goes on at the receiver To receive the signal Both A and D have clean reception scenarios Because the other signals Don't propagate far enough to interfere At the receiver So it's interference at the receiver Which is the problem Because we have no interference And that's what we want So we've solved the exposed terminal problem Now that we know how Makka works we can move on to 802.11 or Wi-Fi We've really seen Most of the machinery we need to understand How multiple access works In 802.11 So 802.11 of course Is this incredibly popular land technology That we use today It's been around since the 1990s Getting more and more popular 20 years on, it's new ubiquitous It's really the ethernet of wireless That's everywhere In Wi-Fi, the way it's commonly used These clients, different laptops Or other devices, phones and so forth Get their connectivity to the internet From an access point So they're all wirelessly talking to this access point The access point is typically wired To provide connectivity to the greater internet The key bit we're looking at here Is this multi-access problem Of how these different laptops Get to talk to the AP The multi-access problem Is at the heart of Wi-Fi I'll also point out It's a little difficult even talking About Wi-Fi because Many different flavours of Wi-Fi Have been developed over time So if you really wanted to know any details We have to be clear what kind of Wi-Fi We're talking about But generally I'd say I have gotten faster over time And added many more features We'll see just a little bit on some of this What I'm going to do now Is just talk about the Physical layer and the link layer of wireless The physical layer I'll tell you a little bit about it Just so you know, this will relate To some of the lectures we saw on Physical layer characteristics So you should be able to understand Some of these parameters So Wi-Fi is sending using A 30 or 40 megahertz channel Of bandwidth on these ISM bands The bands that the government opened up For unlicensed usage in about 1985 They let anyone Make equipment that would use it With some constraints but no expensive License like a TV station This led to huge innovation Mostly in the form of Wi-Fi Which is taken off so that was really A very valuable thing to do Of the different flavours of Wi-Fi 2.11B and G And also N They're all different flavours of Wi-Fi That work differently at the physical layer Though the same at the link and high layers Mostly These flavours of Wi-Fi operate on The ISM bands around 2.4 gigahertz And the added 2.11A And N flavours Work around 5 gigahertz So N is capable of working in either one Now they use a kind of Frequency division Multi-plexing scheme To modulate information Over those bands They divide this band 20 megahertz up into many fine channels Which are used in parallel It's actually a form of FDM called OFDM It's more detailed than we're going to have time To go into. You can read a little bit In your book about it if you'd like This is for 8.211 G And A and N G is mostly the legacy form Of 8.211 out slower Has some different physical layer details We're not going to worry about it When we're sending wirelessly Here the different symbols Use different amplitudes And different phases to convey information Depending on your SNR You might be able to distinguish more amplitudes And different phases So you will have many different Kinds of symbols And you can get different bit rates 24 megabits per second Just depending on your SNR And how many amplitudes and phase levels you're using In addition to this Many other bits are transferred across the physical layer To provide error correction In wireless errors are common Just because the medium is very noisy Because of interference So we need to use error correction In the form of error correcting codes To be able to even receive packets And sort of clean them up You might, well Have heard of faster kinds Of 8.211 than 54 megabits per second Various tricks are used Including for some of the fastest Kinds of 8.211 using multiple antennas At the same time This is pretty cool It's well beyond what we can cover in this class But if you're interested You could look at a little article here I recommend it 8.211 with multiple antennas for dummies Would give you a sense of what's going on Let's talk about the link layer Because that's where the multiple access Control problem comes up In 8.211 Multiple access is done with a scheme Called CSMACA It's a carrier sense multiple access Scheme with CA stands for collision avoidance So it's not quite MACA But it's a variant of it And it optionally includes RTS-CTS as part of that RTS-CTS we've seen Although it tends not to be used very much In practice because it's often not necessary For typical Wi-Fi configurations With Wi-Fi Unlike Ethernet The frames are acknowledged And retransmitted with ARQ With Ethernet we just had a CRC32 If an error was detected You threw it away, that happened really With Wi-Fi Because wireless is more prone To errors, many packets Would be lost if we did this So the packets are acknowledged And if they don't get through they're retransmitted Just to up the likelihood of them getting through Now I said Just moving on to the third bullet here That a good thing to do with protocols Is to look at the format of their messages To see what's going on If you do this for Wi-Fi You'll see pretty funky things with the addressing Most data frames Are going to have three addresses on it It's kind of weird You'd usually think of a source and a destination What's going on here So we actually have three addresses Identifying a source and a destination And an AP that's potentially in between them Although Often The AP is really the destination as well Errors here As well as the acts and transmissions We have a 32-bit CRC Just to sort of detect residual problems And there are many, many more features You could read about for Wi-Fi That I'm not going to go into But I'll just mention By way of example That these features include encrypting The contents of the frames You can't read what's there And other functionalities such as power save functionalities So devices can tell the AP That they're going to sleep So they can save on their battery Finally Let's look at this 802.11 CSMA CA scheme for multiple access To see how it works It's somewhat simplified Compared to MACA Multiple access control is the subject Which hasn't really been definitively solved For wireless There are different variations around And they sort of work okay, but none of them are quite ideal And so this is just what 802.11 Does as a reasonable trade-off Instead of using RTS-CTS Most of the time You can optionally do that as well What 802.11 does is It avoids collisions By inserting small random gaps Instead of an RTS-CTS If we have these small random gaps That's why you don't need RTS-CTS Always So in this scenario We have a timeline here Time is just going from left to right Across the page And we have timelines for three different centers A, B and C A is going first A is just sending a data frame There's also going to be an AC after that Because that's how wireless works Unlike Ethernet I know that's not shown here Now let's suppose that B and C both Want to send While A is sending Here, B is ready to send its packet But it uses CSMA It senses the medium and it hears A A must be talking to the AP or something Similarly, C was sending Oh sorry Not sending, C became ready to send While A was sending It heard A So both B and C are waiting to send Eventually A is finished It's data frame and AC frame is done What happens? If we just sent right away As is the case with Ethernet We would run into a collision We would waste a lot of the medium It would be a problem Instead Both B and C Insert small random gaps Here's a small random gap C inserts this random gap Waits after this much time has gone by Let's just pack it here There's the data frame Followed by the AC B happened to choose randomly A slightly large day Even though it was very first Everyone picks a random one And its roll of the dice was bigger It waited this long And then it stopped here Simply because it heard that C was sending So it suspended its timer After C was done It continued counting down its timer B got to send its frame And in this fashion By inserting these small random gaps Just to sort of test and allow Someone else to use the medium And see who's waiting to send B and C, even though they both wanted to send Have ordered themselves And they both got to send their frame These back offs Are sort of wasted time Vital time on the air And this is the cost of using wireless But these back offs are small So we do okay in wireless And finally Just to wrap up 802.11 Let me just talk a little bit about Some of the future trends for 802.11 802.11 is a key technology So I thought it might be interesting Just to do this Now I don't really know what's going to happen With 802.11 of course So this is just a guess Firstly, it's likely that 802.11, well it's already ubiquitous It's likely to become more ubiquitous But really all devices these days Seem to have an 802.11 Nick for a wireless connectivity What's likely to happen here though Is that we'll have greater diversity You can have very fast computers High end computers and very low end Computers, wristwatch or whatever Can all have Wi-Fi And all want to use the same AP So now the nodes are not generally Equaling capability like a laptop Some are more powerful, some are less powerful That will affect the protocols Small and subtle ways We can also expect a lot of innovation Everyone wants to be able to send More information across Wi-Fi It always seems to be getting faster This is likely to continue And maybe more so than simply getting faster Wi-Fi is likely to get more power efficient So that the nodes that can use it If their battery operated Don't deplete their batteries so quickly This kind of innovation Is very much driven by physical Air technologies As these technologies advance Wi-Fi just sort of gets better Even without the Mac layer changing very much And finally I'd point out right now That Wi-Fi is a bit of a hassle to use It's quite manual in terms of identifying What access point you can use For which you have credentials Typing things into web pages and so forth It's also a little limited in that Transmissions go through an AP Even when you have two devices In the same room most of the time It's often more easier to use something Like the cloud Dropbox or something to exchange files Than Wi-Fi even when your devices Are in the same room That's just wrong in some sense So we're likely to see more Seamless integration of Wi-Fi Into the massive connectivity That devices have Then people would have to be less involved In setting up and configuring Wi-Fi This is likely to happen over time Okay so now you know about Wi-Fi Good day viewers In this segment we'll talk about Contention-Free Multiple Access An alternative design to the method Of multiple access used in Wi-Fi And Classic Ethernet So in Wi-Fi and Classic Ethernet The multiple access problem is solved With randomization What we'll talk about in this video Is a completely different technique Which is based on taking of turns So in this picture here The four nodes might take turns From left to right Before we get into the design Of turn taking multiple access protocols One issue we need to talk about A little bit is why we would bother Why aren't random multiple access protocols Good enough If they were after all There's no need to worry about These different turn taking protocols Well it turns out that CSMA The carrier sense multiple access method We looked at For Wi-Fi and Ethernet Is good under low load It's very effective there And the reason is that it grants Immediate access so there's no delay And under conditions of low load Few collisions are expected So the overhead is very low But the issue And the reason we're talking about Turn taking multiple access Is this bullet here Randomized schemes are not so good under high load The issue is that under high load You expect collisions And this leads to a high level of overhead It's also the case That the access time varies A node when it tries to send Is unlucky Try and send And get its packet off right away Its frame off right away Or it might get unlucky It might have suffered repeated collisions And so it might take a long time For its frame to be sent We would like to do better Under conditions of high load With turn taking multiple access protocols The protocol is to find an order In which the nodes send The order is really an opportunity to send It's a chance to send So if you have a frame When your turn comes around You get to send it If you don't you just pass And the next node gets turned to send a frame All we really need to do To come up with these protocols Is to devise some ordering I'll talk about one on the next slide A method called token ring But you can imagine other methods For instance the nodes could use their addresses To impose an ordering From lowest to highest Or vice versa In terms of who gets to send next So with token ring The physical topology Is used to provide the ordering The nodes are wired together In a circle, in a ring And then a special frame Called the token Is put on and sent Around the ring You can see the token here And it's going around the ring And clockwise As the token passes the nodes It gives each node The who has the token An opportunity to send They grab the token Then they Instead of sending it on The first of all they send their frame And after their frame has been sent They then pass the token on to the next node Further along So the sending order here is going to go one The token has gone to node two To node three Four Five Six Seven Eight Nine And then we're back and so forth That's our order And that's token ring in a nutshell This kind of turn taking protocol Token ring As well as other turn taking protocols Do have advantages In this scheme There is a fixed overhead With no collisions The collisions are gone As a source of overhead And in particular We won't have an increasing number of collisions Or a large number of collisions As the load gets high Just the fixed overhead Because of this The turn taking protocols Are more efficient under high load We also get a regular opportunity to send This leads to More predictable levels of service You know that you'll get to send a packet Every say a hundred milliseconds or so And the concept is Easily extended to different qualities of service As you might imagine We could just allow one node To send say two frames Every time we've got an opportunity to send Instead of one That way we get to send Twice as much traffic As another node If it was a high priority node for instance There are some disadvantages though And the principal disadvantage Is this complexity There's more to this protocol Defining the ordering And imposing it And that means that there's more to go wrong What could go wrong? Well just as an example What would happen if the token was lost? Now this really shouldn't happen The token's just a frame going around the ring But unexpected things Can happen occasionally Let's just suppose that the token is corrupted By bit errors And it's too corrupted For any error correcting code That's used down there to deal with Or even an error detecting code To recognize that the token's in error To be repaired If that were the case The token might suddenly appear to disappear And then the whole protocol would lock up And if you can't send Until you've got the token And there is no token Boy you just never get to send That would be no good So we'll obviously need to guard against that How? Well Token ring protocols in practice Have every node Have extra machinery To guard against these kind of failures Know it's my run of timer For instance And if they haven't seen a token for a long time They might decide there's been an error And the nodes would collectively Mint a new token They'd work out who would do it They would have to coordinate So they didn't have to have multiple tokens And so forth You can see that even though Losing a token is a rare case It can add considerable complexity To the protocol There's also a somewhat higher overhead At low load The overhead of token ring is fixed Just passing that token around But it's non-zero And at low load CSMA or randomized schemes Have almost no overhead whatsoever Today viewers In this segment We're going to talk about switches Which are a very widely used technology To connect computers together Into small networks inside buildings Okay so we've talked about Multiple access schemes a lot Now they are very widely used For wireless networks 802.11 was the popular example But when we're using wires Rather than have the host run a multiple Access control protocol The method which is used today Which is vastly more popular Is to connect all the hosts To a switch device in the middle You can see in this figure at the bottom here I have four different boxes Which are all wired to one switch The switch will provide connectivity Between all of these different devices This architecture is the basis Of switch Ethernet Or modern Ethernet And it's used ubiquitously To tie together computer equipment In all manner of buildings Let's just drill down in a little more detail So the scenario is like this Inside your building, your home Your office, the campus You have different hosts And these hosts are connected By a twisted wire cable A twisted pair cable typically To a box called a switch This switch has many ports So you can connect many different hosts to it Somehow, this switch Is going to provide connectivity Between all of the hosts Because we're still operating in the link layer When they send frames The frames will go From one host to the right other host Typically the wiring Is done so that the switch Will be in some kind of central location And all of the wires in your building Will be run to a wiring closet In a convenient location So the big question for us Is how do we make a box To provide all of the connectivity That's a pretty interesting question If you remember back to our diagrams On protocol layers I said something like this That all of these different kinds of boxes There are many boxes That have cables attached to them They're distinguished by the functionality Of what goes inside And we can draw different kinds of protocol diagrams To describe the processing that goes inside In a hub Box or a repeater box The switches The devices operated the physical layer So they're really just connecting bits Around moving bits around In a switch device that we're looking at now The functionality inside the box Runs a link layer So it's connecting frames From one port to another port And in a device called a router The functionality inside the box Works at the network layer So it looks at the details of IP packets In the case of the internet To work out which way to send them We'll get to routers later on So we're not going to look at IP packets and routers now Instead we're just looking at Switches Operating at the link layer Sending around ethernet frames To understand that We'll go over both hubs and switches Because this will show us the difference between the two We'll start with hubs These are physical layer devices In a hub Inside view for what could be going on inside this box We have all of the different lines coming in These lines come from some hosts They attach to the ports inside the box If this is a hub As a physical layer device You could simply imagine that all of the ports Are wired together This will provide physical layer connectivity And that's all we need So for instance, if a frame comes in On this port from some host And it's all wired together The same frame will go out On all of the other lines Functionally This is equivalent to the setting on the right Whereas if one host Sends onto the wire The frame will be delivered to all of the other hosts It's just another way of wiring it It's generally more convenient Than winding one long wire through All of the different offices Because now we can run twisted pair To a central wiring closet It's also more reliable If we lose one particular wire here Well Some host is out of luck But chances are that the rest of the host Are still able to communicate However, if we break This wire here You Generally do more damage You might have broken your land in half It just doesn't work anymore The signals get messed up too Inside a switch Something very different is going on That looks like the same box Switches operate at the link layer So as the frame comes in now The switch will look at the link layer information That's the source and destination Ethernet addresses To be able to forward this frame Out the right output port This means for instance That if let's just say I just number these hosts 1, 2, 3, 4 If I send a frame in here It might be destined The host on port 4 I would then send it through the switch fabric And out port 4 At the same time The host on port 2 Might be sending A frame To the host on port 3 Using a different path Through the switch fabric The switch fabric here is shown as a grid You could just imagine this as You know almost a street map And traffic lights The switches that are on the frame Different kinds of traffic lights Or switches here have been turned on or off To connect different input ports To different output ports And so that is how We can use different parts Of this switch fabric To connect different input Hosts to different output hosts At the same time Here's just a clean up of that figure Where 1 is sending to 4 and 2 is sending to 3 At the same time A couple of other things First of all I just sort of draw a line between the host And the port here to represent a link Typically for all switches you get today This is a full duplex link So even though I draw one line Really you might think of this as having Two halves inside the cable There's usually a Y going one way And a Y going another way to make it full duplex And this port really has an input And an output port structure Yes, so they're full duplex Also what that means Is that I can use Because I can do the sending in parallel There's no multiple access control Protocol for a switch The host just send the frame into the switch When they're ready And the switch will deal with making All of the right connections To send information at the same time This is quite different than a hub For instance with a hub When one host sent The message was received on the wire At all of the other hosts This means that two hosts couldn't send At the same time Those hosts need to use a multiple access control protocol To coordinate their actions With a switch there is no MAC protocol Though what lines are full duplex They send into the switch The switch works it out This new method Of working however does pose some problems There is a lot going on inside a switch In particular In particular You might wonder what happens If two different inputs Are sent to the same output So let's say That the first host here Is sending a packet Through the fabric To the same host on the output side Well What happens if all of the other hosts Are also sending there It's just a very popular destination So we're all sending through the switch fabric To this one output This can't happen at the same time If the lines are the same speed Only one Frame could be going in Or out of a given port Maybe in and out if we can use it By direction at the same time The other frames which are coming in from other ports Which are destined for this one port over here Will need to be stored somewhere temporarily For this reason A switch has buffering Either on the input side of the switch Or both You can see I've shown the buffering here As the pink here So this is a little bit of storage memory To temporarily store frames Until they can be sent on an output port The right output port The issue here however Is that This buffering is fine If there are very short term mismatches Two hosts sent to one given output And it took two frame times To send it out But it's not going to work Even buffering won't solve the problem If these hosts are sending To a If multiple hosts are sending to one output In a sustained manner If that's the case The frames will build up inside the buffers Eventually the buffers will be full And we will have loss Now this Is an example of some kind of Contention or congestion Happening inside the network Because of this loss As you send packets or frames Across the network they can Almost disappear inside the network They can be thrown away because the network Could not support the traffic pins We're going to look at this issue much more Later on when we get to TCPAP Because this same sort of issue Happens as you send packets across the network They can be lost due to lack of buffering Inside switches For now we're not going to worry about it too much We're going to say if the switch is well engineered It can happen but we hope it won't happen very often So switches And also hubs Have some significant advantages Over just connecting all the hosts To a single shared wire As was the case with classic Ethernet Hubs and then switches Became possible Really due to Moore's law As electronics sped up greatly And also became a lot cheaper And nowadays they're prevalent They're what you find everywhere It's just possible because of technology But they have definite advantages It's more convenient generally To run wires to one central location Rather than to sneak it through the offices Imagine what you have to do to change it If you want to add another host And you've just got this one wire They're also more reliable as we said before In that if the wire fails You might lose a host But you probably have connectivity For all of the other hosts in the network This is different than a classic Ethernet If there's a break in the Ethernet Actually it doesn't work for all hosts For electrical reasons You may wonder if the switch itself Is a problem for reliability It is after all a single point of failure You blow up the switch You lose connectivity to all hosts That's true But if you lose connectivity to all hosts You know exactly what to do Go find the switch, take it out And put another one there So it can be repaired fairly easily The other key advantage For switches is this Switches offer scalable performance This is a real win With our single shared cable Maybe you have a 100 megabit per second cable You attach 10 hosts to it Each host's fair share Is maybe 10 megabits per second of bandwidth With a switch Because we can send frames in parallel You might provide 100 megabits of bandwidth Per port So every host Is able to send and receive it up to 100 megabits per second Performance is much more scalable For these switches I'd like to go into one particular issue For making switches work You might have wondered as they talk through there How switches, if they deal with Ethernet frames Find the right output port To which to send a frame This would be easy If frames carry port addresses Send me output port number 7 But they don't The addresses which are on these frames Are Ethernet addresses They indicate a host Either the source host Or the destination host Now that destination host Might be plugged into any port On the Ethernet switch We could imagine Having someone manually Configure a big table This would be a terrible job to have That's exactly what we want computers to do So let's try and solve it with an algorithm And we also want an algorithm which will allow Hosts to move around You might move your computer to another office And connect it to a different switch And that should be okay too So we need to find some way When frames come in And we just have a source and destination address To work out what output port To send that frame to The algorithm we use To solve this problem with switches Is called backwards learning It works as follows The switch needs to build up its own table That maps between Addresses and ports So it knows which port to use It does so as follows Step one, first thing we do Is we build up this table An insight to allow us to fill in This table without having any human Configure it is to note That Ethernet frames carry both source And destination addresses So if you see a frame on a port You can look at the source address and say Well, you know, I see a certain source address So this port is where This address lives If I ever see a frame Which is destined to this same address Now I know what port to send it on So you look at the source address Of the frames to find out what port they're on That's the backward bid and backward learning Usually you might think you just look At the destination to work out Where to send the frame But by looking at the source We can also work out where people live To forward these frames You just got a frame on an input port Destined for a particular destination What do you do You look at your table If you know the port where it lives Because you've learned it earlier somehow Then you just send it to that port And you're done What if you don't know, what do you do In that case you broadcast it By sending it out all ports You just say I don't know It's attached to some port That way it's going to get To the right port destination It'll also get to a lot of other ports And they'll just have to ignore it Let's see how that works in action So the very first time The network's used after it's powered up A is going to send to D No one knows anything at this stage So A's frame comes in It just says hey I'm a frame from A I'm trying to reach D is the destination address This switch is clueless It's just been turned on There's nothing in my table So therefore I'm going to broadcast this frame I'm going to send it out all ports It reached D That's very good It also reached B and C Oh well Not a very efficient use of bandwidth We also learned something here We learned that A is on port one That's a valuable bit of information So this is what happened Now step two Let's assume because most communication Evolves requests and then replies Sometime later D is going to send a frame Back to A What will happen? Here's D Sends its frame in destined for A This stage the switch can look up It's table here and say yep I'm just going to send it directly out that port Wonderful We did not have to broadcast it out the other ports Here we are, cleaned it up I just changed the color so you can see them Oh I should have said we also learned something We also learned that D is on port four By looking at the source addresses The frame came in This is the normal situation Now everyone sent a little bit of traffic And we've learned Because if they're using the network They're going to send some traffic Then we learn what port they're on Now we're fine Let's imagine now that A Happens to send another frame to D The frame will go into the switch It'll come in port one The switch will know yep D port four Now we're sending frames Between the port one And port four between A and D Fine without broadcasting And sending extra traffic to other hosts That just happens once And this mechanism is fully automatic We've learned how How to get from one port to another With no configuration From a human and in a way Which is fairly efficient So that's pretty cool There's something actually that's even cooler about this This same mechanism works If you run it independently In the different switch, they're shown here as B1 and B2 Even if you have some hubs in there here too By the way, there's a hub in here H1 Assuming there are no loops in the topology This is a crucial assumption We're going to want loops in the topology At least we're going to want to allow them So in the next segment We'll handle the case where there are loops in the topology But now we're assuming there are no loops Then the mechanism I've shown you Has solved a problem Let's see what would happen When A sends to D and then later D is going to send to A OK, A sends to D Here the frame comes in Beginning of the world, everyone's just woken up This switch, B1, has no clue This switch says, OK, I will broadcast it Out all of my ports Because I don't know I'll also remember that if I ever want to get to A I use this port, port 1 OK, so this frame Is going to go to host B and C I'll also go over this link And into switch B2 Through this input port B2 actually doesn't know that it's come from another switch As far as B2 is concerned A could be directly connected here It really doesn't know You can't see the overall topology But B2 runs exactly the same algorithm It gets something in From A, destined to D It's clueless also It learns, hey, A is here D, no idea That's what we do, we broadcast if we don't know It'll go to D Yes, that's what we wanted It'll also go out here to the hub The hub by definition Wires everything together So it will go out the other ports It'll reach E and F So A's frame went everywhere But at least it got to D Here's that again And now let's look at what happens next Now D is going to send to A Here's D's frame comes in There's one on this switch It wants to get to A Well, switch B2 Actually remembered that the way you get to A Is you send out this port So it'll simply send it out that port There's no need to broadcast It'll come in this port Switch B1 As far as switch B1 is concerned This could have come in directly from D D could be plugged here, it doesn't know Switch B1 Looks at the destination that's A No worries, done No broadcast, we now have an efficient way For D to send to A And of course, you know where I'm going here You can work through yourself the case of how A Sends back to D And you'll see that we're using the switch very efficiently So this algorithm extends naturally To topologies with multiple switches And hubs That's pretty cool Now you know a lot about how switches work This is how a modern switched ethernet works We've just In one condition and that's There might be loops in the topology I'll get to that in the next segment G'day viewers, in this segment We'll talk about the spanning tree algorithm Which will complete our understanding Of how land switches work Okay, so in the previous lecture I talked about switches Modern switched ethernet How hosts were connected to them And how they forwarded frames So thus providing connectivity Between all of the hosts The solution we made was that the topology In the way these switches were connected Could not contain loops Now I'd like to talk about how we can allow These switches to be connected in ways That do contain loops And still have the overall system work There are a couple of reasons you might want To have a loop in the topology You might simply want some redundancy In your network You can see here on the diagram On the right I've added a redundant link In the middle between the two switches In the middle You might do this simply because one of them Might fail and you'd like to provide A little bit of redundancy ahead of time So if there is a failure There are still links in the network So it can work You might also make a simple mistake Networks evolve over time I think components are always Been added and removed And it would be very easy for someone To plug a cable into the wrong port And inadvertently create a loop This could happen and we wouldn't want a simple mistake To take the whole network offline And have it not work So we would really like For these LAN switches to just work To provide very much A plug and play environment LAN switches in fact are some of the earlier Plug and play computer networking That just works I guess Ethernet does too But LAN switches are really an extension of that We also want to do this One of the constraints for the design of LAN switches For Ethernet switches Was that the switches should work With no change to the hosts So we don't want to have to go and upgrade All the software and millions of hosts Just to be able to connect switches with loops But if we don't Do something Compared to what we've seen so far We have a major problem with loops Let's look at that for a minute What can happen? So suppose that the network is started And we have our network here And we're able to host A through F What's going to happen? I think I'm just going to overwrite On this diagram And draw a series of frames A sends to F Well at the beginning of time No one knows where anything is So they're just going to broadcast frames A's frame goes into C C gets it, C will broadcast So we'll send it out the other ports That's what we've got to do initially So it went to B and it went to D Twice Because we have a loop in our topology D, well now let's just look At the first of these frames it gets Consider the right one first D will get that frame in And then it will send it out everywhere else To F, to E It will also send it back to C On the other port to C Oh boy, you can see that things are going to go A bit south here D will look at the second frame that it gets This is from D on a different port Now it doesn't know this is the same frame You might think we could just look At the contents, but you don't know Whether this is a second message from A Or not, we really have no way of telling D will then send this frame Out to E and F And of course up the other link back To C Wow, E and F are now not so happy They've now received two copies of this And they didn't want, well at least E Didn't want any of them Not done yet We now have these two frames that have gone to C Let's look at the one on the left It went to C, what does C do with it It broadcasts it because it still doesn't know where F is Hasn't seen any frame from F Goes out to A and B and down to D On the other link And similarly For the frame from D to C The second one, it will come up Go out to A, B And down to the other link Back to D Now, this diagram is getting very messy If you follow some of the logic through I could write all this down I think I'll do that on the next slide You'll see that we have something nasty going on I'm just going to draw a big massive circle here Some packets are spinning around here left to right There's another series of packets Spinning around here in another direction And traffic has been forwarded out To all of these nodes A, B, E and F As we go around this loop So we have a storm here in the network One packet was sent in by A It never ends, traffic keeps going around the network And fresh copies of packets have been delivered To all hosts on the edge This is really nasty So here is just the beginning of that logic Spelled out for you a little more In terms of who sends where So you can follow it through And it just goes on and on It never ends, so a forwarding loop here Is something pretty nasty to happen The solution that we'll come up with To prevent this problem And we would really like to nip this problem in the bud Because you can see that one packet Can cause devastation here with the loop The solution we'll use is for switches To collectively find and agree On something called a spanning tree A spanning tree of the topology A spanning tree is simply A subset of links of the topology Which is a tree So it has a root and branches out from the root But it has no loops In that topology The subset of links In the spanning In this topology Is a spanning tree, if it's a tree And it spans the topology It reaches all switches So it will allow us to deliver Frames to all hosts on the network Once we find this spanning tree This is the first step The thing we want to do We simply use it as before Switches simply forward frames Along the spanning tree So they just Pretend that the topology was only the spanning tree If we know which way to go Grady will get there If we don't we're going to broadcast And if we broadcast on the spanning tree Frames will tend to go Up the spanning tree to the root And then down all branches So they'll get everywhere But they won't loop You know this sounds pretty messy With spanning trees I'll show you some examples To get a sense of what a spanning tree is And then I'll talk about the algorithm to find one Here on the left we have the topology This is the links which were Physically installed in the network Now I want to talk about some spanning trees There are actually Usually there are many different Possible spanning trees for a network Let's just see some of them Let's just pick a node here arbitrarily Top left one as the root of a spanning tree How are we going to create a spanning tree Let's create some branches Let's say I go down here and here And you know I'm just going to say There are only two branches in the tree So from here I'll go up to here And from here I'll go over to here This then is one spanning tree It reaches all switches in the network I can cross out the links we haven't used Okay, fair enough Here's another spanning tree Just to show you that multiple ones are possible I'll select a different node as the root From here I'm going to just arbitrarily And from here I'll divide I'll just say I'll use this other branch here That's going to reach these switches And a different branch here will reach these switches In this spanning tree I don't use these three links Of the topology These are all different Possible spanning trees Of course in our automated solution We're only going to want to choose a single Spanning tree and everyone agree Which spanning tree we'll use Here's that same diagram cleaned up Oh You can see Oh, it looks like in this example here Sorry, I chose a slightly different spanning tree This is just yet another possibility Instead of going here I went over here Okay, well that just shows you Yet another spanning tree But conceptually The point is exactly as I'm saying Okay, so now we need an algorithm To find the spanning tree We've seen there are few I can't even agree Amongst my slides on which spanning tree Is which one But we want all of the switches to find A single spanning tree Then they can use it How are they going to do this It's a little complicated Or subtle Again because this is a distributed game You know If someone Like you or I could just see the network We could draw a spanning tree and say Here use this But the switches can't do that Firstly every switch runs the same algorithm There's no special distinguished Switch which is in charge This is actually helpful because then there's no Switch that can fail and throw your network into chaos All switches can handle What's going on in the network These switches are going to start With no information because we don't want to Have to have configuration or make assumptions Now switches can only See what's going on with themselves They can send and receive messages But they don't know what's happening In fact all of the switches are not only doing this But they're operating in parallel Because they have no way to otherwise coordinate Their actions with other switches As they operate in parallel and send messages We want these switches to continually Search for the best solution If we do this We will end up If we can solve this problem I haven't told you how to yet We will end up with a highly robust solution We'll work for any topology With no configuration Because we assume that we start with No information and have no special Switches or position in the network It will also adapt To link and switch failures And the reason that we will try And do that is that we'll have The switches continually search For the best solution And we'll have them throw out information About nodes that's not Repeated over time so if there's really Old information about a switch that you Haven't heard from for half a day You'll eventually forget that And find the best solution in the network That you believe exists now And that way If some component fails You'll converge to another spanning tree Which uses the nodes that are in the network And cut over maybe From a failed link to another redundant link I'm getting a little bit ahead of myself Let's work through some examples To see this spanning tree algorithm Because if you haven't seen algorithms like this There's a lot to it And I'll just tell you That the spanning tree algorithm That I'm going to go through Was pioneered by Radia Perlman She's shown here, you can see her picture She did much of the early work On different kinds of Spanning tree and early routing protocols In the internet She worked on different kinds of routing In the internet, the spanning tree algorithm We're going to look at And also different kinds of link state routing In particular link state routing When we get to IP networks Nowadays she works on network security But what we need to go through now Is the spanning tree algorithm Here is an outline For that algorithm These are the steps that will happen First of all To come up with a particular spanning tree We need to elect a root The root could be any node That's possible, they just need to agree on who it is So we're going to let the switch With the lowest address be the root The switches can use their addresses to look And send messages and agree on who's the root When we have the root We are going to Grow the tree From the root using The shortest distance from the root As a way to decide what branches are on the tree If we have ties Because from one particular switch You can get to the root by two different paths Of equal length We will again use the lowest address As a tie breaker to decide Which branches Are on the spanning tree And when we have the spanning tree We'll then simply turn off Any of the links, the ports Which don't forward onto the spanning tree And we can then use the spanning tree To forward using our learning algorithm Now actually One thing that's slightly complicated Is that steps one and two happen in parallel There's no phase one and then phase two This kind of logic is interleaved Whereas once things have stabilized Then we proceed with turning The ports off and using the tree for forwarding Okay now in a little more detail I've said what these nodes want to do Find the lowest node Grow a tree out From that node But they do that by sending messages So here's a few more details on the messages they sent Initially Each switch is going to believe that it's the root of the tree That sends its messages And every switch is then going to follow This same behavior Every switch Will send periodic updates to its neighbors These updates Will contain its address The address of the root And the distance in hops to the root So an example is shown below here Here's switch C It's sending out a message It might say to its neighbor Hi, I'm switch C And it's two hops away from me We will abbreviate that message As CA2 When I write down what happens Or the state of a switch Now all different switches Are going to get messages from their neighbors And they're going to process them When they hear different messages Switches are going to Update their configuration And they will favor ports Which reach better roots Lower cost roots With shorter distances Again using lowest addresses as a tiebreaker And it's quite amazing Really that if all switches follow The simple process This rule, this one two punch rule An update, the network as a whole Will converge to a single shared spanning tree Wow Okay, let's see how that could happen This is kind of tricky stuff We do need to work through an example To see what's going on Okay, so in the beginning All nodes here have a simple topology With their state Everyone thinks they're the root And they're just zero from the root Now In every round All nodes send out messages to their neighbor With their state And then they receive the messages from their neighbors And update their own state Let's look at the kinds of messages That are sent out I'm just going to pick one node So node C, this is its state To nodes A B and D, D twice They'll all get these messages And similarly, every other node will send that information To its neighbors Having got that information, they'll then update Node A, for instance, will hear from node C But A will say, well My state's better, I'm a better root Node B Will get messages in From node C And node F saying that they both think they're the root And node B will sort of say, well rubbish I'm a better root than either of you, so I'm sticking with my state Some people will change though Let's imagine node E Node E will send out And it will get messages back from D and A Well, guess what A is lower than E D is lower than E2 So E will actually hear two better messages The best one is A So E will be forced to update its state It will say, oh, okay, well, I'm still E But now I've heard this is root A And I am distance one from it The message from A is saying it was zero hops away Similarly There are going to be some other updates C is going to update To say C, A1 C now thinks A is the root And it's next to it D will also update D will actually think The best thing it hears here is from C It thinks it's next to C1 Now, I can also see here That F will update To be F From B is its best option And it's one hop away So that is the new state of nodes Let's go to round two now Round two, I've replaced the diagram I've updated the state of nodes All of the nodes send these messages Out to their neighbor So C sends the message C, A1 Out to neighbors A, B And D, twice, for instance What's going to happen? Well, A still sticks with its configuration It's the root No one can beat it B, as it gets This message from C Let's see here Unfortunately, B learns That it is not the best option B will update its state to be B A2 It's two hops from A A is a better root than B And it's going to reach The root through C C is going to keep it state It won't change D will actually update too D will hear from both E And C that there is a root A In fact, D could get to the root A By two different routes It could either send via C to A Or E to A D is going to decide that it will send Via C To reach A Because C is a lower address than E And D state is going to update From DC1 to D A 2 And I think everyone else Is about where they were Okay, so here it's cleaned up Third iteration Everyone sends out their state again We process to receive messages What happens? This is a lot of work How long can this go on? We'll see Okay, A And B And actually C and D remain where they are Now you notice here for D I said that D Is going to reach the root via C On the left-hand side There were two possibilities Actually both of these ports will have addresses So D will be able to choose the lowest port That's just a quote there E Yep, E stays the same F However, he's going to update F is going to hear That there is a better route Because B sent this message out Saying I'm B You know there's this route A I'm two hops from it D actually will also send a message out And F will update its state To be F A 3 Well, I think we've finished now Let's see Which steady state has been reached Every node will now continue To send out its message But nothing will change The algorithm will continue to run And it will time out information So that for instance If node A fails Then eventually other messages Other nodes switches here Will discard the messages from A And forget about it Because it really doesn't seem to be there anymore B will become the new route And that new spanning tree for B Will be computed and then used We can see how the node Will be used We can see how the spanning tree is used Forwarding proceeds just as usual According to the backwards algorithm The backwards learning algorithm So let's see that The network has just been turned on D wants to send to F What's going to happen? Well, now since no one knows where anyone is Everyone will forward cast Out a broadcast And forward out all ports We're only going to use ports on the spanning tree though That was our restriction So D sends to C C sends to A and B A sends down to E B sends down to F Got it, we've reached F Now when F sends back to D We're going to proceed along the reverse path Because now this switch F knows that you get to D Through here And A knows that D is down here And C knows that D is down here We're more efficient sending back From F to D In that we did not broadcast Over our spanning tree So we didn't reach all switches on the network Nonetheless You might have noticed That we didn't really use the best route There was a link here between D and F But our spanning tree didn't include it So we didn't get to use it This should give you a hint That we can do better than the spanning tree We'll see how when we get to the network layer And think more about routing We can come up with better algorithms Works well In that no hosts were changed That we've solved this problem It's completely plug and play And we can handle any topology This slide cleans things up Just shows you some of the transmissions In different colors I don't know why I think I see one area here There are two areas here I'm just going to cross one off There should only be one A will only send to E once I've written down just the transitions here So that you can see them So the forwarding And if you're sort of wondering How you would remember all of this Here's a poem, an algorithm That Radia put together She came up with the spanning tree When she was at deck Well it initially seemed like a very difficult task It proved to be easier than she thought When she worked at how to think about it She did that in the early part of a week And it gave her enough time to write a poem So there you have it You can see this algorithm And now you know how LAN switches work G'day viewers In this segment I'm going to give you an overview Of some aspects of the network layer And we'll go into more detail in these aspects In the following lectures Okay so first of all let's look at where we are In the course Well we're starting the network layer That's where we're at And yes this is IP This is the unit in which we'll learn As you can see from this Reference model We've gone through the physical and link layers So you know how to send information Bits across a link Instead of signals And you know how to send frames of information Across connected links That's great Now we're going to move on to the network layer The network layer builds on the link layer And its job is to have routers Send packets of information Across multiple connected networks So let's see how that works Well actually before we do that One of the first questions I'd like to talk With you about Is why we even need a network layer in the first place Now we've already seen With switches and links That we can build small scale networks So here's a small scale network And if we follow all of the ideas We've seen so far We would be able to send frames From one computer to another computer That's connected somewhere to those switches Pretty good If we can do this already We should ask what it is That we're going to get out of a network layer Since a network layer would seem to be doing Much the same thing Sending packets across all of the hosts And routers that are connected together Across many networks Well I'm glad you asked There were actually three shortcomings Of the switch approach we looked at That I remarked on very briefly At the end of that unit The thing was that the method we looked at Didn't really scale up to large networks Now as your network gets larger It goes from tens to hundreds To thousands up to millions of different hosts Think for a moment About how the switching approach would scale A couple of things happen One, A, there is a blow up Of the routing table So that's this situation here Every different switch in this diagram Is keeping a table Which maps for every different destination Which way to go That table is going to have millions of entries With our switching approach As the network gets bigger That's a lot, everyone needs to maintain this table A second issue Is this broadcast That's here And you remember to reach new destinations That they haven't heard of before Switches broadcast This means that the first time you send to a new destination It could get sent across the entire network Imagine sending a packet To a new destination And having it go through millions Millions of other hosts on the network Just because you weren't sure which way to go So this design doesn't scale As well as we would like A second shortcoming Is that the switch approach we've seen Doesn't work across more than one Kind of link layer It's a link layer approach So it's designed for a particular link layer Now we've already seen different kinds of links We've seen Ethernet inside Wide enterprises Ether to 11 inside many houses And 3G for cellular Mobile connectivity There are different kinds of links from our point of view We would like to be able to network them All together and send packets From an Ether to 11 Host through to a host On a wide Ethernet But the switching approach We've seen so far doesn't really take this into account It isn't equipped to join These different kinds of link layer technologies Together And a third reason Is that switches don't give us much control Over the routes which are taken Through the network The spanning tree algorithm we looked at Is pretty impressive really And that you can just plug your network together However you like And the network will be able to find A spanning tree and get packets From any host to any other host But it didn't guarantee that the paths Which were taken were necessarily very good ones Traffic in our spanning tree network Might follow this path Say from one switch to another We might go along this path of outline When in fact there was a direct link Which would have gotten you straight there That's not what you would necessarily want Because usually the most precious resource In a network is the network bandwidth On all of the links We would like to use it well And to do that we want to have good control Over the paths that packets take Through the network So when we look at a network layer approach We're going to see ways in which We can improve on all of these shortcomings We look at ways to scale The network Essentially instead of sending To an individual destination We'll be able to do all of the routing And forwarding through the network Of the wall of the work at routers In terms of blocks of IP addresses Called prefixes This is applying hierarchy So that all of these different routers Have smaller tables that won't necessarily Need to have millions of entries For millions of hosts We'll also see in the network layer Support for heterogeneity IP uses an approach called internet working In which different link layer technologies Are put together And we'll study IP really as The big case example here In which there's a lot of experience In what you have to do to make an effective network And finally Eventually we'll look at different ways Of having better control over how you use bandwidth Rather than the spanning tree We'll look at lowest cost Or shortest cost routing Which is a different framework For deciding which way to go And eventually we'll even look at quality of service Although that will come later in the course Quality of service is really also About different ways in which You would make good use of the bandwidth you have Okay so this slide here Gives you a topic list Of what we're going to go through in this unit It's fairly detailed and I don't expect you to understand All of the terms here right now You can use it as a roadmap For the units that All the different topics in lectures That we're going to go through in the different segments First of all I'm going to tell you About different network service models As well as a traditional Packet model, datagrams There's also a virtual circuit model So there are different possibilities for networks Then we're actually Going through different segments on IP IP is the big example From which we can learn a lot About how to build networks As well as understanding how the internet works So we'll go through many different Aspects of IP And we'll cover all of these things You'll get to know what all of these are And DHCP and MTU and ICMP Acronyms mean So don't worry about it now We'll go into it This that we're going to look at IP is really IP version 4 IP which are essentially Most of us probably use today with our computers There's a new version Of IP and internet that's now been deployed It's the future And that is IPv6 So to finish up on IP we'll look at IPv6 To find out what's different And what's going on with its deployment Many of you have probably heard of IPv6 As something that's coming To the internet And finally In this unit we'll look at NAT NAT is a strange kind of forwarding technology It's called a middle box It is something that many of you Probably have in your houses If you have it inside an AP That you hook to the internet Usually has NAT technology inside it We're going to see We're going to understand exactly what it is Since it's something that many of you Probably encounter today And we'll see how it does fit Or rather how it doesn't fit With the standard IP model And here that's greyed out for now Routing algorithms which we'll get to In the next unit There's actually a lot of detail in there Routing is a big and important topic But we're going to put that off for a while Before we go ahead though I want you to be able to Be aware of one important distinction And that's the distinction Between routing and forwarding They're two different things It's a little confusing because routers in the internet Do both of them So that's why I'm pointing it out Now routing is the process Of deciding which way Your traffic should go in the network This is a process in which all of the routers Participate, so routing involves Talking to all of your neighbours And saying hey who's where And do you know who's over here And generally working out What is the best way The best links you should use to Send to reach all different destinations So it's a network-wide process It's global and because of that It's relatively expensive Forwarding on the other hand Is the process of deciding What to do when you get a packet Someone tosses your packet What do you do with it? You forward it By throwing it out the link on which it needs to go And doing a few other things So forwarding of course uses The information that comes out of routing After routing you're sort of left with a table Which tells you which way to go to get To different destinations So you have to be active using this table This means that it's a process That happens purely at one node It's a local process And because of that it's fast Actually it has to be fast Because a router might have to process millions Of packets a second So we've got to be able to forward quickly Now our plan Looking ahead is to Treat these two topics differently Actually the first one we're going to do is forwarding And understand what routers do with packets Actually you might think that routing comes first It's difficult to know How to forward a packet until you know Which way they need to go But we think that it will actually prove Easier for you to understand the internet If we go through the forwarding model first And then we deal with routing later So I'm going to ask you just to Spend disbelief for now And just imagine that routers somehow Magically know which way to send packets What we're going to look at In the upcoming segments is how they Packets on their way because there's quite a lot Involved in that Now that we've got this distinction in mind Let's go for it and find out How the internet and IP work Good day viewers In this segment I'm going to talk about The different kinds of network service models So our topic Is really the kind of service Which the network layer provides To the transport layer Like all good layers the network layer Is going to provide some kind of service interface To the higher layer the transport layer In this case and so what We would like to talk about is just What kind of network service Is going to be presented By the network layer and how that Service is implemented at routers We're just going to talk about these topics At a high level and in Future segments when we dive Into IP you'll see how one of these models Is realized in detail So it turns out that there are actually Two quite different kinds of service Models that the network provides To the transport layer Both of which have been talked about a lot And experimented with in practice One kind of model Is what's called the datagram Model datagrams or connectionless Service the analogy here Is the post office So datagrams are just like Sending letters through the postal system They're self-contained units You send them you know you write You seal it up you hand it to the post office They're all treated individually The post office delivers them by looking At the address and sends them on their way This is very much like IP IP is based on a datagram service And that's really the way You might have expected the internet to look Because of that but there is another model Here too this other model Is called the virtual circuit model Or a connection oriented model And the analogy here Is one of the telephone system You need to make some kind of connection That's like dialing someone Before you can use the network But once you've made this connection You can then send data down the pipe And it will arrive out the other side So this is quite a different kind of model Both of these models Have their pros and cons And I think it's useful for us to Know about both of them Before we dive into the details of IP too much So I'll also say That both of these different models Are implemented with a technique That's called store and forward packet switching Well that's a bit of a mouthful It really doesn't mean anything too complicated It essentially means That the way routers are going to work Is that they will receive A complete packet unit And they will store that packet Temporarily While they work out what to do with it And send it out on the right link So that it's going to arrive at the destination They won't necessarily need to store it For very long They might only need to store it If there's contention for that destination Other people are trying to use the link at the same time One thing that's important About this model That's one reason why it's used widely For all Data communications networks Is that it uses statistical multiplexing To share the link bandwidth over time In the description I gave you Of having packets come in on links And simply sending them out links The other thing is we're sharing The bandwidth of all of the output links At a fine grain over time By sending different packets Maybe coming from different hosts And going to different hosts over that link And we're using a bit of buffering inside the router To queue things up if you can't get on right away So this is statistical multiplexing at work It's quite different Than dividing that link According to fixed time periods Or fixed frequency periods Like radio stations using the link Any of the advantages of Networks in terms of using the capacity well As an aside I'm going to dive into the store and forward model a little more Just to give you a better sense Of what can go on inside these routers So here's a fairly general model For all switching elements Switchers, routers, funny devices That have a lot of input and output connections Inside the network They're all going to look something like this They have inputs here They have inputs on one side So these will be plugged into ports Twisted pair wires coming in maybe And they'll have outputs on the other side Really the input and output might be combined in a port But it's more convenient for me to draw this From left to right Inside the box, it's just another box You can't tell what the functionality is Inside until you have some description Of what layer it's doing the processing at And so forth Inside the box is usually a switching fabric That's what's providing the connectivity Between different input ports and output ports And What I want to highlight here Is this also necessarily some buffering That's these pink things here That's both the input and the output Why is the buffering? Well it's buffering because maybe At the very same moment A packet came from This first input up top And it was destined for this output up top And also a packet came from another link And it was destined for this output And yet another link and it was destined For this same output All three of those inputs can't go to the One output at the same time So if the packets enter the switch They need to be stored somewhere Either on the input buffering side Or the output buffering side But we do need buffering And that buffering is just for temporarily Holding the packets to help with Our multiplexing of the output link That model I just gave you Is a little detailed in some ways And it will often suffice To think of a much simpler conceptual view Of what's going on inside a router So here's another picture of a router I've really drawn here just one output port And In the simplified model here We imagine that there is output Buffering for each output port So there's just one unit of buffering And that unit is provided At the output port That buffer, that big long buffer Is then filled up with packets You can see I'm drawing them in here As the packets come in From the input side and they're waiting To go out that output link Exactly how that buffer is managed Depends on how the router or switch is implemented There are all sorts of different possibilities But a typical one Is to use a policy that's called FIFO First in, first out That just means that whatever packet gets In the buffer first is going to go out The output link first And the rest of them will just have to queue up behind it If this buffer gets full By the way, there's no space And another packet comes That packet will be discarded Or there'll be some discard policy A packet will be discarded So you can see here an important implication Of these switching elements with buffering And that's that packets may be discarded Under load This is actually what we refer to as congestion And we're going to study it In a lot of detail later on Okay, so now you know Some of the internals of routers I'm going to tell you about the two different models We talked about in a little more detail So first of all A datagram model, here's a network And packets are going to go through this network Between different hosts In the datagram model Each packet contains a destination address So every packet contains A full destination address That's what the router uses To be able to deliver the packets onwards Now the path through the network To get from one host to another might be This path here initially The way that will work Is all the routers Here A, C And E As a packet comes in, router A Will look at the destination address And if it sees it's really h2 But let's just say it's F over in this direction A will look up in its table See what it is F And it will learn that the way afforded Is along this path to here And then arrive at C Which will go through the same process But now realize because every packet Is handled individually And a different process is responsible For maintaining the routes It's possible that the routes can change While someone's using the network At a later time A might change its mind And packets might follow a different route Through the network Thus the host at the other end Might receive its packets fine Because the packets could actually Have gone along different routes Some of the time We can just look at that in a little more detail Just to sort of complete our thoughts About the datagram model These pictures here show you The forwarding table that's used In each of those routers So here over here Maybe is C's table And you can see that it has a table Where for every different destination It has a next hop To output the packet to That next hop is really going to correspond To which output line you should send it on To send it to there I've shown you Tables here for A, C, and E And A's table actually changes Over time Let's just imagine that we're trying to send a packet From A to F And if When the packet arrived at A What A would do is it would look up In its table it would see that it was going towards F And the next hop for that is C So it would then send it over the network It would arrive at C C would similarly see the packets trying to go to F Look it up, see that it's meant to send it to E And so on, it would get through the network At some later time A's table might change You can see here that for some reason Routes towards the destination E and F Have changed They're now forwarded onwards To the next hop of B Rather than C That doesn't really matter We don't have control over it We don't know when it could happen The datagram model will still be fine These packets, when they arrive We will look up a destination like F If another packet came This time we would send it to B No B will have to look at its table And maybe now we're following that other path Through the network So this is datagrams The most popular datagram model By far is IP Sorry, example of a datagram model IP is the network layer Of the internet It's what you have to use to be on the internet So it's used everywhere Almost defines the internet The addresses I've shown you here Just shade it These are the 32 bit addresses In IPv4 They're on each and every packet Often packets might be up to Around a kilobyte and a half long So you can see the picture here shows the header Which is going to occupy some number of bytes Not that many if you've got a kilobyte And a half packet, the overhead is not too much There are various fields there And the bottom one that says payload Or TCP segment That's all of the data Of the packet beyond the header Don't worry about all of these details On the header here, all of these different fields They're the fun bits of IP that we get to go into In all of the segments which are coming up But for right now I just want you to know That IP is the most famous example Of a datagram model That's out there and we're going to look at it In detail to understand how it works Second model The second model I talked about For providing a network service to The transport layer was the virtual circuit model Virtual circuit model is Unlike a datagram model Datagram model letters Packet is independent Self-contained, fully addressed Not the case in a virtual circuit model In a virtual circuit model Just like the telephone, we go through three phases The first phase here Is a connection establishment phase You've got to set up Some connection or circuit From the person who wants to send To the person who wants to receive the information Setting up the connection Really means finding a path through the network Choosing that path And setting information about the circuit That we're about to use in all of the routers That are along that path So they'll know what to do when they see Packets from this virtual circuit Once it's set up, then there's a data transfer phase This is the useful bit in some sense The bit we want We send packets Along this virtual circuit And all of the routers along the path Ford them on to their destination And then finally when we're done Particularly if we're nice There is a circuit teardown phase In which everything is cleaned up The state about this circuit is deleted From all of the routers along the path You can forget about it And move on to new circuits So this model is called a virtual circuit Because it's fairly similar Conceptually to a telephone circuit But it's But unlike imagining a physical wire Or a certain level of resources That are reserved for a telephone call It's virtual in the sense That there's usually no bandwidth Associated with this circuit The bandwidth across the links Are still shared with statistical multiplexing So how much bandwidth you get From this circuit is just going to depend On how much traffic you send And all of the other traffic In the network that was competing for it Well let's look in a little more detail Here's our picture of our network again Now unlike Packets in a data RAM model Packets in a virtual circuit model Don't necessarily, well they don't Contain a full address All they need is a short label Which says what circuit they run For circuit number 7 So that the router will then know what to do with it Because during the connection establishment phase It's worked out what circuit's number 7 Means and where it should go So these low labels don't have any kind of Global meaning They just have to be unique to the Link, to the router where they're going to arrive In a certain link so the router will know what to do But they don't have to have any other Unique meaning In this network we might have two different circuits Going at the same time Now both of these circuits might be going Along some of the same links So here's one and here's another Both of these circuits could be used At the same time, maybe if Host 3 and host 1 Maybe if they're both sending to Host 2 Well it's just because we're going to want to be able To send multiple circuits on the one link Otherwise we haven't got much of a network Okay let's look At just a little more detail We looked at the forwarding tables inside A datagram network Let's look at the forwarding tables inside A virtual circuit network And the reason to do this Is for you to see how they're different Than the forwarding tables Inside a datagram network So now all we really need Is a table which tells us The incoming circuits And what to do with them By convention the table tells you The incoming circuit, it tells you What link they're coming from One thing arriving at A could be coming from Either host 1 or host 3 And what circuit number they have on the link They're coming in, these both happen to be Labelled circuit number 1 On their respective input links And then the output table tells us What to do So you can see that the circuit that comes From host 1 with identifier 1 Is forwarded out The link going towards C Where it is known to C as circuit number 5 What that means Is that we're going to change the label Or the circuit number Inside the packet as it goes through the network This packet Is Going in the link from A to C It's identified by 5 When it arrives at C it comes from A With 5 that's right and what happens We look it up in the table We're meant to send it on to E With the circuit identifier of 1 So we're going to change that 5 to a 1 Send the packet out the link to E It gets to E What happens, it's coming from C with a 1 It goes out to F with a 1 And so on I'll just go back now and consider Traffic from host 3 Going to F And eventually on to host 2 Let's say The reason to do this is because This circuit travelled down some of the same links So we've got to be able to separate These two different circuits on this link This example will show us how we do that Now the traffic from host 3 Comes in with circuit identifier 1 To A A has different input lines For host 1 and host 3 So it knows which one is which When it gets circuit identifier 1 In from host 3 It's instructions in it's table here And this is just one example You could construct many different tables But it's instructions here Is to send this packet onwards to C With circuit identifier 2 To change the 1 to a 2 Send it on to C At C, this comes in on link A With circuit identifier 2 Note that both of these circuits At C came in from On link A So we really needed them to have different circuit Identifiers so we'd be able to distinguish them We have, one's 9 by 5 And the other's 9 by 2 So we couldn't have called them both 1 Going out C From A's table because that would have resulted In confusion at C C wouldn't have been able to separate these two circuits But they have different numbers so it can Now we send it onwards To E with a circuit number of 2 E When it receives it from C with a circuit number of 2 Sends it on to F with a circuit number of 2 And so forth They still have different numbers so we've distinguished these circuits Okay, so that's virtual circuits Here's a cleaned up version And hopefully I've got everything right there You can check that I've got all the numbers right And work through it yourself Okay We all hear about datagrams a lot Because that's what IP is all about But I'm also here to report to you that Virtual circuits are alive and well Some of you might have heard Of a technology called MPLS, multi-protocol Label switching This is a virtual circuit like technology Which is widely used inside ISPs The way it works Is that ISPs set up circuits Inside their backbone From different ingress points To different egress points So across their network they set up all of these circuits By doing this They can carefully control The path through the network And separate traffic in different circuits And handle them differently It allows them better control over their network This means by the way That when the packet comes in To the network Since it's now using circuit switching Is going to need to add this MPLS header To the packets So you can see a packet Here's an IP packet came in And what happened inside the ISP network Is we added this MPLS header That header What's the most important part in it The label we talked about The label is this circuit identifier Which is going to tell routers inside the ISP Which way to go So this packet will then follow The labels to follow the circuit It will eventually get to the other side of the ISP And when it does All of this MPLS header And the PPP link layer header Are going to be stripped off And will then be left with the IP packet And you can then send that onwards To internet style routers That understand IP as datagrams I'm not going to go into more detail about MPLS You can look at it in your book If you want to know more about How ISPs work in detail It is worth finding out about Although it's a bit of an advanced topic For our course And finally we're able to Now that we've seen these two different Alternative service models To draw a bit of a comparison between them So just on a bunch of different issues You find that datagrams and circuits Behave a different way This is actually a good way to check your understanding Of datagrams and virtual circuits So let's go through them First issue, a setup phase A setup is not needed You just make your datagram packet Throw it into the network whenever you like On the other hand For virtual circuits A connection Setup is required Router state What do routers need to remember? With datagrams they just need their table Of how to get to different destinations With virtual circuits They actually need to remember more For every different circuit or connection To remember what to do about it So you might have a lot of different circuits On going at the same time Addressing Datagrams carry the full address IPv4 address say of 32 bits Whereas a packet might carry a short label 20 bits or less 20 bits for the case of MPLS Routing Routing essentially happens On you have to do the work For every packet, so it's on a per packet Basis for datagrams Routing for virtual circuits is really done When it's set up, and after that We're just sending packets down the circuit However it is So there's a chance to amortize work Across the whole circuit full of packets Failures On the other hand Well, in datagrams Failures are easier to mask Because we're not storing any information In the network about a circuit And how to handle it With virtual circuits we are Doing something and we have to scramble To do a lot of work to repair it So in theory, datagrams should be easier To mask failures in Than a virtual circuit Quality of service is the other way around With datagrams Every packet is handled independently So it's hard to add quality of service Because quality of service Is usually not something that applies To an individual packet Usually it applies to a group of packets Like all of the packets in a video conference For example With virtual circuits it's easier to add Because we do have this identifier For all of the packets in a circuit We might have one circuit for the whole video conference For example Okay, so now you know about these two different models Datagrams and virtual circuits And we're going to dive into the datagram model In lots more detail as we go through IP Good day viewers In this segment we're going to talk about Internet working, or how to combine Multiple networks together into one larger network So internet working Or connecting all of these different networks Into a single larger network Is difficult because the networks we might Want to connect might be very different In terms of how they operate internally They can just Be different in many ways I'll go into some in a moment And what we would really like to do with internet working Is to paper over these differences So that we're able to connect from host on one network To host on another network As though it was a single network That sounds kind of hard It is hard, it doesn't always work What we'll do to learn about internet working Is we're going to essentially look at IP IP is a case example If you like a case study But it's the most extensive case study around And it has a lot of experience With how to combine different networks together Because IP of course is the protocol That grew up into the internet That connects all of the different kinds of networks today So how might networks differ To connect them we need to understand Some of the differences Basically they can differ in a lot of ways And we're not going to be able to resolve all of those ways I talked about In an earlier segment for instance Different kinds of network service models Suppose you have a network service model Using datagrams in one network And one using virtual circuits in another network Imagine combining these It's a little like combining the post office And the telephone network It's not clear that would work very well Different networks might have Different kinds of addressing Since they'll basically They'll normally be designed by different people So they might have different kinds of addresses So it's not clear that we can even write The different kinds of addresses in the right place In other networks And there may be many different features In these different networks They can range from large to small A fairly large one for instance Might be quality of service Imagine if one of the networks Has all different kinds of qualities of service Maybe it has regular packets And packets that are priority packets Which should be afforded ahead of regular packets And another network doesn't It just has basic service How are we going to combine these networks And still provide Still honor the quality of service Arrangements of the one network That uses quality of service It's not clear Smaller examples of a difference Might be that different networks Or packets of different sizes Is this going to be the case? Yes, it's the case all of the time For technological reasons Different kinds of link-layer technologies Can handle packets of different maximum sizes This seems like a small mundane detail But even this detail Actually turns out to require a lot of work From the architecture to deal with Let alone larger things like Networks that have different kinds Of quality of service or security The job of internetworking Is to hide all of these differences Across networks with a common protocol If you think that sounds kind of tricky You're right, it is Just to give you an example And sort of get into the flavor Of how we might connect these things I'll talk about connecting Datagram and virtual circuit networks As an example So suppose that you have a source Sending to a destination The source is on a datagram network The destination is also on a datagram network And here in the middle I put a virtual circuit network Just to make things a little tricky And bring up some of these issues So let's imagine what's going to happen When you want to send from this source To this destination We have the packet here on the left So first of all You need to be able to write the destination Addressing this packet Even though the formats might be different Because one's on 80 to 11 and the other's on ethernet Suppose we could do that In the datagram network It will be forwarded Using the destination address All the way through here At a time until it reaches the virtual circuit network At that point Something needs to happen This individual datagram Needs to be mapped to the right circuit And it then needs some other Identifying information that it didn't have The circuit identifier slapped on it So that it can then go down This circuit and that circuit All the way across the network In our case it's going across At the other side We're back on a datagram network So we can forget about whatever Virtual circuit it came from I've described the transition here As a bit of a bump in the road Because suddenly you have to do a lot of Potentially unusual things For instance, this circuit needs to be set up If it wasn't set up ahead of time Then we would need to hold the packet away While setting up a circuit Because packets can arrive fairly fast So in MPLS for example The circuits are already set up ahead of time Even so We'll have to have some sort of special table To look out how destination addresses Well actually it's more than destination addresses It's how packets from the Certain source to a certain destination Should be mapped to circuits Virtual circuits that go across The ISP network So we'll have to do that at the ingress And at the egress we'll have to Take off the virtual circuit information And so forth so that it can go into The datagram network So you can see that this adds some amount Of complexity Well internet working Is a topic that's been around For a fair time In fact it was pioneered by Vint Cerf and Bob Kahn You can see their pictures here These two are widely credited As being the fathers of the internet They began working on internet working Internet working is what really led to Both TCP and IP The early internet working protocols Kind of combined some of these functions And it was only later that it was Divided into TCP, transport layer functionality And IP, the network layer Functionality for datagrams that we're Looking at now Their work tackled all the problems Of interconnecting these networks And really in some ways their key Insight Was that of internet working They would find some way to connect All of these networks Instead of for example, mandating That a single link layer technology A lower layer network technology be used If you only had that single Lower layer network technology It would be fairly easy to grow larger networks Because we wouldn't have to deal With all of these differences Like some networks use virtual circuits But others use datagrams However, if you've been around the block More than once, you'll realize That digital network technology Is something that would never have worked There are many different reasons Technical and non-technical Using different networking technologies And so it's very much to our advantage If we can have some way to combine them That's what we do with internet working in IP This slide here Is actually one from one of our Early lectures And I put it up just to remind you Of what sort of happened with IP IP Has been this layer to which we want To put all Different networks together And so the different link layers and transport layers All essentially conform to IP And IP because Connecting these networks is so valuable Has become the narrow waste Of the internet as it's called It's shown to be Narrow here because there's somewhat Of an explosion of link layer technologies And different applications Both the link layers go below And the transports and applications go above And IP is the glue That's really holding all of this together So these days if you come up with any Application or networking technology There's great pressure for it to conform To IP There was less pressure I guess in the early days As IP essentially emerged As all of the different networks Worked out what they would have to do To be able to connect together A result of a lot of that pressure Is that IP really is forced to Become something of a lowest common denominator Service If you think about it, just imagine for a moment This hypothetical case Suppose that you have two networks And one of them has good support for quality Of service, priorities Or different priority levels And the other has nothing What's going to happen if you internet Work them and combine them together You can combine them, sure Let's say you can send a packet, a normal Priority packet from one network And it will just go through But it's going to be difficult for you to preserve This quality of service feature Since inside the network That doesn't support quality of service You have no easy way to distinguish Between the high quality and the low quality Of service packets As a result, IP tends To be pushed to be the kind Of lowest common denominator It asks very little of the lower layer Of services, essentially the ability To deliver packets to where They're sent, that's it And as a result Because it asks very little of the lower link layers It's only able to provide You know, it gives a very little extra To the higher layer services Essentially, it's a glorified way To deliver packets through the network If applications want more than that When they're going to have to build Transport layers and application Processing of their own to provide Higher level services which do more for us But this approach, nonetheless Of having lowest common denominator Service proves to be very useful Because it does allow this glue To essentially combine everything together Into one internet Well here is the picture Of the IPv4 header And a payload following it Often the best way To find out what's going on with a protocol Is to look at the format of its messages Because they tell you the information That's been exchanged This picture here shows us what Is going on inside the IP Inside all IP packets And it really focuses on the IP header Because that's where the action is This last bit here, payload This is just the data That the packet is carrying If the higher layer is TCP This would be a TCP segment Now these diagrams, you might not Have really seen them much before This diagram shows us the order In which information is put in a packet You might imagine that it's difficult For us to draw a packet As a very very long Yet thin line that goes from left to right Our page isn't wide enough So instead it's common to see diagrams Drawn in this format You read it from left to right Across one layer and then the next layer Going down So left to right Top to bottom Is the way we read all of these bytes This really corresponds to the one long line So you can see here what this means We begin at the top left That says the diversion field And this diagram is 32 bits Wide so every time we go across That's another 32 bits Let's look at a little bit What's in the IP protocol Most of our looking We're actually going to do in the subsequent segments So first of all The IP header here includes Various fields which meet pretty Straight forward needs They're interesting to look at But I'm not really going to spend any other time Than this slide to go into them in detail They're things which It's fairly obvious that we'll need In some ways, there are length fields There is a total length field here Which tells you how long the overall datagram is And this one IHL The internet header link Tells us how long the header is So down to here Before the data starts There's also a checksum here Just provides a little bit of way to check the reliability Of the different header There's a version number Since this is IP version 4 That should carry 4 And a 4 there really tells us That the rest of the format is what we expect For IPv4 One one that might be a little interesting to you Is there's a protocol field This tells us the higher layer protocol That's inside IP Like for instance, TCP If the payload Is carrying a TCP segment If you remember Way back from protocol layering This protocol field here Is the demultiplexing key Which allows us to Pass the contents of the packet To the right higher layer So they're all the scaffolding fields Which really holds everything together Here are some other fields And what I'm going to do now Is just give you a quick tour To mention what fields are in there Works are going to go through And how many of these fields are used In lots of detail in the following segments So in this segment I'm really just going to point them out To you and then we'll go through them later A very important part Of the internet header are these fields The addresses, there's a source address And a destination address Since the network layer of the internet Uses datagrams, every packet That's a datagram needs to include A full address on it So that the routers will know what ascended This layer of addressing Is a new layer of addressing Which is not the link layer addressing Like an ethernet address It's a layer of addressing above it This is a new network layer address And in IPv4 32 bit addresses are used What we'll go through In some of the next segments Are how routers forward packets Based on these addresses And then there's a bit of other Information in the header You can see here that there are several fields Which are actually used To handle the relatively Simple sounding problem Of networks which transit Packets of different sizes So you know actually Ethernet and 802.11 for instance Can carry packets of different sizes The largest packet on 802.11 is too big to fit Through an ethernet So IP includes machinery That uses these different fields To handle this problem It including breaking packets Large packets into multiple smaller packets And then reassembling them On the other side So we'll look at some of this machinery later And there's really very little That's left in the header There are a couple Of fields here Which will come to eventually A fair bit later Some number of units further on One is a differentiated services field This has to do with quality of service So IP has sort of been retrofit In terms of quality of service And we'll talk about that Near the end of the course almost Something we'll get to sooner Is there is a time to live field This field is used in conjunction With the error reporting protocol Called ICMP It's actually used for trace route We looked at trace route And that uses this field quite heavily So in a few segments You'll learn how that works Okay so What it's time to do in the next segments Is to go into some of the functions That are behind those fields in detail Good day viewers, in this segment I'm going to talk about IP addresses And IP prefixes So I've talked a fair bit about packets And we know packets carry addresses and so forth But I haven't really gone over any of the details So far of those addresses inside packets That's what we're going to do now In this video is we take a deep dive And look at IP addresses And as well as IP addresses There's a network called IP prefixes Which are really blocks of addresses And just a quick note here What I'm going to cover is for IPv4 The version of IP which is Mostly deployed in the current internet It's going to change when we get to IP version 6 Later on So IP addresses IPv4 uses 32-bit addresses When we get to IPv6 later on We'll see that IPv6 uses 128-bit addresses A much larger address space For that is that the 32-bit address space Is near exhausted But for now We'll just concentrate on those 32-bit IPv4 addresses These addresses are written in what's called a dotted Quad notation There are four 8-bit numbers separated by dots Because of course the four 8-bits That's where the 32-bits comes from You can see here I have Binary representations Where all of the bits are spelled out In the groups of A's, B's, C's and D's And on the other side are the decimal numbers That they correspond to So we might be able to write out A number in binary But we're not going to want to work with it In that format it would be tedious Instead we'll convert the 8 groups Of bits into the decimal equivalent And write them in this dotted quad notation As four decimal numbers They're going to range from 0 to 255 Since they're 8-bits Each number separated by dots So let's do an example We want to write it in our dotted quad notation So what's it going to be I'm going to start at the end And this last number All zeros and a 1-bit That's the equivalent of the decimal number 1 So there's a 1 at the end I just know that because the 1 is in the 2 to the 0 position Above that all zeros That's also the decimal number 0 That's not too hard Now we have to do a little bit of work For the 1 above it We have a 1-bit on in the 2 to the 0 position That's a 1 in the 2 to the 1 position That's a 2 The 2 to the 2 position a 4 The 2 to the 3, 8 And the 2 to the 4, 16 So if I add up all of those numbers 16 plus 8 plus 4 plus 2 plus 1 I will get 31 So this is the binary representation of 31 And going on over here This has the 2 to the 2-bit And the 2 to the 16-bit Set so when you add them up you get 18 So that's the binary representation of 18 But you might be a little Rusty or unfamiliar with all of this And it can take a little while to get started But you can usually work through Binary addresses It just takes a little getting used to That's an IP address I also want to tell you about this concept Called an IP prefix IP addresses are allocated in blocks Called prefixes And that's what routing in the internet is going to use That's why we're going to talk about prefixes Well what is a prefix Well it's really just this block Of IP addresses But it's a block that's structured in a specific way All addresses In an L-bit prefix Are going to have the same top L bits So you can see here's L Here's my prefix length of L L can range from 0 up to 32 Although commonly it will have values such as 16 Or anywhere from 8 to 24 Now if I have The prefix length of L bits That means that the top L bits In this number are going to have some fixed value And the last bits Here I can just write X as here because they can take on Any of the different possible binary patterns So this means That since the top 30 The L bits are fixed and there are 32 bits Overall we have 32-L bits At the end that can vary So there are two to the 32-L Addresses in an L-bit prefix For instance A 24-bit prefix Is going to have 8 bits left over So there are 2 to the 8 Or 256 addresses In a slash 24 In a 24-bit prefix These addresses by the way Are also going to be aligned On a 2 to the power of 32 minus L boundary So prefixes with 2 to the 16 addresses in Will start on a multiple of 2 to the 16 Rather than any arbitrary binary Position This is just like talking about Numbers that are powers of 10 Aligned on multiples of 10 Numbers that are multiples of 10 10, 20, 30, 40 and so forth And there start On multiples of 10 Rather than 22, 32, 42 and so forth Okay We also want to write IP prefixes How are we going to do that We need a notation We're going to use this IP address Slash length notation The address will be the lowest address In the prefix written in our Familiar dotted quad notation And the length at the end Slash length will be just the length Of the prefix in bits So for instance 128.13.0.0 Slash 16 Means it has A 16-bit length prefix So that means the last 16 or 16 bits will be free So the Addresses will range from the bottom address Which was given as part Of the prefix to the same address When I turn on all of the bottom 16 bits so you can see When I do that I get to 128.13.255.255 This means that Slash 24 And this is how you Pronounce something like this Slash 16 for instance Previously a Slash 24 Will have the last 8 bits free So it will have 2-8 or 256 addresses Similarly a Slash 32 Really means one address Let's do an example To see how all of that works So here is a number written out in binary Except I've xed out the last bits Because they can take any value How will we write that In our notation Well we have the last 8 bits free So the first 24 bits are fixed This is a Slash 24 prefix Okay and to come up With the value well I'll set For the lowest address I'll set All of the x's to 0 So we have a dot 0 Above that is 0 and above that Well I have to do my binary to decimal conversions But luckily I'm using the same examples as before So you might recognize that As a 31 and an 18 So this prefix is 18, 31, 0, 0, Slash 24 Let's do another one Okay, this other prefix That I talked about above 128, 13, 0, 0, Slash 16 Well we said that the first 16 bits are fixed The last 16 bits are free So I'm going to write x's for them We sort of fill them in as 0's Just to write the lowest address in the prefix Above that I have 13 I want to write that as binary Let's see 13 in terms of Powers of 2 is 8 Plus 4 plus 1 So I'll turn those bits on And I'll turn the other bits off 1 on the 8 bit, 1 on the 4 bit And 1 on the 1 bit And everything else is 0 So this was 13 And I also want 128 for the top bit It sounds a little hard but it's a bigger number But 128 is actually a power of 2 That is 2 to the 7 So the top bits are going to go on And all of the other bits are going to go off And there we have it There's a little more terminology That goes with prefixes too That we need to know We can talk about either more specific Or less specific prefixes More specific means that The length of the prefix is longer That is narrowing the range of addresses Because we're pinning down More of the bits at top So a more specific prefix Will have a smaller number of IP addresses Similarly a less specific prefix Has a shorter prefix That allows more of the bits to be free So it will have a larger number Of IP addresses And I'm spelling this out Because it's a little counterintuitive at first But you can see on this diagram As I go to less specific The prefixes get shorter But the number of addresses That can be within the prefix Gets larger Similarly as I go to more specific The length of the prefix gets longer But the number of addresses inside that prefix Is smaller So that's IP prefixes Now you know about IP prefixes There's a little more I can tell you About IP addresses though And I'm going to start with Classful addressing Which was used historically So we use IP prefixes today Originally IP addresses Came in fixed size blocks So the prefix length if you like Was fixed and pinned down as part of the address In particular class A addresses On here had The first 8 bits were used For the network portion The last 24 bits were free And class A addresses were identified by leading 0 And then you could set the remaining 7 bits Of the network mass To whatever value for the different class A Addresses So you can see actually that a class A address Corresponds to a slash 8 Since only the top 8 bits are fixed So there are a lot of addresses in a Class A address To the 24 that's large Similarly if you do a little bit of work You'll see that the class B And class C addresses here Are equivalent to our slash 16 And our slash 24 prefixes Although of course the top bits are constrained In these patterns 1 0 and 1 1 0 So we can identify the class A B or C addresses Just from looking at the top portion of the bits Now addresses still have These top bits that identify Whether they belong to a class A Or class B or class C networks But the classes themselves are ignored If you like the prefix notion That we use today Is a generalization of these classes Which is used instead Now instead of only being able to have Slash 8, 16 and 24 We can have prefix lengths in between And so forth And that's why the top bits of the address Are left in there for compatibility But they're ignored There's also one important distinction For addresses that will come up As we use them in the internet Is between public and private addresses So far I've been talking about public IP addresses So for instance 18, 31 And here I'll use .0, .1 Is a public IP address Public IP addresses are any address Which is a valid destination address And can be used on the global internet So you can send packets to that address And from that address Well before you can use a public IP address You've got to get one from somewhere You can't make it up So they need to be allocated to And I'll talk about that in a minute The problem with this allocation Is they're mostly exhausted We've almost run out of them That's why we need IPv6 On the other hand And this is the distinction I want to draw There are also a small number Of what are called private IP addresses Private IP addresses Are addresses that you can use freely Without anyone giving them to you In your own private network And that might be a small home network Or a small company network You can just assign these addresses to computers You might have seen some of these addresses Already Anything in net 10 Or often home networks for instance Use 192.168.0.0 Slash 16 as their prefix So these are private addresses But of course Pretty much any network Even a private network you make You're going to want to connect it To the public internet So you can talk to all the computers out there To do that You will need to get a public IP address You'll get that from your ISP And you will need to use a technology called NAT to translate Network address translation To translate between these private addresses Which are only valid within a private network And public addresses Which can be used on the public internet We'll get to NAT in a later segment And I'll explain how it works For now You should mostly think in terms of public IP addresses When we're talking about addresses On the open internet That's what we mean Well to complete the picture Let me finally tell you Where these addresses come from The allocation of public IP addresses Follows a hierarchical process In the beginning On the left hand side of this diagram All addresses belong to a body Called IANA That's the internet assigned Numbers authority Something like that And what IANA does It owns all of the address space Just a factor It delegates different portions Of the address space To all of these regional bodies These are called RIRs Regional internet registries And they have different names There's ARIN Is the name of the internet registry The RIR That serves the US and Canada North America Other places Maybe Antarctica Something like that There's APNIC For the Asia Pacific Actually maybe they serve Antarctica RIPE LACNIC For Latin America AFRINIC And so forth These are all regional bodies What these bodies then do Is the regional bodies Then delegate IP addresses To companies in their regions The companies apply for these IP addresses And they get them And then finally Once your company has an IP address It assigns those addresses to computers In its network Either its customers Or in the case of an ISP Who then assign them to their computers Or in a small enterprise You would assign them directly to your computers This is done with a protocol Called DHCP in these days And we'll get to DHCP again In a later segment Okay, but now you know A lot about IP addresses G'day viewers In this segment We'll talk about how routers forward packets So as we get into our topic I do want to remind you Of the distinction between routing and forwarding Forwarding is the process of handling a packet When it arrives Sending it on its merry way Routing is the process Of computing all of the paths through the network So that you'll be prepared Later on to forward packets Because you'll know Which way to send them When they arrive Now, we're actually going to We're just looking at forwarding Right now And really I would also flag That we're going to be looking at How IP does forwarding So this is really learning about IP Rather than the more general topic As for routing We'll get to that much later So for now Just suspend disbelief And imagine that routers Have all worked out the paths Through the network And we're just looking at How routers actually handle packets When they arrive Before we get into The meat of that topic Let me just recap Where we're at in the network layer We really had several goals For our network layer To go beyond What we could do in the link layer With simple switch networks We wanted to be able to scale To large networks That's what we're getting to In this video right now Seeing how we use The hierarchical structure Of addresses to scale We also wanted to do other things Support diverse technologies I've talked about internet working I'll talk a little more About that later And we also want to use The bandwidth Of the different links In the network well This is covered by different Routing formulations And we'll get to that much later So let's look at how We scale to large addresses With IP 40 Well without much ado I'll simply tell you That we use IP prefixes To our advantage To achieve scaling And here's how it works The key observation here Is that all of the IP addresses On one network Belong to the same prefix That means that in our Forwarding table What we can do is simply Put down one entry For the entire prefix And that way If we encounter any packets That are destined to IP addresses Within that prefix We'll all send them to the same place Whichever way we should go For the prefix Here's an example of that And you can see here Is a forwarding table For a particular router here This router here And the forwarding table Only has a couple of entries But they're prefix entries So the first prefix here That's a slash 18 And the second prefix Is a slash 22 There are different next hops So there are different things You do with addresses In each of these prefix But both of these prefixes Could cover a relatively Large number of addresses Many different destination addresses That different nodes Were sending packets to So even though There might be a large number Of IP addresses represented here And you can work that out From the prefix links We'll get to that In just a minute actually You can see that The forwarding table Is quite small It scales well Now it's not quite as simple As I'm making out For IP forwarding And the reason is this The prefixes in the table Can overlap If you just imagine Sort of a very basic notion Historically with classful addresses The blocks didn't overlap But with prefixes You can have prefixes Of different links And they can overlap one another To resolve this We use a forwarding rule Called the longest matching prefix rule Which I'll tell you about And this rule Is able to combine the hierarchy That we get from using prefixes With a little bit more flexibility Even though the rule The longest matching prefix rule Was a little more complicated Than a straightforward table lookup The rule is simply this For each packet That you're trying to forward You look at its destination And you find the longest prefix Entry in the table That contains the destination address That is going to be The most specific entry This is why it's called The longest matching prefix of course So we might find in our forwarding table That there are several That the destination address fits Within several different prefixes We have We want the most specific of those And then we'll simply forward The packet according to the rules For the next top router For that most specific prefix That sounds pretty simple Let's work through an example Just to see how these prefixes Overlapped with what it means So here's the same table From before With the address ranges And I'm going to show them on this figure Here IP addresses go up From all zero at the bottom To 255.255.255.255 at the top So let's put some of the addresses on here And show where the ranges are Okay, so this first prefix here The bottom address Is 192.24.0.0 That's down here The first address And so I just drew that in here The next prefix in the table Its bottom address is 192.24.12.0 So it's higher And I've drawn that here We don't have the top addresses yet Let's try and calculate them Okay, so for the slash 22 prefix That fixes the top 22 bits Leaves the bottom 10 bits free So we will calculate the top address By taking 192.24.12.0 And turning on the bottom 10 bits Well, if I do that I'm going to turn on the bottom 8 bits For sure, that gives me the 255 up here And I'm also going to turn on the top The bottom 2 bits of the next one That's equivalent to adding 3 So we go from 12 to 15 And I end up with 192.24.15.255 So you can see for the slash 22 prefix I've coloured that with the pink diagram And I've made it longer Because it's a more specific prefix What about the top of the other one? So for this other prefix 192.24.0.18 Well, this will have 2 to the 14 addresses in it The last 14 bits are going to be free So I've got to turn on the last 14 bits So what will I get when I do that? Well, I started from all 0s And I turn on the last 8 And I get 255 Then I've got to turn on another 6 So it's going to be 00 And then all 1s And then 6 1s If you convert that from binary to decimal You should get 63 So the top address will be 192.24.63.255 This is the grey block Where we forward to D This is a much bigger block And the other pink block is within it And I've drawn this to be not as wide Because it's a less specific address Well, anyhow This is a representation of our 40 table Let's try and use it for 40 now So I have several addresses here Number 1, number 2, and number 3 Let's see where they go The first one, number 1 192.24.6.0 Well, where is this on our address range? Well, it's somewhere in here Because it's below 12.0 So this is number 1 So guess what I want to do to forward number 1 It's in this grey region here So I'm going to forward it to D Okay, what about 1 Let's do the last one What about number 3? 192.24.54.0 Where is that? Well, it's above .15.0 And it's below 63.0 So it's going to be in here somewhere Number 3 So number 3 is also going to go to D Okay, the middle one You can probably guess what's going on here It has a .14.32 So that's actually somewhere between The lower and higher address of B So it's going to be in here Number 2 Number 3 is in here somewhere So this one will go to B So you can see how we use the forwarding table to do this And this is the longest matching prefix algorithm Okay, so there's one other thing I can tell you about Routing and forwarding, sorry And how we scale it Using a little bit of hierarchy and so forth There's actually a distinction in the Internet Between hosts and routers So in the Internet in particular, routers do the routing So hosts don't do the routing Hosts just send packets to routers That might sound a little obvious But that's actually a little bit of a choice In particular, what I'm trying to say here Is we place the responsibility Of knowing which way to send packets For all IP addresses on routers They need to do the routing So they'll be able to afford to all different destinations Hosts on the other hand Are on a local network So they might be able to reach Hosts on their own prefix But they send any remote traffic That's off the prefix to the nearest router So hosts really don't need to participate in routing They just need to know the nearest router And you can see here, the host is saying Okay, if it's a local, I'll send it on my network But if it's not, just send it to the router Because the router will have to work out Which way to go and it might be different ways For all sorts of different IP addresses The reason that I'm bringing this up now Is that this distinction between Hosts and routers fits very naturally Into our longest matching prefix rule In particular, we can formulate A forwarding table for hosts Which has this kind of behaviour And we just use it by using A default route to 0.0.0.0 Slash 0 That might sound a little odd But a forwarding table for a host Will look something like this It will have the network prefix So hosts will need to learn that And if you're sending to a destination In that address, it's to a local host So you just send direct To that next host because it's on the local network Then we have this funny entry here 0.0.0.0.0 Slash 0 Well, what is this? Let's think about it It's a 0-length prefix That means that the remaining 32 bits That's everything can be freeing So this is really an address Meaning everything, all IP addresses Is encoded simply using a prefix notation And the next top for that is Just send to the router So that way we'll let the router worry about it So our longest matching prefix rule Lows us to encode this fairly Simply and directly You can see here what I'm getting at Is the flexibility of the longest matching Prefix rule In particular, we can use Longest matching prefixes in a couple of different ways We can add less specific Entries to a forwarding table To provide a kind of default behavior You saw that with hosts Sent to the router But we might also use it for routers within a network For instance, you might have an enterprise network And routers in it might know which way to go For all sorts of your different networks But for other IP addresses Which are outside of your network You might have a default rule Saying send it to your ISP router And your router could simply use the default rule To get packets out of the network Instead of providing defaults We can also provide special case behavior You might take a particular address And request by using a more specific prefix That they get special handling at a router And maybe send it a different way Than they would normally This might be for reasons of performance Maybe this is a voice over IP call And you want to route it over a low latency path Or it might be for reasons of security This might be suspicious looking traffic And you want to send it along the path To a special bot to inspect all of the packets More carefully and see if this is a security problem This could be for any number of network management Reasons you might like to come up with The point is that we get a certain degree Of flexibility from this longest matching prefix rule And we can use it to our advantage When managing networks Well the flip side of this is to talk about The performance of the algorithm How well does the longest matching prefix perform Well in terms of table size It performs very well We use hierarchy to get a nice compact table And by using prefixes of different sizes We can actually get quite a compact table Note that This depends on people Using addresses Which have a reasonable prefix Length Or actually rather small prefixes Which contain a large number of addresses So less specific prefixes Good grief, that's all I'm trying to say here Actually if everyone uses very specific More specific addresses We won't get as much compaction as otherwise And another aspect of performance Is just how fast the lookup operation Runs at routers It turns out that the longest matching prefix rule Is computationally more complex Than a simple table lookup Actually it can be quite so In some cases with strange overlapping entries This was a concern When we were trying to build routers In the early days and make them fast Today it's not really a performance concern You can just get silicon which will do this And you don't need to worry about it So I wouldn't worry about it too much If I were you And finally I've really just talked about addresses for 40 I do want to point out that it's not all about addresses Here's our picture of an IP header again And you can see the addresses were in here But I've shaded in pink everything else In the header and there are a lot of other fields What do all of those other fields have to do with 40? Well there are many other small aspects Of 40 We've touched on some Well actually I'll tell you about others In the future And let me just briefly mention a few You might have noticed there's a TTL field here A time to live field This value is decremented as you go through routers So that if it hits 0 You can throw away the packet The reason for this is to protect against routing loops What if there's a mistake and packets are going round and round In a circle They can do this very fast and clog up the network There were also other fields there such as a checksum A header checksum is used to Just check that the header values Are all okay to provide A little bit of added reliability There are fields in there For a fragment in large packets If the packet is too large to send it to the next link We're going to break it into pieces We'll cover some of this in a segment that's coming up There are other fields in there To be able to deal with congestion The network may be congested And these other fields help us to send congestion signals To hosts And there's other functionality to be able to Generate error messages that goes hand in hand With the IP That will help us manage the network We'll get to that later And there are even other optional fields Which I'm not going to cover in any of these videos If you're interested in all of this You can look in your text for more information A little more about IP But we will get to some of the more important aspects Quite soon Good day viewers In this segment we'll talk about ARP and DHCP Two key helper protocols that work with IP Okay so I might have realized that there are a few gaps In my explanation of IP forwarding In fact we need a little bit of extra functionality To make things work And in particular to answer a couple of questions First of all Nodes need to be able to get an IP address from some place To use as a source or a destination And we'll look at how the DHCP protocol does this Next Even to be able to send a packet across a link We need to be able to fill in both IP addresses And link layer addresses And That raises a problem of mapping between the two Going from a destination IP address To what the link layer address is There's a protocol called ARP Which takes care of this that we're looking at Both DHCP and ARP Are actually pretty good examples Of just the real world kind of glue You would need to make designs work They're very necessary for IP To work in practice DHCP provides a little bit of IT support If you will Whereas ARP provides a bit of glue between all of the layers To join the network layer to the link layer Okay, so let's look at those questions The first question here Is getting an IP address So imagine that you're a node You know, you're just being powered on You wake up for the first time You don't know very much In particular you'd like to know what your IP address is What the IP address of the nearby router is What network you're on And so forth One thing you do know That I'll point out now Is your Ethernet address The reason you know this Is that the Ethernet address is set on the hardware On the network interface card itself So when a node wakes up If it's attached to Ethernet It usually knows it's Ethernet address But it doesn't know it's IP address So let's look at how we solve that problem Well, it could be solved In a couple of different ways Now in the good old days You would simply set up an IP address On a computer by manually configuring it So someone would fill out a configuration file Actually this was really not that long ago In the 90s You would do some of this So you just add the information by hand You might wonder why this is necessary For Ethernet We simply have the address On the NIC so that no one has to Encode it later on For IP however The address you have Depends on where you are in the network And that's because remember To be able to forward efficiently We required that all nodes That are sitting on the same network Belong to the same prefix So where you place the computer Is going to affect its IP address So it can't be set at the factory The second alternative Which of course we're going to follow And use today, it's very popular Is to come up with a protocol For automatically configuring the IP addresses Of new nodes as they wake up The protocol is called DHCP Dynamic host configuration protocol And effectively what it's doing Is shifting the burden From the user of a system You and me to some of the IT folks Who help manage the network If you like in the manual configuration days Everyone with their own IT For all of their different computers So let's learn a little about DHCP I've already told you DHCP Is a dynamic host configuration protocol It's been around since about 1993, it's now very widely used Its main function that we're going to look at here Is to provide a computer With its IP address Actually it doesn't give it to you permanently It leases you this IP address So when you wake up the DHCP server Will give you an address and say You can use this for the next day The address is really belong to the network So the DHCP server can give them out Over time DHCP also Provides a lot of other parameters too It's a general configuration parameter For hosts, it's quite useful Not only an IP address But other things we would need to know To use the network For instance, you might want to know The IP address of your local router The network prefix you're on So you can decide whether you're trying to send To another host on the local network Or a remote host But you could imagine would be very useful Such as a time server To be able to set your clock And a DNS server That's to be able to translate host names Like www.cs.washington.edu Into the IP address Here's the protocol stack for DHCP DHCP actually runs As a client server application Between the client that's on Your machine when it's woken up When it's trying to talk to the network The server which is running somewhere in the network It runs on top of UDP You can see here on the stack And it uses UDP port 67 and 68 to identify itself Actually If you remember all the way back To the beginning of the course According to this diagram, DHCP is an application It's really one of the first applications We're going to look at It's a little funny because from the network's Point of view it is an application You could write DHCP using the socket interface And all of that sort of API we looked At although the one for Datagrams not streams However, from most people's point of view DHCP is a protocol hidden in the system They wouldn't necessarily think of it As something that's an application So let's see a little more About how DHCP works There's in fact one crucial issue That it has to solve And this is the bit in some ways That's most interesting for networks That's the bootstrap issue If your node is trying to Contact someone to find its own address Because it's just woken up How does it know the IP address Of who it should contact to ask it's address I mean it's just woken up and it's not configured If we could configure that We could probably work out how to configure the IP address So there is this bootstrap issue Of just waking up and getting things done Now the answer is When your computer wakes up It doesn't know the IP address Of the DHCP server It's trying to talk to on its network Instead it uses Broadcast communication It sends a packet on the network That is a broadcast packet The network will then deliver it to every host On the network One of those will be the DHCP server That host will realize that the packet Is intended for it And it will further process it And begin answering DHCP messages The way you send a broadcast Is it uses a special destination address By convention the broadcast address Is made up here of all ones So for IPv4 Which uses 32 bit addresses When you write down the all ones And express that in the dotted Quad notation here You see that's going to come out to 255.255.255.255 When we write all ones In a different format The format of an Ethernet address That's 48 bits It looks something like this The reason is that an Ethernet address Is used in written As 6 chunks of 8 bits And each 8 bit quantity Is expressed as 2 hexadecimal digits Where a hexadecimal digit Goes from 0 Through f So f is the highest That has all of the ones on When you turn all of the ones on The broadcast address on an Ethernet Is ffffffff So there you have it Broadcast is a key component of DHCP Now that we know it uses broadcast Let's talk about what the exchange is This is a timeline diagram So time is going to go down the page As usual here And we have a line here To represent the client That's how you are a computer that's just broken up And the other to represent a DHCP server Now these need to be within One IP hop of one another So they're on the same The same network I see here the same link The same sort of connected links You could actually have switches In between them And that would be just fine So we're really like one IP hop Of connectivity That's going across a series of links Which are joined by switches Which is logically still one link How does DHCP work This is what the exchange looks like First of all A message called a discover That's basically saying Hello is there a DHCP server out there I'd like to contact the DHCP server So I can work out what my IP address is The DHCP server will then reply With An offer The offer packet is essentially saying Hello yes I'm here And you could use this address if you would like If you want to use it Your host will then send a request Saying yes I'd like to take that this particular address And if that's okay Assuming it will be if you're picking the one That's just been offered to Then the final step is The DHCP server will send an act An acknowledgement to say okay you've got it Now we're both clear on that The acronym for remembering this is Dora D-O-R-A And let me see yes okay I've probably got it right Here's a clean up version of that And I've noted The first packet here at least Often more packets in the exchange The request packet for instance So The request packet too Is broadcast So it is sent to The IP address and the Ethernet address That's all ones and so It will be received by this DHCP server And it will also be received by all other hosts On the network and they'll simply throw it away Because they won't have a DHCP server Running on port 68 Okay so that's the exchange To get an IP address The first time Once you've got an IP address The more lightweight operation is simply to renew it Remember we said this is a lease So DHCP server might give you an address For a day, for four hours For anything like that Once that time period is up You're going to want to get another IP address What you usually want to do is not change your IP address But keep the same address And say yes I'd just like to renew my lease If that's the case you can use an abbreviated sequence Just the last two packets in this exchange The request followed by the AC The protocol is actually Much more interesting if you'd like to look at it In detail It supports for instance Replicated DHCP servers So that an organization can set up several DHCP servers All of which run in parallel And using broadcast communication Helps us here, that's why the packets are often broadcast Because that way all of the DHCP servers Can see What messages the clients are sending And coordinate themselves But this is a little advanced for where we're at We're just going to skip over that I put that out in case you're interested Okay We'll move on then To the second problem The second problem essentially was How do you send an IP packet To do that you need to be able to craft A header and the header has All sorts of addresses on it Source and destination IP addresses And destination link layer addresses Now The question here really If we're trying to send a packet to a certain IP address We already have the address is Where do we get the link layer addresses To go with the frame to be able to send it Over the local link If we might have an IP address Here And a client might know That it's trying to send a message to a router With a certain IP address But it still needs to make the packet Not be sure what link layer address to use So let me Just try and clarify that a little bit By drawing a diagram So we now have a client Trying to send, well a node Trying to send to another node on the same network To do that It needs to craft a packet So here's a picture of the packet You can see there's the payload at the end But in front of it we have The IP header And in front of that We have the link layer header Those headers have addresses in And I've just shown the addresses You have a destination IP address That's the target, we'll assume that's known Because you've got to know somehow If you want to send a packet to someone You need to know their address There's a source IP address That's your address, where do you get that From DHCP, we just answered that question Now we need to be able to make The link layer addresses on a frame To send something into the network Well, the source Ethernet address We can get that, that's on our NIC Remember we said these were configured at the factory So you just sort of ask your NIC What its address is But we also need this one here The destination IP address Which is the right destination Sorry, the destination Ethernet address The right address which corresponds To the destination IP address Where do we get that address The answer is that we get that address By using the ARP protocol So let's talk a little bit about ARP Here's the protocol stack for ARP ARP stands for If I didn't say this already Address Resolution Protocol So it sits directly on top of a link layer Such as Ethernet There are no servers involved here So it's actually different than DHCP Instead, since ARP by definition Is going to help us send a frame To a node on the local network We're going to Essentially interrogate everyone on the local network And ask the person who has The right address we're trying to talk to To just chime up and tell us What their Ethernet address is So ARP is just going to ask the node With the target IP address To identify itself Like DHCP, it's going to use broadcast To reach all of the nodes So that its message will go to the target node As well as everyone else Here's how the exchange works It's simpler than DHCP We're still operating on the one Logical link here Even if it's a series of physical links Connected by a switch So there's no, we can't go across Routers with this protocol In this protocol we simply send a request And then the request is Broadcast across the network Everyone will get it The request is going to be looking for the Ethernet address that corresponds to a certain IP address Whoever has that IP address Will get the packet Say oh, someone wants to know my Ethernet address Look up what their Ethernet address is And send it back to them In a reply So here's that cleaned up And I've also shown you the Sort of conventions for what these Messages contain The request usually is viewed as A who is message It's essentially asking the question Who is or who has IP address 1234 Everywhere including To the node with IP address 1234 That node address Will send a reply saying I do I'm the one who has that IP address At my particular link address And it's this thing here So the node who's asking Can then have the mapping between them And it now knows the destination Ethernet address to use So it can fill in the frame Send it and we're happy We're done with ARP I'll just make a few comments ARP and DHCP contain elements of Discovery protocols So these are protocols that help nodes Find one another They're very useful actually And there are more of them Some of you might have heard of Zeroconf Or if not Bonjour The Bonjour protocol is Apple's implementation Essentially of Zeroconf These nodes help other nodes Find one another For many reasons Often it's to do with configuration In these protocols They use the broadcast trick that we just saw Where a message on a link On a one logical link Will be delivered to everyone on that network So it will get So this is a good way to search for someone It will get to the party you're intending And you do this since With this Discovery protocol You're trying to find a node If you already knew it you'd be able to send a message to it directly But if you're just searching if it's there Nearby printers for instance This is how when you open your Mac it might be able to show you Nearby computers to connect to They're all discovering one another with these protocols So this is a very handy kind of glue Which is used very much in practice Okay Good day viewers In this segment we'll talk about the issue of packet fragmentation So our topic here Is really an issue that arises Because of the heterogeneity of different networks When we connect networks together They might have different maximum packet sizes That can go through the network If that's the case You could send a large packet in one network And it wouldn't fit through in another portion Of the network We need some way to handle this issue And in this video we'll look at Well a couple of different approaches One is simply having routers inside the network Split the packet up into pieces Each of which will fit through a link Because it's not too big And an alternative to that is Discovering, having hosts discover What size packet Will fit through the network So let's just recap some of the problem Before we dive into the details of the solution The problem in a nutshell Is that different networks Have different maximum packet sizes You'll often see this Referred to as an MTU Or maximum transmission unit That's just a fancy way of saying The largest packet which will fit through this network It would be wonderful If we could just kind of mandate One single maximum packet size Then everything would be simple A lot of this issue would go away Or maybe in theory But this is not the case This is never going to happen All sorts of different kinds of network technologies Have different maximum transmission Unit sizes We're stuck with this problem for many reasons Just as a quick example The Ethernet we've talked about The very popular wired technology Permits packets up to about a kilobyte and a half On the other hand Wi-Fi, and this is garden variety For both of these technologies Permits packets up to about 2.3 kilobytes And different versions of Ethernet And Wi-Fi actually have Different maximum packet sizes That they will allow through So we're really stuck with this issue Now the problem arises Because not only do different networks Carry different packet sizes But we would like to send packets As large as will fit through the network The reason for this is Because of efficiency If we send large packets We'll spend fewer bits sending those headers And routers will also have to process fewer packets To get the same amount of information through So we want a large size But what large size What size is too large And what size is okay This is difficult to work out Because a host on the network Knows how big packets Can send through the link to which it's attached But it doesn't know what size packets Will fit through somewhere Way on the other side of the network If it's sending packets to a particular Destination out there There are two different kinds of solutions That we'll look at to this problem One is fragmentation Which is simply the word for a splitting Large packet up into smaller pieces That will fit through the network This is the classic method that's used in IP It's somewhat dated now But it's depreciated in favor of another method The other method that we'll look at Is a discovery method This is a method that hosts Can use to find ahead of time The largest packet which will fit through the network Once they know this They can simply use this size And they'll avoid unnecessary fragmentation Okay So let's look at how Fragmentation works This picture shows an overall setup I have a source Here on the left And a destination Here on the right And I simply want to send a packet across Now, the way fragmentation works Fragmentation will happen At routers inside the network Our source here Sends a big packet The biggest packet which would fit on its link Its first link And it looks like that's fairly big When we get to some router Any router in the network Then the router will fragment it And you can see that's exactly what happens At this first router We've now divided the packet Into two different fragments A long one which was probably the longest size That fit over that link And then a leftover chunk Well, those fragments Then proceed through the network They're routed independently The routers treat them all as individual packets As it were And these pieces will then go through the network And arrive at the destination When they're at the destination The destination will do the hard work Of reassembling these pieces Completing the jigsaw puzzle To produce the original packet And that original packet will then be handed up To the transport layer So the transport layer won't know Whether or not there was fragmentation You'll note here That there's a little bit of asymmetry Fragmentation happens at routers Where it needs to happen But reassembly happens at the Ultimate receiving host And the reason for this Is to reduce the load on routers We don't want them to have to reassemble the pieces Buffer things and complete a jigsaw puzzle To put them back together That's a lot of work potentially And we would like to Push all of this work to the end host Where we can to reduce the amount Of work routers have to do So they can forward packets at very high rates So going into more detail For fragmentation Fragmentation information Is conveyed using header fields On the IP packet I'm showing you here a picture Of the format of the IP Before header This is the same picture we've seen before And I've shaded In pink some of the fields Which are used for fragmentation We'll see how in just a minute So those fields are identification This sort of provides a number on a packet We'll have a stamp that's unique for a packet That we can use to put pieces of it together If it's broken There is a total length field That's highlighted Because the length field will change If we break the packet into pieces We'll update it to reflect The length of the pieces, not the Complete packet There's a fragment offset field This field is used to indicate Where in the overall packet the fragment Belongs, what it's offset or position And then there are a couple of control bits MF Here stands for more fragments That's used to indicate Whether there are any more pieces So in this way a receiving host Can know whether it has all of the pieces Of a fragment, or all of the fragments Of a packet There's also DF which we'll see later Which is don't fragment It's used to turn fragmentation off Okay so with these fields Now let's go through the procedure Of fragmentation So when rounders receive a packet Which is too large, they'll begin fragmentation To do that they need to Divide the packet into pieces Typically they'll break it into large pieces The largest piece which will fit across The next link And whatever's left over after that And you could break it into more than two pieces too We're just using two in our examples here You then copy the IP header To all of the different pieces Needs to be routable through the network And routers need to have An IP header on packets So they can work at what to do Then you adjust the length on the pieces So that the length reflects the fragment Not the overall packet You set an offset In the fragment offset field To indicate the position of this fragment In the overall packet So we'll know how to put them together And finally you use the MF the more fragments flag To indicate whether there are any more fragments This is fairly clever Because when we turn this bit on As soon as a host at the end Receives any packet With the more fragments bit on It knows the packet has been fragmented And it should put all of the pieces together And it will look for all of the pieces Until eventually it will find a last piece That has this flag cleared And knows that it's got to the end The receiving host Reassembles these pieces When they've all made it through the network The identification field Is the field that's used to link All of the different fragments together They all bear the same identification value And I've already talked about The importance of the MF flag The more fragments flag Here Let's go through an example That will probably make fragmentation clearer So here I have a packet It's a large packet Comes into a router The CPU of the link beforehand Was 2300 bytes So a large packet came in Now when I talk about length here I am just going to talk about The length of the data Actually the total length field on the IP packet Includes the length of the header So we would need to adjust things But to keep this example simple I'm just going to talk about length As though it refers to the data in a packet So here imagine I have a packet It has some identifier value It's OX12EF The length The data length of this packet Is 2300 bytes It has an offset of 0 Because it's not fragmented It begins at position 0 The beginning And the more fragments bits cleared Since there's been no fragmentation Now for the outgoing link Let's say the MTU is 1500 bytes It won't fit. What do we do? You guessed that we fragment The first piece we'll break it into Is the largest size that will fit Let's call that 1500 We have a fragment here Here's the fragment This is the first piece Let's fill in these fields For the identification number We just copied that. 12EF The data length I told you We'll try and send 1500 bytes That's what we'll send in the first fragment The offset is going to be 0 For the first piece There is something coming The second piece Will be whatever is left over Now the first piece Is 1500 bytes We've got another 800 bytes Left to make up the packet For the identifier I copy it again The offset we need to change The offset should now be 1500 To indicate that this 800 bytes Of data starts at position 1500 The more fragments flag The more fragments flag Will be set to 0 To indicate that this is the last of the fragments If I clean that up You can see that example I've just highlighted The fields Which differ To show you the fragmentation has occurred And how they changed The pieces were divided That's fragmentation You've seen an example of the procedure Basically it works The way it has some clever properties You might have wondered what will happen If we encounter another router Where the MTU is even smaller This design allows fragments to be fragmented Using exactly the same procedure Without having to group any packets together Or do anything that would be hard work However And here's the issue It turns out that Fragmentation is undesirable For many reasons Experience with networks as shown as this Fragmentation is more work for the routers And hosts compared to not doing it For the routers They're trying to process packets Millions of packets per second maybe So it can be a lot of work to do For hosts, they don't maybe have to process At such a long rate But they have to buffer They might have to hold on to pieces of packets For a long time To see if they can put them together In Sawadjigsaw puzzle If you lose a fragment There's no provision for re-transmitting individual fragments So this tends to magnify the loss rate And complicate things for the host Because if you lose any fragment It might be holding a lot of the other fragments For a long time before it decides to give up Fragmentation even causes security problems too Fragmentation makes it easier To kind of hide the contents of what's in a packet So it's more difficult For security boxes to check That the traffic isn't malicious So let's move on And look at the alternate method That's used instead these days And that is pathMTU discovery Really here we're trying to discover The largest MTU Which will fit through the network If we can do this We avoid fragmentation And this is the method that's in use today Now the procedure we'll follow Is here The host is essentially going to try and send the data And as a side effect It's going to test the network It will send a large packet And if it wants to get through Hopefully that will get through But if it doesn't because it's too large Then routers will send feedback to the host Telling it what size packet would have fit through the network That way the host can discover How large packets it can send through the network Here's an example So let's just imagine We have a source on the left Sending to a destination on the right You're going through a couple of routers The MTU of the first link is 1400 bytes So on try number one The host might send 1400 bytes It knows this is the MTU Because it's attached to this link So it just hopes this will fit through the network All the way to the destination But as we go through the network Guess what, the first router The MTU goes down, it's only 1200 bytes This packet won't fit Now if this were fragmentation We divide it into pieces and send them onwards But this is not, this is path MTU discovery So instead The router sends back This message to the host Saying try 1200 And then it drops the packet Host gets this message And then it will try again It will send another packet This time it will resend packets With an MTU A packet with an MTU of 1200 bytes That will make it through the first router And to the second router And when it gets to the second router Unfortunately it's too big Because the MTU of the next link Is even smaller Well in this case We'll send another feedback message Now we'll say try 900 bytes Okay The host will get that message And these other two packets have been discarded And the host will now try sending 900 bytes And it will go through the network All the way up And eventually It will be received by the destination The destination will then send a normal reply And we won't get any error message From the network saying that we should try something smaller To fit our packet through Here's a version that's cleaned up And that's essentially path MTU discovery Now this process might seem a little bit involved There was a whole dance we do here With messages and negotiation To find the MTU Along the network path But actually it usually works fairly quickly To find the right size Because there are some common number of sizes And they usually aren't that many discontinuities We run into You can also usually remember this information You're doing it once maybe To talk to a destination And it's usually fairly stable So it works reasonably well in practice It is and this is interesting too It's really Because the path MTU depends on the path And the path can change The search is really an ongoing procedure We're really performing the search In parallel with sending data It may be the case That we stabilize at a path MTU And use it for a while and then suddenly It changes, it gets smaller Or possibly larger We would like to discover that So we might send a larger probe packet occasionally And occasionally during the connection We may get error messages saying To use a smaller packet You might wonder how all of this is implemented This is implemented with a protocol Called ICMP That's the protocol that sends the error messages We're going to talk about that next In addition to ICMP, one bit that's used That's key is this df, don't fragment bit To use path MTU discovery Hosts send packets with the don't fragment bit Set This tells routers not to fragment the pieces And instead, if the packet is too large This error message will be triggered And that's our feedback We'll see that soon G'day viewers, in this segment We'll talk about how IP handles connectivity Errors with a protocol called ICMP Now many different things Can happen while a packet has been forwarded They can go wrong because Maybe the fields in the packet were not quite What was expected The topic that we're looking at in this video Is what do we do When there's an error during packet forwarding What we would like is some kind of Error reporting facility So that information about problems Could be returned to the host or whoever's Sending so they could actually do something about it Not surprisingly This is the kind of facility that turns out To be very important in real networks To help them operate smoothly So let's look at how IP does it Well, IP handles The various kinds of error reporting And connectivity problems With a protocol called ICMP That stands for Internet Control Message Protocol It's what's called a companion protocol To IP is how it's often described Essentially, IP and ICMP Is always implemented together You'll really hear about IP all of the time But ICMP is implemented right beside it ICMP messages Are actually carried inside IP packets So if you like ICMP as a protocol sits on top Of IP And you can tell this if you look at an IP packet And the protocol number is set to 1 Then that IP packet Is carrying an ICMP message ICMP provides A variety of functionality That's useful for understanding connectivity problems From our point of view Most of this functionality is Error Reporting When there's an error Well, when there's a problem Fording a packet at a router That's what I'm calling an error And that is often reported to whoever sent the packet So they could do something about it IP also provides a little bit of other Functionality For instance, for testing the network Without having to have any error occur But we won't worry about this too much We'll concentrate on errors Here's the overall picture For How ICMP is involved In Error String Fording What happens is that Step number one Someone sends a packet This source on the left Sent a packet into the network It looks like a strange packet Maybe it makes it through the network somehow And then at some router Some router has a problem fording this packet Because of bad information in it Step number two What does the router do then Well, it sends a report That's this ICMP report And then it discards the packet Because it can't handle it So this ICMP report This is step number three This will make its way back Across the network to the source That sent this bad packet And hopefully Step number four The source will receive this ICMP message Let's look at more about ICMP By looking at the format Of ICMP messages So every ICMP message Has an ICMP header That carries information about the type And code of the message As well as a checksum Most ICMP messages Also carry a portion Of the offending packet The trigger packet, whatever you want to call it The packet that encountered an error And caused this message to be generated As we'll fit in the ICMP message We're sort of returning that packet To where we sent it So they can look at it and see what it was They did wrong And this whole message is carried in an IP packet So instead of let me just talk Let me just try and draw some of this So we'll start sort of in the middle Here's the ICMP header I said it has a type A code And then a checksum So they may be different portions of it It's then going to carry some data So here's the ICMP data What's carried in there Well essentially the beginnings Of an IP packet I'll just call it bad packet That's the packet which caused This problem in the first place And this ICMP message is sent Over the network in its own IP packet So at the front of it there'll be an IP header Just a standard IP header Here I cleaned up that drawing And I've also added a little bit more information About the addressing We need to be able to put Well the different addresses In this packet To make sure the message gets to the right place So let's think about how it is That the router knows to send An ICMP message back To the host which was causing The problem The packet which we have inside The ICMP data here Since it's the beginning of a bad packet It will have its IP address Since it's the beginning of a bad packet It will have its own IP header That header will have a source and a destination That tells us where this bad packet came From and where it's going to So to send the ICMP report We can look at the source of the packet Who sent it, that's A And we can use that as the destination When we make an IP header To slap on the ICMP message For the source of the message We don't use anything that's in the packet Rather the source of this ICMP Message is the router which is generating it Which had the problem So you can see here that the router will put Its own IP address on the source packet As the source address And send it through the network I've shown the protocol here one To indicate that inside the packet The IP packet there is ICMP information That will have a different type and code Depending on the message And some other information The format of ICMP messages Depends on their type and code values It can be different after some initial Type and code values Here are some examples Of ICMP messages Which you might see on networks There is a destination unreachable network If you ever sort of get a message About hosts not being reachable Or networks not being reachable Usually it's because your Computer has received A destination unreachable ICMP Message When you tried to send a destination And the network couldn't work out Which way to send it It will be type 3 And it will have different codes Another kind of unreachable message Is destination unreachable Because of fragmentation The network needed to fragment the packet But the fragment bit was set So it couldn't return this error message That's actually what's used To Provide for pathMTU discovery The mechanism we looked at In a previous segment Another interesting message Is one called a time exceeded In transit message This essentially means That the packet has been in the network too long And has not yet reached its destination This is functionality Which is cleverly used by Traceroute We'll look at that on just the next slide And then finally there's another bit of functionality You might see from time to time And that's an echo request Or echo reply packet This is used for the program ping To ping a host and see if it's alive And reachable on the network This last category ping Is a little different than the former ones Because this is not an error That occurs that's generated by a router During forwarding Instead an echo request Is something that a host sends From one host to another host And the destination host The IP layer inside the destination host Knows that it is an echo request And it responds with an echo reply So it's a way of seeing if a host is alive Rather than error reporting So to wrap up Information on ICMP Let's look at how Traceroute uses ICMP Recall here's another picture Same picture of the IP header And now I'm highlighting that The IP header includes this Time to live field The time to live field is A value which is put on the packet When it's sent into the network It's decremented every time the packet Goes through a router So it's really actually a hot limit field Not a time to live field That's an old name And if this counter ever reaches zero Then the network throws The router throws away the packet And sends an ICMP error Message back to the source The purpose of this time to live field Is to protect against forwarding loops Imagine that the network forwarding tables Were somehow messed up Well if you sent packets They could get caught in this loop And go round and round and round amazingly fast And clog up the network So the time to live field is important for robustness It throws away packets If they're caught in a routing loop Traceroute Very cleverly repurposes This time to live functionality As well as the ICMP error message functionality This you might recall Is a slide from something I showed you Right back In the Julia unit at the start of the course It's how traceroute works Recall that traceroute Sends a probe into the network one hop And then it gets a message back So it knows what the first hop is Then two hops gets a message back Three hops and so on So it finds the path through the network You might have been wondering exactly how that works Well it works with ICMP errors And the time to live field The way traceroute works Is it sends a message with a TTL of one To do the first hop That will expire At the first router and cause this ICMP message To be sent back Next it will send a message With the TTL Of two To go two hops And we'll get another ICMP message back Then a TTL of three That will produce an ICMP error The third router out And so forth And you can see that this is essentially Traceroute performs its magic By repurposing this functionality That was there for other mechanisms By reusing it in a very clever way We have one of the most important Error debugging facilities in the internet G'day viewers In this segment I'll talk about IP version 6 The future of the internet protocol So Most of us use IPv4 While we access the internet today IP version 4 that is But there's a new version of the internet protocol IP version 6 Which has been standardized and has been deployed Into the internet to solve some problems I should say maybe that it's still Been deployed because it's been In the process of being deployed for more Than a decade now So in this segment I'm going to talk about Why we need IPv6, what it is And what the state of it is How it's been rolled out Okay so here's the background This is a slide Actually you saw this slide earlier on In the first week of the course The slide simply shows you The graph gives you the internet growth And you can see how rapidly the internet Is growing It's really exponential growth Here as we trend up the line And over the past A couple of decades we've gone From a small number of million hosts To a billion, this is a huge number Of hosts on the internet and still growing Rapidly as every device goes online And to top it all off we're using 32 bit addresses With 32 bit addresses we have A maximum of 2 to the 32 addresses That's basically about 4 billion Actually there are fewer addresses Because there are all sorts of reserve things And format difficulties and so forth So there are many fewer than 4 billion addresses Not only that but you can't use them all Because we allocate these addresses in blocks So we've used up a good fraction Of the internet's usable addresses already Actually the situation is more dire Than I'm letting on We are very close to The end of the availability Of new IPv4 addresses This somewhat complicated Diagram on the left shows How IP addresses are allocated IP addresses start With a body called IANA The internet assigned Number authority I think And IANA Owns all of the IP space What IANA does is it hands it out Big chunk at a time To these other bodies which are shown here These are the arrows going here These other bodies AREN, APNIC, RIPE, LACNIC And AFRINIC you might have heard of Or you might not These are regional bodies That administer IP addresses In different parts of the world AREN is for the US, Canada And various other bits of the world I think Antarctica For instance, RIPE covers most of Europe And you can see all the other bodies For Latin America, Africa And the Asia Pacific region APNIC covers Australia of course So IANA hands off IP addresses To all of these bodies And these bodies in turn Hand out IP addresses To ISPs and other companies When they ask for them Now IANA has handed out All of its IP addresses On In February of 2011 So that's a little while ago That's almost a couple of years ago now You might think this is no big deal But IANA has been going for I think more than 40 years Handing out IP addresses And just in recent history, it's run out So this means the routing registries Really have only their left over Blocks to use Already, some of the routing registries Have run out Oh, yep, sorry That's the other way around APNIC was the first to go In April of 2011, it ran out Much more recently, RIPE ran out of Addresses In September of last year So everyone is sort of on a countdown Now that the Addresses are almost gone Much tighter allocation policies Have been used You need to satisfy many greater hurdles If you were to obtain new IP addresses Then secondary markets are springing up Where companies are selling the IP addresses They already have to other companies and so forth So it's all getting more difficult Maybe this is actually Somehow tied to the end of the world The Mayan calendar At the end of 2012 The world's going to end because we run out of IP addresses What can we do? Well, don't worry Don't panic, this will be One of those softs falling off the cliff kind of things And there's a solution in the wings IP version 6 is going to come To our rescue Actually it's been coming to our rescue for a very long time Already now IP version 6 was an effort Started almost 20 years ago By the ATF in 1994 Following on some research The main feature of it Really it's motivated by this Addressing crisis The exhaustion of addresses Is much larger addresses These addresses 128 bits long And 2 to the 128th power Is an enormous number It's not simply 4 times as big as 2 to the 32 It's 2 to the 96th times as big So there are more addresses Than Essentially every device on the planet In the foreseeable future In this number, many more It's an astronomical number The reason for starting on IP version 6 With these big addresses Even almost 20 years ago Was that the growth of the internet Was obvious then And it was clear that we would shoot through these addresses And really different techniques People have been using have only been delaying The end of these addresses IP version 6 also includes Many sundry small improvements Basically you really don't get To change the internet protocol The bedrock of the internet Very often at all It's a very rare event So everyone would like to take advantage of it To clean up a few things in many ways IP version 6 by the way is the version That comes after IP version 4 5 was allocated to a protocol That never really made it big time So it's disappeared At any rate, IP version 6 Became a standard in 1998 That's more than a decade ago So what's happened? Since it became a standard After that it was expected That people would begin to deploy it Well really very little has happened In the past decade There were various improvements Windows notably began to ship it Around 2000 Other major operating systems Had begun to ship it And had it enabled by about 2008 So all sorts of people got a little Rady in the meantime But I think the big point is here Deployment has really been Hampered, greatly hampered By the difficulty of deploying it We'll talk about that in a while Because it's really such a big change In the adoption incentives I mean if you're a new ISPO company Why should you bother installing IPv6 If you can still get IPv4 addresses It gives you a lot of headache And not really a lot of new features So deployment has been very slow Of course Now in recent history Over the past couple of years There's a big push to deploy IPv6 And it's beginning to take off Because the exhaustion of IP addresses Is really very close IP addresses will shoot up And the costs and the difficulties And we'll gradually switch over to IPv6 This slide Shows you a little bit about IPv6 deployment The Metal here is a campaign to launch Into the future with IPv6 It's World IPv6 Launch Day And that was about the middle of 2012 It follows About a year After a World IPv6 Day in which ISPs And large networks turned on IPv6 For a day Just to try and do a bit of a test And debug it Since it is such a big change to the internet They want to see if everything is compatible That went well enough That in World IPv6 launch day Many big content providers and ISPs Turned on IPv6 and left it on So that you can now begin to use it This graph comes from Google It shows you just some of their data That you can look up And some of these are coming to them And making queries using IPv6 Rather than IPv4 You can see a while ago it started at basically Nothing And it's been going up And I think we're getting ready for some growth At least I hope Here In case you can't read it easily This is about 1% of the traffic So IPv6 is still very much In the noise But hopefully it's growing very rapidly now What we're going to do now Is just look at the header of IPv6 So we can see the messages And just see what's a little bit different Compared to all of the IPv4 messages So here's Another one of those header diagrams Looks maybe The same sort of thing as IPv4 But it is different in some respects The biggest difference by far Is this This shaded region These are the addresses They now take up the bulk of the header Because they're huge They're 4 times bigger Than the IP addresses used to be before them So because of that We have a new convention for how to write them IPv6 addresses Are written as 8 groups Of 4 hexadecimal digits Each of these 4 hexadecimal digits Is really corresponds to 16 bits That's why there are 8 of them To make 128 bits So here's an example In long hand notation Of an IPv6 address You see this address here 2001 0 0 0 0 0 Wow, that's a very long address Most of the notation we use Is about how to shorten those addresses So we don't have to write it in such a long hand way There are 2 rules for shortening essentially You're allowed to Amit the leading zeros And you're also Allowed to omit entirely groups of zeros We'll know the range of ones Which have been omitted By Usually there's just one run of them By seeing that there are 2 columns In a row So let me just write out and you can help me What this address would be in the new notation So I'm going to shorten each group To 0 0 1 Column I'm going to get rid of this 0 Db8 Oh look I can get rid of This block, this block and this block Now I'm left with another Column there Then I've got ff 0 0 I can't get rid of these 0 0s Because they mean something at the end It would be a different number otherwise Column, get rid of this 4 2 3 2 9 Well that's still pretty long but it's a lot shorter Than what we started with So those are the addresses What else is in the header Well there are lots of other smaller Changes I've shaded the other header fields One feature of IPv6 Is a more streamlined header processing If you want to You can compare it to IPv4 And you can read more about it in your text Just to understand some of these details I'm going to give you You might notice for instance That the header length Filders disappeared The header has a fixed length here And the next header points Towards anything that's optional As well as the higher layer headers You can also see that the header check sum Has disappeared That was something that maybe added a little bit of reliability But it wasn't felt to be worth it In the complications in practice So things have gotten simpler here That's likely to be important in the future Recall that Datagrams are all sent individually Through routers But often if we're doing something All of these datagrams might belong to a higher level construct Like our video conference What you can do is use this flow label To put labels on packets And identify the ones Which are in the same group together This is almost a little like a virtual circuit Just without any of the setup If we do this There are cases for the network to treat all packets With the same flow label in the same way It might route them the same way through the network Forward them the same way through the network Excuse me Or it might try and do different things In terms of congestion or priority With them in the same way This is mostly in the future And this has to do with quality of service We'll probably get to that later And finally IPv6 has a better fit With some of these advanced features I'll go into all of the details here The point I would just make Is that over time Lots of experience has been gained in the internet With how to implement mobility Different kinds of multicasting That's sort of like a cross between Unicast and broadcast So a packet is sent to a group And a little bit extra security Those learnings have been incorporated into IP Just to sort of meet the fit Between these features in IP a little smoother So this is basically what IPv6 looks like Now let's talk about the big issue for IPv6 And that's the transition If IPv6 is such a big thing We really need it Great, let's get on with it But how do we go about using it How do we transition to it The internet is far too big for us to have any kind of flag day Where we say Everyone stop using IPv4 And start using IPv6 Instead, both of the protocols will need to coexist Probably for decades together So we need some deployment Strategy which will let us deploy IPv6 And begin to Allow people on IPv6 networks To talk amongst themselves And with people on IPv4 networks This is very difficult It's really an internet working problem Like before But it's difficult because There are fundamental incompatibilities They have very different addresses For instance, how on earth are we ever going to get them To talk directly to one another Well this is the problem There's a huge answer here In fact, dozens of different approaches Have been proposed I can't go into them all That would be more detailed than we want But I can just sketch Some of the different alternatives And I'll go into one in detail because it's useful So some people have proposed Running what's called a dual stack If you have a host You might have it speak both IPv4 And IPv6 That way it could use the old IPv4 protocol To communicate to old hosts Which were on an IPv4 network And it could use the new IPv6 protocol To communicate with IPv6 hosts On a new IPv6 network Another approach Is to add translators into the network And try and convert packets From one to the other That will allow us to talk across IPv6 and IPv4 hosts It'd be wonderful if we could do it It's just kind of hard and there are various constraints Because for instance, we have to work out How to fit IPv4 and IPv6 addresses In each other's packets Using some kind of convention And the third approach Is something called tunnels We might have islands of IPv6 Where new networks which are using IPv6 Are set up, but they might not all be connected Some of them might be connected By the IPv4 network We can tunnel across the IPv4 network To allow the IPv6 Host to talk with one another And this is the one that I'm going to Explain in a slide or so Just so you can get the sense of how tunnels work Here really to help with IPv6 But tunnels are a useful mechanism In general, they're not specific to IPv6 So here is The tunneling scenario We have on the left We have an IPv6 network We have another IPv6 network So we'd like to send a packet From the source to the destination Source on the left, destination on the right They're both on IPv6 networks Sounds wonderful Except of course in the middle We have an IPv4 network Now Because these are very different protocols What we probably can't do for instance Is have a host in this IPv6 network Talk directly to a host in this IPv4 network They speak different protocols So we're not even going to try We really just want to get our source To communicate with our destination Even though the path goes across an IPv4 network What can we do? Well here's what we can do We can send our IPv6 packet Because that's what will be produced by the source Across the network The IPv6 network Then we'll get to the border router Which is at the edge of an IPv4 network At that time, what we can do Is simply wrap the IPv6 packet In an IPv4 packet We'll take it as a payloader Not even look at the IPv6 packet We'll simply encapsulate it With our own IPv4 packet And send it to another border router On the other side of the network So that it can get back on to an IPv6 network This is a tunnel in the middle here And it's called a tunnel Because when the packet goes into it With this wrapper This IPv4 wrapper It's going to come out the other side It can't get out halfway through the tunnel And go to say this host up here It has to go through the network So it can only go through this tunnel Now, in fact If we look at the source and destination Of this IPv4 We'll have the source will be here This ingress router and the destination Will be here It's identifying the tunnel endpoints And the wrapper is just to carry the IPv6 packet Through there. Once it gets to the other side It can be unwrapped and then It will go across the IPv6 network And arrive at the destination So effectively this IPv4 Network in the middle is acting As a single logical link That's how we're folding it into our network Let's try and draw some of the Layered protocol stacks for that Just to make sure we understand it So on the sender side Let's say we have IPv6 On top of some link protocol Such as Ethernet So we're going to have the same thing On the receiver side IPv6 link In the middle what's going to happen Well, at this ingress We need to have the same thing So this is meant to go here IPv6 and link Because we need to terminate these protocols But now we need to enter the tunnel So we're actually going to do something tricky on this side We'll have IPv6 We need to have this because We're maintaining IPv6 connectivity Across this entire path But underneath IPv6 We'll put IPv4 That means we will take an IPv6 packet And encapsulate it in an IPv4 packet So we're going to do the reverse On the other side So I'll have to have 3 in here And this then Will be our tunnel Of IPv4 Whereas this is really A native IPv6 network And so is this So that's what the protocol layers Will look like corresponding to those packet formats You can see this is a bit of a strange device We're putting a network layer On top of a network layer Just to provide a fancy path But it's quite effective And tunneling will see it again in some other context When we get to security and look at VPNs for instance Here's the diagram Again, just cleaned up So you can see And check that I got it right and check your understanding But that's basically it Now you know about tunneling And you know about IPv6 And at least one option for how it can be rolled out Good day viewers Network address translation A networking technology that's widely used In the internet today So many of you probably have A NAT or network address translation box That you use This is because NAT boxes are commonly used To connect home networks to the internet Say it's part of a wireless router Or AP Or any other kind of router device That connects your home network to the internet We're going to cover them today And talk about What a NAT box actually is And how it does its job And we'll do this for a couple of reasons You might be interested just to find out how it works Since it's a pretty much an everyday Networking technology, that's one reason And the other reason is It'll give you a chance just to think about How some of the NAT mechanisms Fit with some of the principles of networking We've learned Or rather, maybe you'll see how they don't fit In some of the tensions OK, so I'd like to start with just A view of layering Remember this layering model This is the kind of slide we saw earlier In the course We have some applications using TCP At a source on the left And there's a destination on the right And That application is able To send information down the network It goes across the network through routers And arrives on the other side This is our standard layered model The way layering worked with encapsulation Was that TCP passed information down to IP It was encapsulated to be wrapped in a packet That packet went through the network I'll draw it at the router So there was an IP packet On the outside And on the inside was the TCP data Header and data And because of our layering This meant that IP devices Didn't look at what was inside They didn't inspect or modify The TCP packet in any way This is a nice clean layering abstraction That's great in theory That's actually the way a lot of networking Devices work But it's not the whole story It turns out That there's a whole class of devices Called middle boxes Of which an ad is going to be one example Of course Middle boxes are these very odd kind of beasts Which don't fit with our architecture at all Middle boxes sit inside the network So logically They're in the middle of the networking In some way But They perform functionality That goes further Than simply IP So in some way they're doing processing The packets which would logically belong At the host on the edge of the network And I've tried to draw it Just on this device here In a router, I don't know how to draw A middle box in our diagram Because it doesn't really fit You can see here I've drawn that it's interfering With this data flow somehow Between the sending TCP and the receiving TCP It's mucking it up The reason for Middle boxes Is that people use them to add new kinds of functionality So a NAT box is one Example We'll see exactly what a NAT box does Just in a short while There are other middle boxes you might have come across too A firewall is an example of one And an intrusion detection system So to understand more We have these middle box devices Let's talk about their advantages and disadvantages They have some very strong advantages And very strong disadvantages So they're quite controversial The advantages Really have to do with the deployment of new functionality Often it's possible To deploy new functionality Just by upgrading one box in the network And turning it into a middle box This is a wonderful alternative Compared with, for example Upgrading all of the routers in the network Or upgrading all of the hosts Both of which might be well not impossible Or take a very long time So if you can deploy something with a middle box It's a very strong incentive too If you're in the IT business too A middle box can also be Quite helpful in that if you can Deploy it at a good position in the network You can see traffic from many hosts And so it provides Almost a scalable point of control It's easier again Than deploying functionality On many different hosts in the network You can sort of almost do that By deploying a middle box On the other hand, it comes with Some pretty strong disadvantages This middle box Breaks our layering model You need very much runs counter to it Now you could say Well, so what? It was only an abstraction We'll just break it Fine, what that does Is it interferes with connectivity Is no longer just a simple matter Of sending and receiving IP packets And often strange things will happen We will have strange side effects Depending on exactly what that does Some of which can complicate the future deployment Of things We'll see more about this When we get to net boxes This is the primary downside That they really make the network More complicated It also turns out that a middle box Is a pretty poor vantage point For implementing some functionality We simply see packets going through the network If you wanted to do a lot of functionality Like intrusion detection For instance, you might want to see The web pages or complete documents But it's difficult to see that At the packet level You would maybe need to reassemble all of the packets Into complete documents to inspect them That can be a lot of work And it's not always possible If, for example, end-to-end encryption Is used so that inside the network So let's move on Now that's middle boxes You've heard about this class of devices Now we'll talk about a net box Or a network address translation box This is a specific kind of middle box Whose job is to translate addresses And it translates addresses To connect an internal network Which has many hosts To an external network Using a very small number of addresses Or a relatively small number of addresses In that network It's very much motivated By address scarcity So Net boxes have been around Since IPv6 was proposed And explored They've sort of really developed concurrently And they were first proposed As a solution to the address scarcity problem Really is as an alternative Or a short-term measure Before IPv6 would hit They're really very controversial At first Of the way they break the layering model And the damage they cause But over time they've come to be Accepted as part of the Internet architecture Or maybe that's too strong Maybe I should say they're accepted As a widely deployed networking technology That we just have to live with today So I still really haven't told you Very much about what a net box is Or how it works Let's zoom in on a net box And I'll do that just by sketching What it looks like about I do want to point out that there are many variations On net technology So if you look it up on the web You'll potentially see all sorts of different ways That now works The variety I'm going to talk about Fits our common home usage scenario It's actually a network address And portrait translation So the scenario is this You're at home You have this as your home here On the left-hand side I don't know, 5 computers, 10 computers 2 computers, I don't know And you're connected To the Internet via your ISP Of course Your ISP Gives you a single public IP address To connect It doesn't actually want to give you many more IP addresses Particularly since we're running out But you want to have as many computers as you like You set up your computers in your home network And actually you can give every computer What's called a private IP address There are reserved prefixes For private addresses For example One of them is 192.168.0.0 Slash 16 Is one 10.0.0.0 Slash 8 Is another one You might see these numbers around quite a lot They're private addresses So this means they can be used on anyone's private network You just can't really attach them To the public network Because they don't have any unique meaning Nonetheless, we can set up our home network And give every computer Its own IP address and be perfectly happy What the NAT box will do Is it will translate Between these many private addresses At home And the one unique public IP address In the ISP To the computers at home It will make it look as though everyone has their own address And they can use this to talk to hosts out on the Internet To the ISP or other hosts out on the Internet It will make it look like there's a single machine at home I see I've drawn this pink line around all of the boxes They're sort of looking from the outside As though they're one big happy machine That sits at the public IP address That the ISP has given you Which the NAT box is reusing So that's the functionality That a NAT box is going to achieve And just to point out the NAT box Often a NAT box will be integrated Into a wireless router That's part of your access point And it's often part of our firewall Since it's providing some firewall like technology In any case So you might not be buying a NAT box But you might find that NAT is in many of the boxes You use to connect your home network to the Internet So let's dive in a little bit And talk about how NAT works We've talked about the goals How it's trying to translate the addresses How does it do it There's a table that has a mapping Between the internal address for the home side And the external address For the Internet side Now in the table That I've shown here The mapping is between an IP address And a port To another IP address and a port This is sort of typical Of the way NAT technology Is used inside home This is actually technically called address Translation as opposed to only address translation The reason you do this Is that if you have many computers At home And they're using the Internet all at once We can't map them all to the one IP address Without getting confused We would really like an entry in this table To map uniquely From the left side to the right side And vice versa To do that we can use port numbers And map a combination Of IP address and port number On the left to IP address And port number on the right In a unique way So that there's one to one mapping And we won't get confused About what belongs one side To what on the other side This is an example table Of a mapping that I just made up So let me point out a few things About this table Here we have the IP addresses Inside the house These are private IP addresses Now they map to another IP address On the External side that's this one This is just one Public address So while there were many internal addresses There's just one public address So all of the different IPs map to that same one public address The way we're disambiguating this Is using ports When you made a connection You also have a TCP connection TCP port For the moment The port numbers are shown here Different hosts might have different port numbers It turns out that two of these different hosts Actually by chance use the same port number Well when we map to port numbers On the External side Since we've got the one IP address Well all the port numbers better be different So we could know Which internal thing it maps to So you can see here That the different combinations are mapped Different port numbers None of these port numbers can be the same And none of these port numbers needs to be Any of the original port numbers It can all get redone I've shown them here as sequential 1500, 150, 1502 That's chosen on the output side But really it's more likely your NAT box Would choose them randomly Because it's slightly better for security So if that's still a little puzzling Let's just try and work through an example To see what happens The NAT box has this table To use this translation table As packets come And they're going from the internal side To the external side The NAT box is going to use this table And rewrite the IP header of the packet According to the table And for packets coming in from the internet To the private side To the internal region The home network is also going to rewrite the headers of the IP packets According to this table So let's see exactly how that would happen The danger that you just have this table That your NAT box is somehow configured with this table I've just shown one entry in this table There would normally be many But this is the only one we need for this example You've mapped this Internal pair of IP address And port to an external pair So if we have a packet That's going from this internal source To an external destination Say a big popular web server Just used X for the IP address And Y for the port What the source address would be in this packet Well, it's going to be The internal source And we know here from the table This one is 192.168.1.12 And the port Which I'm showing after a caller Is 5523 A caller to a port number Is just a 16 bit number It's used in TCP We mention that very briefly At the beginning of the course And we'll see that in more detail At the destination Where do we want this packet to go to We want it to go to IP address X And port Y So the packet will then proceed through the NAT box As it goes through the NAT box For an outgoing packet What we want to do is look up And rewrite the source IP And port That's right, this box is going to Change the IP header So it's going to rewrite our traffic Which can be very confusing But it's going to get changed According to our table We map this incoming source And port to this particular external IP address And port So now the source will be 44.25.80.3 Call on 1500 Oops, a little squished there The destination is going to be unchanged Because we want it to go to X column Y And it will reach that web server Which will hopefully do some things And send a reply Moving on, now it's sending the reply So our packet is coming From the external side to the internal side Let's look at that packet On the external side, what do we have Well, the source here Since it comes from this web server Or whatever the external source is It's going to have IP address X And port Y The destination, where is it going to go to It will reply to whatever the source is On the packet it received And I can remember the source We made this external IP address And port, so the source Sorry, the destination of this packet Will be the previous source Which is 44.25.80.3 Call on 1500 That packet arrives At the NAT box Because the destination IP address Takes it there As it goes through the NAT box The NAT box will look up and rewrite The destination address It's now going to map that Name to the internal name Okay, so let's go through On the internal side, the source Well, that's going to be the same, we didn't change that It will be X column Y Meaning it really came from this external web server The destination will get mapped According to our table to 192.168.1.12 Call on 5543 And that will be routed to this Internal host And so we translated between these addresses There's one other bit we need You might wonder how this table Is formed in the first place Now you could maybe have your network Administrator fill it in by hand But that would be cruel and unusual punishment For any reasonable networking technology We want to automatically create this Mapping table And we can do this By populating the table Whenever a host On the internal side first makes a connection To something on the external side Suppose you're surfing the web And you contact a particular web server Then you're going to send this packet From the internal source To the external destination Now if the NAT box can recognize The beginning of connection packet The first packet, the very first TCP packet Which it can, we'll see how Later when we get to TCP But it will look to see if something is a TCP Start of connection or SIN packet If it is The NAT box will make another entry in the table It will copy the source Which was here, 192.168 .1.12 .5523 It will actually take this And copy this into this table I've actually already written that in this table It'll make a new entry, the destination But still x column y And on the other side Since this is a new entry in the table It doesn't have an external IP In port yet It will fill in the external IP From the From the ISP I can't remember what it was I had Let's just say 180 Whatever it is Let's say the port that it's going to Is It's going to port 80 Sorry, that's not where it's going to This is what we're going to put to the source So I'm just going to map that I had 1500 before The point is this 1500 port That's chosen at random The one thing that's unique Since the external IP address will all be the same So on the outgoing side We've then moved it to our 44.25.1.80 Column 1500 The destination is still x column y Don't worry if I make use of A slightly different external IP address It just needs to be whatever the netbox is configured with This one is configuration But once we've done that We have populated an entry in the table That comes from that external host We're set, we'll know how to map it to the internal one And we can continue using this Eventually we'll reclaim the space from this When the connection is closed down It hasn't been used for a long time So that's how a netbox works And just to wrap up I'd like to talk about some of the pros and cons Of netboxes There are definitely some downsides here And that's why nets are really very Controversial The connectivity is being broken Making the layering abstraction would interfere With the connectivity and cause strange side effects Well it has And hopefully you can realize Exactly what one of the side effects is here That if you want to To be an internal host To communicate with an external one You can only do it by having the internal host Send The incoming packets to Send incoming, oh sorry The internal host has to make a connection To the external host You can only send incoming packets That is from the external host to the incoming one After this outgoing connection Has been set up Well that actually fit quite well With web usage in the early days Because your client at home Is usually making a connection to a web server That's exactly what we want And then the web server can reply Of course it doesn't work very well If you want to run a server at home And have people contact you Or if you use peer-to-peer technologies Including or apps including things like Skype These do not work Very well with NAT boxes At least NAT boxes pose a big Complication for them So this is a good example of how NAT boxes have strange side effects Which can make it very complicated For apps to work There's a lot more to this I'm not going to go into too much detail But you need to do a lot to get a NAT box to work well You might have noticed I'm talking about TCP So actually NAT doesn't work so well With a connectionless Kind of transports like UDP It also breaks apps Which somehow expose their IP addresses The NAT box is translating Between internal IP addresses If the IP address is in the header If you use any other mechanism to convey it Like you found out your IP address And put it in a packet and told someone Well it's not going to be the right IP address By the time it gets to the other side Because the NAT box won't have translated it And in general to get something like A TCP connection to work There's a lot of other traffic that goes with it As well as a TCP connection for instance You might have ICMP traffic that goes with it You might have DNS traffic On top of UDP Later we'll see that this is the traffic To map between host names Like www.udu And the IP address of their servers So all of that traffic Has to get to and fro through the NAT box Properly for the overall application to work Otherwise it will only be half work And will have these strange effects So these are the downsides What are the upsides? If there weren't upsides We wouldn't be using these devices NAT boxes Really have been quite effective at relieving Much of the IP address pressure Many many many homes use NAT boxes To connect multiple hosts behind NATs To the public internet So they have really Greatly helped With the use of the address base And they really pushed off the exhaustion of IP For addresses by a long shot They're also very easy to deploy You can deploy it rapidly on your own at home And gain some value from it This is really I think why NAT has rolled out Through these incentives Are very much in favour of its deployment Since you really have very few alternatives Even though there are downsides And NATs also provide useful functionality For instance As well as all of this Helping with addresses They're also providing some kind of firewalling technology Maybe a weak one But one nonetheless Because external hosts can't connect To any of your internal hosts so easily There will be no state in the NAT box So it will simply drop a packet Because it can't map it properly It also helps someone with privacy Since in the internet Maybe your seven machines look like one machine So you can't really be sure What the department was necessarily doing What And I think over time NAT boxes are part of the internet now At least they're widely deployed There's something we need to live with So many of the kinks will get further worked out As NAT boxes get cleaned up a little bit over time Technologies such as Natroversal Will streamline how applications From the public internet Can get through NAT boxes To devices on the other side So you can use Natroversal to operate More smoothly behind NATs And a lot of this functionality Is being sorted out So there you have it Now you know about NAT boxes and how they work G'day viewers In this segment I'll give you an overview Of the routing topics that we're going to cover Here's a reminder of where we are in the course We've gone through some of the lower layers The physical layer, the link layer We're part way through the network layer Don't worry, there's more fun to come We previously talked about packet forwarding Now we're going to get on to the business of routing That's our topic for this unit Before we dive into it Let me go over the distinction Between routing and forwarding To make sure that you recall it From previous lectures So forwarding is this process Of when you get a packet, actually sending it on its way So it's very much a local node process You can see here a node gets a packet And forwards it Sends it in the right direction And we've looked at that already and seen how IP forwards Routing Is the process of deciding which Direction to send traffic when you get it So that's an agreement process amongst All of the nodes to understand Which way they should send traffic through the network So if you like, if I was to draw the equivalent circle Routing is a process that involves All of the nodes in the network So they're quite different in character And we're going to look at routing now Well, actually, the truth is We've already seen a very simple kind of routing A spanning tree We looked at a spanning tree when we looked at LAN switches And the spanning tree provided Basic connectivity in the network So you can see here in the network Of switches I have on the left I've drawn a spanning tree So some of the links are kind of turned on there Not all of them So there are a couple of links in the network there They're unused But this spanning tree is enough to connect all of the nodes And in fact, it provides some path Between every pair of nodes, for instance Between B and C traffic is central on this route Well, that's great For being able to get something through it all But it's not really a very good route In terms of using the network Because you can see here that there is a link that's unused So with routing We would like to make good use Of all of the links in the network Because bandwidth is the key resource of the network So we want to be able to use it well What does that mean? Well, it's actually a little bit of a tricky subject That we'll look at in the next segment But I'll tell you right now That we would expect good paths To be able to use all of the links in the network For example, here We've shown links between B and E E and C I'm drawing over them And B and C These are all links in the network And so we would like to be able to use all of them If we wanted to send traffic between those individual nodes We couldn't do that with a spanning tree Because the spanning tree Can't have all of these links at the same time Or it would have a cycle And it would no longer be a spanning tree So these kind of routes Were precluded under our spanning tree We're going to see how we can do better And at the risk of going a little bit Meta on you I'd also like to provide some Perspective on where routing fits in To the set of techniques We have in networking Routing is really You could think of it as one technique For allocating network bandwidth The key resource of the network is the bandwidth It has to provide connectivity Between the different points We want to use it well And the way we're going to use it Is going to adapt along different timescales The routing we're going to look at Will find paths through the network Which will adapt to equipment failures So the routes Will be recomputed If a link fails Or if a node fails There are also other timescales Starting at the longest timescale Down here there's provisioning Provisioning is all about building Your network to fit your customers And what they actually want to do with traffic So it takes place in a long Timescale months, even years An example might be if you had A lot of customers sending traffic Between Seattle and San Francisco It would be pretty sensible To build a network that had a Direct path between Seattle and San Francisco In that case If traffic had to go via the east coast Of the United States that would be Not so good So provisioning will take care of that problem And really routing can only do what it can do On top of the network Can't change where the links physically are At a slightly slower scale Than routing is traffic engineering This is adapting the routing itself On a timescale of Hours or so Minutes to hours to even days Depending on the overall load of the network For instance, just talking about Our United States network again The load might be different At different times of day And because of the time differences You might have a lot going on on the east coast And the west coast at different times of day So you might want to specialise Your routes for the busy hour on the west coast And the busy hour on the east coast Slightly differently. Traffic engineering Would let you do that to adapt To the network load slowly Over the day in the week Routing, as I've said before Is about adapting to equipment failures Finding good paths around Using only the working equipment So the routes are going to change On the order of minutes at most We would hope less often Unless we've got a lot of failures There's also a much more dynamic Form of bandwidth allocation That I'll call here load-sensitive routing This is adaptation on the timescale of seconds Around hot spots in the traffic For instance, if there's a lot of traffic Going between Seattle and that San Francisco For some reason there might be a big pile-up In a lot of congestion in Oregon If that's the case, it might make sense To route some traffic by Chicago That's going to be a longer path But if there's really a problem in Oregon Like a traffic jam, it might be advantageous To take the longer route to get around it So these are all important In the overall management of the network Is different mechanisms to Allocate our bandwidth, our key resource The one we're going to focus on right now And for all of this unit is routing So let's adapt to some of those failures Okay, so for routing It turns out routing is actually quite a large field In that there's a lot of literature On many different variants of routing We're only going to focus on one kind Of routing in our unit here And I've shown here four different delivery models In terms of how the network can deliver traffic We are going to spend all of our time Looking at a unicast routing model That's the one on the left here Unicast is the kind of routing that takes traffic From a given source to a given destination So you can see I've got a path through the network To send traffic between one source To one destination, great That's what you'd expect So this is going to be our focus I do want to point out to you That there are other kinds of delivery models And they're important and useful in the internet We don't have time to cover them In this introductory course But if you're interested In some of these other models I've provided pointers to the sections I'll just very briefly tell you what those models are So in a broadcast model You're trying to deliver traffic From a node to all other nodes of the network So you can see here from the source here If I follow the arrows I'm drawing over it It's maybe not the clearest to see But hopefully you get the idea If I follow these blue arrows Then I will end up delivering A copy of the packet To every other node On the network That's broadcast Multicast is like a subset of broadcast In a multicast model We deliver a packet from one node To a group of nodes But not everyone else on the network So you can see this tree here Is a multicast tree That I'm drawing over right now And it is delivering packets To these two pink nodes here I'll just circle them And not all of the other nodes in the network So there is another three nodes That aren't circled as end destinations That don't directly receive these packets And a final other model Is really a pretty interesting one If you would like to look something up That's something called anycast The model here is that When you send to an anycast address The network will deliver it To the nearest member of a group If we send from somewhere over here In the network We might send a packet To this particular pink node here That would be the nearest member of the group To these two sending nodes On the other hand If we send from a different destination To the same anycast address That we might be delivered To a different destination It actually has the same address And that is the closest instance Of that group Where the sender was This may seem like a very strange model But it's actually quite useful in the network If you want to deliver packets For instance to the nearest root DNS server Or the nearest one A copy of many servers In a content distribution network But as I say here We're all going to focus on unicast delivery Okay Now I just have a little bit more To tell you before we go ahead And look at some of these algorithms I thought that I would give you some of the goals Of the routing algorithms This is really food for thought For you to keep in the back of your mind We'll see different algorithms How do you know which ones are any good Well these are the goals This is what we want of our routing algorithms First of all we want them to be correct In finding paths that actually work To get from a source to a destination That might seem obvious But it'll turn out that it's a little harder Than simply looking at a map Which way to go for some of these routing algorithms Because they need to work In a distributed setting Where everyone can't see the whole picture We still want them to be correct in this setting We want a routing Algorithms to find efficient paths Paths that use the network bandwidth well I haven't defined what well is yet We'll get into that later We also want these paths to be fair Well Life's not entirely fair So by fair I really mean We don't have any of the nodes For instance it wouldn't be reasonable In our network to come up with good paths That work for most nodes But we could only do it by making sure That some other node really didn't get to send traffic at all That wouldn't be reasonable Every node on the network should have the ability To send traffic through the network reasonably And then Here are another couple of important Properties at the bottom We would like fast or rapid convergence So if we're adapting to failures After there's a failure We would like the routes to recover quickly Because they need to do that before we can Really use the network again And a last goal is one of scalability We know that many of the networks We build grow large very quickly They become successful disasters If you do it right We would like routing schemes that can work well Even as the network grows large These are called scalable algorithms Okay And here is the setting Routing algorithms This is really what makes a routing algorithm interesting Routing is really not like Looking at a map and trying to work out Which way to go Because the routing algorithm must operate In a decentralized and distributed setting This is actually what makes routing Both difficult and somewhat interesting Intellectually Now in this setting just imagine There are all these nodes in the network They're all alike and they're all working on this Problem of routing There's no controller So somehow they're all going to have to work out How to agree on what to do What's more They can't all talk to one another directly They can only talk to other nodes By exchanging messages with the neighbors That they're directly connected to They don't yet have any other way To reach further away than their neighbor They don't even know what the rest of the network looks like They're all doing this concurrently So they're all operating in parallel Which makes coordination even a little bit more difficult And we also want them to be able to work And find correct paths Even when some of the links and nodes may fail Whichever links and nodes remain working We would like all of those That equipment to sort it out And simply find good routes So you can see that it's really A pretty interesting problem Well we'll see some of the solutions To these problems as we go through The different topics Last time we went through forwarding Essentially that was our IPv4 And IPv6 model As well as other things like NATS Now it's all about routing So I'm going to tell you just about Some different frameworks For routing, like what shortest paths are As well as different algorithms For computing routes On some of these networks to find their way through And we'll start by looking At enterprise networks Or even individual ISP networks And by the end of this unit We will have grown in scope Instead of routing across the internet Where all of the ISPs and networks Are combined together You can look at this topic list That will just be your roadmap For where we're going to go through But I won't go into it in detail now Let's just jump ahead and see some of those units Good day viewers In this segment I'm going to talk about Shortest path routing For selecting good paths through the network So in previous segments I've talked a fair bit about That routing is going to find the best path Through the network But we haven't really said what that means In this segment we're going to delve into that topic And provide an answer And the answer we're going to provide Is going to assign costs to links And use the notion of shortest paths As a way of defining what a good path is Let me go into that in a little more detail So we would like routing To find best paths or good paths Well what are they It really depends on what you the network operator want And there are many different possibilities here You might want a good path To have low latency Because this would avoid a Securedest route There's no need to sort of go from the west coast To the east coast and back If you could avoid it On the other hand If you had a different kind of network We might want paths which had High bandwidth You might want to avoid any kind of slow This way you would fit more traffic through your network Depending on exactly How you paid for your network too You might want to avoid expensive links Maybe you'd want to avoid cellular links Of some kind for instance Just because you had some budget on them And you were going to have to pay a lot of money If you used them too much Or you might want to minimize the number of hops That packets went through the network Because in some way that would reduce the volume Of switching that goes on And if you're lucky maybe some of your equipment Would be good for your facilities Now there's actually While it might seem like I've admitted Pretty much everything here There's a class Of best That we've actually ruled out here That I haven't mentioned And that is to do with hotspots Now it might be the case that just in this network There's a bit of a hotspot at B And if we've sent traffic from A To E along that blue path there That's shown in the network here But then maybe we would say Hey there's already a lot of traffic at B So we don't want to send traffic from G say to C We would like other traffic to go round Instead of through B Well we're not going to focus On those kind of policies today Because that kind of routing Involves the traffic And best as we're going to define it now Will only consider static features Of the topology such as what nodes Are connected where You might also see That just I'm going to represent Networks as these kind of graphs So in this diagram here A line here this is a link And the circle here This is a node Previously I had a little icon or a picture For some of these things But often for routing it will suffice Just to call it a dot and give it a label Like a name like A through G Okay so best could be all of these things This is a little bit too complicated What can we do? With shortest paths We come up with an approximation Which can represent Many of these factors Roughly and what we will do Is make a cost function So that we'll be able to compute The cost of different paths And we'll choose the path Which has the lowest total cost To be the best path By assigning the cost In different ways we'll be able to Assign different factors Now often we'll call The lowest cost path the shortest path This is what you would get If you assigned the cost function To be the distance And since this is a common choice In large ISP networks What I will tend to do is use I'll be a little sloppy And I'll use cost or distance interchangeably And we'll also use Lowest or shortest interchangeably So don't be too confused about that The best paths will work As we'll go through these three steps First of all we'll assign To every link a cost Or a distance And we'll do that to capture The factors we care about It's literally distance If we wanted to minimize the latency Through the network If you made it all one You would minimize the hops through the network If every link was one If you cared about bandwidth Then we'll assign a cost to a link Because that way if we take the lowest cost We'll tend to prefer the faster links At any rate you assign a cost to a link And the operator does this This is policy And then we simply define The best path through the network Between every pair of nodes As the path through the network That has the lowest total cost Or is shortest And if we turn up any ties In that process We're just going to randomly break those ties And pick a path Whatever we pick out of those ones Since we'll have lowest cost It will be best according to our definition Let's see some examples To see how shortest paths work Here I have a picture On the right of a fairly complicated Looking network topology It's that graph from before Where the Lines represent links And the nodes Represent different equipment Kinds of icons And what you can see I've added here Is I've added a number on every link This is the cost of using the link Which I've assigned In this diagram all of the links Are bidirectional and they have the same cost In either direction It's possible to extend all of these models To networks that have links Which are not bidirectional And which have unequal costs In either direction We're going to ignore all of this And in the networks we'll look at We'll have bidirectional links with equal costs So the task here Is to find the shortest path From node A to node E Through this network What's it going to be In this segment we're going to solve problems like this Simply by inspection And later we'll see algorithms Which will work this out Now just looking at this network I see different possibilities here That could be good That has cost 10 Well actually I can see I can do a little better Than that if I go through here If I go A, B, E That has cost 8 That's lower so it's a shorter path It's best Is this the shortest possible path Well you should have a look for a moment And see if you can come up with anything better There is actually a better path through this network Hopefully you've worked it out Now I'm going to draw it in for you A to B B to C And C to E That has cost 4, plus 2, plus 1 Is 7 and that's the shortest path On this graph I've cleaned up this diagram a little bit And retraced it over and you can see it there And I've also listed Just the costs Or the distance function For some other paths that you might think of Here was our AE That was 10 But A, B, E is 8 We did slightly better than that You might also come up with some other paths Just looking around but they'll turn out not to be better For instance A, B, F, E This path Has cost 9 Not quite so good Or you could imagine doing something Going a little further around looking for something better A, B, C, D, E Cost 10 And everything else is getting longer So the other one is definitely the shortest path So now we know what a shortest path is The interesting thing about these shortest paths Which we're going to use as part of our routing Algorithms to compute these things Is that the paths have What's called an optimality property And the optimality property is that If you have a shortest path Any sub-path of it Is also a shortest path That's kind of handy actually So in one shortest path There are actually many different shortest path segments we've found So for instance Our path A, B, C, E is a shortest path Okay Well that means I actually found a lot of other shortest paths A, C is a shortest path Sorry A, B, C That first segment C, E is a shortest path B, C, E is also a shortest path And so on Now You can actually reason fairly easily to see Why these must be shortest paths The reason for instance Is that B, C, E is a shortest path If A, B, C, E is a shortest path Is Imagine for the moment that I could find A better path than B, C, E Well If that was the case I would simply Use a different route to reach E By taking that path And stapling the A to B bit on front of it And then I would have a better path From A to E But we know that the path from A to E We have is the shortest It's a contradiction So that means that the path from B, C And E must itself be a shortest path There's also another nice property we get With some of these shortest paths And this should give you a nice warm feeling You should be beginning to see why in fact We work with shortest paths because they can approximate Some of these different cost factors And they have a lot of attractive properties So the other interesting property Is that if I take the union Of all of the different shortest paths From all nodes to A particular destination Then I will get what's called the sink tree It will actually be a tree Because once you go further in Then the path When two paths meet They will both follow the same route From there on to the destination Because of this optimality property So let's see if we can find The sink tree for E So that's all destinations going towards E You can also similarly In our formulation Find source trees Which would be all of the paths from one node Say E again, out to all other nodes In fact, given that we're looking at Bidirectional links with equal cost The sink tree and the source tree will basically Be the same though, just be pointing in different Directions to go towards The route or away from the route And I'll use them a little interchangeably too Depending on what is most convenient So let's find the sink tree for E Well C goes towards E So we had this link here Now I can see the shortest way to get From D to E is just to go along this link So that will be part of the sink tree From F to E The shortest way is along this link There's no other shorter way around It's not always the case that the direct link Is shortest by the way From B to E, we actually saw That we want to go to C And then from C up to E, a dog link Way rather than going along that direct link To C What's left? Can all of the nodes get to E yet? Not quite, I need to extend it We need to work out how H gets to E Well, it's going to have to go along here To C and then from C It's going to go straight up to E And G also Is going to have to decide which way to go I can see cost 7 Sorry, let's see 3 6 here Or I can also see cost 6 up here That's a tie And we could use either of these And I'm somewhat arbitrarily going to go like this So this is a sink tree For E, and since we broke a tie There could be more than one Let's just clear that up So there are some very nice implications of sink trees Because Of this shortest path property Given that we have these shortest paths All we need to follow them Towards a destination is the destination The source that they came from Is irrelevant So you can see here Once I get to node C I'm going to then go onwards To E, it doesn't matter Whether the packet came from H Or whether it came from B Or whether it actually came from A Once it gets to C It simply follows the same remainder root to E So all we need to do is look at the destination That's fairly simple What's more We can sort of see How we might send the whole path But really all A needs to know For instance Is that it needs to send it to B Rather than directly to E And then someone else like B Will carry it further onwards This leads to a notion of a forwarding table For a node We assume that there are forwarding tables To do IP forwarding At a node the forwarding table Is going to list the next hop So that's going to allow us to forward a packet Because we'll know the direction to send it By simply looking at the destination You can see this will fit well With shortest path routes It may be that if we compute shortest path routes We will actually know a lot more About the routes through the network Than simply the next hop As I was saying in this diagram We know the whole path that you're going to take From a node to the destination But we're not going to need that forwarding So we might distill a forwarding table Of the information we have So far we've just been using Inspection to look at these graphs And find out which way to go With the sync trees In the next segment we'll look at how you can compute These paths yourself Or rather the nodes can compute it themselves By using well-defined algorithms Good day viewers In this segment we'll talk about Dijkstra's algorithm For computing shortest paths This will let computers do the calculations Instead of us, which is generally a good thing So the figure down below here Shows an example of a network topology What we'd like to be able to compute In this network topology Is the source tree from a particular node Like for instance E Out to all of the other Destination nodes in the network All of the other nodes as destinations This will allow us to work out The forwarding table for E Or which way to go To reach all the different destinations You can do that We've solved the forwarding problem Dijkstra's algorithm provides One way of computing these source trees And it's widely used as part Of a common routing protocol Which is why we're covering it Dijkstra's algorithm is named after E.W. Dijkstra, a famous computer scientist He is Well known for his contributions To programming languages You might have heard of a paper Called GoToConsideredHarmful It's also made many contributions To distributed algorithms Such as the algorithm we'll study For computing shortest paths As well as program verification So Dijkstra's algorithm That we'll look at, or it dates from 1969 So it's been around for a while It's a Single source shortest Paths algorithm Which means that it takes a given source And from that source it computes shortest paths To all of the other nodes in the network To do this it needs to know The network topology And there's also a caveat, a little restriction here All of the link costs That are on the various links in the network Need to be non-negative This is usually perfectly fine For using network graphs Because if the quantities The cost correspond to Anything physical or meaningful Chances are that they're non-negative anyhow So here's an outline of the algorithm I'll go through this outline And then we'll work through an example So you can see it in action So the first of all is an initialization step Dijkstra's algorithm Is going to visit all of the nodes So we begin by marking all of the nodes As tentative And we set up distances for them All of the nodes are keyed by their distance The distance of the source From which we want to compute The shortest paths from there Out to everywhere else is set at zero And the distance of all of the other nodes Will initialize it to be some constant That means infinity We don't know how to reach them yet And then we proceed in this main loop This main loop says while there are any nodes Which are tentative, meaning the algorithm Hasn't found them yet how they fit in To the source tree Then what we will do is we'll Extract the node with the lowest Distance that we know We'll then add that node To the source tree We'll be drawing a link from wherever It was used to get its current Distance to the node And then we will We will use the information from that node To relax other costs To lower other costs We do that by taking the cost of the node Looking at the nodes' neighbors And seeing if there is a lower distance Way to reach any of the nodes' neighbors That might sound a little mysterious But let me go through an example And you'll see that this relaxation step Is straightforward Okay, here's an example That I'm going to walk through It's the same topology from before And I've shown it with an initialization phase Where you can see That next to all of the nodes I've written in red Their costs For many nodes, it's infinity For the source node where we're going to start From, it's zero Now I'll proceed through that while loop First step of the while loop The node with the lowest distance That's A where we want to start from And do a relaxation around A So if A now has cost zero You can see I've changed the cost to blue It's locked in Once we visited the node And taken it Then we found the path to that node Of course this is just the source Now I'm going to color nodes that we visit Black And then the relaxation from here It looks at the cost of this node at zero All of its neighbors And sees if it can lower the cost What are its neighbors of A One is B You can see here I've circled B B's cost used to be infinity But B is one link of cost four Away from A which has cost zero Therefore B's cost could be reached By A at cost four That's less than infinity So we're going to lower the cost of B From infinity to four That's one relaxation So B's cost used to be infinity When we didn't know how to get there But now we have an option We can go from A to E directly Over this link of cost 10 So E's cost will be 10 Both of these nodes have been relaxed That's a step in the right direction Next iteration What do we do? We pick the next lowest node That's going to be B with cost four Just circled B So we add B to the shortest path tree From the source tree from A Now B with cost four was reached from A Directly over this link So we add that this link to the shortest path tree Now let's perform a relaxation We'll go around all of the nodes Connected to B And see if we can use the links From B to lower the cost Let's look at C first C's cost used to be infinity But C is a link of cost two Away from B at cost four So C can go down to cost six It got lowered E is A link of cost four Away from B so that can be reached at eight E's cost before used to be 10 So actually E has now been lowered To be cost eight So interestingly E's distance is full and not just from infinity down But it used to be some finite number 10 Now it's gone down to eight So we're finding better paths over time As we go out Further and further away from A Similarly we'll do the relaxation From B When we look at its neighbour F Its cost goes down to seven And G goes down to seven Two. This is great Okay next step What do we do? The next lowest cost Well the lowest cost of the remaining nodes That haven't been visited is C with cost six So we take it I've changed its cost to blue To say it's done We add this link C with cost six could be reached At that cost from B So we add that to the tree that's a new link My coloured C black too To indicate that node is visited Now we do our relaxation around C What's going to happen? Well H's cost is going to fall We have the cost of D can be reached now At eight here So I think D's cost Will fall in two I'm not sure we'll see that I guess Well you have to look at the previous slide Relaxing from C We get That the cost of E Has now gone down to seven Because it can be reached over a link of cost one From C is six when plus six is seven So it's gone down again Well our route to E Is just getting better and better I guess D went down from Well I don't know You can look at the previous slide It's hard work going through these graphs I hope I haven't made too many mistakes That you're going to find Okay so continuing Well it looks like we've done All of the relaxations for C So let's continue on Now we've got to pick the next lowest node There are actually three nodes That have cost seven So any of those will do As the minimum cost to extract We're going to arbitrarily pick G Just to work our way around The graph G could be reached at cost seven from B So we've now added this link here To the shortest path tree Out from A And I've changed the cost Of G in seven to blue And marked the no G in black Let's do the relaxation from G G has one other neighbor So that other neighbor We can reach A link at cost four So the cost to reach F by G Would be eleven Eleven is not bigger than seven So actually that means that Routing to F by G would be a bad move And we don't lower the cost And remember that as a new route So that hasn't changed anything Next moving on We'll do a relaxation Around F So first of all We're taking F as the next lowest node We're going to add The link at which F was reached At cost seven to the shortest path tree That is a link from B It was reached from B at cost seven So we've added this node to the shortest path tree We do the relaxation And we find actually that it doesn't lower Anyone else's cost Everyone else has reached a better way Than going through F I guess Is what that means Continuing Now we get to E So we want to do a relaxation around E So we take E Make its cost in seven Is now in blue We've colored the node black We've added the link E at cost seven was reached via C So we add this line From C To our shortest path tree Now as we do that relaxation I think nothing much changes By the way all of these nodes That are already being visited They're not going to change We've found the lowest cost way to reach them The only node that could potentially change Is this one in red But seven plus two is nine That's bigger than eight Doesn't change Okay going on what's left D Now we'll take that as the next lowest And we will Take this link So relaxation doesn't change anything And finally There's one node left that's eight at cost nine So we add this one And we're done We've now found the source tree From A to all nodes If you just look at all of these blue lines You can see that they started A They go out And they provide a set of paths To reach all other nodes on the graph And these are the least cost paths To reach any of these other nodes We've done it We have a nice methodical procedure For finding this source tree From a given node For a particular topology And that's Dijkstra's algorithm Let me make just a couple of comments Before we wrap up So you might have noticed that Dijkstra's algorithm Finds the shortest paths In order of increasing distance from the source What it's really doing is leveraging This optimality property That for long shortest paths Smaller shortest paths Sub-paths are also shortest paths So we can build up From small paths to large paths And they all overlap That's why it works to Go out at increasing Distance and that ensures that once We've gone out to a certain distance We'll never change your mind later And change any of the paths we've already selected This algorithm Can take a little while to run on a graph topology Actually the efficiency Of running it depends on how you Implement this Extract minimum cost node function Depending on what data structure you use You can use different ones Depending on if your network is Dense in edges or sparse in edges But in any case the running time Is super linear in the size of the network That means as the network grows larger The run time of this algorithm Is going to go even more quickly And eventually for very large networks The run time will get very large It's not surprising really There are so many different little paths That you can easily imagine Some of the complexity here And finally I'll note that it gives us The complete source tree or sync tree Depending on which way you run it This is actually more than we need for Fording each node Just needs to know the next hop For all particular destinations So we have more than we need for Fording and we can use it That's great. To get this of course We need to know the complete topology So that's going to be an issue We'll have to address in routing Now that we know Dijkstra's algorithm I think we can keep moving on And look at other routing algorithms In this segment I'm going to tell you About distance vector routing One of the two main methods Which you use to find routes So we've talked about the notions Of shortest paths and how you can use These paths if you have the topology All in front of you What we're going to see now Is how to compute these same shortest paths But in a distributed network setting As we need to in the internet And we're going to look at what's called The distance vector approach to do so Distance vector is a fairly simple approach To computing routes It was used fairly on in the internet Actually when it was called the ARPANET And also in a protocol that you might have heard of Called RIP Distance vector is one of the two main approaches Towards routing the construction Of routes that is If you want to impress someone I guess you can tell them that technically This is a distributed version Of the Bellman Ford algorithm Maybe they won't impress them, who knows The algorithm itself works fairly well It's correct But it does suffer from very slow convergence behavior After some kinds of link failures And for that reason The kind of algorithms which we use In routes in most Real networks today Are often link state algorithms Which we'll see in a little while These algorithms are a little more involved In terms of the work they do But result in better overall behavior Okay, now here's one thing That I would like to stress Because I think it's very interesting For our routing protocols We had looked at a centralized scheme Where you run Dijkstra if you know the whole topology That's not how networks work at all You need to compute routes in a distributed setting What is a distributed setting Well, I'm glad you asked It's really very different than the centralized setting Where we have the whole network in front of us In fact, if you're a node in this setting All you know is your neighbors And maybe the cost to reach your neighbors So you just have local knowledge You don't know the overall topology at all In terms of finding out things And deciding things, you can only talk To your neighbors using messages You can't send messages magically You can only gossip and exchange messages With your immediate neighbors It's also the case That all nodes run the same algorithm concurrently There's no special leader or boss Or centralized place that's in control of it Every node is equal And yet amongst themselves Somehow they all need to decide On compatible routes And just to make things a little more challenging Nodes and links can fail And messages can be lost Actually, so it's not just the links That can fail and messages that can be lost But nodes themselves can go down and fail And that's going to be a little tricky Because you might have been talking to a node A while ago and now it's gone away And yet we still want to be able to find correct routes How do we do this? Well, distance vector is one approach And here's how it works just in one slide And then we'll go through an example Now in the distance vector algorithm Each node maintains a vector of distances Let me just underline that As well as next hops To all destinations This is the distance vector And that's the heart of the algorithm What you're going to do is compute the best distance vector And keep that best distance vector over time So you start by initializing Your distance vector with zero For yourself as a destination Because you're already there, congratulations And infinity to everywhere else You don't know anything else And then this algorithm All you do, and this is a simple repeated step Is you exchange every node Since its distance vector The one it currently has to all of its other neighbors You just, you keep doing this And then as you receive From your other neighbors The new distance vectors periodically You update your own distance vector And you update your own distance vector To choose the best path And that's going to be the Since we're after shortest paths The lowest distance to each destination That you've heard When you correct of course Your neighbor that you've just gone across That's the one extra link From the distance vector information they gave you And you're going to pick the best route And then you'll use it for 40 Okay, that's the distance vector algorithm It's a little bit of a mouthful If you're not used to these kinds of algorithms So let's see an example of how it works in practice So here's a simple network I'm just going to look at this basic network With four nodes, A, B, C and D And just a few links here You can see I put the costs On all of the different links And every node In this network is going to run its own Its own instance of the distance vector algorithm And keep its own distance vector And exchange messages with hosts Here, with its neighbors, excuse me Here is the view Of just the distance vector that A has At the beginning of time So A says, well, I can reach A with cost zero Great, I'm already here B, C and D, they're the other nodes in the network They're the same And you note here that A can only talk To nodes B and D directly Can't reach C directly So what happens? Well, what's going to happen Is that A Is going to send its distance vector To the other nodes B and D Now B and D and all other nodes Are of course going to be sending their distance vectors To all of the other links So A is going to be receiving two distance vectors One from B and one from D And I put them here in this table The distance vector Tells us information to all of the different destinations A, B, C and D And we can see what B says B can just reach B And everything else is infinity And D can just reach D Now A needs to choose the best entries After correcting for the local link costs So for B We really want to look at B plus 3 Because 3 is the cost to go over the link From B to A To A, that's the special case We already had 0 For everyone else So to B What did we find? Here was the lowest It's just cost 3 Going directly via B To C We want to choose the lowest number As we go across So what do we have? Well, A actually To A, that's the special case Going directly via B To C, we don't have any lowest cost It's still an infinity And to D, we have 7 So that's going to go over here And then we can see here is the distance vector That A has learned after the first iteration And it will have in fact found the best One hop routes which are possible in this network And all you can do with one hop Is just reach B and D directly So this is what A is going to do A is really here learning the minimum Of B plus 3 For a special case of reaching itself At cost 0, because it knows its own identity Of course This is the same process As you're going on, not simply at node A But everywhere else So wow, this looks a little more complicated But let's just imagine for a moment What's going on elsewhere Now here This table here shows us all of the distance vectors That B, C and D Exchange with their neighbors We worked out what happened today We copied it over here B is going to learn the minimum Of A plus 3 As it comes in here C plus 6 As we come in on the link on the right And D plus 3 is becoming those things And I've written that there I could also tell you that C C is going to be equal to The minimum Of, let's see, C is connected To B Over a link with cost 6 and to D over a link with cost 2 So that would be what you would want to use To compute the routes for C So if we follow this same process And you can check this Hopefully I've got all of the numbers right Then you can compute the first The one hop best routes That B, C and D learn Well this process doesn't end Actually it's quite complicated Thinking just trying to keep in your head What's going on in all of these nodes The second exchange Here are the distance vectors That are going to be advertised These are simply the best ones Which were learned at the end of the first exchange So they're going to be sent out And we will then Every node will go through exactly the same process And here you'll end up finding The best two hop routes After the second exchange Well what's A going to learn Remember we said that A Is equal to the minimum And D plus 7 Let's look here So we really want these ones Plus 3 And these ones plus 7 What's going to be the minimum here Well to A of course is the special case of 0 To B Let's see, well 0 plus 3 is 3 That's lower than 10 So we're going to learn a route to Well I guess we already had that We're still like that I've coloured in pink here the ones that changed We've got C To C by B is cost 6 Plus 3 is 9 To D To C by D is cost 2 Plus 7 Is the cost of that link So A now actually knows two routes To reach C at cost 9 So we'll choose simply one of them Let's say it's arbitrarily here chosen D by D To reach C Similarly if we look down here 6 and 7 and 0 is 7 So we find that A can actually reach D at cost 6 by B It's learned a better to hop route That is this route to get to D We've now learned that that is shorter Cost 6 instead of this route That A was using after the first exchange Well this process continues I'm going to leave you to Check some of it at home What we will find out is that We're now finding the best 3 hop routes For the better A here is reaching C Via B at cost 8 So that's actually going to be like this Is the shortest route Looks like we're actually using this In two directions C is seen to A by D So it's going to go like this too So we found that is the best 3 hop route Well after that If you go through and check all of this table You should find that there are no shorter 4 hop routes Because the diameter of this network There are no longer paths So we've converged now And all subsequent exchanges should send the same information Until there's a failure that is And then the routes may change So in distance vector You should imagine that In the dynamics here In terms of adding routes News about new possible routes Is being added in 1 hop Per exchange Every exchange we were finding information about routes Which were 1 hop longer We haven't yet got to when you remove routes But I'll tell you when you remove routes What happens is that A node fails So actually it doesn't send a message saying You can no longer use any of my routes What happens instead is that other nodes Need to forget and time out the information Over time if it's not Reiterated There are problems though with distance vector Remember we said some convergence Issues can arise Particularly with something that's called partitions Partition is when you divide a network Into two different portions So that you can't get from one side to the other side If this happens Because say a key link breaks This is why you actually want more than one key link In network so there's a little bit of reliability You get a convergence problem You get what's called the count to infinity scenario Here's that scenario So I've shown on the left The desired behavior This is a simple chain and we're looking at how information From the destination A propagates You can see here good news Reaching A, news travels quickly After one hop B knows you can reach it Node 1, it's down here After two hops C knows you can reach A across two and similarly As we're going down and down and down this table What about when there's a failure Here on the right hand side And A can no longer tell people how it can be Reached Well initially we'd found out all of these Good routes and now there's a failure What's going to happen Actually if you look at B B will now get that announcement Not from A because A can no longer reach it But from C, C will say well I can Reach A it costs two because that's what it could So B will now say Okay well I can reach A it costs three Because that is The C's distance plus one to go over that link Well You can imagine what might happen here In the next iteration C Is learning how to get to A from B C's going to raise its cost to four Uh oh That will cause B to raise its cost To five and D to raise Its cost to five in the next round And subsequently C Is going to have to raise its cost to six Oh because they depend on one another And you can see that something really screwy Is going on here This is called a count to infinity scenario Because the network is really exploring Ever longer routes in a vain attempt To try and reach a destination which is Not reachable For desirable convergence behavior Because it means that for a long time The routes in the network can be in flux Now you might think that my example Was a little contrived because C shouldn't be fooled so easily C knew that it was getting to Uh sorry B shouldn't be fooled So easily because B knew That it was normally getting to A directly And it was in fact telling C The best route to use so B Shouldn't really decide to go via C And then just add one to the cost However these same effects Arise in larger Uh cycles In longer paths and other networks Even when you're not talking to one another directly Cycles of three nodes and so forth So they're uh They're very involved In these networks and they're quite hard to get rid of There are various heuristics They have colorful names here like split horizon And poison reverse just means You know B Don't suddenly start using information from C If you told C how to actually get to A But these heuristics turn out not to be very effective In practice They get complicated and they don't really solve the problem In nearly all of the cases For that reason link state algorithms Are more favored in practice And we'll look at link state protocols In the next segment One exception is that distance vector Is really very lightweight and all you're doing Is keeping this distance vector and propagating No complicated graph algorithm This distance vector When you're very resource constrained Might be one exception Okay so distance vector Is the technique Distance vector is the technique which is used In a protocol called RIP It's one of the more famous distance vector protocols It uses hop counters A metric so we're simply counting The number of hops routers we go through And we use infinity as 16 hops Just to this limits the network size But also It stops us exploring ever longer routes In case of some of these weird things It also includes these heuristics For split horizon and poison reverse RIP is actually quite An old protocol now You're unlikely to use it in practice So you might look at it just to understand How some of these protocols worked There's an old IRFC you could look at It's quite dated now But it's a nice small IRFC You can read the whole thing and understand the protocol You get all of the details like the 30 second timers For sending these distance vectors It's run on top of UDP Information times out if a node goes away After 180 seconds As a way of detecting failure So there can be a failure Once there's a failure it can be a long time Before the network responds and fixes routes This is not so good these days But And this is why we run faster And better routing protocols these days But nonetheless it's an interesting protocol to look at Okay you know about distance vector G'day viewers In this segment we'll talk about flooding A useful primitive for routing So flooding Is a mechanism to broadcast A copy of a message from one node To all other nodes in the network It's called flooding Because it really works By making sure that the message appears everywhere It's flood throughout the entire network Just like water going everywhere This makes sure it'll be received by everyone It's a simple mechanism But somewhat inefficient such that You wouldn't want to use it Regularly a lot of the time So Here is the rule for flooding Now I'll remind you that this is a distributed setting So all nodes are executing This rule in parallel concurrently Right and none of them know The overall topology of the network The rule for flooding is very simple That's its virtue Every node When you Receive an incoming message Which is meant to be flood to the network You simply send it out on all of your other links So it will reach all of your other neighbors Except where it came from Great And there's one condition here Just to make sure that we don't keep sending Messages around and around in circles You need to remember the message That you've flooded in some way So that if you see it again Because it arrived at another path And keep it going around the network Flooding is inefficient Because one node Can receive multiple copies of the message Along different network paths And really It only needed one copy of the message To see it, the copies that come along the other Network paths are wasted in some sense So let's go through an example Just to see how flooding works Same topologies before For our examples We're going to flood from A I've shown the node that is busy Doing the forwarding of messages It starts at A I've labeled A in red A is going to flood the message By sending it to its neighbors So it will send to B Via A, B and E Via A, E And I've shown both of those Floods In blue, so you can see that the message Is propagated to the other nodes And is used some of the links What happens next? So our message reached Both B and E So let me just circle the nodes which were reached Both of these nodes should now flood Let's look at B B received the message from A So flooding means it should send it On all of the other links So it's going to send it to C It's going to send it to E In this way It's going to send it up to F And it's going to send it to G Similarly E is going to flood By sending it to all of its neighbors So it will send it down here to D It will send it down to C It will send it back to B And it will send it to F So you can see this message Is really getting copied around the network So F here has received Two copies of it One from B and one from E It only wanted one but it's got two And B and E Actually happened to do their flooding At the same time So both of them have sent each other The same message So it's crossed the link between them In both directions This is what flooding can do It'll really make sure the message gets everywhere What next? Well we've gone through A, B and E The other nodes which Received the message most recently And haven't yet flooded it Were C, D, F And G They all need to do their flood Let's have C do the flood C received two copies of the message One from B and one from E So it's going to send it to the other Nodes It's H and D here D Received the message from E So it can send it to its other neighbor That's C down here So you can see the messages crossed C and D two times Now F Is going to flood F's actually received a copy of the message On two links from B and E So all F has to do is send Down to G And G similarly received it from B It can send up to F So F in fact You'll see here Is very fortunate or popular It's getting another copy of the message So F has received a copy of this message On two links and it's sent it out once And finally We've reached H H has no one left to flood Because it's at a dead end And we're done with the flooding algorithm You can see here That the algorithm was fairly simple And it caused the message to be carried On each link at least once Sorry Each link in at least one Direction is maybe a better way to say that So for a given link Both directions are only one These pink arrows show you what happened This is inefficient Because really to reach nodes like F We didn't need to send it along all of these links We could have omitted many Of these messages and we would have Still broadcast the message Effectively So there are a couple more details I could tell you about flooding Just to complete the algorithm I said one of the keys here is to remember the message So that you can stop the flood eventually Well we only considered one message This would be harder if many different nodes Were using flooding What is typically done is instead of Literally memorizing the whole message You will, for each source Associate a sequence number And put sequence numbers in the message That way we might remember that A Last flood a message with sequence number Seven If you ever see a message from A Whose sequence number is seven or lower You know that you've already flooded If you see a message from A with a higher sequence number You assume it's new Flooded and then update your sequence number And the flooding we saw was also unreliable If you want to make flooding reliable You can simply use the ARQ mechanism we saw So when we flood And one node sends it to a neighbor The neighbor can acknowledge that flood And if the node doesn't receive the acknowledgement Then it can resend The flood message At a later time by using a timeout This will make sure that we reliably Send the information and reliably broadcast it To all of the nodes in the network So now you know about flooding Flooding is fairly simple It's a little inefficient but it's a good Building block or foundation on which to build Other more efficient protocols G'day viewers In this segment we'll talk about the Link state approach to routing So our topic is really computing This shortest path that we've talked about Previously in a distributed setting That corresponds to a network We've looked at distance vector routing Now we'll look at link state A very different approach One in which there are a couple of phases First everyone floods the information And then we compute the routes So it's interesting to compare Link state routing with the distance Vector approach that we've seen Because they operate quite differently The distance vector approach Spread the work of computing the routes Across all of the nodes of the network In link state we give Everyone a copy of the topology And let everyone compute Their own routes so we're really replicating A lot of work in some ways As opposed to having everyone work Cooperatively as in distance vector So link state is actually a little Closer to that old view Of giving everyone a map of the network And then letting them work out their own routes Now link state routing Is widely used in practice It's been around for a long time Almost as long as distance vector It's been used in the ARPANET Since about what's it say here in 1979 Onwards And many modern networks today Use protocols That are based on the link state approach Here I mention OSPF and ISIS Which we'll just mention Very briefly at the end But these are protocols that would be used In ISP networks, large enterprise networks Like on campus or in a big company They all use this link state approach Before I dive into the details Of the link state approach Let me just remind you of the setting we're working in This is the same as the setting for distance vector It's really our distributed setting Which makes routing more complicated Than simply looking at a picture And being able to centrally compute things Or remind you briefly So in this setting The nodes only know about who they're connected to Their neighbors and their costs to the neighbors They don't apriori when they're turned on Know the whole topology They can only talk to their neighbors Using messages to find out what's going on For the network at large So they have no other way to gain information About the network All of the nodes are running The same algorithm concurrently None of the nodes are special So there's no centralized controller They're just going to have to agree on monks themselves On what's going on And they operate in parallel And they coordinate their actions And finally, since this is routing We would like to be able to deal with Fail components So some of the nodes and links may fail And we would like the remaining portion Of the network that's working To correctly find routes Messages may also be lost So that's the setting What about the link state algorithm Here's how it works There are two phases In the first phase It floods information about It's local portion of the topology To everyone else using what's called Link state packets In this way every node Will get a picture of the full topology So we do this whenever the topology Changes or when we start And then when everyone has The full topology Will move from step one to step two Each node is simply going to Compute its own routes And forwarding table The first step here uses flooding Which we've looked at previously And the second step uses Dijkstra's algorithm Which we've also looked at previously Link state really just combines these two steps And that's how it works I'll go into just a little more detail So the first phase Is flooding to disseminate the topology Each node Is going to flood what is called A link state packet that describes Their portion of the topology So I've shown the link state packet For node E Here And you can see from node E If I just look at node E Its portion of the topology includes a link To D Actually let me go through it in order It includes a link to A Which I'm drawing over here With cost 10 Then a link to B With cost 4 And you can see in the Link state packet The connectivity from node E So we can see there's a link here to A At cost 10, B at cost 4 And similarly there's C here D trace over And then E well There's no connection to E because that's where we are And there is a connection to F All of those are listed in this vector With the appropriate cost That is the link state packet That's what node E will flood out And every other node will do similarly For its portion of the topology Well once that phase 1 is completed Every node will have received every other node's Link state packet By putting them together they'll have a picture of the Complete topology Phase 2 is to compute the roots All we do is have every node run Dijkstra's algorithm So there's some replicated computation here The nodes are looking for the source trees From themselves out And so that can be different in different parts of the topology Although there's definitely some overlap here Once we find the Source tree in the node We'll be able to compile the forwarding table From it directly That sort of tells us all we need to know And that's it Let's look in just a little more detail to get comfortable With that Here at node E again I've shown the source tree That is the result of running Dijkstra's algorithm So node E will gain this picture And gain this source tree By itself by going through these steps And it will then know which way to go To reach all of the nodes What I've done now From this source tree All of the different lines here have arrows Which show the path to take For instance, to get from A To Sorry, from E to A I follow this path through the network Through here and over here Through E, C, B, A What I can do now Is simply compile it Into a forwarding table The forwarding table lists for every destination The next step So for instance, to get to A The next step is simply to forward to C And that's all E needs to know C will then take care of the packet from then on And similarly for all of the other destinations That's our forwarding table And if that's all that's going on in the network We're done But of course, the whole purpose Of routing protocols Is to be able to adapt to changes So when there's any change in the topology Because a component is failed Or maybe because a new router or link has been added We want to Redo some of this process Go through the phases again So you'll flood any updated versions Of the link state packets And recompute the routes Let's look at an example here Of just what would happen What is going to happen when there's a failure Is that the nodes that are adjacent To the failed link or node Notice that something's changed They'll be able to update Send updated information And everyone who receives it will be able to recompute So you can see here A failed node G It's gone, I don't know, it blew up What will happen? Eventually its neighbors B and F Should realize that it's gone They'll need to be exchanging some sort of regular Hello message to make sure that it's alive But eventually when there's no answer They'll notice that it's gone Now at this stage they can issue Updated link state packets In their link state packets I've listed the same neighbors as before But you can see I've changed the cost From both those nodes to reach G To be infinity Meaning this link does not work The cost is infinite so don't take it When that information is spread Around the other nodes will recompute And they'll work out paths which do not Go through G Now if you think about it Notice that there's a subtle difference Between a link failure and a node failure When there is a link failure Then both of the nodes that are adjacent To the connect to the link Will notice that the link no longer carries Packets so they'll both send Updated link state packets Saying the cost of that link is infinity And therefore the link will be Removed from the topology effectively When nodes calculate their links Now imagine though That there's a node failure That's kind of interesting Well all of the neighbors of that node Will notice that they can no longer talk To it over the link So there's something wrong with the link To the node Actually these neighbors don't know Whether it's their link to the node That's failed or the node that's failed Both of these cases look the same In any case All of the neighbors of the failed node Will notice that something's gone wrong And they'll be able to issue That node anymore The node that's failed however Won't issue a new link state packet I mean it's failed that can hardly send A message saying hi you know I'm sorry I failed because it's no longer there And it's very unlikely we could count on it To issue something saying I'm going to fail That's just not the way failures work However It's okay here Because since all of the neighbors send Messages saying they can no longer get to that node The shortest path computation Will effectively remove paths Which go through the node Even though that node didn't send an update itself Saying that it's links had got A change to cost infinity It's interesting if you think about it And just for the sake of completeness Let me mention that there are other changes For instance you might add New links or nodes to the topology In this case The nodes that have the new links Or the new nodes will send Updated link state packets And some will learn of extra bits of the topology And they'll use some of those new Links and nodes as they Recompute the shortest paths Really here additions are the easy case It's failures where someone fails And can no longer tell everyone they fail Which are the tricky case But we want routing to be able to adapt To either one of course Now to be fair I also want to tell you that There are complications in link state protocols I'm making it sound kind of easy But when you're describing the normal operation The normal cases They work as I've described them But when you design a protocol You want it to be correct and work Pretty much no matter what happens And there are some bizarre cases That we could come up with And I've made up some here Now As part of flooding You have a sequence number on the flood So that we can stop the flood And only flood new information That reaches its maximum We could make that maximum very high But then what's going to happen If the sequence number somehow gets corrupted To a very high number And gets close to the maximum This seems very unlikely But the point is we don't want the network To be jammed up permanently if this happens Another case Would be that a node might crash And when it comes back up It's forgotten what sequence number it was using before It can't just start at zero again Other nodes might know higher sequence numbers For its messages that are flood And so they won't listen to the low numbered Sequence messages Or other bizarre cases The network could partition itself It could divide into two components Due to failures Both of these components could evolve independently And then when the network connects itself again You know, each side Could think the other portion of the network Is in a different state and we would need to fix that Wow, this is a little messy Really a lot of the complexity Of real protocols has to do with handling These corner cases So that things work well in the common case But they are correct Even in these weird cases I'm not going to go into these complications In any detail at all I just want to point out to you That it's important that real protocols handle them You can read a little bit more about them In your text I'll tell you one strategy that's used And that is aging So one strategy that's used Is that we include a time stamp On all of our link state packets And most information that goes around Networks If this information is not refreshed over time Because whatever created it has gone away Then we forget the old information This tends to remove Old Information which is no longer relevant From our network and lets the network get on And adapt to the real situation That we're now faced with Used in link state protocols But it's also a general useful strategy Okay What else about link state One thing we've reached now Now that we've gone over it Is we can compare it briefly with distance vector This is useful just to see Some of the differences between the two Here's a table that lists our goals For routing protocols from long ago And we'll see how the two stack up Now for correctness We wanted to be able to calculate Even in this distributed environment The two approaches Used different algorithms Link states based on a diextra With some replication Distance vector is based on A version of the Bellman Ford algorithm Which has been distributed Different approaches but they're both work In terms of efficient and fair paths We're using our Shortest path framework Where we assign costs to links for both It's the same in both Well where they differ a little bit Is in these last two entries Convergence we would like rapid convergence To the new routes after any kind of change To the topology like a failure We've seen That distance vector can be slow In some cases it can have this count To infinity and require many exchanges Whereas link state generally Tends to provide fast convergence All you have to do Is flood the new topology and everyone Recomputes so it wins here In terms of scalability however The trade off is the other way around Distance vector really has Excellent scalability in terms of Storage and computation at a node Because it does the minimum We just have the lists of nodes The computation is really adding Numbers and comparing them You can't beat it Link state on the other hand Has more computation The amount of computing we need to do And storage to store the whole graph Is super linear with the network So it increases more rapidly Than the size of the network So distance vector actually wins In terms of scalability here It's an interesting trade off Okay and finally I'll just mention a couple of real protocols Which use the link state approach And they are ISIS Intermediate system to intermediate system And OSPF open shortest path first OSPF is really the IETF or internet version Of the ISIS protocol Which had its roots More on the OSIS side of the house These are Modern link state protocols They're very widely used In ISPs and large enterprises They have supplanted distance vector protocols Because they have different Better convergence behaviour Even though they require a little more computation While computation's gotten cheaper over time The basic operation Is as I've described it So you know the heart of how they work With the link state protocol I'll also tell you they have many more features That are added There are notions for instance Of different kind of regions So that will help to scale the protocol To larger networks Or stub areas So that it's easy to compute Roots for stub areas you just need to Go out, you don't need to worry about Doing a lot of shortest path computation Don't worry too much about these features Or any real protocol I'm just mentioning them so you have some sense But you know how these protocols work And now you have a sense Of the link state approach to routing Good day viewers In this segment we'll talk about equal cost multi-path routing That's a mouthful But it's really an extension To the shortest path routes we've seen before What we would like to do now Is to allow The use of multiple routes Between a given node A destination In everything we've seen so far With the shortest path formulation We picked a single path from a node to a destination But what if you want to allow multiple paths For instance in this network To get from A to E you can see I could take This path here Or there's another path through the topology Which actually turned out to be a shortest path Before I could allow both of these to be used at the same time That's what we're going to look at The general name for this Procedure is multi-path routing The use of multiple paths Now These multiple paths usually exist In the topology already And the reason for that is you want to provide Enough links in your network topology For redundancy in case one link fails You want to be able to have a different link To reach a destination So there probably were multiple paths somehow We would just like to be able To use them both at the same time During forwarding The reason for this is simply to Improve performance Maybe we can fit more traffic through the network If we can use these multiple paths What we're going to look at now Is really a simple extension to our framework So far to incorporate multiple paths It's fairly straightforward There are really two questions we need to answer How do we find these multiple paths As opposed to finding a single path We did before And when we have them How do we use them for forwarding The second question is about forwarding Given that we have multiple paths How do we use them at the same time To send traffic So let's go through These questions And we'll do it in the context Of equal cost multipath routing This is really one form of Multipath routing Which is an extension of our shortest path model All we do here The extension really is to keep a set Of next hops and routes If there are ties Previously we just chose one randomly When the costs happened to be the same That was one that was not a unique Minimum cost So here's our picture of the network again Just to illustrate that And I've changed a few of the costs here In red Now we're going to have some Paths, multiple paths Which have the same minimum cost So you can see them in this graph I've sketched them And just compute them to make sure that they're okay The path A, B, E Is one way to get from A to E That has cost 8 Okay Well there's also another path And that is the path A, B A, B, C, E That has cost 4 Plus 2 Plus 2 is 8 And there's even another path Which goes A, B, C, D, E That Is more hops But it happens that the cost of these hops Is lower and so when you add it up Guess what you get again, 8 All of these paths are the minimum path And in our equal cost multi path Formulation we'd like to use them all Now Equal cost multi path Since it generalizes Shortest path routing and actually changes Our notion of a source tree And a sync tree With ECMP These source and sync trees They're actually not trees anymore They become a slightly more general structure Called a DAG Which stands for a directed acyclic graph Now In a normal tree We have a structure like this on the left And you can see just a classic hierarchical Tree there Every To get to a particular destination One next hop In a DAG However You can see I've added some of these cross links Every node can have a set of next hops That it can use to reach a destination So for instance There are two paths through here From the source to the one destination So that means From the root I could go Either of two different ways And I would still be able to arrive At this same particular node down at the bottom It's a DAG It's acyclic So there are no cycles or loops in this topology As you follow paths through here You'll definitely get to a destination Without going round and round in loops So we haven't admitted loops There's also still a compact representation For routing Each node now has not a single next hop But a set of next hops To reach a destination But we don't need to have nodes Store the entire path or anything like that So here's a little bit of an example Here's our graph again Now we'd like to find the source tree Or really DAG for E The procedure that we go through Is simply dykstra But keep all of the tires Instead of randomly picking one And then once we've got this tree We'll be able to compile it into a forwarding table I'm not going to show you here But you'll find that as well as dykstra There's also a straightforward extension For distance vector Using one minimum cost route You can keep multiple of the minimum cost routes The set of neighbors If you like Okay, let's see that source tree for E Well, let's see I'm going to start going out with minimum cost From E we can reach D here Now at distance 2 You can get to F We can get to C Now interestingly This is where things have been added I can get to C in two different ways The direct route here And by D, still cost 2 And we can then go on Adding other Paths through the network So for instance to get to Well to get to H Well let me do B first You can get to B here But you can also get To B Along this path They both have cost 4 And similarly A along here H along here And F along here None of this has changed And this is the shortest path Sorry, the source tree Which is really a directed acyclic graph If I just flip ahead You'll see now hopefully they were actually the same as what I drew That there are two new Lines here that really got added With the ECMP case I'm just tracing over them We can now compile The source tree is before But a slight generalization of it You can verify that for yourself We can now compile this into a forwarding table It's the same procedure as before Just mapping from a tree Down to all we need to do Is remember the next hops But you'll notice here That to get to certain destinations I have a choice of next hops One of the biggest ones is To get from E to A I can go many different ways I could go this way These are the examples I sketched before I could go this way Or I could go this way Three different paths All of minimum cost 8 That means from E I could choose Any of B, C or D As the next hop And you can see that in the table Now instead of one entry We have multiple entries And you can go through the rest of the table And you can see that I've colored in pink They have sets Instead of the single next hop That's it for the routing What about the forwarding We like to forward with these Equal cost multi paths One way you could do this Is when you have a packet You only want to send the packet Down to one neighbor Otherwise we'll be making copies of it You could simply choose at random For every packet Which of the next hops to use That's this option here That's actually very effective in terms of balancing Traffic across all of the different paths However, it adds jitter Now what I mean by this Is that the different nodes Going from a given source To a given destination Might experience quite different delays Through the network For instance, maybe if you send packets One, two, three, four At a particular node One and three and four Will take a certain choice Which is a shorter path physically And in terms of seconds I mean the cost is going to be the same Whereas path two might randomly Be chosen to take a different next hop Which will be a more secure route Which will take longer So we might send packets one, two, three, four But they might be received at the destination One, three, four Because they took the short path And a long time later packet two Will arrive At the destination So we would like to avoid these kind of effects So instead What we'll try to do Is send packets from a given source destination Pair on the same path This is um Imagine if you've got a video conference It's between a particular It's a set of traffic or a flow This is sometimes called Traffic between a particular source Destination pair Often for a particular purpose We would like to send the traffic From a given flow along the same path Through the network This way the ordering of packets Should be preserved We shouldn't get any of this wild jitter So all we do to handle this Is we make the choice not at random per packet But we map a flow To a single next hop How do we do this Well here's an example I've shown the paths here Just a segment of the paths From f to h We have different paths through the network We might go this way Or we might go this way This also includes By the way the paths from e to h We can take those different choices And the paths from f to c And the paths from e to c As well as e to h Well I said one twice there But you can see that there are four different Source destination pairs I've listed them here as flows Traffic from f to h and f to c As well as e to h and e to c Now for all of these different flows As they go through e They could be seen Either to c or d Instead of choosing at random We'll simply make this set of choices For the packets that come from f We'll send them to d And for the packets that come from e When they're going to h or c We'll send them to c as a next hop In this way we have some consistency For the flows But if we think about Traffic that's heading towards c We're actually using both of the next Hops, we're using d And c So traffic towards those destinations Is utilizing multiple different paths Through the network in parallel And that's how we forward With ECMP Now you know this slight generalization Of the shortest paths we've seen before Good day viewers. In this short segment We'll talk about how hosts and routers Are combined in the internet For the purpose of routing Now this topic is really just to Provide a little bit of a bridge Because we've talked about routing and nodes But we've also talked about forwarding And said that there is a distinction Between hosts and routers Routers, routers and hosts don't And we would like to glue them together Into a network Just to recap that slightly As I told you before In the internet Hosts on the same network Have IP addresses that come from the same prefix We do this in order to be able To scale routing And assign addresses And the way hosts handle the issue of routing Is that they send any traffic That is not for a local host That has to go off the network They just send it to the nearest router They don't need to know what the router does with it Their rule is simply if you don't know The local network, send it to the router Routers on the other hand Have to talk to one another And discover the routes to use To get packets to every address in the internet And the way they do this And implement this Is that they use a longest prefix Max longest prefix Matching algorithm On their forwarding table To decide what next hop To send a packet to based on their address Okay, so let's try And put these pieces together Here is how hosts and routers Would be combined in a network Now the networks I've drawn Have pictures here like a Router, here's a router A And that router has links That connect it to the rest of the network That's fine, that's mostly What we've seen with our pictures of graphs The dots represent all of the Different routers which are doing the routing But we also have hosts in these Networks, so where do they fit Well the hosts are attached to the routers Now often there is like A switch, a LAN switch here So that we can attach multiple different Hosts to the same LAN As far as the router is concerned All of these hosts are reachable Over that one wire or wireless link And even though there are Multiple hosts here, it's really a Single network, a single prefix That they're all representing Whether it's one host or meaning They're all on the same prefix Let's draw that as the topology This is the situation I have All of these other nodes before A and B and E Really are what we saw In the other diagrams, here's maybe a portion Of it, E and B go off to the rest Of the network, but what we do To add the hosts is we add Them by adding a link from a router Towards one prefix Which represents all of the different hosts And that way We've connected the host to our network Now what do we do? Well, now all we do is proceed With the routing algorithms exactly As I've described, and they all just Work. The routers What they're going to do, now that they're Connected to this prefix to represent The hosts, is they will advertise The IP prefixes for the hosts It will just go out instead Of a single node address, it's a prefix This fits, by the way With the way they advertise their own addresses A router address An individual address is really like a Slash 32 prefix, it's most Specific, it's a block of addresses With one address in it When they do this All of the routers will be able To find a path to all of the different prefixes That have been sent around And this will allow them to find a path To all of the different hosts, great The hosts are also able To fit into this equation because They have this simple routing rule That says essentially they don't Rout, if it's not for someone on the local Network where they can reach directly They simply send to the router And the router knows the route To all of the other hosts in the network And we're done, this is really Just a little bit of glue So that you can be clear on how we plug Our routing algorithms together with the Host forwarding behaviors we've seen In IP Good day viewers, in this short segment We'll talk about how hosts and routers Are combined in the internet for the Purpose of routing Now this topic is really just to Provide a little bit of a bridge Because we've talked about routing and nodes But we've also talked about forwarding And said that there is a distinction Between hosts and routers Routers, routers and hosts don't And we would like to glue them together Into a network Just to recap that slightly And remind you what's going on Here's what I've told you before In the internet, hosts Are addresses that come from the same prefix We do this in order to be able to Scale routing and assign addresses And the way hosts handle The issue of routing Is that they send any traffic That is not for a local host That has to go off the network They just send it to the nearest router They don't need to know what the router does with it Their rule is simply if you don't know If it's not on the local network Send it to the router Routers on the other hand Are the routes to use to get packets To every address in the internet And the way they do this And implement this Is that they use a longest prefix Longest prefix Matching algorithm On their forwarding table To decide what next hop To send a packet to based on their address Okay, so let's try And put these pieces together Here is how hosts and routers Would be combined in a network Now the networks I've drawn have Pictures here like a router Here's a router A And that router has links That connect it to the rest of the network That's fine, that's mostly what We've seen with our pictures of graphs The dots represent all of the different routers Which are doing the routing But we also have hosts in these networks So where do they fit Well, the hosts are attached to the routers Now often there is like A switch, a LAN switch here That can attach multiple different hosts To the same LAN As far as the router is concerned All of these hosts are reachable Over that one wire or wireless link And even though there are multiple hosts here It's really a single network A single prefix that they're all representing Whether it's one host or many They're all on the same prefix So if I just draw that as the topology This is the situation I have All of these other nodes before A and B and E Really are What we saw in the other diagrams Here's maybe a portion of it E and B go off to the rest of the network But what we do to add the hosts Is we add them by adding A link from a router Towards one prefix Which represents all of the different hosts And that way we've connected The host to our network Now what do we do Well now all we do is proceed With the routing algorithms exactly As I've described And they all just work The routers, what they're going to do Now that they're connected to this prefix To represent the hosts Is they will advertise the IPP Prefixes for the hosts It will just go out instead of A single node address, it's a prefix This fits by the way With the way they advertise their own addresses A router address An individual address is really like a Slash 32 prefix With one address in it When they do this All of the routers will be able to Find a path to all of the different Prefixes that have been sent around And this will allow them to find a path To all of the different hosts, great The hosts are also able To fit into this equation Because they have this simple routing rule That says essentially they don't route If it's not for someone On the local network where they can reach directly They simply send to the router And the router knows the route To all of the other hosts in the network And we're done This is really just a little bit of glue So that you can be clear on how we plug Our routing algorithms together with the Host forwarding behaviors we've seen In IP Good day viewers, in this segment We'll talk about hierarchical routing So our topic here Is really how to scale routing To very large networks And the technique we're going to use is hierarchy Where we route not to an individual node But to a large Region of the network So before we get into that I'd like to give you a little bit of motivation Here's a slide you've seen before About internet growth We're growing very rapidly There are now more than a billion internet hosts And growing And of course The previous slide was just the number Of internet hosts This slide shows the growth Routing tables Which are the tables which are maintained In routers to be able to forward packets To all directions This table is also growing very rapidly You can see pretty much exponential growth And just looking At the axis Right now As of about 2013 The number of IP prefixes In a router in the middle of the internet That's got to be able to reach everywhere Is around 450,000 That's a lot The impact of all of this routing growth Is bad In pretty much every dimension you look at You might look at the size of the forwarding tables That need to be kept in memory That's growing, that's the one that's reached 450,000 That means Both are larger tables So more memory in routers And it could potentially mean an increase In look up time depending how it's done As well as the size Of the forwarding table itself Another concern is the number of routing messages Which need to be sent around As there are more places and addresses to reach The number of routing messages continues to grow And it can actually grow very quickly Because not only are there more locations But we need to be able to inform Every node about What's going on in terms of paths To reach every other node So there's a lot Of growth there And finally The routing computation itself grows If every node gets to learn enough About a topology to be able to compute roots The computation Over this graph grows faster Than the size of the network It's super linear in terms of the amount of work That needs to be done So this is all bad, routing growth Is going to stress the network We would like to come up with techniques To scale routing So that it can more gracefully Handle a large network What are those techniques I'm glad you asked because I've written them down here In fact, we've seen some of them The first technique here Is the use of IP prefixes Where we don't have an entry In the table for every individual host Rather we have an entry for A block of hosts called an IP prefix We've seen how IP prefixes work In this segment We're going to talk about network hierarchy Which is the routing to the different Regions of the network And then in our future segment We'll talk about IP prefix aggregation Which essentially Are more games you can play To join or split prefixes That use hierarchy in different ways We'll see that later So let's look at hierarchical routing That's our focus here In a little more detail And find out what it actually is So the overall goal here Is to introduce some kind of Larger routing unit And be able to structure tables And packets towards that unit We've already seen That we now have IP prefixes Which are groups of hosts That's a larger routing unit from an individual host That's great, we want to build on that And we'll build on that By introducing the notion Of a region of the network This might be a complete ISP network For instance But I'll just call it a region for now And we would like to change our routing procedure So that we route To the region And then when we've arrived at the region We route to the particular node within the region This is really no different Than to pick a real world example Navigating by driving To the city you're trying to reach And only when you get to the city Trying to find a particular address And worrying about how to get around the city What we're doing here really The gain that we'll get for routing Is that we'll hide the details That are internal to the region Outside of that region Well, I'm sure you get the sort of Theory of how we could use hierarchy In regions, but let's go through An example to make some of this concrete And make sure we understand it So I have a network here on the left And you can see that there are Five different regions, and within each Region there are a few nodes connected Together, and the regions are connected Together too Now every node in this network Is going to have its own forwarding table So that it can send packets in different Directions The forwarding table here is shown For node 1a, that's this Big long table, and you can see it lists All of the other nodes, and Which output line, which next hop To get there, and how many hops Away, so this is shortest path Where the distance is simply The number of hops So this is the kind of table You would get this large table If you use the techniques we have so far On the right, I have the hierarchical Table for 1a Now you notice in this table It lists in detail It has the same entries for Entries within Region 1 Because it's 1a, that's 1a 1b and 1c, well 1a, not hard to get to Since you're already there However, the other entries have been Collapsed, if you look at the full table It had four entries For Region 2 That's collapsed into a single entry We don't care about differences here We just want to know which way to go To get to Region 2 Similarly Region 3 Has been collapsed into a single entry And Region 4 And Region 5 Once My arrow is a little off there But you get the idea Okay, so we now have a much smaller table We can also use it to Root Let's just see, here we have a packet That's trying to go from 1a to 5c And I've coloured in those nodes Just so you can see them on the graph At 1a, we can look up the decision For 5c Now since this is a hierarchical Table, there's no entry for 5c In particular, there's just a Blanket entry for 5 It's this last one It says to get to Region 5 Go via 1c So we'll go here We don't have the table for 1c Written down, but the reason we went here Of course is to go this way And you can imagine that the path we will take To get to 5c That's this path Let me just clean up this figure Okay, so you can see the path we took To get from 1a to 5c And we could perform the same exercise For different paths Through this network But I chose this path for a reason And that's to illustrate the penalty That we can pay Sometimes when we use hierarchical routing For most of the paths We're using hierarchical routing The distance that we take in hops When we follow them is the same Even if we didn't use hierarchical routing And we've just got a smaller table But for some paths We can actually end up taking slightly longer paths Than the shortest possible path That's the example here Now you can see in the full entry The full table From 1a if I want to go to 5c That's this entry here It says I can get there in 5 hops Going by a 1b And you can see I've put in blue on the diagram The path we would have taken To get there And you can count it and you can see that it's 5 hops However In the hierarchical routing version The best route To get to region 5 Is simply given here as 1c And that took us along the other path That's because we've forgotten about All of the detail inside region 5 And we simply wanted to get into region 5 As quickly as possible So that's the penalty we might pay sometimes And just to close on this I'll make a couple of observations About hierarchical routing Just to reinforce the concept So the main concept here is that Outside a region Every node has a route All hosts within that region We're hiding what's inside that region We don't worry about it when we're far away This is what gives us the savings in table size They can be substantial It's also a savings In terms of messages and computation We also get benefits there Even though we didn't look at them in detail One thing I want to point out though Because it's sometimes a source of confusion Is this doesn't mean That all nodes inside a region Need to take the same path To reach another region They typically don't Every node has a path to a region For all destinations in that region But every node could take a different path To reach the same region The reason for this Is that routing decisions Are still being made individually by nodes It's just we're looking At the routing decision To reach an entire region There's no notion of taking a single decision That everyone within a region Can get somewhere else Okay now you know about hierarchical routing Good day viewers In this segment we'll talk about things you can do With IP prefixes Aggregating, joining them together And subdividing them to split them up Our topic here really Is how to help scale the routing Of the internet As well as improve its management And we can do that by adjusting The size of IP prefixes And in particular we'll look at two ways Split up a large prefix Into smaller subnets Or we might join together Several prefixes into an aggregate Into a larger prefix So just a little bit of background So recall that IP addresses As we've gone through, they're allocated in blocks Called IP prefixes Such as this prefix 18, 31, 0, 0, 16 And a key observation is The hosts on one network share the same prefix Now just as a quick reminder And because they share the same prefix We can route towards the prefix That's where we're getting scalability in routing As we've gone over Just as a reminder, let's work through an example here A slash n prefix has the first n bits fixed And so it contains The other 32 minus n bits are free So it contains 2 to the 32 Minus n addresses So for instance A slash 24 will have 8 bits free so it will contain Actually 2 to the power of 8 addresses That's not very clear 2 to the 8 is 256 addresses And a slash 16 will have 2 to the 16 addresses In it and that is What's that? 64k addresses 64,000 different addresses 65,000 actually If you compute all of the numbers out Okay, now The key flexibility That we get from using prefixes Is that actually it's routers that keep track Of the length of different prefixes They use it for the longest prefix Longest prefix matching algorithm To decide which way to forward track Traffic Now because it's routers That keep track of the length of prefixes Not hosts The key flexibility we gain with prefixes Is that routers can change the length Of prefixes without affecting the hosts For the most part In particular, we can change an IP prefix To make it more specific By lengthening the prefix Turning it into a block which has Fewer addresses so dividing a big block Into blocks with fewer addresses Or we can change the prefix to make it less Specific and we can take several Blocks and then join them together into A bigger block which is the less specific Prefix Well let's just go over a little bit How that would work Here is just an example Of the sort of thing we're going to do In this figure down here we have 3 slash 18 prefixes IP 1, IP 2 and IP 3 And what we'll do when we use Aggregation is we would join those together For instance into 1 larger slash 16 If all of the addresses were of the right form Such that we could aggregate them That slash 16 would then represent the whole region Here and we'd be able To route towards that for instance In fact there are two different use cases Which are really just converses That allow us to adjust The size of IP prefixes Both of them are taking advantage of hierarchy In slightly different ways And they'll help us both manage the network And to reduce the size of the routing table Really after scalability By doing this So one of the two use cases One is that you can do What's called subnetting You can divide a large prefix Which has many addresses Into Multiple more specifics Which represents a smaller network These are a smaller portion of the network These more specifics Prefixes are then called the subnets And in this way You can acquire a big block Of addresses Or a block of addresses from your ISP And you can divide it up into different chunks To help you use it most effectively Within your organization The converse side of this is aggregation Externally we might have IP prefixes for several networks And we might be able to join them together Into a more specific Sorry, into one large prefix Which is a less specific prefix We take all of those more specifics And we join it into less specific prefixes Which will represent A larger number of addresses We can do this if all of the addresses Are about right if they're in the same portion Of the address space so that they can be aggregated Let's see an example of how this would work So here Externally maybe this is a company here You can see the line is dividing it The company is to this side And here's the rest of the internet So from the ISP The company has acquired This IP prefix here For all of its computers 12820800 slash 16 So it's a slash 16 So it has 64k different addresses Well internally It might want to divide that into different structure Because often there is structure Inside an organization Here it's a university and we have the ECS and art departments So what are they going to do Well internally they could divide a slash 16 Up into a slash 17 A slash 18 and a slash 19 There's actually a little bit left over Now I'll let you Go ahead and afterwards Work out all of the different addresses Here just to see That in fact this block of addresses If you draw the address space has been divided up Properly It looks like the slash 18 Here starts at the very bottom Of the address range The slash 17 It looks like it starts about halfway through the address range And then goes up And there's also a slash 19 Somewhere in there above the slash 18 And there's actually a little bit of space left over It can be a little confusing unless you look at the values Of the binary In binary and draw a bit of a map Of how the address space has been divided And here's an example Of the flip side I might have Three different universities here Cambridge, Oxford and Edinburgh Have a slash 21, a slash 20 and a slash 22 Now It just so happens That these prefixes Are also chosen from A address space Which is quite close, it's all related In fact it all forms a larger block I can aggregate those prefixes So into a single slash 19 Is large enough to contain All of the IP addresses in here And you can see here's the address Of the slash 19, the lowest address In the slash 19 And again to really understand How these prefixes have been joined You need to be able to write down the top and bottom Address for all of these things And see how they relate For the size of the prefixes And the size of the overall block But there's an example of subnets and aggregation Of using IP prefixes to suit our needs Good day viewers In this segment we'll talk about routing When there are multiple parties in the network So this formulation For routing is very much like the internet In which we work There are now, the network is comprised Of multiple parties altogether And in the internet here There are the ISPs You can see three ISPs here And the complication is that Each of these parties might have its own goals About what would be a good route Yet somehow they all need to work together To be able to get traffic From a source to a particular destination Across the network Ok so first of all Let's just drill down on the Overall formulation a little bit By looking at the structure of the internet To give us a better idea of what we're talking about So here's a picture of the internet architecture And you can see that There are a series of different networks Here that are shown There are three, four, five, six Different networks that are connected here The networks act as They source and sync traffic They have different prefixes here We talked about prefixes being blocks Of IP addresses They're everywhere here These are all the sources and destinations On the networks Now there are different kinds of networks ISP networks, host customers here CDN networks Provide content which is often delivered Enterprise networks and so forth All of these different networks Are richly interconnected With one another In all sorts of different ways They might be connected directly But it's a common strategy That many different networks Will actually connect together They will connect to what's called an IXP IXP stands for internet exchange point And IXP is really a meeting place Where many different networks Are connected to traffic Our routing problem is that Somehow, even though these are all different Networks run by different people They have different ideas of what routes They would like to choose We want to be able to find routes From Source, let's say the CDN here Is sending traffic somehow To reach a particular destination Such as a customer here Within the ISP We'll get to how exactly we do that But first of all are just the issues Which are introduced By this internet wide view of routing Across multiple parties Because really These multiple parties bring in Two different problems That go beyond what we've seen In routing in individual networks The first one is just of scale We now have a very large network Because we're gluing all of the different networks We can think of together to form the internet So we're going to need to use techniques That work We've already seen things like IP prefixes And how they provide hierarchy And we'll see other kinds Of The scaling techniques that will be used Such as prefix aggregation I guess we talked about that But we'll also see the use of How we can use these parties Also for a bit of scaling that's going to help The other thing that I want to talk about In more detail Because this is really what's unique In different decisions Each different party They might have their own idea About what constitutes a good route So they might want to choose routes Or at least portions of routes to suit their own needs The way they choose it is described According to a policy So I said Yikes here because What's going to happen to the overall route When different people are trying to choose Different portions of it Will it even work? That's exactly the issue In fact A route with different preferences Can lead to some strange effects So let's look at The kinds of things that can and do Happen in the internet today So here's a simple model network We have two ISPs, ISPA on the left And ISPB on the right Now the policy for each of these ISPs Is that they want to choose The shortest path within their own network Why? Well If they carry the traffic the shorter distance It'll probably be cheaper And cost effective to run the network Okay, that seems like a pretty reasonable policy And actually you might think That if everyone chooses short routes Everything would all be fine But let's see what we would get Short routes overall That's not quite what's going to happen Let's look at what happens Let's consider Amongst all of the different prefixes We have here just the path that gets chosen Between traffic going from A2 to B1 So here is A2 We start inside ISPA ISPA gets to control how traffic Goes through its network So from here we want to send it along the shortest path To reach B2 Well we could go by any Of these different points These links which connect to To ISPB To reach prefix B1 This is where we're trying to reach B2 So which of these am I going to choose Well I'm going to choose the one that's closest To wherever I am because that will be the shortest path In the network Now I've drawn this figure so I can tell you That this one is the shortest path So then we'll go over this segment here Out the network we'll land in ISPB Here and we'll take the most direct path To B1 here Okay It's a little bit of a roundabout path as you can see Well what about the path from B1 To A2 Okay Well I start in B1 I'm going to go back but I similarly want to go to ISPA To reach prefix A2 I could use any of these three exit points Which I'm drawing The closest one is this top one here So I will go there and then across the link Then within ISPA I'll go directly To prefix A2 So you can see here the result Of the best paths that would be found According to these two policies If we could somehow come up with a mechanism To find them And I've just cleaned up this diagram To draw them And I'd like to make a few points About these paths Because they're not quite what you might expect If we had done one overall routing formulation Called this one big happy network We would have found the shortest path Between these two points Actually both of the shortest paths Between both of the paths Which is selected according to these policies From A2 to B1 And back Neither of them are the shortest path The shortest path here Is the one that's shown In the pink I'm tracing over it And we took a different path In one direction that was longer And a different path in the other direction Which was also longer than the shortest path Not only that But the two paths are different In different directions So they're asymmetric So you can see that policy routing In fact these effects are common in the internet Policy routing often leads to asymmetric paths Where it's different Going from A to B to B to A And often paths Which are not quite shortest And these effects are really consequences Of the independent goals And decisions Which have been made by the parties Rather than simply the effect Of hierarchy hiding a bit of information Causing us to take longer paths Well So this is what we're up against What I'm going to do now Is talk just a little bit about policies And then we'll have Fulfilled our goal of just understanding The formulation for routing With multiple parties And what policies are And later in the next segment We'll move on to BGP The protocol which finds Policy routes in the internet today So policies The idea with policies Is that they'll capture the goals Of the different parties Now Policy is this general word And that's because It's abstract Because policies could actually be anything Here's an example of a real policy The internet too Is a research and education network In the United States That's used to connect universities One of its policies Is that it will only carry Non-commercial traffic So it will carry traffic Between educational institutions So U-dub to MIT and back But it won't carry traffic From those educational institutions To commercial networks So that we could all serve Google For instance Why? Well that's just It's acceptable use policy Because that's what the network is for And that's a condition Of funding the network So the routes will be Computed to comply with this That's one policy In fact we don't know For all the commercial networks Exactly what their policies are Because these are proprietary They can depend on The two different parties That are connecting Can have all sorts Of different policy What we're going to do instead Is talk about two common policies We're going to talk about The policy of transit ISPs give transit service To their customers That's one kind of common example Of a policy that's often held up And we'll talk about A different kind of policy Called a peering service Where an ISP provides A peering kind of service To ISPs often provide A peering service To one another under some situation So let's look at those two policies Well here's this transit service So the idea of transit service Is one party in this deal That's the customer Who's going to pay for this Is going to get What's called transit service From another party The ISP So transit service is what you get When you connect to your ISP You're paying it for transit service And the idea of transit service The policy is that the ISP Party I'm going to refer to them As just the ISP and the customer Will accept traffic from the customer And make sure that traffic Can be delivered to Anywhere else in the network So you're a customer here You can hand packets to your ISP And destined for wherever And your ISP will somehow send them To the rest of the internet And where they will reach customers Who are outside that ISP Similarly your ISP will accept traffic From the rest of the internet And deliver it to you So some traffic could come from here And the ISP will accept this traffic Because it's for you And make sure that it gets to you And you the customer Generally pay for this privilege When we connect to the internet Pricing is often depends on The amount of bandwidth we have The size of our DSL link How rapidly it can send information But often what we're really paying for As well as the size Is connectivity to the rest of the internet The ability to send traffic And receive traffic from all of the other Destinations that are out there And the transit policies providing us that But there are other kinds of policies too And here's our peering policy In this policy We have two parties I have ISP A on the left And ISP B on the right These parties are both going to give one another They're going to use a policy Which gives peer service to each other Now in peer service Each ISP accepts traffic From the other ISP Only when it's for the customers To and from their customers So I have the two customers down here And you can see we can send from one customer To the other across this link and back And similarly for the customers up here We can do the same Okay that's great You might wonder what I've precluded by that Well actually why is this not transit service Well here's what ISPs don't do ISPs do not carry traffic To the rest of the internet for each other So in fact customer A1 Can't send via this link To reach some other place on the internet Not allowed I'm going to cross that off Not allowed we don't do that Why? Because that's not part of the peer policy So the ISPs will allow these routes Just between their customers but not further out And as a consequence of this Both ISPs are sort of doing one another a favor Because by doing this they then Don't have to send traffic via a transit provider And pay for it And usually as part of peer service We said that the ISPs don't pay one another Because they're both providing value For each other So these are the two policies that we've seen And in the next segment We'll look at a mechanism called BGP A protocol Which finds these kinds of routes In the internet today G'day viewers In this segment we'll talk about The border gateway protocol Which is used to find routes across the internet So we talked before about the fact That the internet is comprised of Multiple independently run parties Such as ISPs And we need to find routes across those parties That respect the policy constraints Of the different parties What we haven't told you so far Is how those routes are actually found Well in the internet It's with a protocol called BGP But in this segment I'm going to give you a brief introduction To some of the issues that we find in BGP Rather than extensive coverage Because BGP is kind of complicated And you might go over more details In an advanced networking course Okay so just as context Recall that we're viewing the internet As made up of all of these different Independent independently run networks We have here content distribution networks ISPs and just generic networks here You might be trying to find paths Through this network from a source here Say prefix C1 Acting as a source address That's going to send along some path Through the internet To get to a destination here Such as A1 Now which path will be chosen Through this graph Well I've just picked an arbitrary path there But the routing protocol needs to decide Which one will actually be used And that's exactly what BGP does So here's just an overview Of some of the aspects of BGP We'll move into some examples So BGP computes inter-domain routes As they're called These are routes across different entities Such as across ISPs and the internet As distinct from intra-domain routes Intra-domain routes are routes within One single network such as within an ISP Now we've already talked about Distance vector and link state protocol Methods for computing routes BGP it turns out is what's called A path vector protocol Not related to a distance vector protocol But a little more general In a path vector protocol What happens is that route announcements Which carry the path From the point in the network Back towards the destination Propagated throughout the internet So you can see here The blue line is meant to represent A route announcement Which is propagating out in the network It's propagating out from prefix F1 So it's going to tell people How to get to F1 And if we look at it inside ISPA We might receive a route announcement That says something like Well, to get to prefix F1 That's the destination here Here is a path you can use It goes ISPB net F Well, they are the networks Through which you go along this path Once you leave your ISPA To get to the destination And the way you access this path The next top is to go Via the IXP That's here So you just send across the link To the IXP And you'll be on your way Along this path That's an example Of a path vector announcement Okay, a little more terminology About BGP before we see examples First of all, we're used to talking About ISPs Here are the different parties In the internet But in BGP terminology These are ASs That stands for autonomous system All sorts of networks Might be autonomous systems You don't have to be an ISP It could be a content distribution Network A campus network And so forth So ISP and AS are not one to one We're also interested here In what are called the border routers These are not surprisingly The borders Sorry, the routers Which are on the border Of the ISP And they send routing announcements To border routers That are on the edge of another ISP Or another AS To which this AS is connected So we're really interested In the announcements that flow Between the ISPs here There are also announcements That can flow within a network Such as an ISP But I'm not looking at them here We're really going to focus On these route announcements As they move around And I'll tell you that A route announcement Just like we saw in that picture before Contains several things It contains an IP prefix That's the destination That you're trying to reach So that was F1 in our example On the previous slide A path vector That you go through to reach This destination I forget what that was That was maybe ISPB And netF on the other slide And a next hop That you use To get onto this path And that was via the ISP Or internet exchange point In our example Now the reason that you actually Carry the list of ASs The whole path Rather than the distance Actually if you think And just compare it To a distance vector protocol In a distance vector protocol You'd be sending a prefix Or a destination A next hop Which way to go maybe And a distance metric To decide which way is best In BGP We don't send this distance metric We just send the whole path As a list of ASs One reason this is done Is that the designers Were very worried about loops Between multiple ISPs Just imagine that packet Zapping around across multiple ISPs That would be pretty nasty And so the idea is That if you list the whole path You'll be able to recognize Directly if there's a loop If you've already gone through A particular ISP And you'll be able to Not use that route And you're going to see Two kinds of flows In network diagrams I'm primarily going to be talking About the route announcements How they go out from a destination To other places in the network To tell you how to reach That destination But if you think about Actual traffic that is forward Along the internet Realize that this traffic Will go in the opposite direction To the route announcements So it will go from wherever You are in the internet Towards that destination Well, here's a little example Just to look at To see how some simple Announcements would propagate In this diagram here We have three ASs You could think of them As ISPs if you like Here's one Here's two And there's three I'm just going to look At the announcements That propagate out From prefix C So that's the destination Well, along these dotted paths You can see that Announcements VGP announcements Carrying path vectors Propagate out in the network And I've shown them Here above Now This announcement here To reach prefix C You go via AS3 And the next hop is here R3A Is the announcement You would see If you would look over this wire Connecting this border router In AS3 R3A To a corresponding border router In AS2 R2C As that announcement Propagates further along If we look at it Over this link here Between AS1 and AS2 You can see that now The path has changed So the path you go through Now is AS2 And AS3 To get to C And also the next hop has changed Now to access it You go via here And this last announcement Just looks at what you would see Actually in the middle here Of AS1 Since it can't really Propagate any further out to A Similarly You'll note that Routes towards Prefix C Are also propagated Along this other path Along the bottom of the diagram So it's not the case that Each AS Is making a single Decision for routes Towards each prefix In different places In the AS Different routes Are propagating Using different next hops And so forth So we can see As we go down here I'll just circle The corresponding places Where these announcements are That here we go out The paths actually look the same In terms of the path vectors The ASs that you go through But the next hops Are all different Here Actually let's do this one here You can see that AS1 Which here is this announcement Goes via R2B Not R2A To get to C So anyone down In the lower portion here Of AS1 Is probably going to go Via a path here to reach C Whereas anyone up here Is probably going to end up Going via a different path To reach C Even though they go through The same sequence of ASs I've also drawn Darker arrows on this diagram And those dark lines Represent the flow of traffic Which is the opposite Of the flow of the routing announcements So for instance Over the top of the diagram A dark line goes from C All the way through The top of the diagram To A Going in the reverse direction That the round announcements propagate Right, well So you've now seen A lot of the mechanics Of BGP I haven't explicitly Talked about policy though And that's really What we wanted to get out of this So far I've just shown Your path vector How do we get this policy Of our ISPs Being able to make decisions Which suit their need Choose routes Which suit their need Well in two ways When a border router The first way is That when a border router Announces paths To the border routers Of other ASs It only announces paths That it's willing To have those ASs used Doesn't need to Announce other paths That might exist But it doesn't want Someone else to use It can just Withhold them And filter them out That is applying policy A second way Is that when A border router In an AS Here's multiple routes Towards a particular Destination prefix It can choose Whichever one Of those routes It would like to use If this was A distance vector protocol We'd choose the one Which has the shortest distance In BGP We don't have to Choose the one That has the shortest path We can choose Whichever one we want For our own reasons Which may have to do With strange Contractual Requirements Between the companies For instance Which you wouldn't Normally think Would be part Of a protocol But BGP Can accommodate Them by letting You choose The particular route You want Regardless of The length Let's see an example And then we'll call it quits And you'll have a rough idea Of how BGP works Here's another diagram In this diagram I have four ASs And I'm going to focus On this one here This is AS2 We'll look at The route announcements It makes And receives And how it chooses Its own paths To get elsewhere In the network I will also tell you That in terms Of commercial relationships Between these ISPs Two things are going on AS1 Is buying transits Sorry, AS2 The one we're looking at Is buying transit service From AS1 AS1 up the top here Is this big ISP That's kind of Providing transit service To everyone It will connect everyone To one another If you pay it money AS2 is also Getting a peering service A peer service With AS3 And it looks like They're doing that To exchange traffic Between A and B Just for their traffic Between A and B That's what you would do With a peer service To see how This is paths Found Which are consistent With these policies What happens Well, several kinds Of route announcements Flow around First of all We're going to look at What are called Customer route announcements The customer side Is really the flip side Of transit For an AS Like AS1 To provide transit Service To let everyone Reach a certain Prefix And to allow Traffic from That prefix To go everywhere else The prefix Needs to get To the transit provider That destination Needs to tell The transit provider Who they are That they want service This is a customer Announcement It's going up here It's labeled Cu In this diagram So AS2 Is going to tell AS1 Okay I am Here's an Announcement To prefix A That's the destination The path Is going to be AS2 Just by me And it's going To AS1 That's pretty straightforward Really This is really just saying To AS1 Hey Prefix A Exists down In me AS2 Well let's look at The flip side AS1 To The one we're looking at That's this one here Is also going to Receive Transit Routing announcements From AS1 Which will tell it How to Reach other Prefixes in the internet What transit Announcements Will it receive Well AS3 Has B As a prefix destination And AS4 Has C As a prefix destination Both of those Are going to advertise B And C To AS1 And since AS1 Is providing transit It will tell AS2 About the possibility Of reaching these destinations So AS1 Will tell AS2 A couple of routes For B As a destination AS1 Will say Hey, this is prefix B You can reach it Via the route AS1 Here you can see Our path has now gotten longer So we're now going through Two ASs To reach that destination And I'm ignoring the next Top here And similarly We will hear AS2 Will hear from AS1 That it can Reach prefix C Via the path AS1 AS4 Okay, that's a Transit Announcement But wait There's more AS2 Here is also Going to receive A peer routing Announcement Across here And it's also going to Send a peer routing Announcement So what are they for? Well this is really AS2 Wants to tell AS3 That it is allowed To send to A Over this link And AS3 Is also going to tell AS2 That it can send to B Over the same link So AS2 Is going to say Well AS3 You can send to A Via the path AS2 Over this link And AS3 Will say AS2 You can send to B You know AS3 Over this link So now we have All of these different Announcements That have been received By AS2 So what route Will AS2 Actually choose To use in the internet? Well let's do An easy one first AS2 Will actually Only hear One route to C So the way From AS2 That you're going To reach C Is actually This is the way The traffic will flow It's the dark line And the routing Announcement That we're selecting To follow The direction That's the only one We heard So that's the watch You're going to use To reach C What about to reach B Well we actually Heard two announcements We heard One which came Up here That the transit One And we heard One which came Here from AS3 Directly to AS2 Since AS2 Is now Heard two announcements It can use Its policy To decide Which of them Is better And the answer Is paying For transit service By the volume So AS2 Is going to send Over this Link to reach B And similar You can work through On your own What's going to happen For the route That AS3 And AS4 Will choose To be able to Send from B To other destinations On the internet Well that's Our simple example Of BGP So you're now Seeing a little bit About how it works And hopefully That gives you a feel For it For those of Strange effects We're going to leave That though For a more advanced Networking course I hope that One thing I would like you to take Away from this Is an appreciation That policy The policies Which ISPs use Is a substantial Fact in the routes Which are used In practice AS2 Could have chosen Any of two paths And they're really Quite different Different things Would have happened And it totally Depended on what AS2 wanted In fact The overall routes Will actually work This is an interesting Problem Something that Researchers look at How we guarantee That will be the case And there are Key factors That you might care about For BGP We're not going to look At them now But I'll just mention Some of them So you know What an interesting area Is to find out More about If you would like to One is convergence Just how fast These protocols Converge When new changes To find a new route Another is scalability BGP needs Routing messages Are going around At how much work Routers have to do And also You'll note That I skipped the integration Between the BGP We looked at Where messages Are sent across ISPs With the routing That goes on inside ISPs Really those two Parts of routing Need to be integrated Together well For overall Internet routes To work well So that's it For BGP I hope you've Learned a little bit And we're done G'day viewers For the transport layer But first Congratulations are in order This diagram shows Where we are in the course And you can see That we've gone through The physical, link And network layers And now we're starting On the transport layer The transport layer Builds on the services Of the network And it delivers data Across the network To applications With different kinds Of reliability Or quality Depending on The transport service model So here are A couple of slides Just to recall Where we are In the course Of the protocol In general This diagram Shows two hosts Communicating Across the network With a single router And you can Ignore all the details Of the protocol They happen to be TCP, IP And so forth The point I want to Make is That TCP The transport layer Is communicating Information From host To host Across the network This is the first Time we've Reached a layer Where all of The information That's sent by The network Or at least it shouldn't be That wasn't the case With the Network Lincoln Physical layer Where intermediate Systems Switches and routers Handled all of The information there The transport layer Is really using The network Simply to get Information Between hosts And we can Also provide Just a brief Review In terms of Data units The name For a message At the transport Level Is a segment And you can Transport control Information like a TCP header As well as A payload The payload is Application data That's carried Across the network The segment itself Is carried within A packet At the network Layer And within a Frame At the link layer Okay so I'm going to spend Most of this Segment Talking about The different Clients of transport Services That a transport Layer Might offer to Its user Information The axes I'm going to use To classify them Here are the Ones that we use In the internet A transport Service could Provide Either reliable Or unreliable Transport By reliable We mean If you send it It will be Delivered to the other Side Unreliable Packets can be Lost in the Network And this will Be exposed to The transport user Packets can Still be lost In the network That was this Top Axis And you can also see A distinction in The unit of Data that's Transferred We might transfer Individual messages Sort of like a Post Office model Or an Infinite stream of Bytes That's the Bytes stream model Now in the internet We really provide Two kinds of Service For applications To use Two transport services The common one You probably Heard of Is TCP TCP is actually The protocol The service itself Is a stream Service It's a A reliable Bytes stream A bidirectional Reliable Bytes stream Between applications The other Service that the Internet provides Is a Datagram model Where you send messages That service is Implemented by UDP Okay, let's Just compare Some of the features Of these Two different Transport services To get a little Bit of a feeling For how They differ About what A layer does for you So on the left here We have TCP In this table And you can see That TCP Well, it Sends information Reliably And so there are Many features That are related To reliability Connections have To be set up The Bytes Then are delivered Reliably Meaning Essentially that They delivered once And in the same order That they were sent Actually ordering And reliability Is somewhat separate But we get both Of them here This also Since it's a ByteStream It's an Arbitrary content length Model You can send as many Bytes as you like They will have to be Divided into Packets or segments Inside the network But that's The Transport Layer's business At the other side You'll receive messages As if they came in On an Infinite ByteStream The Transport Layer with TCP also provides Flow control To match Sender to the Receiver Capabilities We haven't seen Expect you to know What flow control Is yet Nor congestion control That's going to be A mechanism That matches the Sender to the Network's capabilities In terms of its bandwidth So you can see here TCP is really Quite a full Featured protocol It does a lot On top of the Network layer To provide a service For applications On the other hand UDP on the left side Sorry On the right side Of this table Is really just A glorified Packet Transport Very little Over IP You send Datagrams Well, they really like Packets The messages Just like the Post Office They can be lost And reordered Somewhat like The Postal Service They can be Duplicated on Networks You could send One copy And two could Come out That's a little Lot But that could happen There's a limited Message size Because these are Like packets These datagrams But essentially Here I'm saying That the transport service Provides you No guidance On when it's A good time to send In terms of The receiver Being able to handle Those messages Or the network Being able to deliver Them TCP Helps us With those tasks So this Right hand column You can also See that If I wrote down The capabilities For packets That would be Very much like this So here We see a bit Of a dichotomy For the whole Kitchen sink In terms of features Okay Let me go on And talk more About the Interface Between the transport Layer And the application Layer Which is using It as a service We've actually Seen this interface Before It's our good old Sockets API Now A socket's provided The simple abstraction Called a socket To use The network Before We talked About the Network That we zoomed in You can see They're really providing An interface To a transport Layer service Sockets are used To write All of the different Internet applications You see out there The socket API Supports both Of these Kinds of internet Transport services Both the streams And the datagrams That we just saw When we looked At sockets Before We only looked At the stream Model And you might Have also seen This Or a connection-oriented Transport And datagrams Are connection-less Just different names For some of those Kinds of services A little bit more About the Sockets If you recall One of the key Addressing attributes In the socket model Is ports Ports are Where applications Attach To the Transport Layer And Sockets Sorry These different Ports Is what lets Multiple different Applications Use the same Transport Layer Instance So we can Multiplex The network between Different applications You can see here Two applications One and two Using different Sockets And ports To attach To the Transport Layer Here was The API Again For Sockets Again We went through this A long time ago When we did An introduction To the course I'm not going to Provide you Going out here Is the table Now you know That it's the same Kind of API That's used for both Sockets and Datagrams It turns out however That these three calls Here listen Accept and connect You only need them For streams Because this is all About setting up the Connection Datagrams are connectionless So you don't need To establish any Connection Before you use them Similarly For send And receive With the streams We simply use Send and receive To send the information And receive it At the other side With our Datagrams Slightly different forms Are used Send to And receive from This is because If you have no connection And you want to send Information Missing parameter You need to specify Who to send it to And with A datagram model You can actually Send datagrams To many different Receivers Without having to Set up any Different connection Between them Over the same socket Similarly Receive Users a form Could receive from That provides information About who sent the Datagram to you Since many Different senders Could have sent their Datagram that could be Received on your Port in a Datagram model Let's talk A little bit more About ports And that will round out The service API That the transport Layer provides In the internet To applications So we say That there are Ports These are Identifiers Which provide Addressing For applications To use Actually it turns out That in an Application process Which is running on Machine Is identified by The tuple Of the IP address So that sort of Told you the machine The protocol Since this could be TCP and UDP And they share The same port space And the port Number itself Now you could Simply think Of a port Even though it's A 16 bit number As representing A numbered mailbox Can lease Those mailboxes To use the services Of the Transport layer Just like you Might get a A mailbox Or a post office To use the postal system In this case Not only Would you get Things delivered to it But that's where You put things in When you want them sent Across the network Clients and Servers use Ports slightly differently Servers Often bind To what are Called Well-known ports These are Ports below 1024 These ports Are ports Which require Administrative privileges To use The idea here Is that Since you need to Know the port To contact someone Servers are going To sit On well-known ports They'll bind To well-known ports So you'll know How to find a server On the other hand Clients Can use Any old port As long as They tell The server Who they contact What port They're sitting On the other machine The server Called ephemeral ports And you can Ask the OS Just for a new port And it will pick one For you That's convenient For you to use Temporarily This table Shows some of the Well-known ports You're probably Familiar with Some of them So these are Ports that Servers would use So that A transport Peer across The network Would be able To open a connection To the server The most Common one here That you'll be Familiar with The HTTP protocol For web traffic Some of you Might also have Heard a port 443 That's used When we use HTTPS A secure version Of HTTP There are many other Ports in the table I won't go through them But there They provide Different kinds Of ways To access Your mail Printers Remote systems Move files around And so forth All of the Different ways We use the internet Well that's All I want to say It's a transport service That's provided To higher layer applications In the coming Segments We'll talk more About the implementation Of that service Inside the Transport layer So we've covered These service models here That's all done And when we Look inside the Transport layer We'll now see All sorts of machinery Most of it's Going to be Related to how TCP works It's sliding window And how Timeouts are used To provide reliability How connections Are set up This mechanism Is controlled And so forth There is One big part Of TCP However As a transport layer Service That I'm going to Defer until later And that is Congestion control Shown here in grey Congestion control Is about matching The transport Right at the edges Of the network To the capabilities Within the network Depending on the traffic That's a major Subject in itself And we'll get To that later First we'll Go through All of this And go for it