How the Internet Works - Part IV - DNS

[This is the fourth in a 4-part post that describes an activity to demonstrate how the internet works. This part describes how the domain names (like "google.com") are translated into IP addresses.]

Some notes on presentation:

This document presents the activity as a rough script with "ACTION" breakouts when you need to perform some task. In this activity, you will be presenting information and directing the students as they act out the various parts of the internet.

You shouldn't just read from this script verbatim (since that will be rather dull), but you will probably want to have this printed out with you while you're presenting. Use a highlighter and mark key points so that you can find them easily while presenting.

Feel free to include additional information if you feel like it and accept questions and ad lib to follow the class interest. Throughout the script, there are a number of questions for the students that can be used to make the presentation more interactive.

The files for this activity (packets, routing tables and labels) can be downloaded from www.cse4k12.org/internet/how-internet-works.html.

[As part of the preparations for this part, remember to cut out holes for the "images" in packets 3-10 and 3-11. Cutting holes makes the lack of images more obvious to students on the other side of the room.]

Domain name lookup

Earlier we temporarily ignored the issue of how we convert a domain name (like google.com) into the IP (Internet Protocol) address (like 74.125.19.104). How does your computer find the address of the wikipedia.org servers?

Let's answer that question now.

Way back in the early days of the internet, every computer connected to the internet had a small "address book" in the form of a hosts.txt file. So you would have something like:

google.com : 74.125.19.104

with an entry for every website that you knew about.

In this example, the number 74.125.19.104 is one of the IP addresses assigned to Google (it has more than one). This is the equivalent of a telephone number for a computer (or any other device) connected to the internet. There's no need to worry about the details of this number, just that it is required to find a computer on the internet.

Having this "address book" file sounds easy enough. But remember, in order for the internet to be useful, you needed to have the address of *every* website in the world, not just a small sample (like you would have in your personal address book).

When the internet was young and small, one computer had the master copy of this address book and whenever there was an update (not very often in the early days), it would send out the updated address book to all of the computers on the internet.

Problem solved, right?

Scalability

At this point, we need to worry about something called "scalability". Scalability refers to how well a solution to a problem handles things "at scale" or when there are a large number of people using it. An approach that works well for 10 people may not be appropriate when there are 10 million people.

ACTION (optional): Do you have a telephone directory for your city? (Does anyone anymore?)

If you do you can hold it up to compare it in size with a small personal address book. And note that the directory only covers one city (or part of one). How big would this book need to be to hold all the telephone numbers in the world?

Our address book solution has a serious scalability problem. It works well enough when there are a small number of computers (a few thousand) on the internet but becomes unmanageable when there are billions of computers being updated all the time.

The internet currently has over 1 billion users and new computers (and smartphones and other devices) are constantly being added, while others are being moved or deleted.

If everyone needed to have a complete and up-to-date copy of this address book, then the majority of internet traffic would be spent sending updated copies of the address book.

So that's not going to work.

How can we have an internet address book that is huge and keep it accurate in the face of being constantly updated?

Domain Name Servers

Before getting into the details of domain name servers, let's start with a phone system analogy:

Imagine that you need to call someone, but you don't know their phone number. What would you do? You'd probably ask a mutual friend if they had the number. And if they didn't, you'd probably keep trying people until you found someone who knew the number.

Now imagine you have a friend that doesn't know anyone else's phone number, but always knows whom you should ask. You'd always get a response like: “I don't know, but ask Mary because she knows”.

That might not sound very useful at first (since they don't know the answer that you're looking for). But with this friend available, instead of guessing and trying friends at random, you could call this special friend first to find out exactly who you needed to call to get the number.

This is basically how domain name servers on the internet work: "What's the IP address for google.com?" "I don't know, but I know someone who does."

DNS Example

On the internet, these "special friends" that can help you find IP addresses are called "name resolvers" and a computer that is dedicated to resolving internet domain names is called a "name server". There are many name servers distributed throughout the internet.

If you look at the ISP node, you'll see a small triangular node attached - this is the name server provided by the ISP. If you want to know the IP address of "google.com" you ask this name server and it responds with the answer. How it gets the answer is rather interesting, so we're going to cover that now.

ACTION: Re-assign the students to play different roles. You'll be re-using the roles from Part III, but you'll be adding 4 more:
   10 : ISP name server — IP address = 65.32.236.240
   11 : root name server — IP address = 198.41.0.4
   12 : .com name server — IP address = 199.19.56.1
   13 : .org name server — IP address = 192.5.6.30
Note that nodes 9 (www.google.com) and 8 (neighbor) aren't used for this part of the activity. 

You'll also be re-using the routing tables from Part III. Note that the google.com and wikipedia.org routing table pages also have name servers.

