 So the basics of mobile IP is that when we move we get a care of address by discovering a foreign agent and then registering with our home agent to tell our home agent that we're now visiting some foreign network. Last week when we used this example you have in the handout we went through and saw the process or an example process for how to discover the foreign agent because I enter a new network. I don't know the IP address of the foreign agent so there's some discovery procedure. Router advertisements broadcast by the foreign agent and or a solicitation is sent by the mobile node and then I register by in fact sending, I send a mobile node sends a registration request to the foreign agent, it processes and then the foreign agent sends a new message also a registration request to the home agent. They are different IP datagrams and you'll see that the source and destination is different but they're both called registration requests. Send one to here, foreign agent sends a registration request to the home agent, if everything's okay, home agent replies and once we receive that reply the mobile node can now start using the connectivity within the foreign network. And the last thing that we need to go through in this example is okay now that we're delivering data to and from the mobile node and the correspondent node, how do we get that data especially via the home agent because we know that when the correspondent node sends data it doesn't know that the mobile node is mobile so the data using normal internet routing is sent to the home network and then it's the role of the home agent to forward that to the foreign network. And the reason that the home agent knows to forward it to the home to the foreign network is because of the registration and in particular the home agent keeps some data structure called a mobility binding table that lists the mobile nodes and where they are. So let's go through that, the data delivery process, we've got one on here. Let's first consider the simple case. My mobile node has now registered with the home agent, we've gone through that and now it wants to send data to the correspondent node. We'll use the example in the handout to demonstrate what happens. Just going back to our example network, we had this example network where our mobile node has moved into network 77770 communicating with 888200 the correspondent node. It has its home address 111100, it has a care of address because we've already moved in here, we've discovered the foreign agent, in this case F, we've registered the home agent, router A, that's what we did last week and the care of address given to the mobile node is what in this case? Anyone remember what care of address our mobile node has? Again, the care of address for the mobile node, try and remember back to last year we gave it the foreign agents IP address. So one way when we visit a foreign network, our mobile node needs a care of address as well as its home address. One approach is to use the foreign agents IP address as the care of address. So let's just record that. For our mobile node, its home IP is always the same, in this case it's 111100 and it's care of address when it's visiting the network run by router F7770 network, we set to 7771 and our foreign agent which is router F in the diagram has IP address also 7771 which is a bit of a strange situation. Two devices, two different devices have the same IP address but this is a special case, this care of address is a special case. For simplicity, when a node visits the network, instead of giving it a new IP address, the foreign agent can give it just its own IP address. The foreign agent F is 7771 and it allocates that as the care of address for the mobile node. If another mobile node visits the same network, so maybe from some other network, network 3 it comes into this network 7, then it would get the same care of address, 7771. We need to deal with that somehow. There's an alternative which isn't covered in this example but an alternative is that the foreign agent allocates a unique IP address for the care of address. For example 777100 or whatever value is free, it just requires some extra exchange to make sure it gets a unique address. Now we want to see how we deliver data while we're visiting a foreign network to the correspondent node. Let's look in the direction from MN is sending to CN. Of course they're exchanging data in both directions but let's look at the packets separately in each direction. Let's say MN has a datagram to send to CN. It creates an IP datagram. What's the destination address? So MN has some data to send, has an IP header, whatever the data is, web request, voice packet, doesn't matter. What's the source and destination address? What's the source address? MN wants to send to CN. Start with a simple one. What's the destination address? We want to send to CN. In fact we can send it to the IP address of CN in this case. We can send direct. So we set the destination to 8800 and the source, we use the home IP address as the source. Remember our mobile node has two addresses, home and care of address. In the source field of our IP datagram, we set it the home address. In fact no matter where the mobile node is, whether it's in its home network, in this foreign network or some other foreign network, we'll note that the source and destination addresses of the IP datagram it creates will always be its home address and the final destination. It doesn't matter if it's moving, source will always be 111100 and the destination will always be the correspondent node's address. It creates this IP datagram. Where does it send it? What does it do with this datagram? It needs to send it to someone. Who does it send it to in this network? We're here. I've got a datagram. We send it to our local router in this case. How do we know that F is a local router? We've done this agent discovery in the previous phase where we received a router advertisement. We learned that the default router for the mobile node is F, in particular 7771, the foreign agent. We send this datagram to F and then F performs just as a normal router does and it looks at the destination address 888200, looks in its routing table and you can see in the handout that you have the routing tables, you look up the routing table and if the destination is network 8, according to F's routing table it will send to C, we've got that somewhere. Router F received a datagram, destination is on network 8, look in the routing table for F, 6, no, 7, no, anyone else send to 6665 which is router C in our case. Router C receives this datagram and as per the normal rules in the internet it looks at the destination address, destined to network 8, check the routing table for router C, destination 3, no, for destination network 8880, router C will send to the next router 4442 which if you go back to the other, the network diagram is router D in the path and D will check its routing table to reach 8, send to 5552 which is router E, E receives this, checks the destination, sends direct in that router E is attached to this network, it doesn't have to send to another router, it uses the data link layer, the layer 2 technology to send direct to the correspondent node, say using the ethernet or the wireless LAN link and sends to the correspondent node and then it's received by the correspondent node. So the correspondent node receives this datagram and importantly from the correspondent nodes perspective the source is the same as it always will be no matter where the mobile node is. When the mobile node was home the source was 111100 and when they're visiting foreign networks the source will always be 111100. From the correspondent nodes perspective nothing has changed, they're still communicating with the same IP address and that's what the objective of mobile IP is that we do not change from the application's perspective the IP addresses that are seen. If we do change them that usually means you need to for the application stop the data transfer and restart especially with TCP connections. So the goal is such that the end applications on the mobile node and the correspondent node always use the same IP addresses no matter where they are. Did we go via the home agent? Did we send via the home agent? What do you think? In this case when we sent from mobile node to correspondent node was the home agent which is router A in this case involved? No, it wasn't in the path. If you look at the path we do not have to go via the home agent. We went mobile node FCDECN. The normal path we'd expect to send in the internet. When we're sending data from mobile node up to the correspondent node we just use normal internet routing. There's one special case in that the mobile node sends to the foreign agent. And then it's the normal routing the correspondent node. Now the opposite direction. Let's consider of course correspondent node receives some data. Often I have to send back some response. Correspondent node creates a datagram. So this was at the mobile node. At correspondent node we create a datagram source. Of course will be the correspondent nodes address 8800 destination. CN wants to send data back to the mobile node. What does it set in the destination of the IP header? Okay, easy. The mobile nodes address. It's home address 111100. Of course it comes directly from the source of the packet it received. And no matter where the mobile node is, it's the same destination. If the home visiting network seven, network three or another network, the destination is always the home address. These packets are drawn in the handout, one of these pictures. This was the first one from the datagram from mobile node to correspondent node. It's the same as I drew on the board. I drew here on the board said just data here in this example. I said it's TCP data. That is TCP is the transport protocol and there's some application data, whatever the application is. But from the IP datagrams perspective, it's just some data contents. And then this is from the correspondent node to the mobile node. Source is correspondent node destination is home IP address. That's easy. Now you follow your routing tables and see where the correspondent node sends it. Going back to our network, where does CN send this datagram to? And the hint is that the routing tables will take us the shortest path. CN, if you look up the routing tables, you'll see it sends to its default router E. There's not only one choice, so that's simple. E will send to D, D will send to C, C will send where? C will send to B and of course B to A because the destination is network one. Okay, the destination is network one. And therefore these routers, D, C and B are going to forward it towards network one. That's how their routing tables are configured. Eventually A receives it, what does A do? A has just received this datagram. What does A do? Round it A, more precisely. Does it, what does it, information does it use? Yeah, something binding table. A is a home agent. Normally, when we receive a datagram as a router, we look up the routing table to determine where to send it. Here we have a special case. We've received a datagram and because it's a home agent, it checks its mobility binding table, which is one of these diagrams. This is the mobility binding table at the home agent, which is router A in this case. What it says is with this home IP address, this mobile node, which is normally in my home network, is in fact visiting a foreign network and it has care of address 7771. Now what happens is that router A receives this datagram, notes that the destination is 111100. Normally, that's a local destination from router A's perspective. But the mobility binding table tells the router, this node is not local, it's visiting a foreign network and now we need to do something special to send it to that foreign network. In particular, we need to send this datagram to 7771. And the way that we send this datagram, this original datagram, is using tunneling. So you may have heard of tunneling or you may have heard of its use or maybe seen it in use. Let's try and explain how tunneling works. So we do not change the source and destination address here. In fact, we put this datagram inside another IP datagram and that's the process of tunneling. Tunneling is a generic concept in networking. It's not specific to mobile IP. It's the concept of if we think of a layered stack, normally if we think of a layered stack, normally we think of the data that we send we take from the top layer and put it inside a protocol from the next layer and then use the layers one by one. Let's draw that. Our five layer stack, application, transport, network, data link, physical layer. When my computer sends data, the application layer protocol uses the transport layer protocol. The transport layer protocol uses the network layer protocol and network uses data link and data link uses physical layer. That's the way that we structure our protocols in a layered manner. You think generally tunneling is the process of one layer protocol using another protocol from the same layer. Normally it's application, transport, network and so on. Tunneling is a process, for example, we take data from the network layer protocol and use either the same or another network layer protocol to send that data. We put, for example, an IP datagram inside another IP datagram. Let's see how it works for mobile IP. What do we keep here? The goal is to send the current datagram we have at Router A at our home agent to the mobile node. We create a tunnel from the home agent to the foreign agent, specifically the care of address. Let's go straight to the picture and we end up with a packet shown on the screen. This is the IP datagram that is sent by the home agent and it's trying to deliver this datagram to the mobile node. Let's go through in detail and see what it shows us. Note that we have two IP headers. It's one IP datagram inside another IP datagram. That's the process of tunneling. So the inner IP datagram is what we drew on the board, our original one, where the source is our correspondent node and the destination is the mobile node home address. That's this one on the board. But what we do is we put that inside another IP datagram. So we attach an IP header and we set the source to be the address of the home agent in this case. It's coming from the home agent and we set the destination to the care of address, which is in fact the foreign agent address in our case. And we send, so the home agent sends this IP datagram and the routers in the internet forward it by looking at the destination address of the outer IP header, 7771, using their routing tables and sending to that destination. So noting the destination is 7771, it's sent by the home agent. We'll see where it's delivered to, to skip back. So we're being, the datagram is sent from router A, the home agent, destination is 7771. If you look up the routing tables, you'll see it is sent to router B. B will send to router C. Destination is on network seven. So C from the routing table will send to F because here's network seven. And now it is reached router F and the destination address 7771 matches that of router F. Router F is 7771. So it's reached the destination. In fact, it's reached the foreign agent. So what the foreign agent now does is just received, the foreign agent, when it receives this datagram, it's reached the destination address. Therefore, the foreign agent removes the header and looks at what's inside. And in this case, what's inside is another IP datagram. And it notes in the inner IP datagram, the destination is 111100. And the foreign agent realizes, ah, mobile node 111100 is currently visiting my network and they realize that from the visitors list. Because in the visitors list, we have the list of nodes visiting the network. So the foreign agent takes this inner IP datagram and sends it direct to the mobile node, which is this datagram. So if you just remove the outer header here, the first header, what you're left with is this. And this is the datagram sent by the foreign agent direct to the mobile node. The mobile node receives this datagram and look at the source and destination addresses. The source and destination are the original correspondent node home address, correspondent node address and the mobile node home IP address. And as we have in all of our communications, always between the mobile node and the correspondent node, we use our original addresses. We don't want them to change. So tunneling is an important part in mobile IP to get the data from the foreign agent, sorry, from the home agent to the foreign agent. It's needed so that we can use the normal internet routing to deliver it across the internet and eventually get it to the original destination home IP address. One way we illustrate that sometimes is concept of a tunnel as it's like this. This is looking at the data. First, we looked at the case when the mobile node sends to the correspondent node. There's nothing special in that case. It sends using a normal internet routing and doesn't have to go by the home agent. But in the opposite direction, when the correspondent node sends to 111100, normal internet routing will deliver it to the home agent. The home agent recognises from its mobility binding table that that mobile node is no longer home. It's visiting a foreign network, creates a tunnel which is really putting the received datagram inside another datagram. Send that datagram to the foreign agent. Foreign agent now realises that the destination is a visiting node from the visitor's list. So removes the outer header and ends up the original IP datagram and then sends that to the mobile node. And if you look again both at the mobile node at what it sends and receives and the correspondent node of what it receives and sends, in particular the addresses are always the same. The correspondent node address and the home IP address. That's the main concepts for how tunneling is used in mobile IP data delivery. Any questions on how that works? Let's check what we've missed. So the datagram sent by the home agent, you've got it on the screen or on one of the previous pictures. This is what is sent. So it's step nine by the home agent. We take the original datagram which we drew over here where the source is the correspondent node address and the destination is the home IP address of the mobile node, 111100. We take this and treat that as the data in another IP datagram. In any IP datagram we have a header and data. So think of the black part as the data and here's the header. And we set the source and destination address. It's coming from the home agent and it's going to the care of address. And that's received by the foreign agent which then uses its visitors list. See where we have it, wrong way. So this datagram of course will go to the foreign agent because the foreign agent has a address 7771 routed across the internet. When it's received, the foreign agent realizes, okay, this datagram is to me. Therefore it removes the outer header and finds inside is another IP datagram destined to 111100. And now realizes by checking its visitors list, okay, 111100 is currently visiting my network. Let's deliver this inner datagram direct. And it knows the MAC address already to send to via the LAN or via the wireless LAN. Whatever technology is used there. Wireless LAN in our example. So make sure you understand how the addresses, especially the source and destination addresses are used in the IP datagrams for the day delivery. From mobile node up to correspondent node, it's simple. Just use normal routing where the source address and destination address are the normal ones. But with correspondent node down to mobile node, it's more complex in that we need to use tunneling from the home agent to the foreign agent. Put one IP datagram inside another IP datagram. The last thing we wanna look at for mobile IP is some of the performance aspects. But before that, let's make sure everyone's clear. So that they can do the quiz. Any questions? Easy. And coming back to the general description of tunneling, here we have an IP datagram or an IP datagram inside an IP datagram. So we've got a datagram or a packet of one protocol type, but one layer inside a protocol from the same layer. In this case, it's the same protocol. A network layer packet inside a network layer packet. That's the general concept of tunneling. It doesn't have to be at the network layer and it doesn't have to be IP. Generally, tunneling can use different layers and different protocols. So we've achieved our aim, which is mobile node and the correspondent node applications do not have to change IP addresses. They always use the same IP address when they communicate. No matter where the mobile node is in the internet, the applications when they receive the packets will always see this 111100 and 888200. We need that because applications, some do not work well if we have to change the IP address. We have to stop the transfer. And we provide mobility in that the mobile node can move to anywhere in the internet and still have the data routed to it by sending via the home agent. And we need to first register with a home agent to tell it where we are. That covers all of our example. So different. What are the problems then? What's some of the problems that happen with mobile IP? The efficiency or the performance, why may it be considered sometimes inefficient or not perform well? What's an example? If you look at some of the steps that we went through, mobile node performed agent discovery, then it registered and then it can start sending and receiving data on the new network. And when it sends data, it goes to the correspondent node but when the data comes back, it goes via the home agent and then to the foreign agent and mobile node. There are two performance issues or two main performance issues that arise here. There are other issues as well but the two main performance issues are first, as we move into a new network, it takes some time to register, to both discover and register. During that time, we do not have full internet connectivity which means that our application may A, have to stop sending data and we may stop receiving data. Okay, so originally I'm attached to my home network. Let's say I'm streaming a video from some web server. Correspondent node is sending me some video, sending me many packets each containing a part of the video and I display that video on my mobile device. And as I move, I'd like to be able to have continuous access and keep streaming that video. So as I move and enter a new network, correspondent node doesn't know I've moved so it's still sending the packets. It's still going to my home network but I'm no longer in the home network so I stop receiving those packets. If I leave the home network, then I'll stop receiving the packets. And then I must discover the foreign agent, take some time. Once I discover the foreign agent, I need to register to my home agent which also takes time. I send a registration request message, it gets to my home agent and at that point in time, the home agent now knows, ah, okay, I'm receiving packets from some server to 111100. It's no longer home, it's visiting some other network. I need to start forwarding, more specifically tunneling those packets to the foreign agent. So from when I leave the original network, until when I tell the home agent that I'm in a new network, I may stop receiving packets. And those packets may be lost in fact, I may never receive those packets unless we do some special buffering. And that may affect the application. So for some period of time of the discovery and the registration, there's some disruption. So one of the problems is to keep that time short. So the disruption is as small as possible. And it depends on three things. The time it takes to leave and join the next network, the time it takes to discover the foreign agent, and the time it takes to register. You'll see one or two, the quiz questions which will ask you to calculate those times. So you can, given some parameters, you can approximate how long it would take to perform those steps. So that's one problem with mobile IP. When we change networks, it takes some time. The other problem is the data delivery. In particular from CN to MN. Whenever the CN is sending data, it goes to the home agent, and then from the home agent to the foreign agent, and to the mobile node. It takes a longer path than what is possible in some cases. You'd think the ideal path would be CNEDCF. But because we must go through the home agent, it's we have to send CNEDCBA, ABCF. More hops it needs to send, and generally leads to a larger delay for the delivery of our data. Not so bad if I'm streaming a video from YouTube, but not good if, for example, I'm web browsing or maybe in a voice conversation or some online game where we need some interactivity. Because the delay from CN to get the data to MN is important in some applications. If that delay goes up, because we need to send by the home agent, that can impact on the applications and make them in some cases unusable. So that's another problem with mobile IP. There are some ways, some additional techniques to try to alleviate those problems, to reduce the impacts and to make the performance satisfactory. We're not going to cover those additional techniques. We'll skip through some slides, but that's basically the end of mobile IP. Any questions before we finish this topic? There's a quiz that I made available today that has 14 or 15 questions about mobile IP. It gives an example network like we have in the handout and asks you what happens in each of these steps of discovery, registration and data forwarding. So try and go through the questions, go through in order because the later questions depend upon the earlier questions. Let's just finish on our slides. So there's discovery, registration and tunneling are the main techniques that we've looked at. There are techniques to improve the performance, to minimize the delay called route optimization, things like handover smoothing. So to help reduce the delay in the registration and also the forwarding and tunneling. We've gone through registration, agent discovery. We've gone through tunneling. This is a more general slide, but I think the detailed example is a better illustration. And we will not cover how route optimization works. An extreme case of where mobile IP doesn't work well or the performance is bad is if my home network where are we? The, all right, in this example, if the home network is somewhere in the US, for example. So somewhere from the US is visiting. And so someone in Toshiba in the US is visiting and they are visiting Toshiba here in Thailand. So what, hundreds of meters away and they're communicating with someone in SIT in Thailand. Then the data needs to go via the home agent back in the US. So from Toshiba in Thailand back to the home agent and then to here SIT. So that's an extreme case where instead of going direct from one network inside Thailand to another, it goes from one network back to another country and then back into Thailand. So a bad situation for mobile IP performance. And route optimization is a way to try and reduce that. Handovers and movement detection and other ways to try and improve the performance which we're not going to cover. And different techniques that you can do like buffering packets, sending multiple copies of packets and having a hierarchy of foreign agents to reduce registration delays. So to finish on mobile IP, for mobile IP to work, the mobile nodes need to have some software that implement mobile IP. And the routers need to have software that implement the home agents and foreign agents. So that's, let's say, additional functionality compared to standard IP software. Optionally, not from what we've seen but if we use route optimization even the correspondent nodes need to support it. But in the normal case, your mobile node, your laptop or mobile phone needs special software as do the routers. What's the current status? The technology has been around for many years. So the protocols have been standardized for both IP version four and IP v6. In terms of implementation of those protocols, and this, you can see how old this slide is but it refers to Windows XP and Vista but most consumer operating systems do not natively support mobile IP. So I don't know about Windows 8, whether it has it supported but not mobile IP version four. It is supported, most likely mobile IP version six is supported in the latest versions of Windows and is supported in some Linux and Unix distributions. Most routers support it but they may not enable the functionality. So it's been around for a long time. Mobile IP version four did not achieve widespread use so you and I don't use it on a regular basis on our laptop, for example, different reasons why. But in terms of mobile phone networks and next generation mobile phone networks when they start to use instead of the circuit switching for voice delivery but use always IP packet switching their mobile IP version six is included in the standards to be used for your mobile phone. So that's one place where mobile IP becomes important and is used in some networks already and that finishes mobile IP. The other two topics in this set of slides we're not going to cover. One is about network mobility. That's the case of with mobile IP one host moves. Network mobility or Nemo is about the special case which extends that what if an entire network moves? How do we deal with that? And it's an extension really of mobile IP and the name of it is called network mobility or Nemo. The example is you have a car, a vehicle, inside is its own network of people of devices all communicating via one internal network and that network is moving through another network and supporting that is the aim of network mobility or Nemo. And the last one you'll see will not skip through ad hoc networks very interesting but again no time to cover it this semester is the case where you have mobile devices and they communicate via other mobile devices not via access points or base stations. For example everyone has their mobile phone there are no access points or there's no connectivity to base stations. We create a wireless network by ICEN to one device that device forwards on to another device and so on. And they have some special purpose applications like emergency services and in some cases some more business oriented applications mesh networks. We will not attempt to cover them. So finish this topic on mobile network. The next topic is on TCP. Yes so the handover like cell switching, lazy and eager cell switching yes we've skipped. That's some more details of how to improve the performance on mobile IP. Everything we've talked about is included. That's the normal rule but let's see. So we've talked about registration for mobile IP, agent discovery, at least agent advertisements and router solicitation that was last week and tunneling we've talked about today. How route optimization works we're not gonna cover. Handover or maybe we will just say what a handover is. A handover is simply changing from one network to another. We consider the case where we move from our home network to a foreign network. The same operations are performed when we move from one foreign network to another foreign network, okay. That's a handover. That is I'm currently in a foreign network. If I want to move to another foreign network I perform a registration. Send a registration request to the new foreign agent and my home agent replies. So this is identical to what we've seen when we register. There's some optional ways that okay if I move from one old foreign network to a new foreign network some optional features to tell the old foreign agent I've left. And it for example can remove me from its visitors list. But other than that there's nothing, nothing different from what we've seen in registration. Handover is you just register to the home agent. That's all. And movement detection, no we haven't talked about in any detail. And these, no we're not looking at the different ways for handovers here. We're not covering handover smoothing and that's it. One thing I want to show you about the assignment. Again, another simple demo and then we're finished. We're not going to start the new topic today. We're going to have a short another demo similar to what we did last week with using iPerf but I just want to show you one different command quite quickly if we can get some internet connectivity. So last week I showed you iPerf. I'll show you again quickly without explaining the details and explain how it works. That's the main thing. We said last week with iPerf we run a server and a client. Only in my case you don't need to set the port. It uses a port number by default. I think 5,001 or some other port number. I do it just for my computer. Set the port on the server. We're going to use in the current phase of the assignment you're using UDP only use minus U and say to be a server. And so that's running on one computer. My office computer it's running as a server. It just listens and it gives us some information. Server is listening on UDP port 50124 receiving 1,470 byte data grams. Something about a buffer size which is the amount of memory it has allocated to receive that. And then we start the client. Need to specify the same port number. Also we're using UDP. Specifies the client and the IP address of the server to connect to. And optionally we can specify and this is important how fast we want to send. In this case IPF calls a bandwidth. So the minus B option. But think of this as the sending rate. The rate at which we send two megabits per second. And we see it says my client is connecting to the server 10, 10, 1, 1, 8, 4 using port 50124 and it's sending 1,470 byte data grams. So what it does is sends creates a data gram a UDP data gram of some random data containing 1,470 bytes and sends it. And it keeps doing that such that it sends at a rate and it's listed here as bandwidth which is a bit confusing for what we've talked about. But this is the sending rate of two megabits per second. And we get a report and effectively, well, this is not the sending rate. This we sent from the option minus B two megabits per second. This is in fact the receiving rate. And importantly the server reports it received approximately two megabits per second, 1.99 megabits per second. It's reported both at both instances of IPF. Now, what's happening there is the server's simple. It just receives data. What the client does is just generates data. But if we draw our computers, here's our client computer and our server computer. And here's IPERF and that's our application layer protocol. It uses its own protocol and it uses UDP as a transport layer which uses IP and then whatever we have as our data link layer. And similar at the server in the operating system we have IP, UDP and then the IPERF, the client and the server. So what the client does is it goes into a loop and by default the test runs for 10 seconds. So for 10 seconds what it does is it generates a datagram in this case, 1,470 bytes and does it at a rate such that it's sending on average two megabits per second. So you calculate 1,470 bytes times by eight which is about 12,000 bits for one datagram. It needs to send two megabits per second so you can work out how many datagrams it sends per second. I don't know the answer. So two megabits per second divided by this number of bytes is how many it sends per second. So the source code of the application just has a loop and it sends a datagram, waits sometimes, sends another one such that it's sending two megabits per second. And UDP is a transport protocol, effectively does nothing. It attaches a header to the data. It takes the data, attaches a header, a UDP header and in the header there's a source and destination port number. But it doesn't do any processing and it just sends it to the IP software inside your computer which takes the data. So if this is our data, this is the data, attach the UDP header, sorry if this is small, data, UDP header and data and the UDP header and data is then put inside an IP data which then just takes that datagram and sends it using whatever link you have. In both UDP and IP there is no protocol for retransmissions. We just send the data and hope it gets there. There's no protocol for flow or congestion control. It's not like TCP. So there's no ARQ mechanism which you may have seen, there's no stop and wait and so on. When we send the data, there's no acts coming back, okay? They're very simple. So we just, IPERF client generates data at some rate and it's sent. And as the server receives it, if everything's working okay, it will receive the IP datagram. IP will check that it's the right destination and just remove the header, send up the data and the UDP datagram UDP would simply remove the header and send the data to IPERF and IPERF just counts the bytes that it receives. And over a period of 10 seconds, at the server received 2.39 megabytes. The test ran for 10 seconds. You can do the calculation and that's 1.99 megabits per second. So all IPERF does at the client is generates traffic. Okay? One option, another option you can change as well as the minus B. So you can change the rate at which it generates traffic. So the reason you're using IPERF and in particular the minus UDP option with IPERF is for this phase of the assignment, you want to determine the performance throughput of the wireless LAN, okay? So in your case, here's the wireless LAN link from your one device to the next device. We want to work out what's the maximum throughput we can support. How many megabits per second? So what we need is some way to generate data to send across that wireless LAN link. If you download a file across your wireless LAN link, it's one way to measure throughput but in fact it normally uses TCP as a transport protocol. And it may not be a good indicator of performance. So we use UDP where we just send data and count how much data we receive over a period of time. There are different options with IPERF. One of them is the minus L option which changes the length of data when we're using UDP. Minus L200 sending 200 byte data grams. It defaulted to 1,470 bytes. If I use the minus L option, it said sending 200 byte data grams. Not much difference in performance. In some cases you will see a significant difference but in others no difference. So all it does in that case is takes instead of 1,470 bytes at a time, generates 200 bytes and sends it and just does that in a loop such that still on total it generates two megabits per second. So your task in this phase is to use IPERF in this manner to generate traffic to send across your wireless LAN. And the performance measured by IPERF is very close to what the raw throughput or the best case throughput is with your wireless LAN link. One other thing, maybe I said it last week but let's repeat it. Your setup, you have a wireless LAN access point. You have a laptop which is associated with the access point and then you may have another laptop or a PC but importantly connected via the wired LAN here. And this, in fact I the direction, it doesn't matter but this could be the client using minus C and this could be the server using minus S. The direction or ordering doesn't matter there but importantly one of them is using the wireless LAN and one is using the wired LAN. So the wireless LAN has a maximum data rate of 54 megabits per second and your wired LAN should be at least 100 megabits per second. If you're using a LAN cable here, the router will not support more than 100 megabits per second. When we run our test, it reports the performance across the entire path. That should be limited by the wireless LAN. So in fact the performance recorded by IPERF is an indicator of the performance of the wireless link because the wireless link is the bottleneck in the path. With throughput, the link with the lowest throughput will determine the throughput of the path. In this case the path has two links. This link should have the lowest throughput so for the path we will not get above that throughput. So set up your network in that manner. Do not use a wireless LAN link here and a wireless LAN link here because effectively then you have two clients competing with each other and the throughput will be much lower than what you get with a single client. And that's all I want to cover today.