Networks

Network Layers

While the Internet has a rough hierarchy, it's more Pollock-meets-Picasso than M.C. Escher. There are outlines here and there, but much of it is a smorgasbord of dizzying components: hosts, routers, applications, antennas, satellites, cables, hardware, software, and so on. All of these components have unique, dedicated tasks, so how do we ensure that one component doesn't go off ruining things for everyone else?

One way to solve this problem is to shift the way we think about the Internet. Instead of thinking of the Internet as some physical connection—as we did in the previous section—we want to think of it as a service. For example, we could think of air travel in terms of its physical components. There are airplanes, airports, security gates, travelers, flight attendants, pilots, airport restaurants, etc. And just like the Internet, we have regional airlines, national airlines, and international airlines. How does air travel not collapse because of all these different components and self-interests? Through layers of services__ and __protocols (i.e., laws). We'll discuss the protocol aspect later, but for now, let's focus on the layers of services.

Suppose our friend Allen buys a ticket from Jacksonville, North Carolina, to LA, California. This is a fairly long flightpath. Allen goes to Albert J. Ellis Airport (OAJ)—a small regional airport—and boards a Southwest Airlines flight to LAX, a large international airport. To get to LA, Allen has his baggage checked in at OAJ, then gets to the gates, and eventually takes off. When Allen gets to LAX, he goes through the same layers of services and points, from bottom to top:

We see the same idea at work with the Internet. Suppose we're waiting at O'Hare airport and we visit CNN.com. Entering the URL, we go through several layers. First, the application layer, our browser. By entering the URL into our address bar and hitting enter, we're telling the browser to communicate with the CNN application, stored on some server in, say, Atlanta. For this communication to occur, the application layer then creates a packet, attaches a message to it, and sends it to the transport layer, which also exists on our laptop.

The transport layer receives this packet, and recognizes that it must deliver this packet to the transport layer of the server in Atlanta. This is akin to how a baggage tag from the Jacksonville airport's baggage check-in area is only understood by the baggage handlers at the LAX baggage claim area. To ensure the CNN server's transportation layer understands what to do when it receives the transport layer's communication, the transport layer provides what we can think of as a barcode—some kind of information that allows the CNN server's transport layer to determine which application layer the message it receives belongs to. This information also ensures that the packet doesn't get lost, and in the event it does, not in the wrong hands. So, it adds this additional information—called a segment—to the packet.

The transport layer then sends this packet to the network layer. The network layer's job is to determine the fastest possible route to Atlanta. Should it go to St. Louis then Atlanta? Indianapolis? Washington D.C.? The transport layer is only focused on efficiency; it doesn't worry about security, or whether there's anything wrong with the message. It just focuses on efficiency. Once the transport layer figures out the best possible routes to take, it adds its determinations—called a datagram—to the packet.

The transport layer then sends the packet to the link layer. The link layer's job is to define the start (through information called the frame header) and end of the packet (the frame footer), as well as information that allows the next device's physical layer to interpret the packet:

Once the link layer is done, it sends the packet to the physical layer—perhaps a physical cable (e.g., Ethernet or a phone line) or, in the modern era, a radio signal (WiFi). Let's say it's a WiFi signal. The physical layer—a WiFi card—receives the packet, looks at the link information, and tells our laptop's WiFi antenna to vibrate at particular frequencies (essentially, the physical form of the packet).

This radio waves (the packet) is received by a switch, a device that routes packets elsewhere (in our case, a WiFi router). The WiFi router's physical layer—another radio antenna—receives these radio waves, and using the frame information, samples the signal into bits. These bits are then sent to the WiFi router's link layer.

The WiFi router's link layer then looks at the datagram, and only the datagram (remember, each layer only understands its corresponding layer from the sending device). Part of the datagram contains our device's MAC (Media Access Control) address, which we can think of as our device's unique ID. Seeing our MAC address, the WiFi router is programmed to forward the packet elsewhere. To ensure the packet is sent to the next router, the WiFi router removes the previous frames, and adds new ones.

This is because the previous frames only included information providing that the packet gets to the WiFi router. It's the same idea behind the physical baggage tag numbers for multiple flights. If a bag is supposed to go from JFK to ORD to LAX, the baggage handlers at JFK must include information providing that the bag's headed to ORD. When it gets to ORD, the baggage handlers there have to remove the information "To ORD", replacing it instead, with, "To LAX."¹

The WiFi router then sends this to a router, a larger device that directs network traffic. That router might be located in St. Louis. The packet goes to the router's physical layer, which samples the packet into bits, and sends those bits to the link layer.

The link layer looks at these bits, and sees that it came from our WiFi router. Recognizing this fact, the link layer removes the frames, and passes it to the router's network layer. The network layer looks at the datagram, and sees that's it's supposed to go to Atlanta. So, it removes the old datagram and adds a new one: The new datagram provides that the packet should go to Atlanta, but the next hub should be Washington D.C.

The network layer then hands the modified packet to the link layer. The link layer then adds new frames, this time including the Washington D.C. router's hardware address.

This process continues, going from router to router, until it finally reaches the server in Atlanta. Once there, it passes through layers, just as we've discussed at length. The packet gets to the server's physical layer, which samples the signal into bits. The bits are sent to the link layer, which then sees that the packet is supposed to go to the hardware address of the CNN server in Atlanta. That's me!" Knowing this fact, the link layer removes the frames, and sends the packet up to the network layer.

The network layer looks at the datagram, and sees that the packet is supposed to go to the CNN server in Atlanta. "That's me!" The network layer removes the datagram, and sends it up to the transport layer.

The transport layer looks at the segment, which looks at the packet's number. Suppose that number is 195. The transport layer asks, "What was previous packet's number?" It determines that it was 194 and concludes that the packet was received in order. So, the transport layer sends the packet up to the application layer.

The application layer—some backend framework, perhaps Node.js—looks at the message, and sees that it's a GET request for CNN.com. So, the application layer creates a new packet, and in that packet's message, it places CNN.com's index.html file, and sends that packet on its way. The process continues.

Protocols

The Internet is also held together by protocols—rules defining the format of messages, the order they're sent and received among network entities, and the actions those entities must take upon message transmission and receipt.

Protocols ensure that we don't have situations where messages crash into one another, entities talking to each other at the same time, or waiting too long to respond or speak.

Designing these protocols is tricky. We have to balance both fairness and efficiency. To illustrate, consider the problem of a Zoom meeting. Undoubtedly, we've all witnessed the situation where attendees speak over one another. How might we avoid this problem? Well, we could write a protocol instructing attendees to be cautious: Have something to say? Wait for ${5}$ seconds and if no one else has spoken, speak.

But does this actually solve the problem? Not really. Some of us have also seen situations where the Zoom speaker asks, "Any questions?" ${5}$ seconds pass and suddenly there are two attendees asking questions at the same time. A few "No please go ahead" are exchanged. ${2}$ seconds pass and again the two attendees speak over one another. Of course, the probability of a collision is lowered with the protocol, but the problem nevertheless remains.