ACTION: As before, assign 1 more student as a “runner”. This person will propagate the packets through the network. 

Note: There are going to be a lot of packets flying around in this part of the activity. You may want to keep the stack of packets with you and hand them out individually just before they are needed. It's also useful to have the students read out the message part of the packet as they hand it to the runner to send it.

So, how do you ask the name server to lookup an address? You send it a packet:

Packet: (2-1)
From: 65.32.200.101 (you)
To: 65.32.236.240 (ISP name server)
Message: Please lookup "www.google.com"

But wait. Where did we get the IP address of the ISP name server? This is usually set up for you by the ISP when you get internet access set up on your computer. That's your starting point for the rest of the internet.

ACTION: Have the runner take packet 2-1 from "you" (7) to the ISP (4) and then to the ISP name server (10).  [Path: 7 > 4 > 10]

Now, when you ask the name server for the IP address of a domain name, it may not know the answer. Just like it is impractical for you to have an address book that covers the entire internet, it is also impractical for the name servers to have one. But the name server has one important piece of information: it knows whom to ask for the answer.

So, if you ask the name server for the address of www.google.com and it doesn't know the address, it knows it can fall back to use one of the "root name servers".

Extra info [optional]: There are 13 root name server clusters, named 'A' through 'M' that are hosted by various agencies: government, education, military and private corporations. Many of these name servers are not single machines, but actually a cluster spread across multiple locations, sometimes across continents.

Since we're starting from scratch, we assume the ISP name server doesn't know the address www.google.com and will need to send a request to a root name server on your behalf:

ACTION: Have the runner take packet 2-2 from ISP name server (10) to the root name server (11).   [Path: 10 > 4 > 1 > 11]

Packet: (2-2)
From: 65.32.236.240 (ISP name server)
To: 198.41.0.4 (root name server)
Message: Please lookup "www.google.com"

When the root name server gets this request, it looks only at the right-most part of the URL ("com" in this case). This part of the URL is known as the TLD or "top-level domain".

Extra info [optional]: There are many different kinds of TLDs, including generic TLDs (gTLD) like com, edu, mil, gov, org, ... and country code TLDs (ccTLD) like us, uk, fr, jp, ca, ... All the different TLDs are handled the same way.

The root name server doesn't have have the answer, but it does know what should be done with TLDs like com. It responds to the ISP name server's request by sending back a message "I don't know, go ask the .com name server":

ACTION: Have the runner take packet 2-3 from the root name server (11) back to the ISP name server (10).  [Path: 11 > 1 > 4 > 10]

Packet: (2-3)
From: 198.41.0.4 (root name server)
To: 65.32.236.240 (ISP name server)
Message: Go ask 199.19.56.1 (.com name server)

That's the only job of the root name server - to tell you where to find the TLD name servers. Once the root name server responds with the address of the appropriate TLD name server, its job is done.

The nice thing about this arrangement is that if any of the .com name servers (or any TLD name servers) need to move to a new location, only the root name servers need to be updated. Updating a small number of machines is much easier than needing to update every computer on the internet with the new addresses.

Back to our example, after the ISP name server gets the response from the root name server, it sends out another request, this time to the .com name server:

ACTION: Have the runner take packet 2-4 from the ISP name server (10) to the .com name server (12).  [Path: 10 > 4 > 2 > 3 > 12]

Packet: (2-4)
From: 65.32.236.240 (ISP name server)
To: 199.19.56.1 (.com name server)
Message: Please lookup "www.google.com"

And the .com name server sends back a response:

ACTION: Have the runner take packet 2-5 from the .com name server (12) back to the ISP name server (10).  [Path: 12 > 3 > 2 > 4 > 10]

Packet: (2-5)
From: 199.19.56.1 (.com name server)
To: 65.32.236.240 (ISP name server)
Message: Go ask 74.125.45.100 (google.com)

What? Again? This time, it's directing us to go ask "google.com". Since a website can have any number of subdomains (like "www.google.com", "maps.google.com", or "images.google.com"), you need to ask the domain (google.com) where they are located because they can have different IP addresses. The google.com site has its own name server built-in to handle these requests.

So the ISP name server sends out another request, this time to google.com:

ACTION: Have the runner take packet 2-6 from the ISP name server (10) to google.com (5). [Path: 10 > 4 > 1 > 5]

Packet: (2-6)
From: 65.32.236.240 (ISP name server)
To: 74.125.45.100 (google.com)
Message: Please lookup "www.google.com"

And finally gets an answer:

ACTION: Have the runner take packet 2-7 from google.com (5) back to the ISP name server (10). [Path: 5 > 1 > 4 > 10]

Packet: (2-7)
From: 74.125.45.100 (google.com)
To: 65.32.236.240 (ISP name server)
Message: It's 74.125.19.104 (www.google.com)

