Internetworking with TCP/IP Volume II: ANSI C Version: Design, Implementation, and Internals,Third Edition by Douglas E. Comer

From the Publisher

97384-2

The Third Edition of this best-seller is a must for anyone working the TCP/IP suite of protocols.

The authors provide an in-depth look at individual TCP/IP protocols in light of design alternatives, implementation techniques with actual ANSI C code, and the internals of protocol software.

This book uses the widely accepted data-mark interpretation of TCP urgent data, a discussion of the consequences is included. Throughout the book the authors use a working system, which they designed and built using ANSI C, to explain the interaction among protocols, the complete implementation process, and the internal structure.

• Reflects changes in the protocol standards and updates the example code to ANSI standard C.
• Contains working source code in ANSI C for most protocols including TCP, IP, ICMP, IGMP, UDP, ARP, RIP, SNMP, and a significant part of OSPF.
• Defines data structures, constants, and code for procedures and processes in ANSI standard C.
• Provides active experimentation with a working TCP/IP implementation.
• Implementation support for the IGMP protocol used for IP multicasting and multicast OSPF routing protocol used in applications such as audio and video multicast.
• Unique coverage of the Open Shortest path First link-state routing protocol designed by the IETF.
• Shows the latest interpretation of the urgent data processing.

Booknews

Supplies details about the Internet protocol suite not covered by the first volume, which deals with principles, protocols, and architecture. Revises the code to use the ANSI-standard C subset of C++, including function prototypes and argument declarations; and updates SNMO to the version two standard, including replacing the address translation table and adding the UDP listener table. The first few chapter could be used in an advanced undergraduate course on networking and the text as a whole for a graduate course that delves into some of the more esoteric aspects of TCP. Annotation c. by Book News, Inc., Portland, Or.

Product Details

• Table of Contents
• Read an Excerpt

Table of Contents

Read an Excerpt

Chapter 5: IP: Global Software Organization

This chapter considers the organization of software that implements the Internet Protocol (IP). While the functionality IP provides may seem simple, intricacies make implementing the software complicated, and subtleties make it difficult to ensure correctness. To help explain IP without becoming overwhelmed with all the parts at once, we will consider the implementation in three chapters. This chapter presents data structures and describes the overall software organization. It discusses the conceptual operation of IP software and the flow of datagrams through the IP layer. Later chapters, which provide details on routing and error handling, show how various pieces of IP software use these data structures.

5.2 The Central Switch

Conceptually, IP is a central switching point in the protocol software. It accepts incoming datagrams from the network interface software as well as outgoing datagrams that higher-level protocols generate. After routing a datagram, IP either sends it to one of the network interfaces or to a higher-level protocol on the local machine.

In a host, it seems natural to think of IP software in two distinct parts: one that handles input and one that handles output. The input part uses the PROTO field of the IP header to decide which higher-level protocol module should receive an incoming datagram. The output part uses the local routing table to choose a next hop for outgoing datagrams.

Despite its intuitive appeal, separating IP input and output makes the interaction between IP and the higher-level protocol software awkward. In addition, IP software, must work in gateways, where routing is more complex than in hosts. In particular, gateway software cannot easily be partitioned into input and output parts because a gateway must forward an arriving datagram on to its next hop. Thus, IP may generate output while handling an incoming datagram. A gateway must also generate ICMP error messages when arriving datagrams cause errors, which further blurs the distinction between input and output. In the discussion that follows, we will concentrate on gateways and treat hosts as a special case.

5.3 IP Software Design

To keep the IP software simple and uniform, our implementation uses three main organizational techniques:

• Uniform Input Queue and Uniform Routing. The IP process uses the same input queue style for all datagrams it must handle, independent of whether they arrive from the network or are generated by the local machine. IP extracts each datagram from a queue and routes it without regard to the datagram's source. A uniform input structure results in simplicity: IP does not need a special case in the code for locally generated datagrams. Furthermore, because IP uses a single routing algorithm to route all datagrams, humans can easily understand the route a datagram will take.

• Independent IP Process. The IP software executes as a single, selfcontained thread of control* Using a process for IP keeps the software easy to understand and modify. It allows us to create IP software that does not depend on hardware interrupts or procedure calls by application programs.

• Local Host Interface. To avoid making delivery to the local machine a special case, our implementation creates a pseudo-network interface for local delivery. Recall that the local interface has the same structure as other network interfaces, but corresponds to the local protocol software instead of a physical network. The IP algorithm routes each datagram and passes it to a network interface, including datagrams destined for the local machine. When a conventional network interface receives a datagram, it sends the datagram over a physical network. When the local interface receives a datagram, it uses the PROTO field to determine which protocol software module on the local machine should receive the datagram. Thus, IP views all routing as uniform and symmetric: it accepts a datagram from any interface and routes it to another interface; no exceptions need to be made for datagrams generated by (or sent to) the local machine.

5.4 IP Software Organization And Datagram Flow

Chapter 2 described the conceptual organization of IP software, and showed datagram flow for both input and output; this section expands the description and fills in details. Recall that IP consists of a single process and a set of network interface queues through which datagrams must be sent to that process. IP repeatedly extracts a datagram from one of the queues, uses a routing table to choose a next hop for the datagram, and sends the datagram to the appropriate network output process for transmission. . . .