How about this: Attendees each have a designated ${5}$ minutes to interrupt and ask questions. Outside of those ${5}$ minutes, the attendee may not speak. This is called a fixed scheduling approach, and it certainly avoids collisions. But what's the problem? Efficiency. Given five attendees, we could have a situation where the first four attendees have nothing to ask but the fifth attendee has plenty to ask. In which case the fifth attendee must not only wait for ${20}$ minutes, but could have used some of the unused ${20}$ minutes. This is both inefficient and unfair.

The same kind of problem exists in networks. When we examine protocols in closer detail later, we'll find that we want to maximize the amount of time, but also need to be fair.

Network Edges

Network edges are internet leaves. These are the applications (e.g., browsers, the Facebook app, Instagram, mail clients) and hosts (also called end systems) (web servers, file storage systems, etc).

Network edges are structured in one of two approaches: the client-server model__ or the __peer-to-peer model. In the client-server model, the client host (e.g., a web browser) sends requests to a server that's always on and listening to requests, and the server responds.

In the peer-to-peer model, there is no dedicated server, but every machine—laptop, desktop, phone, smart watch, smart refrigerator, smart ${x}$—behaves as both a client and a server. This is the architecture behind Skype, Blockchain, BitTorrent, and many others. If ${x}$ and ${y}$ are devices—called peers—in a peer-to-peer network, as long as both ${x}$ and ${y}$ are on and protocols are satisfied, ${x}$ and ${y}$ can connect and exchange data.²

Network Edge Protocols

With network edges, the primary goal is to transfer data between end systems. To help achieve that goal, we use protocols. For example, one protocol is the Transmission Control Protocol (TCP). This is a protocol aimed at achieving three objectives:

Reliability. TCP-compliant devices guarantee that packets are transferred as a stream of bytes, called a byte stream. They further that the packets are transferred in order. That is, packet ${4}$ will never come before packet ${3,}$ and packet ${3}$ will always come after packet ${2.}$ This ensures that we don't see Sammy Sosa running all the bases and then cut to him hitting the homerun, or Gordon Ramsay scrambling eggs followed by him cracking the eggs.

Importantly, reliability doesn't mean we will always get the data. We've all seen the live Super Bowl stream where we suddenly cut to a touchdown. TCP's reliability objective is that it will always notify clients when it fails. If data is lost, or if an objective is not met, TCP will acknowledge its failure and retransmit.

Flow control. TCP-compliant senders guarantee that they will inform TCP-compliant receivers how much data they will send. This gives receivers notice, allowing them to prepare, decline, or inform the senders that they can no longer receive data. In turn, this prevents receivers from being overwhelmed.

Congestion control. Given two TCP-complaint end-hosts—e.g., our phone and the YouTube server—if routers between the two end-hosts become congested, then the server will slow down the rate at which it transmits packets.

This congestion control ensures routers—the intermediaries between the YouTube server and our phone—aren't overwhelmed. Routers are devices too, and they have a finite amount of memory. If they run out of that memory, all of the packets comprising that Vine compilation we were watching are lost, and the stops. We will examine these protocols in later sections, but here are a few brief descriptions for some of these protocols:

1. User Datagram Protocol (UDP) is non-TCP protocol. It's a connectionless, unreliable data transfer protocol. Unlike TCP, there are no flow control or congestion control guarantees. UDP, however, leads to extremely fast connections. UDP is used for media streaming, teleconferencing, DNS, and Internet telephony. UDP is an ideal protocol for packet transfers where it would do more harm than good to retransfer information, as TCP does. For example, a common UDP protocol is Domain Name Server (DNS). When we visit bing.com, our browser sends a request to a domain name server. That server is essentially an address book that matches names like bing.com to a specific numeric address called an IP address, which is the address of the server hosting bing.com. We can see this IP address by running the command ping ⟨www.website_address.extension⟩. At the time of this writing, it's 204.79.197.200. This is a request for a very small amount of data, so it makes more sense to use a UDP protocol, namely, DNS.

2. Hypertext Transfer Protocol (HTTP) is an application layer TCP protocol for establishing connections between different websites. It's what clients use to request data, and what servers use to respond with data. HTTP is fastest when the data transfers consist of many small files. This is the protocol used by the most of the websites we visit. When we go to espn.com on our laptop, our browser sends an HTTP request to the espn.com server, which then sends an HTTP response containing the data comprising the espn.com page that's supposed to be returned.

3. File Transfer Protocol (FTP) is another application layer TCP protocol, used for file transfers. It's faster for single, large file transfers. Applications that use FTP include FileZilla, Transmit, WinSCP, and WS_FTP—all applications used for uploading, downloading, and managing files on a server.

4. Telnet is a TCP protocol for remote logins.

5. Simple Main Transfer Protocol (SMTP) is a TCP protocol for sending and receiving email.

6. Voice over Internet Protocol (VoIP) is a UDP protocol for making voice calls over an Internet connection instead of a regular (analog) phone line. Applications that use VoIP include Skype, Whatsapp, and Google Voice.

Access Networks & Physical Links

As we know, routers are the large devices that connect large parts of the Internet to other large parts. For example, networks in Japan to networks in the United States. These routers are connected with large, thick, fiber-optic cables.

Connected to these routers are smaller, regional networks. These connections are established through smaller, thinner cables, usually either fiber optic or copper.

Connected to these smaller, regional networks are end networks—residential access networks (e.g., the networks provided by smaller ISPs like iTV and Xfinity), institutional access networks (networks at school or a company), and mobile access networks (networks provided by cell towers). These networks are connected to the smaller regional networks either by cable or wirelessly.

Finally, connected to these end networks are our laptops, phones, tables, servers, and so on. These networks are connected to the smaller networks wirelessly (e.g., using LTE on our phone when we're travelling or our house's WiFi network) or by cable (e.g., an ethernet cable at work or a phone line).

All of these connections are links, and they have a bandwidth—how many bits are transferred per second. More specficially, a link's bandwidth is the amount of frequency we have available for transferring packets. If a link has ${1~000~000 \text{Hz}}$ of frequency, it has ${1 \text{MHz}}$ of bandwidth. The larger this bandwidth, the higher the rate at which we can transfer bits, called the bit rate, measured in bits per second. This is given by Shannon's Theorem:

where ${\text{P}_R}$ is the power received by the receiver, and ${\text{N}_R}$ is the noise received by the receiver. The links between routers—fiber optic cables—have an extremely large bandwidth. This is why they have bit rates of hundreds of gigabytes per second.

