The Book(s) of Rules

The Book(s) of Rules

To make the world work well, we need lots of standards. To make networks work, we need lots of networking standards and networking protocols. Most of the individual standards and protocols are not terribly complicated, and most are somewhat obvious when you think about it. As I like to tell students when I teach, often times, no one part of networking is that complicated; people like you and me make it up, and the people who create networking standards tend to follow the KISS principle (Keep It Simple, Stupid).

The complication occurs when you implement a modern network that conforms to hundreds and thousands of individual standards and protocols. Those Who Came Before Us created a lot of standards, so if you had to sit down and research each networking product to figure out which of the large number of different standards it implemented, you would be thinking hard about another career! (By the way, "Those Who Came Before Us" is just my way of referring to all the people who created the myriad of existing networking standards.) To keep things under control, Those Same People Who Came Before Us created large groupings of networking standards and made edicts like "Hey, if you use products that conform to this larger combined set of standards, they will all work together." You can think of these large groups of rules as a rulebook; as long as everyone follows the rules in the rulebook, everything works well. For instance, a rulebook might include the following:

• A standard for the cables and connectors

• A standard for using a certain voltage to mean 0 or 1

• A protocol to recover from errors

• A protocol for making requests to send and receive files from a file server

As you might guess, no one really uses the term rulebooks . I just used the term notebooks to make a point. So, what do people really call these sets or groups of standards and protocols? Here are some of the terms:

• Networking blueprint

• Networking model

• Architectural model

• Networking architectural model

• Network architecture

Regardless of which term is used, they all mean the same thing: a networking rulebook. Standards and protocols make an individual part or function of the network work well, and networking models (I'll use this term the rest of the book, instead of the others) list a set of standards and protocols that, when used together, allow computers to communicate.

Next , I'll describe a few details about a couple of types of networking models: proprietary and public.

Proprietary Network Models Prevent Pervasive Population of Networking Devices

Once upon a time, there were no networks and no computers. Then the first computer was created, but because there was no one else to talk to, there was no need for a network! Finally, the second computer was created, and the need for networking was born.

Networks began to be developed as part of each computer vendor's offerings by the late 1960s, and they became popular by the late 1970s. Each computer vendor created its own networking model, which helped computers from that one vendor communicate easily.

At the advent of networking, the two largest computer vendors in the world were International Business Machines (IBM) and Digital Equipment Corporation (DEC). So, IBM created its own networking model called Systems Network Architecture (SNA), and DEC created its own, cleverly named DECnet.

These vendor-proprietary networking models and others like them were goodthey allowed networks to be created and implemented, and they workedbut they weren't perfect. The problem with these proprietary networking models was that they were…proprietary. So, IBM computers could not communicate with DEC computers. Imagine if the same thing had happened with phones; you wouldn't be able to call your buddy if he used a different vendor's phone! Figure 3-4 outlines the problem, and a description of the solution follows.

As you can see, if a company wanted to own some IBM computers and some DEC computers, it had to have separate networks. Although that thought might simply be ridiculous today, imagine that you could only buy Dell PCs because a Gateway PC couldn't talk to a Dell. That was the case with proprietary networking models.

Two solutions emergedone short term, and one long term. The short-term solution, simply put, relates to good, old capitalism : DEC made its computers conform to the IBM SNA model. Why? IBM was roughly 10 times larger at the time in terms of gross revenues . So, DEC created software that converted between DECnet standards and SNA standards. It wasn't pretty, but it worked. Figure 3-5 shows the solution; the next section will get to the long-term solution.

DEC created a DEC-to-SNA gateway, which allowed the DEC and IBM SNA devices to talk. The term gateway refers to a wide variety of networking devices that generally convert from one standard to another. As you can see, a DEC computer simply acted like an IBM computer, using the SNA networking model. DEC just wrote some software, running on a device called a gateway, which converted DECnet to SNA, and vice versa.

Public Network Models Provide Pervasively Popular Networks

The second, better, and long-term solution was to get IBM and DEC (and Apple and Novell and Microsoft and Banyan and Xerox and so on) to stop using their proprietary networking models and use a public, open networking model. Today, we enjoy the results of that transformation. We live in a world in which practically every computer uses the same public network model, called Transmission Control Protocol/Internet Protocol , or TCP / IP . By having all computers use the same networking model, they can all communicate easily.

TCP/IP is just another networking model, but it won out over all the other models. And when I say TCP/IP won, I mean it won big! If you use the Internet, you use TCP/IP. If you send e-mail or text messages from your mobile phone, you use TCP/IP. If you sit at your desk and use a file server, most of the time, you are using TCP/IP. Proprietary models like DECnet and SNA are still used, but far less often than before.

TCP/IP is considered to be a public networking model because no one vendor dictates the standards and protocols, with individuals from many companies and organizations participating in the standards definition process. The Internet Engineering Task Force (IETF) manages the process of creating TCP/IP standards. The IETF, to quote the IETF website, is "a large, open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual" (http://www.ietf.org). Literally, anyoneincluding you and mecan participate in the creation of TCP/IP standards and protocols.

How TCP/IP Standards Grow

As mentioned in the preceding section, the IETF manages the creation and approval of TCP/IP standards and protocols. The core TCP/IP protocol definitions are written in documents called Requests for Comments (RFCs). Each RFC defines some protocol or standard that is important to the TCP/IP model. The term "RFC" comes from the fact that anyone can comment on the protocol while it is being reviewed before it becomes a standard. In fact, the documents are posted on the Internet so that anyone can look at them and comment before they become an RFC.

If you want to see some of the RFCs that comprise the TCP/IP networking model, all you have to do is use…TCP/IP. That's rightif you use a web browser and connect to http://www.rfc-editor.org, you will be at a website that allows you to look at any and all RFCs. Most people learn about TCP/IP by reading other sources (like this book) before reading RFCs, given the highly technical nature of the RFCs. The point is, anyone can read about the standards, understand them, and implement them.

Some Pretty Popular TCP/IP Protocols

It always helps to think about specific examples when learning something new. TCP/IP is composed of a lot of individual protocols. The name TCP/IP is actually a combination of the two most popular protocols inside the TCP/IP model. The next two sections give you a little background on these two protocols.

Transmission Control Protocol (TCP)

TCP provides several features, which are explained in Chapter 9, "Choosing Shipping Options When Transporting Goods over the (Network) Roadway." But thinking about a few details now can help you with the overall concept of TCP/IP. The most memorable feature of TCP is error recovery, which works like the example back in Figure 3-3. Figure 3-3 showed some imaginary protocol used for error recovery. Figure 3-6 shows the same figure, but with details added for TCP.

To perform error recovery, TCP uses a TCP header in front of the user data. Notice that Figure 3-6 shows some rectangles, beginning with the words "TCP Header," followed by " User Data." A header is a bunch of overhead bits added to the user data so that a protocol can do its job. For instance, to perform error recovery, TCP needs to number the packets. To number the packets, TCP needs a place to put the number, so TCP puts the number, called a sequence number , in the TCP header. The TCP header is part of the packet that is sent across the network.

TCP also defines a part of the header to hold the acknowledgment number. TCP uses the acknowledgment number field in the header to tell the sender which packets had errors. Notice that Fred sets the acknowledgment number in the packets he sends back to Wilma. The acknowledgment number lists the next packet Fred expects to receive; for example, when Fred shows an acknowledgment value of 2, it means that he got number 1 and expects to get number 2 next. That's how Wilma knows to send packet number 2 again. This process of referring to the next expected packet, rather than listing the last received packet, is called forward acknowledgment .

This example scratches the surface of what TCP defines. In addition to checking out Chapter 9 of this book, you can retrieve the TCP RFC free from http://www.ietf.org. Just click the RFC Pages link and search for RFC 793.

Internet Protocol (IP)

The Internet Protocol ( IP ) is another TCP/IP standard protocol. IP defines logical addressing and routing for the TCP/IP model.

The best analogy for how IP defines addressing and routing relates to the postal service. Before you put a letter in the mailbox, you put an address on the front. Likewise, before a computer can actually send a packet over the physical network, it must put an address in front of the packet. The address structure is defined by IP, as explained in RFC 791.

The need for IP and for IP addresses is not that obvious in the network with just Fred and Wilma. However, Figure 3-7 makes the need for addressing a little more obvious.

In Figure 3-7, Barney and Fred are both at their homes , and they are excited about looking for the latest in bowling balls from Fred's Company website (www.fredsco.com). So, from their home computers, they each have a browser window open looking at www.fredsco.com.

So that both Fred and Barney can see their web pages, the web server returns packets to both of them. Packets sent to Fred have Fred's IP address in the IP header , and packets sent to Barney have his IP address in the header, as shown in the figure. (Headers are extra bytes that are sent with a packet.) A protocol uses those extra bytes to hold information that the protocol needs to do its job, like the IP addresses inside IP headers.

ISP3's network includes a lot of devices and cables, including routers . (The router icon looks like a hockey puck with arrowed lines on top in the figure.) When the packets sent by the web server get to ISP3's router, the router looks at the IP address and decides where to forward the packet. Packets sent to Fred go to ISP1, and packets sent to Barney go to ISP2.

To know where to forward the packets, the router uses a table, cleverly called the routing table . The routing table works like a road sign by the highway : It tells the traffic which turn to take to reach the right destination.

TCP/IP Standards That Aren't TCP/IP Standards

The IETF numbers new RFCs sequentially. Many of the earlier RFC numbers are no longer used, but you can count on there being several thousand currently active RFCs in the TCP/IP network model.

The people in the IETF tend to be pragmatic. Although many original protocols and standards are needed to make TCP/IP work, other standards bodies might have already defined standards that TCP/IP can easily use. So, the IETF happily reduces its overall workload by referencing other well-known standards created by other standards organizations. This section introduces a couple of the more important standards bodies.

Standards for Physical Networking Nearby

The term local-area network (LAN) defines a type of network, or a part of a larger network, in which the devices are relatively close together. Everyone might have a different opinion about what's close together, but for the sake of discussion, consider "close" to mean in the same building or in the same small campus of buildings . Like any other network, a LAN includes the computers, hardware, software, and cabling that allow communications to happen.

The TCP/IP network model does not define the details of LAN standards and protocols. The Institute of Electrical and Electronic Engineers ( IEEE ) defines standards for LANs, so TCP/IP standards simply say "Use IEEE LAN standards if you want to use a LAN."

For a simple LAN, like the one Wilma set up in Chapter 2, TCP/IP protocols and standards are used, as well as IEEE standards. The IEEE standards for LANs define how the bits are physically transmitted across the LAN. TCP/IP defines the standards and protocols used by the two computers that are connected to the LAN.

The IEEE actually does a lot of work for standards in many different technologies, not just networking. The IEEE works to define most modern LAN standards. The IETF, on the other hand, focuses on any protocol or standard that helps make the entire combined set of networking devices work together. You can think of the IEEE as focusing on particular technology areas, with the IETF looking at a broader set of requirements and using many standards defined by other standards organizations, such as the IEEE.

Standards for Physical Networking Far Away

The term wide-area network (WAN) defines a type of network, or part of a network, in which the devices are relatively far apart. The distance is relative, but for the sake of discussion, consider a WAN to be a network, or part of a network, for which the cabling must pass outside the property of one company. The distance might only be a few miles, or it might be thousands of miles!

For instance, imagine that Fred's company wants to have a connection between one office in Snellville, Georgia and the home office in Mason, Ohio (about 500 miles away). The problem is that Fred cannot just run a cable between the two offices. So, Fred finds a telephone company that gives him a leased line . That leased line helps Fred create a WAN, connecting the two sites, as seen in Figure 3-8.

The cloud in Figure 3-8 represents the telephone company network. That means that there is a lot more to the telephone company's network, but the details aren't important right now. As far as Fred is concerned, the leased line gives him the physical ability to send packets from his office, to the home office, and vice versa. The leased line, and the related equipment, is one way you can implement a WAN.

Just like for LANs, the TCP/IP network model does not define all the details of WAN cabling and logic. The International Telecommunications Union ( ITU ) defines standards for WANs, so TCP/IP standards simply say "Use ITU WAN standards if you want to use a WAN." The ITU focuses on standards that impact how the telecommunications companiesthe phone companiesof the world operate , and like the IEEE, the ITU focuses on a rather large number of specific technologies. The IETF, which defines the protocols included in TCP/IP, makes good use of the standards created by the ITU.