And now the ISP name server can finally send the answer back to you.

ACTION: Have the runner take packet 2-8 from the ISP name server (10) back to you (7). [Path: 10 > 4 > 7]

Packet: (2-8)
From: 65.32.236.240 (ISP name server)
To: 65.32.200.101 (you)
Message: It's 74.125.19.104 (www.google.com)

And now that you know the IP address of www.google.com, you can finally send your request to Google as we did in Part III (packets 1-1 to 1-4).

Caching

So, what about the next time you need to go to www.google.com? Does it need to look it up again each time? No, just like you recorded your friends phone numbers in an address book to avoid the hassle of asking each time, your computer and each of the name servers remembers the results of the domain name lookups.

This is known as a cache.

If your neighbor (“friend”) asks the ISP name server for "www.google.com" it will be able to answer directly because you already asked and the ISP name server has the answer in its cache.

The only problem with this cache is that, as the internet changes, the data in the cache will become outdated (or "stale"). Thus, the name servers only keep the data in the cache for a limited time (like 2 hours). After that time, the cache entry is erased and it sends the request to the root name server again to get a “fresh” value.

Going to wikipedia.org

So, remember earlier (at the end of Part III) that we got our search results and we're now trying to get to "http://en.wikipedia.org/wiki/Doughnuts". What happens when we click on that link?

Note: Getting the address for wikipedia.org is similar to the process for google.com, so you will likely move through this part fairly quickly.

First, we ask our ISP name server for the address of "en.wikipedia.org".

ACTION: Have the runner take packet 3-1 from "you" (7) to the ISP name server (10).  [Path: 7 > 4 > 10]

Packet: (3-1)
From: 65.32.200.101 (you)
To: 65.32.236.240 (ISP name server)
Message: Please lookup "en.wikipedia.org"

Once again, it doesn't know, so it asks the root name server.

ACTION: Have the runner take packet 3-2 from ISP name server (10) to the root name server (11).  [Path: 10 > 4 > 1 > 11]

Packet: (3-2)
From: 65.32.236.240 (ISP name server)
To: 198.41.0.4 (root name server)
Message: Please lookup "en.wikipedia.org"

The root name server sends back the address of the .org name server.

ACTION: Have the runner take packet 3-3 from the root name server (11) back to the ISP name server (10).  [Path: 11 > 1 > 4 > 10]

Packet: (3-3)
From: 198.41.0.4 (root name server)
To: 65.32.236.240 (ISP name server)
Message: Go ask 192.5.6.30 (.org name server)

Now the ISP name server asks the .org name server:

ACTION: Have the runner take packet 3-4 from the ISP name server (10) to the .org name server (13).  [Path: 10 > 4 > 2 > 13]

Packet: (3-4)
From: 65.32.236.240 (ISP name server)
To: 192.5.6.30 (.org name server)
Message: Please lookup "en.wikipedia.org"

And the .org name server sends back the address of wikipedia.org (which has a name server).

ACTION: Have the runner take packet 3-5 from the .org name server (13) back to the ISP name server (10).  [Path: 13 > 2 > 4 > 10]

Packet: (3-5)
From: 192.5.6.30 (.org name server)
To: 65.32.236.240 (ISP name server)
Message: Go ask 208.80.152.2 (wikipedia.org)

So it asks wikipedia.org's name server.

ACTION: Have the runner take packet 3-6 from the ISP name server (10) to wikipedia.org (6).  [Path: 10 > 4 > 2 > 6]

Packet: (3-6)
From: 65.32.236.240 (ISP name server)
To: 208.80.152.2 (wikipedia.org)
Message: Please lookup "en.wikipedia.org"

And wikipedia.org's name server sends back the answer:

ACTION: Have the runner take packet 3-7 from wikipedia.org (6) to the ISP name server (10).  [Path: 6 > 2 > 4 > 10]

Packet: (3-7)
From: 208.80.152.2 (wikipedia.org)
To: 65.32.236.240 (ISP name server)
Message: It's 208.80.152.2 (en.wikipedia.org)

In this case, the IP address for en.wikipedia.org is the same address as for wikipedia.org. It's OK for the same IP address to have multiple names.

Now that the ISP name server has the IP address for wikipedia, it can send the address back to you.

ACTION: Have the runner take packet 3-8 from the ISP name server (10) to you (7).  [Path: 10 > 4 > 7]

Packet: (3-8)
From: 65.32.236.240 (ISP name server)
To: 65.32.200.101 (you)
Message: It's 208.80.152.2 (en.wikipedia.org)

And you can finally send your request to wikipedia.

ACTION: Have the runner take packet 3-9 from you (7) to the wikipedia.org (6).  [Path: 7 > 4 > 2 > 6]