As we get closer to the edge networks, the bandwidths get smaller. Links in these networks are simply physically smaller or are wireless.³ In the days of dial-up, physical links at the residential access level were shared with the phone line. This led to top speeds of ${56 \text{bps}}$ (far, far slower compared to today's speeds). It also meant we couldn't use the phone and surf the Internet at the same time.

Eventually, the asymmetric digital subscriber line (ADSL)⁴ replaced dial-up, and users started seeing upload bit rates of ${1 \text{Mbps}}$ and download bit rates ${8 \text{Mbps}.}$ Why was uploading slower than downloading? Because of the way the ISPs divided the bandwidth: A small fraction of the bandwidth for upstreams, and most of the bandwidth for downstreams. Why this division? Because this was before the era of cloud-based services and social media—users downloaded data more than they uploaded.

After ADSL came cable modems, the prevailing standard today. These wires were a mixture of cable and fiber, connecting homes directly to a local ISP's router through a shared bus. Cable modems had much bigger bandwidths, allowing downstream bit rates of up ${30 \text{Mbps}}$ and upload bit rates of ${2 \text{Mbps}.}$ The cost, however, was that residents had to share the connections. If everyone used the connection at the same time, everyone would get a fraction of the available bandwidth.

The ISP companies, however, were quick to rebut the concerns, arguing that the probability of everyone using the connection at the same time were negligible. Pre-pandemic, this may have been true (although, there are clearly peak traffic times; e.g., people getting home at ${6}$ and streaming Netflix while they eat dinner). But it certainly wouldn't have been the case during Covid times.

Nevertheless, plenty of people bought the argument, and the ISPs eventually generated enough income to increase their cable bandwidths, to the point where they are now the standard for physical links at the residential access level.⁵

Local Area Networks (LAN)

A local area network (LAN) is a group of computers or other devies that share a wired or wireless link to a nearby edge router. For example, an apartment might provide free WiFi, in which case all of the apartment's residents share the link. Other examples include the computers in a hospital, a university lab, or corporate office. A LAN could have as few as two or three devices (e.g., a resident's WiFi network), or as many as several thousands (a large corporate office).

A common technology associated with LAN is ethernet. For example, some hotels provide an ethernet cable for guests to use. That cable ultimately leads to some router in the hotel, which then leads to an edge router elsewhere. Ethernet connections today support bitrates ranging from ${10 \text{Mbps}}$ to ${1 \text{Gbps}.}$

Wireless LANs are what we're likely most familar with. Wireless LANs are informally called WiFi networks, and more formally called 802.11b/g networks. When WiFi was first released to the public (1999), users saw bitrates of about ${2 \text{Mbps}.}$ Today, we get anywhere from ${100}$ to ${200 \text{Mbps}.}$

Nodes

A node is a network participant that can send, receive, or both send and receive data. There are two types of nodes: (1) end nodes and (2) intermediary nodes. End nodes are the participants that start and end the communication. This includes devices like laptops, smartphones, tablets, printers, VoIP phones, security cameras, wireless debit/credit card reads, barcode scanners, PDAs, fax machines, and so on.

Intermediary nodes are nodes that only forward data from one node to another. Common examples: Switches, bridges, wireless access points, hubs, routers, repeaters, security entities (e.g., Firewalls), cell towers, satellites, and many others.

Links

Also called a medium (plural media), a link is a connection between nodes. There are two types of links: (1) wired links and (2) wireless links. Wired links are said to be guided because they're physically restricted in space. Wireless links, however, are said to be unguided, as they have no such restriction.

Services

The final component of a network is its services — the functionalities that the network can provide. The fact that one network provides a particular service doesn't imply that another network will also provide it. For example, a small peer-to-peer network might provide file sharing services, but not online gaming. The network's services component determines what we can and cannot do on the network.

The overarching service provided by a network is communication infrastructure. It provides a way to transfer data from one system to another, across both time and space. And with the ability to transfer data spatially and temporally, we get distributed applications — web browsing, email, online gaming, e-commerce, file sharing, etc.

Generally, there are two types services in networking: (1) connectionless-unreliable services (CUs) and (2) connection-oriented-reliable services (CORs). CUs are services where the participants do not coordinate their communications before engaging in communication. These services are analogous to paying a bill via USPS's airmail. If ${A}$ wants to pay electric company ${B}$ via mail, ${A}$ merely places the payment in an envelope, stamps it, and drops the letter off at the post office or in a nearby collection box. ${B}$ has no idea that there's money headed their way, but they'll eventually receive it, or they may not.

In contrast, CORs are analogous to paying the bill via Fedex. ${A}$ can set a deadline for when the letter should get to ${B}$ by, and ${A}$ can also receive notice when ${B}$ signs for the letter as received.

Both CUs and CORs have their use cases, much like USPS and Fedex. If we're on vacation in Paris and want to send a postcard to a friend, we likely don't need to go through the hassle of sending it via Fedex. We don't really care when the postcard gets to our friend; in fact we might not care if it gets to them at all. On the other hand, if we were trying to send them a block of Comté, we'd probably want that sent via Fedex.

Both CUs and CORs can only work if we have protocols — ways of responding to some event involving entities, that the entities have agreed to ahead of time. Some protocols are independent, in the sense that the response does not depend on the other entities' responses. For example, exiting a building during a fire drill. There's a route established ahead of time and those involved simply follow the route. Other protocols are dependent; a participant's response depends on the responses of other individuals. For example, crossing a busy a four-way stop. In the U.S., the rule is that the vehicle furthest right moves first. But if that rule isn't followed, the other drivers must yield. Sometimes, the protocol doesn't converge, and we see both drivers pull forward, stop, pull forward, stop, pull foward, stop.

All protocols juggle two fundamental tradeoffs: efficiency and fairness. This problem is best understood via analogy. Suppose we're running a Zoom lecture. What might be the best protocol for asking questions?

One approach is for students to wait, and if no questions are answered, they can proceed to asking. The problem with this approach: On occassion, we'll get students asking questions at the same time. Granted, the probability of a collision might be fairly low.

Another approach is to assign each student a time slot for asking questions. Jill asks questions at 4:00, Tom at 4:05, Kento at 4:10, etc. The problem: Efficiency. Jill and Tom might not have any questions, but Kento has a question that will take more than 5 minutes to ask and respond to. Not only must Kento waste time waiting, he will likely also have break his question down into smaller subquestions and spread them across the lecture's duration.

We might solve this problem by imposing an alternative protocol: If you don't use your time, someone else will use it. The problem with this approach: Now it's no longer fair. Someone might not have used their time because they lost connection, or because the lecturer mistakenly gave way to another student.

Connection-oriented Services

The key characteristic of a COR is that the participants (the sender and receiver) prepare for data transfer ahead of time. To accomplish this, both participants agree to follow a protocol based on COR. One such protocol is TCP. Broadly, TCP imposes the following rules:

1. Data transfers must be reliable.
2. Data must be transmitted as a bytestream, in order.
3. The sender must slow down its sending rate if the receiver isn't fast enough to process all the data it receives.
4. The sender must slow down its sending rate if the network is too congested.

For rule 1, the word reliable has a particular meaning. It does not mean that all of the data from a sender must get to the recipient. TCP does not require its adherents to make that guarantee. No system can ever make that guarantee. Lightning can strike at the wrong time, an anchor can fall on a fiber optic cable, or an engineer in some database might pull the wrong plug. Instead, the word reliable means: "If I fail to send all of the necessary data, or if I don't get all of the necessary data, I will let you know." This is what TCP guarantees.

Under rule 2, TCP guarantees that the data will arrive in the proper order. If we watch the Blackhawks playing against the Capitals, we won't see the Capitals scoring a goal followed suddenly by Patrick Kane kissing the Stanley Cup.

