Next, we're going to talk about how to design networks. In this problem, it's a little bit different for wired networks. In the context of IoT wireless networks, we talked about a lot of protocols to automatically construct topologies. You have all these devices and we can autonomously set up topologies, determine which nodes to connect and have a flow of data across them. That's great because in those environments, you want really plug and play structures that are resilient. For wired networks, things are different. You want to have a lot of control over your topology and how things are set up, and you have a lot of physical constraints. So network design comes into play a lot more. How do you design a network? So in the context of software, if you want to design a piece of software, there's all sorts of rules of thumb about how you do it in best practices. There's EPI definitions and ways to construct classes and design patterns, and we have that for networks too. You don't just sit down and plug devices together. There's procedures you follow about how to connect devices together, where you put certain pieces of functionality, where you do filtering at firewalling and all that stuff. I'm going to be talking about that, to give you a sense of when you design a network, how to do it by following best practices? So in terms of what you want to do. If you have a network, if you think about what you want your network to do, your network has goals. You have a bunch of sensors that you went to connect up to the internet. Maybe you want to filter bad traffic before it gets into your network. Maybe you want to provide voice or video with good quality, so you have a bunch of goals. You may have multiple goals at the same time that you want to achieve. So these goals are realized through network design. Part of this is done by taking your network and then going into individual devices and configuring them. You can go to a device and type in some commands in your router and say, "Okay. In this interface, there's a lot of really high-quality traffic coming in, a lot of voice traffic. I want that to be tagged as high priority, given top-notch quality of service. Then I have my public users, they can have lower quality." You can do all that by configuring devices, but a lot of it also done by designing the topology itself. Where you put various devices and routers, how you connect them together, where you put links, how big those links should be and so on. So the first step is designing the topology and then you can do the configuration. If you think about what you want to do as a whole, usually you take your main goal and you break it down into individual functions. Your goal might be, I don't want bad traffic to get into my network. So you'll realize that by putting some firewalls in certain places, and then getting into configuration and typing in certain commands into this firewalls. So what you do is, you take your high-level task and break it down into functions. These functions are enabled by devices. So you choose devices that do what you want to happen, and then you put them where you want those things to happen. So what I'm going to show you next is a real network topology. This is a reference network topology. This is corresponding to a real network deployment, you have a bunch of branch offices and various sites and it connects to the internet. So when you design a topology, when you design your physical layout, the physical environment and geographic environment matter a lot. So if you stare at this you can see certain patterns. You can see okay, there's different buildings and each of these buildings needs access. So I'm going to run wires to these individual buildings, and in these buildings there's different devices like phones and things like that at the bottom. Then there's a large number of devices, and you can see there's this tree structure where these devices connects into switches, and these switches can aggregate into smaller groups of switches and so on. So this is a common practice, where you have an access layer of switches, then a distribution layer, and then a core layer, and you're getting smaller each of those hops. So what you'll have is, you'll have a thick network backbone which is really what you want, and then tendrils going out to each of your sites to pull in data. So when you construct a topology, physical layout matters a lot. You want to start off with some sort of physical diagram of what you're trying to build. Maybe it's an office building, or a campus deployment with a large number of buildings, or a room with a bunch of sensors in it, you want to draw out physically or geographically, and then do diagramming to figure out where you want to put different nodes in different hosts. You also notice from this figure there's a large number of icons. You may be wondering what these icons mean. There's different boxes and some of them has stars in it, and they look different in different ways. Well, these icons or different kinds of devices. So there's actually a large number of device types that we can use to build networks. So I'm showing you a bunch of examples here. You can see there's layer three switches and routers, there's various kinds of switches, there's intrusion detection systems, I'm listing a bunch of them here. So usually when we design networks, we think about what we want and then we draw little pictures to diagram what we want. It's good to make documentation when you're building things, so other people can see what you're doing and you can remember what you did. So there's all these different device types, and we use different icons to represent each type. So what I'm showing here are some standard icons that are used for each of these device types. So if you see these in documents, you'll know what they refer to. Now a question comes up of if you want to build a network what do you choose from? I mean, there's just so many device types here and there's so many more that I'm not showing on this slide. What do you actually use to build a network? Well, one thing that's helpful when you're designing your network is to think of functionality as being separate from devices. In the old days when you design a network, like 20 or 30 years ago, you'd think about what you wanted, and then go to a vendor, and then you'd buy a device that does that. You'd want a firewall, so you'd go and you buy a firewall, or you want a load balancer and you go and you buy a load balancer, but things have been changing. If you think about functions, what you want do, like switching or packet inspection and things like that, those used to be tied to specific device types. Nowadays, things have gotten a lot more virtualized. If you have a function, it's increasingly available on shared hardware. So nowadays, the main model is, you'll go and you'll buy a switch or you'll buy a router, but it will actually be able to do a lot of other things. It's really cheap to just make a switch or a socket inside of your switch that does a whole bunch of things, and then just turn those functions off. Then if your user wants to use those, make them buy a license from you. So what vendors are doing is, they'll sell a switch, and the switch can actually do a lot of things, they can do load balancing, and firewalling, and deep-packet inspection, all these things on that switch, but it'll be sold with a certain base set of functionality turned on and everything else disabled. Then you can go in and turn on other things. So this makes things easier in some ways because you can deploy your switches. You don't really have to worry about what you need straight off, and if it turns out you need something else, you go when you buy a license and you turn that thing on, you'll buy a firewall license to enable that for your switch and so on. So topology design has become a lot more about the physical nature of disseminating information, figure out where to run wires, and then putting Vanilla switches in different locations, then turning on the functionality that you need. Now, there's something else called network functions virtualization, which takes this idea even further. NFV is about completely decoupling the function from the switch itself. So if you have a function like load balancing, or switching or things like that, you can take that function and place it anywhere you want in your network. So if you've ever used Amazon Web Services or Azure, it's like that. They give you this primitive with VPCs, for example, where you can create your own virtual network and you can place firewalls and switches and things like that. You don't know really where those things are physically. You don't really know Amazon's internal infrastructure. You don't even know if that firewalling functionality is running on a computer, if it's running on a physical switch, but you don't need to know. With network functions virtualization, the functions are revealed to you, and you can place those in the network however you want. You see that with Amazon Web Services, and also functions, and also vendor products lake VMware Nsx. So when you think about functions, there are several key function types that are out there. There's things like forwarding. So there's a bunch of devices that are centered around the idea forwarding traffic. There's some devices that are focused on processing traffic. I mean, they'll forward the traffic but they also manipulate the traffic along the way, or change the contents of the traffic. Some devices also translate the traffic, they'll change the format of traffic, they'll change packet headers or do encryption or things like that, and there's also functions like isolation, by blocking bad traffic or instantiating segments on your network. So what I've done here is, I've given you an overview of how you design networks. What we're going to do next is, we're going to get into this in more detail, and I'll talk about these key device function types in more detail.