Packet: (3-9)
From: 65.32.200.101 (you)
To: 208.80.152.2 (en.wikipedia.org)
Message: Please show me "wiki/Doughnut"

And wikipedia can respond by sending the page you requested.  Of course Wikipedia has a lot of information about donuts (doughnuts), so it doesn't all fit in one packet. It sends back 3 packets:

ACTION: Have the runner take packet 3-10 from wikipedia.org (6) to the you (7). [6 > 2 > 4 > 7]

Packet: (3-10)
From: 208.80.152.2 (en.wikipedia.org)
To: 65.32.200.101 (you)
Message: Website for "wiki/Doughnut" (part 1)

ACTION: Since there are 3 packets, you can add 2 more runners for this last part. The students on the .com and .org name server nodes have no more work to do and can easily be repurposed as runners.

ACTION: After the first packet goes out, start damaging the network so that each packet follows a different route. Also, you can stall the second packet so that packet 3-12 arrives before packet 3-11.

Packet: (3-11)
From: 208.80.152.2 (en.wikipedia.org)
To: 65.32.200.101 (you)
Message: Website for "wiki/Doughnut" (part 2)

Packet: (3-12)
From: 208.80.152.2 (en.wikipedia.org)
To: 65.32.200.101 (you)
Message: Website for "wiki/Doughnut" (part 3)

When your browser receives these packets, it is responsible for re-assembling the parts into a single webpage.

As part of the preparation, packets 3-10 and 3-11 should have holes cut in them where the images would be displayed. If a student hasn't already asked about the holes in the document, point them out as you say the following.

See these holes on the page? Each one of them represents where an image to be displayed in the webpage. Each of these images has a URL associated with it and each one needs to be requested separately. If these images are on the wikipedia.org site, then we can request them directly (since we know the IP address), but if they're on a different site then we might have to initiate another name server request to find where we can get the images.

There will likely be a large collective groan at this time as everyone imagines the amount of work needed to gather all the images. This is a sign that the lesson was successful and everyone appreciates the amount of work needed to get a webpage.

Any questions?

[End of part IV]

How the Internet Works - Part III - Routing Traffic

[This is the third in a 4-part post that describes an activity to demonstrate how the internet works. This part describes how the internet routes traffic using IP addresses.]

Some notes on presentation:

This document presents the activity as a rough script with "ACTION" breakouts when you need to perform some task. In this activity, you will be presenting information and directing the students as they act out the various parts of the internet.

You shouldn't just read from this script verbatim (since that will be rather dull), but you will probably want to have this printed out with you while you're presenting. Use a highlighter and mark key points so that you can find them easily while presenting.

Feel free to include additional information if you feel like it and accept questions and ad lib to follow the class interest. Throughout the script, there are a number of questions for the students that can be used to make the presentation more interactive.

The files for this activity (internet packets and labels) can be downloaded from www.cse4k12.org/internet/how-internet-works.html.

Internet

The phone system (even in the very simplified form as described in the previous post), works reasonably well. But the internet differs from a phone network in a few key ways:

1. Packet-based communication. On the internet, data is bundled into self-contained "packets" that are routed through the internet.
2. Automatic address lookup. Every internet-connected device has an IP address, which is similar to a telephone number in that it uniquely identifies a computer on the internet. However, you don't need to know this IP address for the website you're visiting. To visit a website, you can simply type the domain name (like "http://www.google.com") and the correct IP address will be automatically looked up.

We'll look at these two differences in turn — starting with a discussion of packets. Address lookup will be covered in Part IV.

But first, a note on IP Addresses

Currently, an IP ("Internet Protocol") address consists of four 8-bit numbers (ranging from 0 to 255) written in decimal and separated by dots, for example: 74.125.19.104. This 32-bit (4 x 8-bit) number is known as an IPv4 address and it can provide unique IDs for up to 2³² (about 4 billion) computers.

Because the number of devices connected to the internet will soon exceed the number of available addresses in IPv4, a new standard called IPv6 is being introduced. An IPv6 address is 128-bits long and is written as a set of eight 16-bit hexadecimal numbers separated by colons (e.g., 2001:A3D2:32C9:1F37:0000:0000:0000:0000). These new IPv6 addresses can support up to 3.4 x 10³⁸ unique devices.

In this activity, we'll be using IPv4 addresses exclusively because they are easier to work with, but the same concepts presented here also apply to IPv6 addresses.

Packet-based communication

Unlike the traditional landline phone system, the internet is packet based. This means that computers on the internet communicate with each other by sending packets of information back and forth. Think of it as sending tiny electronic letters to each other with the internet acting as the postal service. Large "letters" are not allowed — they must be broken into smaller pieces, sent separately and then reassembled on the receiving end.