With rule 3, TCP ensures that recipient systems with smaller amounts of memory or processing power don't get overwhelmed by the amount of data they receive. We can see the effects of this problem when we visit sites that cause our browsers to freeze up or run more slowly.

Finally, under rule 4, TCP guarantees that the link the sender and the recipient are on doesn't get too congested. This ensures that the servers forwarding data between the sender and the recipient aren't overwhelmed. Without this rule, a YouTube server might continuously transmit those cat video bytes to a stressed server, to the point where it crashes. Then, not only has our cat video stopped halfway, but so too has the online lecture and potentially hundreds of other applications elsewhere.

Examples of TCP services include web browsing, file transfer, remote login, and email.

Connectionless Services

In contrast to CORs, CUs are characterized by the lack of any communication coordination by two nodes. The most common protocol for CUs is UDP (User Datagram Protocol). This protocol imposes no requirements about reliability, flow control, or congestion control. Examples of UDP services include live-stream media, teleconferencing, DNS, and internet telephony.

If we think carefully about the services that use connectionless protocols like UDP, we might see why we don't want to use a connection-oriented protocol. For example, consider internet telephony (calling someone via the Internet). Under a connection-oriented like TCP, if a byte of data goes missing, the sender might attempt to resend that byte. Thus, when a speaker says: "Hello, is this Dan?" and the sender determines that the "Hello" never made it to the receiver, the sender will attempt a retransmit: "Hello, is this Dan? Hello".

For the other services, a common characteristic is time sensitivity. COR protocols, because of their requirements, have a time overhead for coordination. CUs have no such time overhead — just send and receive data. This level of speed is critical for services like DNS, which must reduce website URLs to IP addresses.

Local Area Networks (LAN)

A LAN is a computer network that interconnects nodes over a limited area. For example, a computer network for a house, hotel, hospital, university building, lab, apartment, or office building.

There are two ways to implement a LAN: A wired LAN or a wireless LAN. With a wired LAN, all nodes are connected to a single switch via some wired link, most commonly an Ethernet cable. For wireless lans, the nodes are all connected to a single switch via a wireless link, e.g., WiFi.

Metropolitan Area Networks (MAN)

A MAN is a computer network that interconnects nodes over a geographic area, usually by connecting LANs, and whose area is usually the size of a city. This network is formed by interconnecting LANs. For a node ${A}$ in Brooklyn, New York, to communicate with a node ${B}$ in Manhattan, then either ${A}$ and ${B}$ are on the same MAN.

Wide Area Network (WAN)

A WAN is a computer network that extends over a geographic region, usually by connecting MANs; and whose area usually covers large swathes of a country (e.g., the East Coast and the West Coast). For example, a node in Los Angeles, California seeking to communicate with a node in Miami, Florida would do so over a WAN.

The Internet

The Internet is a computer network that extends globally, connecting WANs across international borders. For a node in San Francisco, California to communicate with a node in Suva, Fiji, the two nodes must do so over the Internet.

The internet itself is roughly a hierarchical structure. Its primary nodes are the tier-1 ISPs (Internet Service Providers). These are communication companies whose networks stretch across multiple countries (think MCI, Sprint, AT&T, etc.), much like major airlines that fly internationally. Some of these tier-1 ISPs — for example, AT&T — are also the same companies that invest in laying the copper and fiber optic cables connecting countries.

Tier-2 ISPs are network providers that purchase transit — the service of moving packets from their network to another — from tier-1 ISPs. Tier-2 ISPs include Comcast (purchases transit from Tata Communications, an India tier-1 ISP), France Telecom (purchases transit from Sprint), Korea Telecom (purchases transit from U.S.-based Cogent, Sweden-based Telia, and Italy-based Sparkle).

Below tier-2 ISPs are tier-3 ISPs (also called local ISPs). These are ISPs that purchase transit from tier-2 ISPs. Examples include Time Warner, Earthlink, Spectrum, etc. These ISPs are often found providing network access to small neighborhoods or sections of a town/city.

A few things to note about these divisions. First, most ISPs provide customer-facing products. That is, tier-1 ISPs aren't purely in the business of selling transit to tier-2 ISPs, and tier-2 ISPs aren't purely in the business of selling transit to tier-3 ISPs. AT&T, for example, is a tier-1 ISP, but also provides network access to end-users via AT&T Wireless and AT&T Internet. Comcast provides network access to end-users both directly and through Xfinity.

Second, both tier-1 and tier-2 ISPs engage in a practice called peering: a tier-1 ISP will transmit another tier-1 ISP's packets free of charge, and a tier-2 ISP will transmit another tier-2 ISP's packets free of charge. This is not the case for tier-3 ISPs.

Bus Topology

A bus topology looks like:

To transmit data, nodes on a bus topology send the data to single link called the bus or common transmission medium which the sending node and all others are connected to. Because of this property, all other nodes on the bus topology also have access to the data sent. The nodes ${\T_1}$ and ${\T_2}$ are called terminators, and they determine the endpoints of the network.

Bus topologies have costs and benefits:

Of note, bus topologies do not handle traffic well. Because all of the traffic gathers on a single link, data transfer rates can quickly slow to a halt.

Ring Topology

A ring topology appears as follows:

Here, the nodes are connected through a closed loop. As we can likely tell, this is a peer-to-peer network. Moreover, each node has two links: One to each of its nearest neighbors. The data flow is also unidirectional. If node ${H}$ wants to send data to node ${C,}$ that data must pass through nodes ${A}$ and ${B.}$

Because the data flow is unidirectional, ring topologies must provide a way of ensuring that nodes aren't "talking over one another." That is, if a node is receiving data, it can't also be sending data. One way to ensure compliance isi by implementing a variant of the ring topology called the token ring topology. In this variant, there exists a single token that's passed around the nodes. Think of it like a "talking stick." When the node receives the token, only that node has the right to send data. All other nodes must either (1) wait for the stick to get to them, or (2) transfer data if called upon. The token moves around the loop, going to each node one by one.

Comparing the costs and benefits:

For the ring topology, if we have ${n}$ nodes, we require ${n}$ cables, 2 ports per node, resulting in a network with ${2n}$ access points. We can see this is the case by just sampling a few nodes:

Like the bus topology, star topologies do not handle traffic well. Because of their unidirectional nature, a node has no choice but to wait for whatever is in front of it to move along before it can get to the next node.

Star Topology

The star topology looks like:

Here, every node is connected to a central node called a hub or switch, through which all data transfers must pass. This provides a means of centralized management. For example, if node ${E}$ wants to send data to node ${D,}$ it sends the data to ${\S_1,}$ which then forwards that data to ${D.}$

The costs and benefits:

For the star topology, each node, other than the hub, has one port. The hub, however, has a port for each of the nodes. Accordingly, for the star topology, given ${n}$ nodes: ${n}$ cables are needed, yielding a network with ${2n}$ access points.

A key cost to star topologies is traffic handling. Because all of the requests are sent towards a hub or switch, there's always the risk of congestion. With large enough traffic, the hub or switch runs out of available memory, culminating in network failure. That said, compared to the other topologies, star topologies are somewhat better in terms of traffic, since they provide a single point — the hub or switch — for optimizing traffic handling.

