So we've been talking about protocols that allow nodes to communicate effectively, and share clock information, and go to sleep, and things like that. So we've been covering a big space. But there's another category of protocols I want to mention. That is about how you talk directly to your neighbors, how you discover who they are, how you associate with them, how you form connections with them. We're going to be talking about that next. As motivation for this, and to give some intuition behind this, I want to talk about how neighbor discovery works on wired networks, in non IoT applications. There is a protocol I want to talk about called the Link-Layer Discovery Protocol. This protocol is good to know about because IoT applications use protocols that are based on this, are inspired by this protocol. So it's good to know this as a foundation. Link-Layer Discovery Protocol is a very widely used protocol in wired networks, to discover the network. One of the challenges you have when you run a network, is you build it, and you put it together, and you hook together all these switches and routers, and then you forget how it's hooked together. This might be surprising, but you'd be surprised how often you go and you talk to companies, like at our company, we go in and we talk to companies a lot. One of the first things they say is, we don't know what our network looks like. We had this guy set it up and he quit and we don't know how things are hooked together, we don't know how many switches we have. So one standard practice that's good to do is to run this protocol because what this protocol can do is, it can tell you your network topology. It can tell you how many switches you have, how they are connected to each other. The way it works is the protocol sits there on each switch and each router in your wired network, and it has them exchange messages to each other. So periodically, every 30 seconds, routers will exchange these protocol data units or these packets for LLDP, they are called LLDPDUs, with its physical neighbors. Each of these packets contain a set of records. These records contains some information, and they're basically hello messages. These routers are introducing themselves to each other. So these messages contain these records, each of these records are called TLVs, type-length-value, they are just tuples. They contain information such as: chassis ID, the port ID, the system name, system description, and so on. So basically, these routers are introducing themselves to each other every 30 seconds. They're saying, "Hello. My name is such and such. This is my management address. This is some description about who I am, pleased to meet you,'' and they're saying this every 30 seconds. It is here repeatedly because you might disconnect a router and put a new router in there or a link might fail. So these messages are small, it's not really that wasteful to keep sending them over and over. We have gigabit links, 10 gigabit links now, sending a tiny little message has nothing to do that. So that's what LLDP is. There's a variant of LLDP called CDP, which is also very common. It's a Cisco-Proprietary variant of LLDP, works in a very similar way. So to show this graphically, I'm going to show you some switches and I'm going to show you how they run LLDP. So I don't know if you've ever seen a switch or a router, but these are specialized computers we use in the internet to communicate. They have a bunch of ports on them. So you see my little diagram, they have a bunch of little holes. You can plug Ethernet cables in there or optical cables or whatever, and you can hook them together. You can also plug computers into them as well. So there's a bunch of switches, and these switches are computers. So they forward packets at high speeds. But you could also log into them and configure them. So when you configure them, you need to tell these switches, hey, I want this port or this interface on you to act in a certain way. So you need to identify each of the ports. Each of the ports has a name. They have names like this, like Eth1/40. The first part of the name, denotes the type interface. So this is an Ethernet interface. The next number, defines the chassis number or the line card number. So in this case, I'm just drawing single switches. We can have switches that are part of stacks or you can have big switches with a bunch of line cards, you can slot in and out. That would be that first number. But since these are just simple switches, that's going to be one. Then there is a slash, and then there's a number which defines the port number. So I'm pointing to port number 40 on this switch. On Switch 2 and Switch 3, there's interfaces as well. Not all switches use the same terminology. So Switch 2 happens to use an operating system where they call these gigabit interfaces. So that's fine. But in general, ports and interfaces have names like this. So what I will do when I build a network, is I will hook together these ports using cables, and I can build networks and topologies this way. So if I turn on LLDP, that tells the switch to periodically start sending these messages to introduce itself to its neighbors. You can see that Switch 2 is sending some messages, it's sending messages that say its name, Switch 2, it's saying its chassis ID, it's also sending the port ID. So Switch 2 is saying, ''Hello, whoever's on the other side of this link. You're connected to me via gigabit interface 0/27." But it's going to send to that other switch, ''Hello, whoever's on the other side of this link. You're connected to me via gigabit interface euro/43," and so on. So switches send this information out to their neighbors. Then what you can do, is you could log into these switches. So these switches have consoles where you can log into them, you can type commands, and you can configure these switches but typing commands. You could also type in certain commands that ask the switch to tell you some information. So these are called show commands. One such command is 'show LLDP neighbor'. So that tells the switch, "Tell me about all the neighbors you learned about through LLDP.'' So if you type that, 'show LLDP neighbor', on the switch, you'll see something like this. The switch will say, ''Well, I've learned about one neighbor. Its name is Switch 2, this is its chassis ID, this is the interface that it uses to connect to me," and so on. You could imagine that you could build stuff on top of this. You could build Python scripts or whatever to login to each of these switches, collect this information, build a nice-looking network diagram. You can also use this to implement protocols on top of wired networks or do analysis of your wired networks. So LLDP is a great protocol to run for these things. Sometimes people say LLDP is not secure because there's not a lot of security in it. These messages are often not authenticated, but you can layer off authentication on top of this. The counter-argument to that is, well, if you don't know what your network is, how can you make it secure? So there's debate over this, but a lot of people think LLDP is actually a good practice to run because it helps you know what your network is. If you have a secure perimeter, you're not going to let unauthorized host fabricate LLDP messages in your network anyway. You're going to filter those out at your porter. That's something to keep in mind. So that's LLDP. That's a widely used protocol to perform neighbor discovery in wired networks. So getting back to wireless IoT situations. You have a pretty different situation because you're operating in a wireless environment, where you have a lot of issues. You're not directly connected to a single neighbor or ports. Instead, you have situations where you're sitting there and you may have a lot of equivalent neighbors. For example, suppose you're a device, you need to access something in the Cloud. Well, to do that, you're going to have to discover an entry point up into the internet. In a lot of times, you're going to have a lot of choices for that. You're sitting there, there's going to be a lot of access points up on the ceiling you can connect to you to reach out to the internet. So there's this notion of having equivalent neighbors. You may want to discover a service or a network behind the neighbors, and beyond that, those neighbors are equivalent. So that's one challenge. Another issue is you may want to discover your closest neighbor. So for the access point example, maybe there's an access point that's really close by and there's another access point that's further away. You may want to connect to the one that has better signal strength. You're less likely to lose packets, things like that. You don't really run into this with LLDP so much. Because with LLDP, it's much more about you're physically connected and this is your only choice. Another issue that comes up in IoT is dealing with quality of service. So a lot of devices, your Bluetooth headphones, you may be streaming video, your Alexa needs to reach up into the internet, you may need to have real-time quality of service for your connections. So a lot of these protocols have the ability to reserve resources. You can connect to a neighbor, choose out what neighbor you want, but you can also tell that neighbor, "I would like to have a guaranteed one kilobyte connection, and I would like responses to happen within a millisecond, because I'm doing real-time natural language processing. I need to respond to a human." So you can reserve resources in this way. So this is another challenge. Another issue is that, in wireless, we have a lot less ability to really understand who's connecting, because in IoT, it's much more about humans are walking around. Someone has 10 devices on them and they walk into a room and they want to connect, what's stopping a device from just lying about who it is? Someone could walk in a room and say, "I'm an access point. I'm connected to the internet, everybody connect through me," and then you can watch all their data, block it, fabricate responses. So neighbors can lie about who they are. So there's much more of a need for authentication and authorization. So there's protocols to address exactly these things. In wireless, we have additional protocols beyond LLDP, where we do association, where choose out which neighbor we want to connect to. We do discovery to analyze the network and figuring out what's out there. What sort of things are in the room I'm in? Are there audio devices? Are there projectors I can project to? So it'll discover the services in the network. There's also authentication protocols to figure out. Once I discover what I want to connect to, I have the ability to prove who I am, to prove that I'm authorized to connect to the network. So let me run through some of these protocols real quick to give you a sense how they work. I'm going to start out by talking about 802.11 wireless, because this is a protocol that you're probably familiar with already. Your laptop uses it. A lot of these IoT protocols like Zigbee and Bluetooth, they do the same thing. So if you understand 802.11 steps, you're going to understand all these protocols. So I wonder if you've ever gone into your computer and set up wireless networking, you go to your dentist's office or whatever, and you want to connect to the guest network or a hotel or something like that, you may have clicked on the little network icon and you may have gotten a list like this where you see a list of networks you can connect to. Well, behind the scenes, there is a network that's deployed. There's a physical network, a wired network, which provides a set of access points. So people have gone on the ceiling or the floor and they've installed these access points which transform digital data from wired connections into wireless signals. What your device is doing, is it sits there, and it sits there and it listens in these different devices, these different access points and beacons where they periodically tell about who they are and what networks they support. Your device will sit there and it'll analyze the signal-to-noise ratio. How powerful the signal is coming from these different points. Then your operating system will make a determination about which one it wants to connect to. But it can't do that alone because it doesn't know what network you want to connect to. So in this list you see in your operating system, where it has these different network names, like Dentist Guest network or VFCorp or in M1-Enclave-Wireless or whatever the network name is, those are names of networks. Those are not names of access points. So there's notions of virtual networks, which overlay the access points. So you have a set of access points, these access points provide service for different networks. These networks are called SSIDs. SSIDs are names of networks. So in this example, VFCorp, VFGuest, M1-Enclave-Wireless, these are names of networks, these are SSIDs. What an access point will do, is it will advertise the capability to reach a particular SSID. So you can see from the diagram on the right, some SSIDs are reachable out certain access points, and not others. So there's an access point in the lower left, for example, which can only provide service to M1-Enclave-Wireless. Whereas, there are several that can provide access to VFCorp and VFGuest. So a single access point can provide service for multiple SSIDs. So what your operating system does is it builds a list of all the SSIDs that are reachable, and it asks you which one you want to connect to, because only you know that. The user knows which network they want to connect to. Then the operating system makes a determination about which access point to connect to because the Operating System is best at deciding which access point to reach, because it can sit there and they can monitor signal-to-noise ratios. We shouldn't have humans do that. So one thing that new network engineers sometimes get wrong when they build networks, is they say, "I'm going to have a different SSID for each access point." That's not a good way to build networks because you wouldn't have the operating system determine which one to connect to, because it's better at that than humans are. So you have this situation, and these access points, the way it works in 802.11, is they periodically advertise these beacon frames, which contain the set of SSIDs that they offer, their supported rates, transmission parameters. By default, 802.11 beacons pretty often, every 100 milliseconds. So that makes it so you can discover these access points quickly. On the other side of the connection, your device is going to sit there and it's going to scan all the channels. So this isn't the firmware of your NIC. It's going to scan all the channels, it's going to continuously listen to beacons, and then it's going to show this list of the users. So it's going to sent that up to the operating system, and it's going to sort them by preference or whatever. Your NIC can also actively send probe requests to actively scan the network if it wants to, so that's a backup to the beaconing. All this is programmed in the next firmware, so that NIC knows how to do this. So that's how 802.11 works. Now there's a protocol that's used to actually form the connection between your device and the access point. That's an association protocol. Zigbee and Bluetooth, they all have variants of this, which are very similar. The way it works is, your laptop or your device is going to go through a series of phases. It's going to start out by choosing which access point to connect to. So it's going to sit there and listen to probes. It's going to listen to beacons, it can also actively send out probes and probe requests. It's going to figure out a set of access points and then it's going to choose the one it wants to connect to. Then it's going to do an authentication process, where it's going to introduce itself to the access point and convince the access point that it is allowed to connect to it. So it's going present credentials and keys. You know that key you type in when you connect to new access point, it's going to present that. The access point is going to validate it, and then send back a message indicating whether that host is indeed allowed to connect or not. Then the host does an association phase, and this is a phase where the host says, "I would like to connect to you." The access point can reject. The access point can say, "I have too many users connected to me right now, go find another access point for this SSID." Or it could accept it. It sends back its decision in this association response. Then your device can access the network, it can go ahead and exchange data with the access point. This process is done on the first connection, when a host first joins the network, but it is also done repeatedly. So the host is sitting there and it's monitoring its connection to the access point. It's sending data, but it monitors that signal strength. So that allows mobility. If a user walks around and gets closer to another access point and gets further away from the first access point, then the signal to the other access point is going to get lower and lower. Your NIC will realize that and initiate a hand-off process, where it will perform the association to the new access point. Depending on the setup, it may not have to go through the authentication phase again. There's ways to hand off authentication keys between access points. So what it will do, is it'll just re-associate with a new access point and then send data. So that's how you can walk around an environment and always stay connected even if you get far away from the original access point. So what I've done is I've given an overview of association and neighbor discovery, and I've gone through a set of protocols and protocol steps. Next, what we're going to do is we're going to get into this more. We're going to talk about how these different protocols can work together to do something called mesh networking.