As an example, imagine writing a long letter (email) to grandma. You'd have to cut it into (say) 3 pieces, put each piece in a separate envelope (packet), number them (1,2,3), and mail them separately. When your grandmother receives the letter she would wait for all 3 pieces (packets), tape them together and then read the letter. Note that the pieces (packets) might not be received in the correct 1,2,3 order, so she may need to sort them before taping them together.

The advantage of the packet-based system is that doesn't require a dedicated connection (remember the rope in the phone system example). This allows computers to support a very large number of simultaneous connections — receive a packet, respond to it, go to the next packet. Imagine how inefficient it would be if you needed to have a dedicated connection to access every website you wanted to visit. And popular websites like Google or Wikipedia would only be able to support a relatively small number of simultaneous users. In addition, most of the connection capacity would be wasted while the computers waited for the next command/communication. And once people got a connection, they would probably try to hold on to it for as long as possible.

So, how does this work? Basically the same was as the phone network except that we use "routers" instead of "switches". A "switch" (like we saw in the phone network), takes an incoming connection and connects it to its destination. It also needs to maintain this connection for the duration of the call. A "router" accepts a packet of information and then sends it on its way — completely forgetting about it after sending it off. This allows the router to support a much larger number of users than it could otherwise handle.

ACTION: Collect the switching tables from nodes 1-6 and replace them with routing tables. The switching tables can be set aside since they are no longer needed.

Skipping over the issue (for the time being) of how we lookup an IP address from a domain name like "www.google.com", let's follow an internet connection like we did with a phone connection.

We'll start with a very small "internet". In this network, we have the basic elements that we find on the internet:

• Two websites: in this case, google.com and wikipedia.org. In this network, Google is represented by 2 nodes (#5 and #9). In general, large websites on the internet will be distributed across multiple machines.
• Two homes: you and your neighbor
• An ISP: this is your "Internet Service Provider". That's the company that you pay to keep you connected to the internet.
• Three routers: "1", "2" and "3"

ACTION: Relabel the nodes on the graph as you mention them:

4 : ISP — IP address = 65.32.236.122
5 : google.com — IP address = 74.125.45.100
6 : wikipedia.org — IP address = 208.80.152.2
7 : you — IP address = 65.32.200.101
8 : neighbor — IP address = 65.32.200.102
9 : www.google.com — IP address = 74.125.19.104

Note that nodes 1, 2 and 3 don't have labels. These are the “routers”. No need for a label, but they should be referred to as routers during this part of the activity.

ACTION: Assign new students to the graph nodes, or re-assign the students to play different roles. Nodes 6 (wikipedia.org) and 8 (neighbor) aren't used for this part of the activity, so you will only need 7 students for the nodes on the graph + 1 additional student to act as a "runner". This runner will propagate the packets through the network.

As mentioned earlier, we'll start by pretending that we already know the IP address of the website we want to visit. So we already know (somehow) that "www.google.com" has an IP address of "74.125.19.104".

Once we have the IP address of a website, we can send a request to it. These requests are similar to letters in that they have a "TO" and a "FROM" and some content that is being sent.

Here is a sample packet that we're going to send to Google:

• The "FROM" is your IP address.
• The "TO" is the IP address of Google.
• The default content is a generic "Hey, show me your website" request. This is what we commonly refer to as "visiting" a website.

When you want to visit a website, you send your request out so that it gets delivered to the correct website. Since your ISP is your connection to the internet, you sent your request first to your ISP which sends it along to its destination.

ACTION: Have the student at node 7 ("you") give the packet 1-1 to the "runner". The runner should then carry the packet, starting at “you”, to the ISP.

Packet: (1-1)
From: 65.32.200.101 (you)
To: 74.125.19.104 (www.google.com)
Message: Please show me website

The routers operate in much the same way at the phone switches do - except that they use IP addresses instead of telephone numbers to decide what to do.

ACTION: Follow this packet through the various routers, up to node #9: www.google.com.

When Google gets this request (packet), it sends back a response. This response is also a packet, but this time FROM google TO you. Since you didn't ask for anything specific, the contents of the packet are the main search page (the default for this website).

ACTION: Have the runner give the 1-1 packet to the "www.google.com" student at node #9. The website will now process the request and create a new packet to send back. Introduce packet 1-2 at node #9 and have the runner route it back to the user.

Packet: (1-2)
From: 74.125.19.104 (www.google.com)
To: 65.32.200.101 (you)
Message: Website contents (main search page with empty search box)

When you get the response packet, your web browser displays it on your computer screen. You can now interact with the webpage and enter a search term, like "donut", and send another request to Google.

ACTION: Have "you" give packet 1-3 to the runner and send it off.

Packet: (1-3)
From: 65.32.200.101 (you)
To: 74.125.19.104 (www.google.com)
Message: Search for "donut"

But this time, let's see what happens when the network is damaged. Let's pretend that link "Ii" is no longer working.

ACTION: Walk over to the "Ii" link and stand there as a reminder that this link is no longer functioning. Alternately, you can have a student stand there to block network traffic.

As with the phone example, the network routes around the damaged parts. Note that with the packet network, we didn't lose the connection and need to re-start it. The packet was already on its way and simply continued around the damage to reach the destination.

When "www.google.com" finally gets the request, it runs the requested search and creates a new packet with the results to send back.

ACTION: Have "www.google.com" give packet 1-4 to the runner to send back.

Packet: (1-4)
From: 74.125.19.104 (www.google.com)
To: 65.32.200.101 (you)
Message: Search results

If we have more damage to the network...

ACTION: Walk over to link "Dd" to take it out of commission. Make sure the keep "Ii" blocked as well.

...the network will route the packet around the new damage as well.

And eventually the search results come back to you.

So, a question: How long does all this take to run end-to-end? Well, how long do you wait for a webpage to return results before you start to get annoyed that the "internet is slow"? In general, anything that takes longer than 1 second is irritatingly slow.

Setup for part IV

So now we have our search results for "donut". Let's say there's a wikipedia link (http://en.wikipedia.org/wiki/Doughnuts) in the results. What happens when we click on that? And how do we find the wikipedia.org website if we don't know its IP address?

[to be continued in Part IV]

How the Internet Works - Part II - The Phone System

[This is the second in a 4-part post that describes an activity to demonstrate how the internet works. This part contains an introduction and a description of how the (landline) phone system works.]

Some notes on presentation:

This document presents the activity as a rough script. For this activity, you will be presenting information and directing the students as they act out the various parts of the internet.

You shouldn't just read from this script verbatim (since that will be rather dull), but you will probably want to have this printed out with you while you're presenting. Use a highlighter and mark key points so that you can find them easily while presenting.

Feel free to include additional information if you feel like it and accept questions and ad lib to follow the class interest. Throughout the script, there are a number of questions for the students that can be used to make the presentation more interactive.

The files for this part of the activity (routing tables and labels) can be downloaded from www.cse4k12.org/internet/how-internet-works.html.

Introduction

What is the internet? Basically, the internet is just an interconnected collection (a "network") of computers throughout the world. The interesting part of the internet is how the computers are connected with each other. It's easy to connect a small number of computers to each other, but the internet consists of millions of computers.

In order to understand how the internet works (i.e., how these millions of computers interact with each other), it's useful to start with a networking system that you're already (somewhat) familiar with and then compare that system to the internet.

So, let start with a discussion of the phone system.

(Note, we're talking about traditional landline phones here. Cellular phones are different beasts and we don't cover them.)

Phone system

Let's say you want to call someone on the telephone. What do you do?

You somehow get their phone number and dial it. Then the phone system finds the target phone and makes it ring.

This raises 2 questions:

1. How do you know which number is associated with the person you want to call?
2. How does the phone system use the number to find the target phone for that person?

(#1) So, how do you know the phone number?

Well, you ask someone. Either the person you want to call (if they're around), or a mutual friend (if there are any). You can also try the phone book, but people might be unlisted or listed under a different name (like their parent's name).

In addition, when using a phone book that covers an entire city, multiple people might have the same name - what do you do then? You may only know one person named “John Smith”, but there may be a dozen people with the same name in a single city. The phone system uses phone numbers instead of names to avoid this problem.

So, once you get the phone number, you probably write it in your personal address book so that you don't forget it. This address book provides a mapping from “name” to “phone number” for you. Once you write a number in your address book, you don't have to ask around or search for that number again.

ACTION (optional) : Show a small personal address book.

The point of showing this object is to emphasize that each person typically keeps track of a relatively small number of people/phone numbers. Larger phone books will be shown later for comparison.

But what happens if the person moves and gets a new phone number? Well, if they remember, they tell you the new number. But if they don't contact you, then you will still have this old, obsolete number that no longer connects you to that person.

(This is a great way to discover if someone is still your friend ^_^)

(#2) How does the phone system connect calls?

Like most automated systems, the phone system works with numbers.

In this case, you give the telephone system the telephone number it needs to identify the target phone. It then uses this number to set a bunch of switches to make the complete connection.

The exact details of this routing are complex and have evolved considerably over time. In the early days of the phone system, there was a person who manually connected the calls using a plugboard. Nowadays, there are computerized systems that handle the connection automatically.

What we'll do here is present a greatly simplified system that is intended to give a general overview of how this switching works:

ACTION: Assign students and add labels to the nodes in the network graph:

1, 2, 3 : These are switches. No need for labels, but they should be referred to as switches during this part of the activity.
4 : Area code "206" – The next 3 are also switches, but it's convenient to refer to them as "area codes" or "local switches".
5 : Area code "212"
6 : Area code "425" – Only a label is needed here. No need to assign a student to this node since there is nothing for them to do.
7 : "you : (206) 555-1000"
8 : “neighbor : (206) 555-2000”
9 : "friend : (212) 555-3000”

You will need 9 students total: 8 students for the nodes (1-5 & 7-9) plus an additional student to act as a "runner" to help you make the phone connection.

Depending on how everyone is arranged, you may want to have the students sitting down at each node so that everyone can see what's going on. Have them stand up only when they are an active part of the demonstration.

Feel free to change the area codes and numbers, but make sure that you keep the labels consistent with the switching tables.

Each of these nodes has a "switching table" that tells it how to connect phone calls. Simply look up the phone number in the table and it will tell you which link to connect the call to. There's a primary and a secondary column - we're only going to use the primary column for now.

ACTION: Hand out the printed switching tables to the students in nodes 1-5. Node 6 also has a switching table, but it is not used in this exercise so it can be placed on the ground by node 6. This table can be used to extend the exercise if desired.

So, let's pretend that "you" are located in area code "206" and your phone number is "555-1000". If you want to call your neighbor at "555-2000" in the same area code, you simply dial your neighbor's phone number and your request is sent to the local phone company.

ACTION: Using a rope, have the "runner" student start from the "you" node and travel along the "Aa" link to the “206” switch. The rope should trail behind the runner so that it maintains a connection back to the "you" node. The student at the "you" node should pay out the rope as the runner walks away.

When the phone company gets the request, it uses the phone number and the switching table to connect the call.

ACTION: The runner student should approach the "206" node and ask to be connected to "555-2000". The student at the "206" node should look up this number in the switching table and direct the runner down the "Bb" link.

The runner should give a part of the rope for the 206 node to hold and then continue down the "Bb" link. When the runner reaches the destination, the rope should form a connection from the start (“you”) to the end (“neighbor”) nodes through the “206” switch.

Even if you want to call your friend who lives far away in a different area code (212-555-3000), the process is the same: you simply dial the number. The "206" node recognizes that it needs to send this to a different area code when it looks at the switching table.

ACTION: Reset the rope from the previous part and have the runner go back to the "you" node.

Have the runner start again, this time asking to be connected to "(212) 555-3000". As before, have the rope trail out behind the runner and have each visited node hold onto the rope and let it slide through their hand.

The "206" node directs the call down the "Dd" link to switch "1".

ACTION: For each of these connections, have the runner walk from the one node to the next along the path indicated by the switching table. As the runner gets to each node, they need to ask the node where to go next.

Switch "1" directs the call down the "Ii" link to area code "212".

And the "212" node sends the call down the "Pp" link to the friend's phone.

ACTION: At this point the rope should run from "you" (node 7) to "friend" (node 9) going through area code "206" to switch "1" and area code "212".

But what happens if one of the links or if an entire switch goes away?

ACTION: Disable the "Dd" link by "cutting" it. You can actually cut the rope to be dramatic, but it suffices to simply pretend.

What happens? You get "cut off" and the connection is dropped.

If you want, you can call back. And you might get the same connection path if the problem has been fixed. But if the problem has not yet been fixed, you'd like the call to be directed around the problem. For this reason, the switches typically have a primary/secondary path. If there's a problem with the primary path, it uses the secondary.

Let's assume that the problem has not been fixed. Now if you call back, you get a new path around the problem and your call will go through.

ACTION: Reset and start the call over again. Stand in the middle of the "Dd" link as a reminder that it is currently not working.

Now when the "206" node tries to connect the call through the "Dd" link, it fails and it needs to rely on the secondary path "Ee" which leads to switch "2".

Switch "2" sends the call down "Gg" to switch "1".

Where it continues, as before, down the "Ii" link to area code "212" and then down the "Pp" link to the friend's phone.


Notice how the connection is directed around the damaged part of the network. What happens if there is more damage to the network, for example, if the "Gg" link is also disabled? What happens if the entire switch "1" is broken?

ACTION: Remove other links/switches and see how the phone connection is directed around the damage. Have the students experiment with damaging the network. Which nodes are critical to making the connection? How much damage can this network sustain and still be able to connect the phone call?

So that is a (greatly) simplified view of how the phone system connects phone calls. But you may recall that the point of this activity is to demonstrate how the internet works, so we'll get to that in the next part.

[to be continued in Part III]

How the Internet Works (activity for elementary/middle school)

The post is the first installment of a "How the Internet Works" activity which is suitable for upper-elementary and middle school students.

I've been running this activity for the past year or so and have been promising to write it up for a while. With Computer Science Education Week happening this week, it seems like the perfect opportunity to get my act together.

I'll be posting this activity in 4 separate parts:

(1) Overview and setting up
(2) The phone system (switching network)
(3) The internet (routing network)
(4) DNS (Domain Name Server)

Overview

This activity is an interactive demonstration of what happens when you type a URL into a browser.

In this activity the students will be guided to act out the various parts of the internet: websites, routers, name servers, ISPs and home computers. In this activity, students will:

• Learn the difference between a switching (phone system) and routing (internet) network
• See how packets are routed through the internet
• See how the internet routes around damage
• See how domain name servers are used to lookup an IP address

It is designed for 8-13 students, but fewer or more can be accommodated if needed.

Required time

Preparation:

• 30 minutes printing and creating signs
• 1 hour room prep (creating network on the floor using tape)
• plus whatever time you need to familiarize yourself with the material

Activity: 45 minutes

Note: Because of the room preparation required for this activity, you may want to present it multiple times back-to-back to different groups of students.

Materials

You will need the following materials:

• Masking tape/chalk to mark network on floor
  Masking tape is useful indoors, chalk works well on hard surfaces outdoors
  You'll want at least a couple of rolls of masking tape for this
  Alternately, if outdoors, you can use hula hoops and rope to mark the network
  Note that you'll need to attach labels to each rope
• Rope (50' is more than enough)
  This is used to show the phone switched connection
• Manilla folders
  Used to label the network nodes
  You can skip this if you have another way of labelling nodes
• Markers
  To write labels on the masking tape and manilla folders.
• Print out the following:
  Routing tables
  Packets
  Website results
• Scissors (to cut out holes for the “images” from the web page printout)
• Props (optional):
  Small, personal address book
  City phone book (as thick as possible, perhaps have a few from different cities)

Preparations

(1) Draw the network map on the floor

Draw the following network map on the floor using masking tape:



You'll want an open space roughly 20'x20' (6m x 6m) in size for this.

If you're outdoors, you can use chalk or you can use anything else convenient: hula hoops connected by rope would also work. The important thing is that you're able to label each node and link in the diagram.

Make each node (circles/boxes) large enough for a student to stand/sit within. Circles are hard to do with masking tape, so squares are fine (the shape of each node does not matter). Each square should be about 3' (1m) on each side. Nodes 10-13 can be a different shape (like a triangle) if desired.

Make sure there's enough space between each node so that the links between them are easy to see. Ideally it should take from 2-3 steps (~5' or ~1.5m) to go from one node to another.

The graph is easier to make if you start with the 3 central nodes (1, 2, and 3) and label them for identification. Add the other nodes to this core network, but don't label them yet (since they will change function during the activity) – you will make signs for these nodes. See the next section (about creating signs) for information about labeling each of the nodes.

Each of the links between the nodes should be labeled so that they are easy to identify. If using masking tape, write the label directly on the tape.

• Write the label more than once along the tape. At least mark the points closest to each node, but it is preferable to mark all along the tape (separated by ~1' (~30cm)).
• Note that the students will be walking around and viewing the labels from all angles, so make sure that they are easy to read.
• We use both upper-case and lower-case letters to label each link (e.g., "Aa"). This is because the labels will be viewed from all angles as the students walk around and using just upper or lower case letters leads to cases where the labels are ambiguous ("p" vs. "d" or "H" vs. capital "I" with serifs) .

The graph can be stretched and distorted to conform to your environment, but do not change the topology (i.e., don't change the connections between the nodes).

(2) Create signs to place on the internet nodes

Only 3 of the nodes that you just created can be labeled permanently (i.e.: for the duration of the activity): “1”, “2” and “3”. You can label these using tape or chalk or whatever is convenient.

Don't give permanent labels to the other 10 nodes because we need to give them more descriptive names during the presentation (and these names will change during the course of the activity). You should create name tags for these nodes - I just use manilla folders and wrote the node names on them, but you can label them however you see fit.

You will need to create the following 10 signs:

For Part II (phone system):

• “206”
• “425”
• “212”

(or you can choose whichever 3 area codes you like. Just remember to adjust the switching tables to be consistent.)

For Part III (internet):

• “google.com”
• “wikipedia.org”
• “ISP”

(or you can replace these with whichever search engine / web resource you prefer. Just remember to adjust the routing table and all the packets to be consistent.)

For Part IV (DNS):

• “root name server” (rns)
• “.com name server” (.com ns)
• “.org name server” (.org ns)
• “ISP name server” (ISP ns)

(3) Print out the switching/routing tables and internet packets

Print out all of the switching/routing tables and internet packets in the PDF files. They should all be printed single sided.

[Links to these files will be in the following posts.]

(4) Cut out holes for the “images” from webpage in last set of packets

The last set of printouts requires that you cut out the squares where the images should be displayed in the web page.

[to be continued...]