Mesh Topology

The mesh topology looks like:

Here, each node is directly connected to every other node in the network. Because of this arrangement, every node has a means of communicating with another node independently.

Mesh topologies are the best at handling traffic. Because each node is connected to every other node, a sending node doesn't have to rely on another node to transfer data.

Hybrid Topology

A hybrid topology is some combination of two or three of the previous topologies. The Internet, for example, is a hybrid topology network.

IPv4

As we said earlier, IP addresses serve as unique identifiers for a node's location. Importantly, IP addresses can change depending on the physical location of the node. For example, say we're at a hotel in Chicago and connect to the WiFi to check our email. When we join the hotel's WiFi network, we're assigned an IP address, perhaps something that looks like:

119.14.102.8

The next day, we head to O'Hare to board our flight. We join the airport's WiFi to again check our email. If we checked our IP address, we'd see that it's changed, perhaps to something like:

149.27.189.5

Because this address can change based on the node's location, IP addresses are sometimes described as a node's logical address. IP addresses can be assigned both manually and dynamically.

Circuit Switching

In circuit switching, a dedicated path is created between the sender and receiver before data transfer. That is, before a data transfer ever occurs, the dedicated path is established first. The classic example is a telephone network. With phone calls, we cannot speak to the node on the other end unless they answer.

Circuit switches are generalized through a 3-phase process:

1. path establishment,
2. data transfer, and
3. path disconnection

Let's examine circuit switching under the client-server model. Suppose node ${A}$ is the client, and the server is ${B.}$ Node ${A}$ wants to read a file hosted at ${B.}$ So, it begins by making an end-to-end call. This is a small message that travels from ${A}$ all the way to ${B.}$ We can think of this message as containing: "Hi, my name is ${A,}$ could you be a node for a path from me to ${B}$?" This message goes from intermediary node to intermediary node, each saying yes or no.

If a node has enough resources to handle the traffic between ${A}$ and ${B,}$ it agrees. Otherwise, it says no. Regardless of whether the node says yes or no, it forwards the message to the next node it thinks will agree. Eventually, the node reaches ${B,}$ and the predetermined path is established. From then on, that path between ${A}$ and ${B}$ is reserved exclusively for ${A}$ and ${B}$ (hence why some nodes will say no).

The benefit to circuit switching: We can make strong guarantees about data departures and arrivals. And if we can make these strong guarantees, data transmissions are not only safer, but faster as well.

Of course, this comes at the cost of efficient resource usage. As long as ${A}$ and ${B}$ maintain a connection, no other data can travel along the path. Even if ${A}$ and ${B}$ aren't sending any data.

Bandwidth Allocation

Note that with circuit switching, it's only the path between ${A}$ and ${B}$ that's exclusive, not the nodes. The nodes might form a separate, unique path between ${C}$ and ${D,}$ exclusive to ${C}$ and ${D.}$ This can only be done if the nodes along the path (the routers) allocate bandwidth between ${A,}$ ${B,}$ ${C,}$ and ${D.}$

The two most common allocation methods are frequency division multiplexing and time division multiplexing.

Frequency Division Multiplexing

In frequency division multiplexing (FDM), the bandwidth is divided according to frequency:

In the diagram above, each color corresponds to a user. The benefit to FDM: Nodes always have a connection. The cost: They only have a fraction of the bandwidth. FDM is the ideal method for applications that:

1. need constant connection, and
2. do not need to transfer large amounts of data at a time

In the context of modern network services, one such application is internet telephony. Voice signals are tiny — just a little less than ${10\text{kHz}.}$ That's not even a megahertz. On the other hand, we want those voice signals transmitted continuously, rather than intermittently.

Time Division Multiplexing

In time division multiplexing (TDM), the bandwidth is divided with according to time:

The benefit to TDM: Connected nodes have access to the full bandwidth and get the fastest possible bitrates. The cost: They only have access at certain times. TDM is ideal for applications that must transfer a large amount of data in a short amount of time.

