feedback is required (most of the feedback is provided in the drafting process). Each RFC is edited, assigned a number, and available to all. Not all RFCs are standards, even those that defi ne protocols. This book will make heavy use of RFCs to explain all aspects of TCP/IP and the Internet, so a few details are in order. RFCs have various maturity levels that they go through in their lifetimes, according to their requirement levels. The RFC life-cycle maturity levels are shown in Figure 1.5. Note that the timeline does not always apply, or is not applied in a uniform fashion. A specifi cation can fall into one of six maturity levels, after which it passes to his- torical status and is useful only for tracking a protocol’s development. Following intro- duction as an Internet draft, the specifi cation can be a: Proposed standard—The specification is now well understood, stable, and sufficiently interesting to the Internet community. The specification is now usually tested and implemented by several groups, if this has not already happened at the draft level. Draft standard—After at least two successful and independent implementations, the proposed standard is elevated to a draft standard. Without complications, and with modifications if specific problems are uncovered, draft standards nor- mally become Internet standards. Internet Draft Internet Standard Historic RFCs Informational RFCs Experimental RFCs Proposed Standard Draft Standard Six months Four months FIGURE 1.5 The RFC life cycle. Many experimental RFCs never make it to the standards track. CHAPTER 1 Protocols and Layers 19 Internet standard—After demonstrations of successful implementation, a draft standard becomes an Internet standard. Experimental RFCs—Not all drafts are intended for the “standards track” (and a huge number are not). Work related to an experimental situation that does affect Internet operation comprise experimental RFCs. These RFCs should not be implemented as part of any functional Internet service. Informational RFCs—Some RFCs contain general, historical, or tutorial informa- tion rather than instructions. RFCs are further classifi ed into one of fi ve requirement levels, as shown in Figure 1.6. Required—These RFCs must be implemented by all Internet systems to ensure minimum conformance. For example, IPv4 and ICMP, both discussed in detail in this book, are required protocols. However, there are very few required RFCs. Recommended—These RFCs are not required for minimum conformance, but are very useful. For example, FTP is a recommended protocol. Elective—RFCs in this category are not required and not recommended. However, systems can use them for their benefit if they like, so they form a kind of “option set” for Internet protocols. Limited Use—These RFCs are only used in certain situations. Most experimental RFCs are in this category. RFC Requirement Levels Required: All systems must implement Recommended: All systems should implement Elective: Not required nor recommended Limited Use: Used in certain situations, such as experimental Not Recommended: Systems should not implement FIGURE 1.6 RFC requirement levels. There are very few RFCs that are required to implement an Internet protocol suite. 20 PART I Networking Basics Not Recommended—These RFCs are inappropriate for general use. Most historic (obsolete) RFCs are in this category. RFCs can be found at www.rfc-editor.org/rfc.html. Current Internet drafts can be found at www.ietf.org/ID.html. Expired Internet drafts can be found at www.watersprings. org/pub/id/index-all.html. INTERNET ADMINISTRATION As the Internet has evolved from an environment with a large student user population to a more commercialized network with a broad user base, the groups that have guided and coordinated Internet issues have evolved. Figure 1.7 shows the general structure of the Internet administration entities. Internet Society (ISOC)—This is an international nonprofit organization formed in 1992 to support the Internet standards process. ISOC maintains and supports the other administrative bodies described in this section. ISOC also supports research and scholarly activities relating to the Internet. Internet Society Internet Architecture Board Internet Engineering Task Force IESG Area Area IRSG Research Group Working Group Working Group Working Group Working Group Research Group Internet Research Task Force FIGURE 1.7 Internet administration groups, showing the interactions between the major components. CHAPTER 1 Protocols and Layers 21 Internet Architecture Board (IAB)—This group is the technical advisor to ISOC. The IAB oversees the continued development of the Internet protocol suite and plays a technical advisory role to members of the Internet commu- nity involved in research. The IAB does this primarily through the two organi- zations under it. In addition, the RFC editor derives authority from the IAB, and the IAB represents the Internet to other standards organizations and forums. Internet Engineering Task Force (IETF)—This a forum of working groups managed by the Internet Engineering Steering Group (IESG). The IETF identi- fies operational problem areas and proposes solutions. They also develop and review the specifications intended to become Internet standards. The working groups are organized into areas devoted to a particular topic. Nine areas have been defined, although this can change: applications, Internet protocols, routing, operations, user services, network management, transport, IPv6, and security. The IETF has taken on some of the roles that were invested in ISOC. Internet Research Task Force (IRTF)—This is another forum of working groups, organized directly under the Internet Research Steering Group (IESG) for management purposes. The IRTF is concerned with long-term research topics related to Internet protocols, applications, architecture, and technology. Two other groups are important for Internet administration, although they do not appear in Figure 1.7. Internet Corporation for Assigned Names and Numbers (ICANN)—This is a private nonprofit corporation that is responsible for the management of all Internet domain names (more on these later) and Internet addresses. Before 1998, this role was played by the Internet Assigned Numbers Authority (IANA), which was supported by the U.S. government. Internet Network Information Center (InterNIC)—The job of the InterNIC, run by the U.S. Department of Commerce, is to collect and distribute information about IP names and addresses. They are at http://www.internic.net. LAYERS When it comes to communications, all of these standard organizations have one primary function: the creation of standards that can be combined with others to create a working network. One concern is that these organizations be able to recommend solutions that are both fl exible and complete, even though no single standards entity has complete control over the entire process from top to bottom. The way this is done is to divide the communications process up into a number of functional layers. Data communication networks rely on layered protocols. In brief, processes run- ning on a system and the communication ports that send and receive network bits are logically connected by a series of layers, each performing one major function of the networking task. 22 PART I Networking Basics The key concept is that each layer in the protocol stack has a distinct purpose and function. There is a big difference between the application layer protocols we’ve seen, such as FTP and SSH, and a lower-level protocol such as Ethernet on a LAN. Each proto- col layer handles part of the overall task. For example, Ethernet cards format the bits sent out on a LAN at one layer, and FTP client software communicates with the FTP server at a higher layer. However, the Ethernet card does not tell the FTP application which bits to send out the interface. FTP addresses the higher-end part of the puzzle: sending commands and data to the FTP server. Other layers take care of things like formatting, and can vary in capability or form to address differences at every level. You don’t use different Web browsers depending on the type of links used on a network. The whole point is that not all networks are Ethernet (for example), so a layered protocol allows a “mix and match” of whatever protocols are needed for the network at each layer. Simple Networking Most programming languages include statements that allow the programmer to send bits out of a physical connector. For example, suppose a programming language allowed you to program a statement like write(port 20$, "test 1"). Sure enough, when com- piled, linked, and run, the program would spit the bits representing the string “test 1” out the communications port of the computer. A similar statement like read(port 20$, STUFF) would, when compiled, linked, and run, wait until something appeared in the buffer of the serial port and store the bits in the variable called STUFF. A simple network using this technique is shown in Figure 1.8. (There is still some software in use that does networking this way.) However, there are some things to consider. Is there anything attached to the port at all? Or are the bits just falling into the “bit bucket”? If there was a link attached, what if someone disconnected it while the bits are in fl ight? What about other types of errors? How would we know that the bits arrived safely? Even assuming that the bits got there, and some listening process received them, does the content make sense? Some computers store bits differently than others, and “test 1” could be garbled on the other system. How many bits are sent to represent the System A (sender) System B (receiver) read (port 20$, STUFF)write (port 20$, “test 1”) Bi ts FIGURE 1.8 An extremely simple network with a distinctly non-layered approach to networking. CHAPTER 1 Protocols and Layers 23 number 1? How do we know that a “short integer” used by the sender is the same as the “short integer” used by another? (In fairness, TCP/IP does little to address this issue directly.) We see that the networking task is not as simple as it seems. Now, each and every networked application program could conceivably include every line of code that is needed to solve all of these issues (and there are even others), but that introduces another factor into the networking equation. Most hosts attached to a network have only one communications port active at any one time (the “network interface”). If an “all-in-one” network application is using it, perhaps to download a music fi le, how can another application use the same port for email? It can’t. Besides the need to multiplex in various ways, another factor infl uencing layers is that modern operating systems do not allow direct access to hardware. The need to go through the operating system and multiplex the network interface leads to a cen- tralization of the networking tasks in the end system. Protocol layers make all of these issues easier to deal with, but they cannot be added haphazardly. (You can still create a huge and ugly “layer” that implements everything from hardware to transport to data representation, but it would work.) As important as the layers are, the tasks and responsibilities assigned to those layers are even more important. Protocol Layers Each layer has a separate function in the overall task of moving bits between processes. These processes could be applications on separate systems, but on modern systems a lot of process-to-process communication is not host-to-host. For example, a lot of printer management software runs as a Web browser using a special loopback TCP/IP address to interface with the process that gathered status information from the printer. As long as the boundary functions between adjacent layers are respected, layers can be changed or even completely rewritten without having to change the whole application. Layers can be combined for effi ciency, “mixed-and-matched” from different vendors, or customized for different circumstances, all without having to rework the entire stack from top to bottom. Nearly every layer has some type of multiplexing fi eld to allow the receiver to determine the type of payload, or content of the data unit at a particular layer. A key point in networking is that the payload and control information at one layer is just a “transparent” (meaningless) payload to the layer below. Transparent bits, as the name implies, are passed unchanged to the next layer. How can protocol layers work together? Introducing a bunch of new interfaces and protocols seems to have made the networking task harder, not easier. There is a sim- ple method called encapsulation that makes the entire architecture workable. What is encapsulation? Think of the layers of the protocol suite in terms of writing a letter and the systems that are involved in letter delivery. The letter goes inside an envelope which is gathered with others inside a mailbag which is transported with others inside 24 PART I Networking Basics a truck or plane. It sounds like a very complicated way to deliver one message, but this system makes the overall task of delivering many messages easier, not harder. For example, there now can be facilities that only deal with mailbags and do not worry about an individual letter’s language or the transportation details. THE TCP/IP PROTOCOL SUITE The protocol stack used on the Internet is the Internet Protocol Suite. It is usually called TCP/IP after two of its most prominent protocols, but there are other proto- cols as well. The TCP/IP model is based on a fi ve-layer model for networking. From bottom (the link) to top (the user application), these are the physical, data link, net- work, transport, and application layers. Not all layers are completely defi ned by the model, so these layers are “fi lled in” by external standards and protocols. The layers have names but no numbers, and although sometimes people speak of “Layer 2” or “Layer 3,” these are not TCP/IP terms. Terms like these are actually from the OSI Refer- ence Model. The TCP/IP stack is open, which means that there are no “secrets” as to how it works. (There are “open systems” too, but with TCP/IP, the systems do not have to be “open” and often are not.) Two compatible end-system applications can communicate regardless of their underlying architectures, although the connections between layers are not defi ned. The OSI Reference Model The TCP/IP or Internet model is not the only standard way to build a protocol suite or stack. The Open Standard Interconnection (OSI ) reference model is a seven- layer model that loosely maps into the fi ve layers of TCP/IP. Until the Web became widely popular in the 1990s, the OSI reference model, with distinctive names and numbers for its layers, was proposed as the standard model for all communication networks. Today, the OSI reference model (OSI-RM) is often used as a learning tool to introduce the functions of TCP/IP. The TCP/IP stack is comprised of modules. Each module provides a specifi c function, but the modules are fairly independent. The TCP/IP layers contain relatively independent protocols that can be used depending on the needs of the system to provide whatever function is desired. In TCP/IP, each higher layer protocol is sup- ported by lower layer protocols. The whole collection of protocols forms a type of hourglass shape, with IP in the middle, and more and more protocols up or down from there. CHAPTER 1 Protocols and Layers 25 The TCP/IP Layers The TCP/IP protocol stack models a series of protocol layers for networks and systems that allows communications between any types of devices. The model consists of fi ve separate but related layers, as shown in Figure 1.9. The Internet protocol suite is based on these fi ve layers. TCP/IP says most about the network and transport layers, and a lot about the application layer. TCP/IP also defi nes how to interface the network layer with the data link and physical layers, but is not directly concerned with these two layers themselves. The Internet protocol suite assumes that a layer is there and available, so TCP/IP does not defi ne the layers themselves. The stack consist of protocols, not implementa- tions, so describing a layer or protocols says almost nothing about how these things should actually be built. Not all systems on a network need to implement all fi ve layers of TCP/IP. Devices using the TCP/IP protocol stack fall into two general categories: a host or end system (ES) and an intermediate node (often a router) or an intermediate system (IS). The User Application Programs Application Layer Transport Layer Network Layer Data Link Layer Physical Layer Network Link(s) FIGURE 1.9 The fi ve layers of TCP/IP. Older models often show only four layers, combining the physical and data link layers. Suite, Stack, and Model The term “protocol stack” is often used synonymously with “protocol suite” as an implementation of a reference model. However, the term “protocol suite” properly refers to a collection of all the protocols that can make up a layer in the reference model. The Internet protocol suite is an example of the Internet or TCP/IP refer- ence model protocols, and a TCP/IP protocol stack implements one or more of these protocols at each layer. 26 PART I Networking Basics intermediate nodes usually only involve the fi rst three layers of TCP/IP (although many of them still have all fi ve layers for other reasons, as we have seen). In TCP/IP, as with most layered protocols, the most fundamental elements of the process of sending and receiving data are collected into the groups that become the layers. Each layer’s major functions are distinct from all the others, but layers can be combined for performance reasons. Each implemented layer has an interface with the layers above and below it (except for the application and physical layers, of course) and provides its defi ned service to the layer above and obtains services from the layer below. In other words, there is a service interface between each layer, but these are not standardized and vary widely by operating system. TCP/IP is designed to be comprehensive and fl exible. It can be extended to meet new requirements, and has been. Individual layers can be combined for implementation purposes, as long as the service interfaces to the layers remain intact. Layers can even be split when necessary, and new service interfaces defi ned. Services are provided to the layer above after the higher layer provides the lower layer with the command, data, and necessary parameters for the lower layer to carry out the task. Layers on the same system provide and obtain services to and from adjacent layers. However, a peer-to-peer protocol process allows the same layers on different systems to communicate. The term peer means every implementation of some layer is essentially equal to all others. There is no “master” system at the protocol level. Communications between peer layers on different systems use the defi ned protocols appropriate to the given layer. In other words, services refer to communications between layers within the same process, and protocols refer to communications between processes. This can be con- fusing, so more information about these points is a good idea. Protocols and Interfaces It is important to note that when the layers of TCP/IP are on different systems, they are only connected at the physical layer. Direct peer-to-peer communication between all other layers is impossible. This means that all data from an application have to fl ow “down” through all fi ve layers at the sender, and “up” all fi ve layers at the receiver to reach the correct process on the other system. These data are sometimes called a ser- vice data unit (SDU). Each layer on the sending system adds information to the data it receives from the layer above and passes it all to the layer below (except for the physical layer, which has no lower layers to rely on in the model and actually has to send the bits in a form appropriate for the communications link used). Likewise, each layer on the receiving system unwraps the received message, often called a protocol data unit (PDU), with each layer examining, using, and stripping off the information it needs to complete its task, and passing the remainder up to the next layer (except for the application layer, which passes what’s left off to the application program itself). For example, the data link layer removes the wrapper meant for it, uses it to decide what it should do with this data unit, and then passes the remainder up to the network layer. CHAPTER 1 Protocols and Layers 27 The whole interface and protocol process is shown in Figure 1.10. Although TCP/IP layers only have names, layer numbers are also used in the fi gure, but only for illustra- tion. (The numbers come from the ISO-RM.) As shown in the fi gure, there is a natural grouping of the fi ve-layer protocol stack at the network layer and the transport layer. The lower three layers of TCP/IP, some- times called the network support layers, must be present and functional on all systems, regardless of the end system or intermediate node role. The transport layer links the upper and lower layers together. This layer can be used to make sure that what was sent was received, and what was sent is useful to the receiver (and not, for example, a stray PDU misdirected to the host or unreasonably delayed). The process of encapsulation makes the whole architecture workable. Encapsu- lation of one layer’s information inside another layer is a key part of how TCP/IP works. Encapsulation Each layer uses encapsulation to add the information its peer needs on the receiving system. The network layer adds a header to the information it receives from the trans- port at the sender and passes the whole unit down to the data link layer. At the receiver, Intermediate System (node) Intermediate System (node) Device BDevice A Application Transport Network Network L3 L2 L1 L3 L2 L1 L3 L2 5 4 3 2 1 5 4–5 Interface 3–4 Interface 2–3 Interface 1–2 Interface 4 3 2 1 L1 Data Link Data Link Physical Application Transport Network Data Link Physical Network Data Link PhysicalPhysical Peer-to-Peer Protocol at Layer 5 Physical Communication Links 2–3 Interface 2–3 Interface 4–5 Interface 3–4 Interface 2–3 Interface 1–2 Interface 1–2 Interface 1–2 Interface Peer-to-Peer Protocol at Layer 4 FIGURE 1.10 Protocols and interfaces, showing how devices are only physically connected at the lowest layer (Layer 1). Note that functionally, intermediate nodes only require the bottom three layers of the model. 28 PART I Networking Basics . in the fi gure, but only for illustra- tion. (The numbers come from the ISO-RM.) As shown in the fi gure, there is a natural grouping of the fi ve-layer protocol stack at the network layer and the. add the information its peer needs on the receiving system. The network layer adds a header to the information it receives from the trans- port at the sender and passes the whole unit down to the. communicates with the FTP server at a higher layer. However, the Ethernet card does not tell the FTP application which bits to send out the interface. FTP addresses the higher-end part of the puzzle: