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
As you might guess, no one really uses the
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.
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.
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
Figure 3-4. Non-Networking of IBM and DEC Networks in a Single Company
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,
Figure 3-5. DECnet Emulating SNA Using a Gateway
DEC created a DEC-to-SNA gateway, which allowed the DEC and IBM SNA devices to talk. The term
refers to a wide variety of networking devices that
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,
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.
How TCP/IP Standards Grow
As mentioned in the
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
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.
Figure 3-6. TCP Error Recovery
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 "
TCP also defines a part of the header to hold the acknowledgment number. TCP uses the
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
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.
Figure 3-7. Routing Based on IP Addresses
In Figure 3-7, Barney and Fred are both at their
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
. The routing table works like a road sign by the
TCP/IP Standards That Aren't TCP/IP Standards
The IETF numbers new RFCs sequentially. Many of the earlier RFC
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
Standards for Physical Networking Nearby
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
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.
Figure 3-8. Fred's Alternative to Running a Cable 500 Miles: A WAN Using a Leased Line
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
Just like for LANs, the TCP/IP network model does not define all the details of WAN cabling and logic. The
International Telecommunications Union (
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