For modern network services, an example application is viewing a webpage. A typical webpage today hovers around ${2\text{MB}}$ (and they're getting bigger). This requires much more bandwidth to transfer than voice signal. That said, capitalizing on TDM benefits is a balancing act. If the data transferred is too large (say, an entire operating system), if only some of the data is downloaded before the node's time is up, the node must wait until its next turn to get the remaining data. If we add that additional waiting time, the sum time spent downloading via TDM could very well be greater than the time the node would have spent on FDM. This challenge introduces us to two key concepts in networking: throughput and latency.

Throughput & Latency

Throughput is the total number of bits successfully transferred from a source to destination within a specified unit of time. Latency is the time it takes for a specified number of bits to be successfully transferred from one system to another. Note the different notions these terms describe. One measures bits per unit of time, the other measures time per unit of bits. It's imperative to distinguish these two concepts, as they answer two very different questions:

Throughput	Latency
Given a time window from ${t_0}$ to ${t_1,}$ how many bits can I transfer?	Given ${n}$ bits, how long will it take me to transfer them?

To illustrate, consider the following example:

Above, node ${A}$ wants to send 4 bits to node ${B,}$ starting at time ${t_0}$ and ending at time ${t_1}$ (this is the time window). To provide some numeric sense, we'll say the time window is 16 seconds total. ${A}$ has two options to send these bits:

1. Send the four bits via method ${a,}$ such that the bits arrive at ${b}$ in equally-spaced intervals, spread across ${t_0}$ to ${t_1.}$ This method is indicated by the red arrows.
2. Send the four bits via method ${b,}$ where the bits arrive at ${b}$ almost all at once — sort of like a spurt — close to ${t_1}$ (the close of the time window).

Which method should ${A}$ use? Let's compare the two methods. Both of these methods have the same average throughput — 4 bits. The two methods, however, have different average latencies:

$$\left. \begin{aligned} \text{method}~a \\[1em] \dfrac{4+8+12+16}{4}&=\dfrac{40}{4} \\[1em] &=10 \end{aligned} ~ ~ ~ ~ \right\vert ~ ~ ~ ~ \begin{aligned} \text{method}~b \\[1em] \dfrac{11.5+11+10.5+10}{4}&=\dfrac{43}{4} \\[1em] &=10.75 \end{aligned}$$

Note that this is the worst-case scenario for method ${b.}$ If all the bits are sent upfront for ${b}$ instead (i.e., ${t(b_1)=0,}$ ${t(b_2)=0.5,}$ ${t(b_3)=1,}$ and ${t(b_4)=1.5}$), then method ${a}$ would have the higher latency.

This analysis reveals a critical insight: A link's bitrate is insufficient if we want an accurate cost-benefit analysis for different linking options. We can have the fastest possible link, but the true value of that link depends on what we're trying to achieve. If we're just offering a file transfer service and all our link options have the same throughput (perhaps because of rate limiting or network traffic), there's little reason to opt for the more expensive link, since the number of bits transferred per unit of time is the same across all links. If, however, we're offering a service that constantly transmits data (e.g., a game like Counter-Strike), then we should be focusing on latency.

Message Switching

In message switching, data is transferred as a whole unit, moving from node to node, one transfer at a time. For example, given the network:

if ${f}$ wants to send a message to ${c,}$ ${f}$ first transfers its data to ${e.}$ ${e}$ then forwards the data to ${d.}$ ${d}$ then sends the data to ${b,}$ which then sends the data to ${c.}$ As we can likely tell, message switching is not suitable for real-time applications like media streaming and online gaming.

Packet Switching

Packet switching is the switching technique used by the Internet. In packet switching, a message is broken down into small chunks called packets, each sent individually. These packets are labeled with several pieces of information, alongside the actual data transferred:

1. the source IP address,
2. the destination IP address, and
3. a sequence number

We've gone over IP addresses, so what's that sequence number? The sequence number is what allows the receiver to (1) reorder the packets during reassembly, (2) detect missing packets if any, and (3) send acknowledgments.

Packet switching eschews the approach taken by circuit switching: Instead of allocating bandwidth, the router will set up a queue, and all nodes that want to have their packets forwarded must place their packets in the queue. To forward the packets, the router merely dequeues the packets (first in, first out).

The downside to packet switching: There's a great deal of variance. Services like streaming, live online gaming, video conferencing, and internet telephony are inappropriate for packet switching. Their data could get stuck in a long queue somewhere along the path. On the other hand, services like email and web browsing are conducive to packet switching — communications can still be useful even if it isn't perfect.

Packet switching is an instance of statistical multiplexing. The technique is similar to how major airlines sell tickets. Given a flight with 400 seats, the airline might sell 410 tickets. Why? Because the airline bets on the fact that not everyone shows up. Routers along a packet-switched network make a similar bet: That no more than ${x}$ nodes will send data towards it. In light of most web applications, this is a safe bet. However, like the airlines, there are times where everyone does show up. It's during these times that the routers get overwhelmed and packet switching fails spectacularly. Fortunately, those times are fairly rare.

There's another question: What about the path? How is that established? This question leads to the two approaches in packet switching: (1) the datagram approach, and (2) the virtual circuit switching approach.

Costs to Packet Switching

The benefits of packet switching come with a two-fold price tag: packet loss risk and packet delay risk. We examine these two costs below.

$ traceroute google.com
traceroute to google.com (142.251.32.14), 64 hops max, 52 byte packets
 1  10.165.15.254 (10.165.15.254)  3.816 ms  3.920 ms  2.951 ms
 2  162.218.1.57 (162.218.1.57)  3.233 ms  3.519 ms  3.254 ms
 3  198.27.60.164 (198.27.60.164)  3.324 ms  3.975 ms  3.190 ms
 4  xe-2-0-0.cr1.excelsior.as4150.net (66.170.0.72)  4.838 ms  3.732 ms
    xe-0-1-0.cr1.33emain.as4150.net (66.170.0.115)  3.342 ms
 5  ae0-1504.cr1.mngw.as4150.net (66.170.7.105)  8.649 ms
    xe-1-0-0.cr2.excelsior.as4150.net (66.170.9.69)  4.826 ms
    ae0-1504.cr1.mngw.as4150.net (66.170.7.105)  8.785 ms
 6  xe-0-0-1.cr1.cermak.as4150.net (66.170.7.43)  8.924 ms  9.900 ms  9.843 ms
 7  eqix-ch-200g-1.google.com (208.115.136.21)  35.548 ms  9.495 ms  10.692 ms
 8  108.170.243.174 (108.170.243.174)  12.031 ms  299.152 ms
    108.170.243.193 (108.170.243.193)  12.442 ms
 9  142.251.60.23 (142.251.60.23)  15.343 ms
    142.251.60.21 (142.251.60.21)  13.120 ms  15.157 ms
10  ord38s33-in-f14.1e100.net (142.251.32.14)  16.928 ms  20.718 ms  16.791 ms

Layer 1: Application Layer

The data originates in the application layer. This layer is where the user accesses network resources, and it's where the network's user-facing services are found: File transfer and access managment (FTAM), email, VoiceIP, director services, cloud storage upload/download, media streaming, and so on.

Layer 2: Presentation

The presentation layer's purpose is to translate ${n}$ into a format that both ${A}$ and ${B}$ can understand. The new format should allow ${B}$ to answer questions like: What does this bit mean? What does this section of bits mean?

To fullfill that purpose, it provides three services: (1) translation, (2) encryption, and (3) compression. The translation service is a set of modules that convert the data into formats that ${A}$ and ${B}$ can understand. The encryption service is a set of modules that encrypts the data, protecting it from third party access. Finally, the compression service is a set of modules that reduces the number of bits consumed by the data.

Layer 3: Session

${n}$ is then sent to the session layer. The session layer's job is to coordinate all the different data that must be sent to and from the transport layer (recall that there are potentially many different processes).

The session layer offers two key services: (1) dialog control, and (2) synchronization. Dialog control is a set of modules that ensures the communication is between the correct processes on ${A}$ and ${B.}$ For example, if the process in ${A}$ is Snapchat sending a message, the session layer ensures that the message is sent to the Snapchat app on ${B}$ and not some other app.

The synchronization service is a set of modules that ensures the communication is either simplex, half-duplex, or full-duplex. If the communication is simplex, then ${A}$ and ${B}$ can't talk at the same time. If it's half-duplex, then they must take turns talking. And if it's full-duplex, then they're free to talk over each other. Establishing this fact is a critical piece of information for other parts of the systems and the network, as it determines timing and acknowledgment.

Layer 4: Transport

At this point, we know enough to introduce a nuance: When we say that a node on the network communicates with another node, what we really mean is: A process on the network is communicating with another process. As such, we need a layer that can ensure data moves from process to process, rather the more general notion of a "node to node." This is where the transport layer comes in.

The transport layer ensures process-to-process transport of data through several services: (1) segmentation, (2) port addressing, (3) connection control, (4) end-to-end flow control, (5) error control, and (6) reassembly.

The segmentation service is what breaks the data down into the packets we discussed earlier. To ensure those packets get to the right process, the port addressing services attaches to each packet two key pieces of information:

1. the source port number (the port number of the sending process), and
2. the destination port number (the port number of the receiving process)

Moreover, because the recipient may receive the packets at different times, not necessarily in order, the segmentation service also attaches ordinal numbers (i.e., sequence numbers) to each packet, indicating the order in which the packets should be reassembled to construct the original data. That reassembly is done by the reassembly service.

If the link between process ${A}$ and process ${B}$ is connection-oriented, the connection control service performs the call request and call accept methods (mentioned in the packet switching section).

If the sender transmits data faster than the recipient can receive, the end-to-end flow control service establishes an agreement between the two nodes on transmission speed.

Finally, the error control service establishes what constitutes an error or corrupt packet in the transmitted data. This service ensures that the process does not send or receive corrupt or non-network-compliant data. Once thel transport layer has finished its responsibilities, it sends the packets to the network layer.

Layer 5: Network

The network layer's purpose is to ensure that the data from the sending node gets delivered to the destination network. Note the emphasis. This layer doesn't concern itself with a particular process, or a particular node. It's concerned with delivering the data to the network the node is on. This is done through two services: (1) logical addressing and (2) routing.

The logical addressing services attaches to each packet two pieces of information:

1. the source IP address (the IP address of the system where the sending process resides), and
2. the destination IP address (the IP address of the next intermediary node)

The routing service determines the best possible route for transmitting each packet. With the IP addresses inserted and the next receiving node determined, each packet is sent to the data link layer.

Layer 6: Data Link

The data link layer's purpose is to move the packets from one node to the next. This done through five services: (1) framing, (2) physical addressing, (3) flow control, (4) error control, and (5) access control.

The framing service takes each packet and organizes the data into frames. The framing services also attaches two pieces of information:

1. the source MAC address (the MAC address of the system where the sending process resides),
2. the destination MAC address (the MAC address of the next intermediary node), and
3. the gateway node's IP address (the IP address of the next intermediary node).

The flow control service enforces the agreement established by the end-to-end flow control service in the transport layer. It ensures that only a certain amount frames are sent to avoid overwhelming the receiver.

The error control service detects and corrects data frames as they're sent anda received, as dictated by the transport layer. For example, if the transport layer said that it should receive 7 frames total, the data link layer detects whether 7 frames were, in fact, received.

The access control service regulates traffic to a link at a given time. For example, a system with only one WiFi antenna means that processes on the system must take turns using that antenna. The access control service provides a scheduling mechanism for sending and receiving frames through that antenna. Once its a particular process's turn, it sends that process's frames to the physical layer.

Layer 7: Physical

The physical layer is charged with (1) translating the packets into raw bits (0s and 1s) and (2) placing the raw bits on the correct transmission link, or channel. If the link is a metal wire, the physical layer sends the bits as electrical signals. If the link is a fiber optic cable, the bits are sent as light waves. And if the ink is wireless, the bits are sent as radio waves.

The TCP/IP Model

The TCP/IP model consists of four layers: (1) the application layer, (2) the transport layer, (3) the internet layer, and (4) the network access layer. We examine each in turn.

Application. The application layer consists of the data presented to the user, and includes both encoding and dialog control modules.

Transport. The transport layer comprises modules that enable communication between difference devices across different networks.

Internet. The internet layer comprises modules that determine the best path through a network.

Network Access. The network access layer comprises modules that control hardware devices and media that make up the network.

All of the protocols mapped to a TCP/IP layer collectively form the TCP/IP protocol suite. The TCP/IP protocol suite introduces us to some new terminology.

Domain Name Service

When we visit a website, we usually enter the site's URL (e.g., www.google.com). But, as we know, that request needs an IP address. That's where the Domain Name Service (DNS) comes in. DNS is a service that resolves the human-readable name www.google.com into an IP address.

We can see a particular site's IP address with the nslookup command:

nslookup
> www.google.com
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: www.google.com
Address: 142.250.191.132

The nslookup command simply sends a request to the DNS server and asks, "Hey, what's this site's IP address?"

Pinging

Often, we want to know whether a particular site is reachable from our system. We can do so by pinging the site's IP address:

ping 142.250.191.132

64 bytes from 142.250.191.132: icmp_seq=0 ttl=117 time=8.909 ms
64 bytes from 142.250.191.132: icmp_seq=1 ttl=117 time=8.877 ms
64 bytes from 142.250.191.132: icmp_seq=2 ttl=117 time=8.989 ms
64 bytes from 142.250.191.132: icmp_seq=3 ttl=117 time=9.004 ms
64 bytes from 142.250.191.132: icmp_seq=4 ttl=117 time=8.912 ms
64 bytes from 142.250.191.132: icmp_seq=5 ttl=117 time=9.723 ms

--- 142.250.191.132 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.877/9.069/9.723/0.296 ms

We may have noticed the replies steadily coming in one at a time. The ping command basically sends packets to the system whose IP address is 142.250.191.132. The pinged system then responds with acknowledgements. In the example above, we sent 6 packets, and got 6 reply packets back.

If we put some junk IP address:

ping 10.20.34.5

PING 10.20.34.5 (10.20.34.5): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3

--- 10.20.34.5 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

we see the expected result: No acknowledgements, 100% packet loss. Just to demystify things, remember that all of this comes back to links between computers. Suppose we took two computers ${C_1}$ and ${C_2}$ with Ethernet ports, and connected them with an ethernet cable. If we manually set ${C_1}$'s IP address to 15.15.15.1 (purely arbitrary) and did the same for ${C_2}$ with 15.15.15.2, then, on ${C_1,}$ ran the command ping 15.15.15.2, we'd see the same output above.

Path Tracing

We can see the path our packets take with the traceroute command. Below, we run traceroute with Google's IP address:

traceroute 142.250.191.132

traceroute to 142.250.191.132 (142.250.191.132), 64 hops max, 52 byte packets
 1  10.165.15.254 (10.165.15.254)  3.528 ms  4.592 ms  4.402 ms
 2  162.218.1.57 (162.218.1.57)  3.322 ms  3.068 ms  3.109 ms
 3  198.27.60.164 (198.27.60.164)  3.287 ms  4.153 ms  6.255 ms
 4  xe-0-1-0.cr1.33emain.as4150.net (66.170.0.115)  3.907 ms  6.366 ms
    xe-2-0-0.cr1.excelsior.as4150.net (66.170.0.72)  3.703 ms
 5  ae0-1504.cr1.mngw.as4150.net (66.170.7.105)  10.355 ms
    xe-1-0-0.cr2.excelsior.as4150.net (66.170.9.69)  6.212 ms  4.865 ms
 6  162.218.2.51 (162.218.2.51)  18.474 ms  9.085 ms
    xe-0-0-1.cr1.cermak.as4150.net (66.170.7.43)  12.316 ms
 7  * * eqix-ch-200g-1.google.com (208.115.136.21)  9.184 ms
 8  108.170.243.193 (108.170.243.193)  9.780 ms
    108.170.243.174 (108.170.243.174)  10.122 ms  10.445 ms
 9  142.251.60.7 (142.251.60.7)  13.131 ms  15.554 ms  12.976 ms
10  ord38s29-in-f4.1e100.net (142.250.191.132)  8.935 ms  9.267 ms  9.654 ms

On this system, we see that the packet takes 10 hops to get to Google, with a max of 64 hops.

Network Adapter

The network adapter is a chip on system that provides functionalities for connecting with outside systems. We'll take a closer look at the network adapter in a separate section.

Hubs

Hubs (also called network hubs, ethernet hubs, active hubs, or repeater) are devices at the physical layer of the OSI model. Hubs provide a way to establish a LAN. Most commonly, hubs are used to create star topologies.

Each of the hub's slots is a port, to which different nodes on the network can connect. If there are more computers than slots, we can connect another hub to the hub to accomodate the additions.

When a packet arrives at any one of the ports, the packet is copied to all other ports (hence the hub's classification as a repeater). This means that all the other nodes connected to the hub can see the packet. This presents a security risk. Modern hubs mitigate this issue by enforcing protocols where connected nodes are prohibited from viewing messages not labeled with their IP addresses. This approach, however, comes at the cost of easy broadcasting (when a node actually wants all of the others to receive a message).

Additionally, hubs have no memory, since it merely distributes all of the data it receives across its ports. The lack of memory, however, makes hubs fairly cheap devices. For smaller networks, the downsides could very well be offset by the monetary savings.

Switches

Switches are the alternative, and more common device (at the time of this writing) for implementing LANs. The most significant difference between hubs and switches: Switches have memory, and hubs do not.

Switches use this memory to store a MAC address table. On a cheap switch, this is usually a hash table with MAC address entries, and on high-end switches, specialized content-addressable memory (CAM).⁶ Suppose nodes ${A}$ and ${B}$ are connected to a particular switch. ${A}$ is connected to port ${P_1,}$ and ${B}$ is connected to port ${P_7.}$ ${A}$ wants to send a message to ${B,}$ so it sends packets to the switch. After receiving the packets, the switch sees that the packet should be sent to ${B,}$ so it sends the packets only to ${P_7,}$ the port ${B}$ is connected to.

Comparing the hub and the switch:

Routers

Hubs and switches are what we use to establish LANs. But they aren't designed to link systems across long distances. Moreover, there's a limit to how many systems we can link to a hub or switch before we see efficiency losses. If we want systems in Los Angeles to communicate with systems in Seattle, we must use a router — a device that forwards data packets between different LANs, or different WANs, to an ISP network.

Routers are layer 3 devices — they operate at the network layer. This is in contrast to hubs and switches, which operate at layer 1 and layer 2 respectively. Like a switch, routers have memory. They use this memory to store a routing table.

As we know, LANs are created with either hubs or switches. WANs are created with routers. These devices will have their own MAC and IP addresses. When they connect to a router, the router keeps track of their MAC and IP addresses. Thus, we can think of the network created by a hub, switch, or router as having a MAC and IP address.⁷ Suppose we have a router ${R_1}$ which connects two LANs, ${L_1}$ and ${L_2.}$ Suppose further that the LANs have the following MACI and IP addresses:

Let's say a node ${A}$ in ${L_1}$ wants to send a message to node ${B}$ in ${L_2.}$ That message is first sent to ${L_1}$'s switch (or hub). ${L_1}$ receives the message, and sends it to the ${R_1.}$ ${R_1}$ sees the message, and copies it over to its port that ${L_2}$'s router is connected to. ${L_2}$ receives the message, and sends it towards ${B.}$

Comparing switches and routers:

Repeaters

Recall that packets travel from node to node in some medium. The most common media being electrical signals, light waves, or radio waves. Because of thermodynamics, these media weaken or become corrupted as they travel long distances. This is analogous to listening to a lecture in a large lecture hall. Without amplifiers, listeners closer to the lecturer hear clearer than those further.

Repeaters are layer 1 (the physical layer) devices that help alleviate the problems of deterioration. These devices regenerate signals as they travel along the same network. Note the word "regenerate." Unlike amplifiers, repeaters do not amplify signals. Instead, they take signals and reproduce them.

For example, suppose node ${A}$ wants to send signals to node ${B,}$ a node far way in terms of geographic distance. To ensure the signals get to ${B}$ without substantial deterioration, we place a repeater ${r}$ between the two nodes. ${r}$ has two ports: ${r_1,}$ which ${A}$ connects to, and ${r_2,}$ which ${B}$ connects to. When ${r}$ receives ${A}$'s signals through ${r_1,}$ it takes the signals, and repeats them through port ${r_2.}$ We can think of the repeater as a small lighthouse with a tiny person inside, an attendant. When the attendant sees a signal heading towards it on ${r_1}$ (say, flashing lights on-off-on-on-off-on), it pulls out its giant light and repeats the sequence on ${r_2}$ (on-off-on-on-off-on).

Bridges

A special type of repeater is the bridge. Bridges are repeaters with two particular characteristics: (1) they connect two LANs on the same protocol, and (2) they can read MAC addresses. The networks connected to the bridge are called stations. Like general repeaters, bridges only have two ports. Generally, there are two types of bridges: (i) transparent bridges and (ii) source routing bridges.

Transparent bridges are bridges whose stations are unaware of the bridge's existence. That is, the connected networks have no way to determine whether they're connected to the bridge. Transparent bridges have the benefit of not requiring the station's managers from doing anything to connect to the bridge. The networks are simply connected; there's no need to establish the network's default gateway as the bridge.

Source routing bridges require the station managers to specify the default gate way. To send packets to the bridge, the station must specify the route in the packet frames.

Multilayer Switches

Multilayer switches, or layer 3 switches, are link systems that provide the functionalities of a switch, as well as some functionalities of a router. These are fairly recent devices.

Brouter

Brouters are devices that provide functionalities of a bridge as well as the functionalities of a router. Like multilayer switches, these are also fairly recent devices. Brouters have an additional benefit: They can connect different LANs with different protocols, a functionality that traditional bridges don't provide.

Modem

A modem (combination of modulator and demodulator) are devices that (1) transform bits into analog signals, and (2) transform analog signals into bits. The classic example is a a dial-up modem. This device takes bits and outputs acoustic waves that (a) can be decoded by another dial-up modem back into bits, and (b) can travel along a telephone line.

Firewall

The term firewall refers to both software and hardware firewalls. Hardware firewalls are physical devices that filter traffic, often situated between networks. These devices maintain an access control list, a table containing what do for certain requests or IP addresses (e.g., whether th carry out or deny a request, or whether to permit or prevent a packet from proceeding).

Wired Links

Wired links are implemented in various ways:

1. Copper cable (Ethernet cables)
2. Coaxial cables
3. Fiber optic cables

Wireless Links

Wireless links are implemented in numerous ways. The most popular implementations of wireless links:

1. Bluetooth
2. Wifi
3. WiMAX
4. Cellular
5. Satellite

For all wireless links, there are three primary areas of concern: coverage (how far can two linked nodes be separated before the link becomes useless), interference (how well can the link handle eletromagnetic interference), and security (how easy is it for an unauthorized third party to access communications). We'll use these areas to differentiate between the different implementations.

Point-to-Point Connections

In point-to-point connection, ${A}$ and ${B}$ are guaranteed to be on the same link because (1) there exists a dedicated link between ${A}$ and ${B,}$ and (2) the entire capacity of that link is reserved for data transmission between ${A}$ and ${B.}$

Multipoint Connections

In the multipoint connection approach, ${A}$ and ${B}$ are guaranteed to be on the same link because (1) both ${A}$ and ${B}$ are on a single, common link (shared by other nodes). Unlike the point-to-point connection, in a multipoint connection, the link's capacity is shared by ${A,}$ ${B,}$ and all other nodes connected to the link.

Broadly, there are two types of multipoint connections: (a) spatial multipoint connections and (b) temporal multipoint connections. In a spatial multipoint connection, the sharing is done physically. Nodes can join so long as there's an open port to join the link. In a temporal multipoint connection, sharing is done across time. Nodes can only use the link when it's their turn. Otherwise, they do not have a connection.