the linux tcp ip stack networking for embedded systems

The Linux TCP/IP Stack: Networking for Embedded Systems by Thomas F. Herbert Charles River Media © 2004 (600 pages) ISBN:1584502843 Written for embedded systems programmers and engineers, as well as networking professionals, this in-depth guide provides an inside look at the entire process of implementing and using the Linux TCP/IP stack in embedded systems projects. Table of Contents The Linux TCP/IP Stack—Networking for Embedded Systems Chapter 1 - Introduction Chapter 2 - Broadband Networking Protocols of Yesterday and Today Chapter 3 - TCP/IP in Embedded Systems Chapter 4 - Linux Networking Interfaces and Device Drivers Chapter 5 - Linux Sockets Chapter 6 - The Linux TCP/IP Stack Chapter 7 - Socket Buffers and Linux Memory Allocation Chapter 8 - Sending the Data from the Socket through UDP and TCP Chapter 9 - The Network Layer, IP Chapter 10 - Receiving Data in the Transport Layer, UDP, and TCP Chapter 11 - Internet Protocol Version 6 (IPv6) Appendix A - RFCs Appendix B - About the CD-ROM Bibliography Index List of Figures List of Tables The Linux TCP/IP Stack—Networking for Embedded Systems Thomas F. Herbert Copyright 2004 by CHARLES RIVER MEDIA, INC. All rights reserved. No part of this publication may be reproduced in any way, stored in a retrieval system of any type, or transmitted by any means or media, electronic or mechanical, including, but not limited to, photocopy, recording, or scanning, without prior permission in writing from the publisher. Acquisitions Editor James Walsh Cover Design The Printed Image CHARLES RIVER MEDIA, INC. 10 Downer Avenue Hingham, Massachusetts 02043 781-740-0400 781-740-8816 (FAX) info@charlesriver.com www.charlesriver.com Thomas Herbert. The Linux TCP/IP Stack: Networking for Embedded Systems. ISBN: 1-58450-284-3 All brand names and product names mentioned in this book are trademarks or service marks of their respective companies. Any omission or misuse (of any kind) of service marks or trademarks should not be regarded as intent to infringe on the property of others. The publisher recognizes and respects all marks used by companies, manufacturers, and developers as a means to distinguish their products. Library of Congress Cataloging-in-Publication Data Herbert, Thomas (Thomas F.) The Linux TCP/IP stack : networking for embedded systems / Thomas Herbert.— 1st ed. p. cm. ISBN 1-58450-284-3 (pbk. with cd-rom : alk. paper) 1. Linux. 2. Operating systems (Computers) 3. TCP/IP (Computer network protocol) A04. Embedded computer systems. I. Title. QA76.73.O63H47 2004 005.4’32—dc22 2004005014 Printed in the United States of America 04 7 6 5 4 3 2 First Edition CHARLES RIVER MEDIA titles are available for site license or bulk purchase by institutions, user groups, corporations, etc. For additional information, please contact the Special Sales Department at 781-740-0400. Requests for replacement of a defective CD-ROM must be accompanied by the original disc, your mailing address, telephone number, date of purchase and purchase price. Please state the nature of the problem, and send the information to CHARLES RIVER MEDIA, INC., 10 Downer Avenue, Hingham, Massachusetts 02043. CRM’s sole obligation to the purchaser is to replace the disc, based on defective materials or faulty workmanship, but not on the operation or functionality of the product. LIMITED WARRANTY AND DISCLAIMER OF LIABILITY THE CD-ROM THAT ACCOMPANIES THE BOOK MAY BE USED ON A SINGLE PC ONLY. THE LICENSE DOES NOT PERMIT THE USE ON A NETWORK (OF ANY KIND). YOU FURTHER AGREE THAT THIS LICENSE GRANTS PERMISSION TO USE THE PRODUCTS CONTAINED HEREIN, BUT DOES NOT GIVE YOU RIGHT OF OWNERSHIP TO ANY OF THE CONTENT OR PRODUCT CONTAINED ON THIS CD-ROM. USE OF THIRD-PARTY SOFTWARE CONTAINED ON THIS CD-ROM IS LIMITED TO AND SUBJECT TO LICENSING TERMS FOR THE RESPECTIVE PRODUCTS. CHARLES RIVER MEDIA, INC. (“CRM”) AND/OR ANYONE WHO HAS BEEN INVOLVED IN THE WRITING, CREATION, OR PRODUCTION OF THE ACCOMPANYING CODE (“THE SOFTWARE”) OR THE THIRD-PARTY PRODUCTS CONTAINED ON THE CD-ROM OR TEXTUAL MATERIAL IN THE BOOK, CANNOT AND DO NOT WARRANT THE PERFORMANCE OR RESULTS THAT MAY BE OBTAINED BY USING THE SOFTWARE OR CONTENTS OF THE BOOK. THE AUTHOR AND PUBLISHER HAVE USED THEIR BEST EFFORTS TO ENSURE THE ACCURACY AND FUNCTIONALITY OF THE TEXTUAL MATERIAL AND PROGRAMS CONTAINED HEREIN. WE HOWEVER, MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, REGARDING THE PERFORMANCE OF THESE PROGRAMS OR CONTENTS. THE SOFTWARE IS SOLD “AS IS” WITHOUT WARRANTY (EXCEPT FOR DEFECTIVE MATERIALS USED IN MANUFACTURING THE DISK OR DUE TO FAULTY WORKMANSHIP). THE AUTHOR, THE PUBLISHER, DEVELOPERS OF THIRD-PARTY SOFTWARE, AND ANYONE INVOLVED IN THE PRODUCTION AND MANUFACTURING OF THIS WORK SHALL NOT BE LIABLE FOR DAMAGES OF ANY KIND ARISING OUT OF THE USE OF (OR THE INABILITY TO USE) THE PROGRAMS, SOURCE CODE, OR TEXTUAL MATERIAL CONTAINED IN THIS PUBLICATION. THIS INCLUDES, BUT IS NOT LIMITED TO, LOSS OF REVENUE OR PROFIT, OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THE PRODUCT. THE SOLE REMEDY IN THE EVENT OF A CLAIM OF ANY KIND IS EXPRESSLY LIMITED TO REPLACEMENT OF THE BOOK AND/OR CD-ROM, AND ONLY AT THE DISCRETION OF CRM. THE USE OF “IMPLIED WARRANTY” AND CERTAIN “EXCLUSIONS” VARIES FROM STATE TO STATE, AND MAY NOT APPLY TO THE PURCHASER OF THIS PRODUCT. Acknowledgments While working on this book, I often thought of this endeavor as a lonely and particularly solitary effort in attempting to unravel this complex and intricate body of software. In fact, though, I have not been alone. Many influenced me to take on this project, and there are many without whom I would not have been able to complete this task. I owe enormous gratitude to the many people who have helped me along the path that led to this book, some of whom are mentioned here. First and foremost, I am indebted to my late parents, George and Dorothy Herbert. My father is my main inspiration. He was a self-taught and very intelligent man with a strong life-long interest in learning, literature, and writing. He brought me up in a house filled with books, and at a very young age, I came to see the value of the printed word. Both my father and my mother always told me that I could do anything and accomplish anything I put my mind to. Whenever I stumble along the way, I remember my mother’s advice that with hard work, courage, and creativity I can achieve any goal in which I believe. I feel some gratitude to the embedded development community, which has been my profession and source of income for most of the last 20 years. There have been a few key people in my business and professional life who guided my path leading to my publishing activities and ultimately to the writing of this book. I first thought about publishing articles about networking in a commercial magazine after talking with Marty Leisner. Marty was a coworker of mine at Xerox in the mid-1990s and an early proponent of the open-source philosophy. In addition, at that time, I polished my writing skills when my manager, Hugo Buitano, would often ask for my assistance to produce “hand crafted” e-mails when a complex and sensitive subject would come up and needed handling accurately but with tact and diplomacy. I should also mention Lindsey Vereen, editor of “Embedded Systems Programming,” who noticed my paper in the conference proceedings and said that it was “well written for a conference paper.” I have enormous respect and am extremely grateful to all of the people involved in the open- source community and the Linux development project. The open-source movement grows in strength all the time and has defined a new way of doing business in our industry. It is opening markets around the world and proving to be an effective counterweight to the monopolistic practices of some major players in our industry. I am indebted to pioneers in the open-source movement such as Richard Stallman, who begin the Free Software Foundation and first used the term free software, meaning freedom to create, modify, and improve. I am particularly indebted to Linux Torvalds, the original developer of the Linux kernel. In addition, there are all the people involved in the long development and improvement of TCP/IP, beginning with the late Jon Postel who was the editor of the RFCs for many years. He authored many of the early RFCs specifying how the protocols written about in this book actually work. For more information about Jon Postel, go to the Postel Center at the University of Southern California, www.postel.org/postel.html. I also am grateful to Gary R. Write and W. Richard Stevens, authors of what is clearly the definitive work about the internal functioning of any TCP/IP implementation. In this book, I hope I am at least coming close to living up to the high standard they have created. Finally, I extend my thanks to the contributors to the Linux TCP/IP implementation. There are too many to mention here, but I must name one person in particular, Alexey Kuznetsov, who has contributed a huge volume of well-documented high- quality professional code to Linux TCP/IP. I have benefited by the association with the highly professional staff at Charles River Media, which started when David Pallai, the president and founder of Charles River Media, first approached me and invited my book proposal. James Walsh, the acquisitions editor, has been with me during the entire process. Jim has been very patient with me as I faced unanticipated problems delaying the work and needed extra time to dig out the bits or follow all the threads through complexities in the code. He has supported me through changes in goals for this project with the addition of IPv6 and the 2.6 kernel. Bryan Davidson, the production coordinator, has been extremely helpful. He took the extra time to answer my arcane formatting questions and showed flexibility as we moved this work through production. I want to acknowledge the work of my reviewers, Jim Lieb and David McLain. Jim’s review of the first part of the book helped me to focus on the practical needs of my readers and the market. I want to extend special thanks to David, who went way beyond the call of duty. His knowledge of the Linux kernel code, computer networking, memory allocation methods, and good software engineering practice was very helpful. He carefully checked all my explanations against the Linux source code and was not shy about pointing out inaccuracies, mistakes, and places where the text needed clarification. Finally, there is my family, particularly my 14-year-old son, Aaron, and my wife of many years, Carol. Both of them have suffered my absences during the creation of this book. They have been very tolerant and patient and I apologize to them for the many hours that I spent hunched over this laptop ignoring their needs. They have been patient with me while tasks went undone and remained so when basketball games and other events were missed while I struggled to meet my deadlines. Carol never stopped believing in my ability to complete this task throughout this 14- month project. Carol is an inspiration to me in so many ways; even when the amount of work seemed overwhelming, she never lost faith in me. Chapter 1: Introduction Overview This book is about the Linux implementation of TCP/IP. Certainly, some of you are eager to dive headfirst into the Linux TCP/IP source code. These readers can go straight to the later chapters beginning with Chapter 4, “Linux Networking Interfaces and Device Drivers,” and proceed from there. It is difficult, however, to discuss any networking topic, including TCP/IP, without first building a foundation or a common basis of discussion. Later in the book, we dive deep into the details of the TCP/IP implementation in Linux. We will show how TCP/IP is very complex but amazingly robust, particularly as a mature and stable implementation such as Linux. It is also a versatile implementation that is suitable for desktop host systems, high-volume servers, and even routers. In this book, we will cover some computer networking theory, but primarily, we assume a general background in data communications. The early chapters of the book provide background in data communications to show how modern implementations of TCP/IP, such as Linux, evolved as the result of changes over many years. Overall, our approach to covering the Linux TCP/IP is practical. Particularly in the later chapters, the discussion is from a developer’s point of view. It is intended to show how Linux TCP/IP is at the apex of the evolution of data communications. As data communication standards and theory change, because of the open source movement, the popularity and flexibility of the Linux operating system make it one of the main platforms to implement data communications. It will be shown how the strength of TCP/IP is in its age and how it has evolved to meet modern needs. TCP/IP has been around for more than 20 years, and the Linux implementation is about 10 years old. The general approach taken in this book is to follow the data as it flows through the networking protocols. Generally, the book is organized to follow a packet as it is sent from a networking application running in a Linux host as it flows through the stack and out the wire. Then it follows the data packet as it is received by another system until it is posted to the application code. Along the way, it shows how packets are routed, how TCP states are maintained, and how the socket interface works. In this chapter, we will show how the Linux sources are organized. Then, we will launch the complex topic of TCP/IP by providing background material in data communication and computer networking protocols. We will talk about the Linux TCP/IP stack in general terms and will present a general background in data communication. Chapter 2, “Broadband Networking Protocols of Yesterday and Today,” follows by going into data communication in more detail. Some significant networking protocols will be explored in a historical context. Although the protocols in Chapter 2 are not directly related to TCP/IP, the discussion will help to build the background needed for the detailed information in later chapters. Chapter 3, “TCP/IP in Embedded Systems,” discusses TCP/IP from the standpoint of the embedded systems engineer. After some general background on network interfaces, Chapter 4 concentrates on Linux network interface drivers and how to interface them to the Linux TCP/IP stack. The socket library is the primary means for application programs to send and receive data using the TCP/IP protocols and Chapter 5, “Linux Sockets,” covers sockets, including how they are implemented in Linux and how applications exchange data with protocols in the kernel using the socket API. Chapter 6, “The Linux TCP/IP Stack,” covers basic elements of the Linux TCP/IP stack, including the glue that holds the stack together. Information about general kernel facilities is included if it is used by TCP/IP. Chapter 7, “Socket Buffers and Linux Memory Allocation,” includes some background on memory allocation for network systems, the Linux slab cache memory allocation system, and the specific slab caches for networking data and protocols. In addition, Chapter 7 explains socket buffers, which are the basic data structures holding packets as they flow through the networking protocols. Chapter 8, “Sending the Data from the Socket through UDP and TCP,” covers the transport protocols, TCP and UDP. It follows the flow of data packets through the transport layer. Chapter 9, “The Network Layer, IP,” is about IP, the network layer protocol. It covers how IP receives a packet from TCP or UDP and hands it off to the device drivers. In addition, it shows how IP receives a packet from the device drivers and queues it to the transport protocols. It includes information about the implementation of the routing tables and how routing decisions are made. Chapter 10, “Receiving Data in the Transport Layer, UDP and TCP,” covers the receive side of UDP and TCP. It follows a packet as it is received from IP and is queued up to the socket for reading by the application code. Chapter 11, “Internet Protocol Version 6 (IPv6),” covers IPv6. It examines which facilities IPv6 shares with IPv4, and shows how the infrastructure for IPv6 is unique. It discusses in detail some of the Linux protocol facilities that are unique to IPv6. Note All request for comments (RFCs) referenced in the book are listed in Appendix A. In addition, for the convenience of the reader, copies of all the referenced RFCs are provided in the companion CD-ROM. 1.1 Introduction The Linux operating system was originally conceived and written by Linux Torvalds with the assistance of many people all over the world. It was intended to be an open source replacement for Unix and is compatible with Unix in almost every respect. The TCP/IP stack is implemented as part of the Linux kernel. It is also compatible with all the applicable Posix standards. Almost all programs written for Unix readily port to Linux without modification. Like the rest of the operating system, the TCP/IP stack was specifically designed for compatibility. In addition, it is completely interoperable with other TCP/IP implementations. It provides a socket interface that is compatible with Berkeley sockets. The code in Linux TCP/IP is very stable, and this is demonstrated by how few changes there are to the TCP/IP code in recent revisions. In this chapter, we will show how the Linux sources are organized and where to find sources that are referenced in this book. Then, we will introduce a brief history of data communication. We will introduce the OSI seven-layer model and how it forms a basis for examining networking protocols of all types. We will discuss connection-oriented and connectionless protocols. Following this will be a discussion of the difference between local area networks (LANs) and broadband or wide area networks (WANs). In this chapter, we will talk about networking standards and provide a guide for navigating among the various standards bodies. 1.2 The Linux TCP/IP Source Code The sources in this book are based on the 2.6.0-test10 kernel release with some patches applied. All sources in this book are covered by the GNU Public License (GPL). For a copy of the license, refer to the CD-ROM included with this book or Appendix B, the CD-ROM.” Copies of the GNU public license can also be obtained at www.gnu.org/copyleft/gpl.html. The 2.6.0-test10 kernel was the most recent stable 2.6 kernel version available at publication time, and the kernel sources were updated with sources from the Linux IPv6 Development Project known as UniverSAl Ground for IPv6 (USAGI). The USAGI project is where the majority of Linux IPv6 development activity is at the time of publication. However, the official 2.6 Linux kernel releases had not yet incorporated the changes from the USAGI project. There is no official stable release of USAGI available yet for the 2.6 kernel at the time of publication of this book. The most recent stable release of USAGI is 4.1 for the 2.4–20 kernel. Therefore, we decided to go into publication with the 2.6.0-test10 kernel sources patched with the USAGI snapshot dated November 24, 2003. The complete patched kernel source tree is provided on the companion CD-ROM. In this section, when we refer to pathnames, we use the term linux to mean the top-level directory in the Linux source tree. For example, if the 2.6 kernel sources are placed in the traditional place for linux kernels, /usr/src, in our case, linux would expand to /usr/src/linux- 2.6.0-test10. In this book, we are concerned primarily with the source and header files related to networking and TCP/IP. The TCP/IP sources are in the linux/net directory. Most of the core networking source files that are not specific to either IPv4 or IPv6 are in the linux/core directory, which contains fundamental networking infrastructure definitions and functions used by both IPv4 and IPv6 and other protocols. The directory linux/net/ipv4 contains IPv4 sources and the protocols TCP and UDP. Most of the IPv6 files are in linux/net/ipv6. The network interface drivers are in linux/drivers/net. In some cases, there is a separate directory in linux/drivers/net for each specific network interface hardware type. Most drivers, like the tunnel pseudo-driver tun.c, are found in the linux/net/drivers directory. The generic device initialization functions and definitions in net_init.c are in linux/net/drivers as well. The companion CD-ROM does not include all the drivers in the Linux source but does have sources for the drivers discussed in this book. 1.3 A Brief History of Data Communication The purpose of data communication is to transport symbolic or abstract information across great distances. The early beginnings of information transmission go back a long way. From the beginning of written history and before, humans have been working on ways to transmit information across great distances. The early methods used visible smoke or light flashes that could be observed by people watching from a distance. From the start, communication methods required ways to represent information as signals or messages that could be understood by both the transmitter and receiver of the information. All the early formal ways of encoding messages involved breaking down the information into some sort of easy-to-represent pattern. Of course, these early patterns were not transmitted electrically. Instead, the messages were transmitted as timed bursts of smoke or flashes of light that could be observed from a great distance. However, despite the simplicity, this was the beginning of the evolutionary process that led to modern electronic and optical data communication. Along the way, each method of data communication improves something but introduces new problems or challenges. Attempts to find solutions to the problems lead to innovations that are incorporated in the next generation of protocols. Recent data communication methods are the result of an evolutionary process that can be traced back to early and primitive nonelectrical methods. 1.3.1 The Evolution of Data Communication Methods Modern data transmission methods actually evolved from primitive methods of signaling used since the earliest days of written history. However, the first common example of the use of electrical data communications was the telegraph. The early telegraphs consisted of a simple on and off modulation of a continuous DC current. When pressed, the telegraph operator’s key connected this circuit. Pressing the key for alternating short and long lengths of time form what was known as “dots” and “dashes.” The dot was a short duration current, and the dash was a longer duration current [ENCBRIT04a]. This system was invented by Samuel Morse in 1832 and came to be known as Morse Code. All methods of data communication in use at that time involved manual intervention. Telegraph operators were trained to key messages onto the wire as fast as possible and to interpret received messages just as quickly. Eventually, however, it became obvious that there was a need for even more rapid interpretation of the telegraph methods. 1.3.2 Coded Transmission and the Printing Telegraph Once telegraph lines began to stretch from town to town, all over the continent and beyond, there was a need for faster and more reliable message transmission. Most of these improvements involved, in one form or another, what was known as a printing telegraph. There were various systems of printing telegraphs tried in the mid- and late nineteenth century. The early printing telegraphs actually printed the dots and dashes on paper as a sequence of lines that could be read by the human eye, but only an experienced telegrapher was able to interpret the printouts. Most of the early methods used in printing telegraphy required the use of multiple circuits, multiple current directions, or some combination of the two. In those early days, the theoretical advantages of different encodings or of using current directions could not be realized. The methods were not practical because of grounding problems in the single-wire circuits. All this was about trying to increase the capacity of the communications channels. Printing telegraphs needed more capacity but were hampered by the scarcity and expense of multiple wires because inter-urban wiring was expensive and required a separate physical wire for each circuit. These limitations inspired the search for a completely automatic mechanism for data communication. Refer to Table 1.1 for a chronology of some of the key events in the early history of data transmission. For excellent source materials and information about the history of telecommunications, visit the North American Data Communications Museum [HOUSE]. Table 1.1: Events in the History of Data Communication Year Protocol Technology Purpose 1844 Telegraph Modulated continuous character Transmission of messages from operator to operator [NEWTON98a]. 1871 Baudot 5-bit code; Represents alphanumeric data. Also known as IA2. Automatic printing telegraph [ENCBRITa]. 1910 Telex Network of automatic printing telegraphs Automatic message transmission through a network of teleprinters [ENCBRITb]. 1962 EBCDIC 8-bit character encoding Used originally on IBM mainframes such as the 360/370 series [WIKIPEDa]. 1964 ASCII 8-bit character encoding Used for encoding human-readable characters in digital transmission [ANSIa]. 1960s PCM Modulation Digitized voice transmission used in North American T-1 and other digital carriers [NEWTON98b]. 1968 IBM Bisync Half-duplex synchronous Data transmission [NEWTON98c]. 1973 Ethernet LAN Local data transmission. Originally invented by Bob Metcalf at the Xerox Palo Alto Research Center [GALENETa]. Standardized as [IEEE802.3]. 1974 IBM SNA Layered protocol network based on Networking and data transmission among IBM computers and remote peripherals. [...]... signaling between the end systems when a call or connection is requested In the TCP/ IP stack, these concepts are incorporated in the transport layer rather than in the data link layer 1.6 Broadband Networking Versus Local Area Networking For the purposes of this book, the term broadband is used synonymously with the term wide area network (WAN) In both the popular press and the engineering press, the term broadband... the common carrier’s equipment and the customer equipment meet X.25 hides the internal function of the PSTN from the customer’s equipment The carrier’s equipment is called data communications equipment (DCE), and the customer’s equipment is called data terminal equipment (DTE) The top layer or network layer of X.25 is called the packet layer The job of this layer is to manage either connections of switched... the viewpoint of TCP/ IP, if the data link and physical layers do their jobs, the details of data transmission are mostly transparent to Layer 3, the network layer, and the layers above Layer 3 If the lower layers don’t do their job, the result will be dropped packets If the data transmission is using the TCP transport protocol, effort will be made to retransmit dropped packets at the lower layers However,... the ISO 8802 series Wireless protocols also provide an Ethernet-like interface to the data link layer They do have Authentication and Authorization (AA) capability, but this function is invisible to the upper layers Essentially, once a user is authenticated, from the TCP/ IP point of view, the wireless LAN provides a simple Ethernet type interface Each machine on the immediate LAN can see all the other... at the start of each telephone call and maintaining the circuit while the call is in progress In the earliest systems, these circuits were real pairs from the bundle or trunk and the circuits were established by a human operator in the telephone company central office, who would physically connect the phones based on the request of the caller[WIKIPEDb] Late in the nineteenth century and early in the. .. LAPB The control field can be either 8 or 16 bits in length Tables 2.5, 2.6, and 2.7 show the format of the Control field for each type of frame Table 2.5 shows the information format This format is used to transmit user data The “I” type frames or information frames are sequenced or numbered frames for providing a connection- oriented service The transmitted frames include sequence numbers, and the. .. 2.5: Information Format 4 5 6 3 n(s) p/f 7 8 n(r) Table 2.6 shows the supervisory format This format is for control functions only, primarily acknowledgment and requests for retransmissions Outgoing information frames are not sequenced, but the n(r) field might contain the number of an acknowledged frame 0 1 2 1 0 Table 2.6: Supervisory Format 3 4 5 sc p/f 6 7 n(r) The format for commands used with the. .. the OSI seven-layer model We illustrated the difference between broadband and LAN protocols and covered networking standards Now, to fully appreciate the TCP/ IP protocol suite and how it came to be so widely used, it is helpful to discuss other networking protocols that influenced the development of TCP/ IP Some protocols in this chapter are included because they are often used to interface to TCP/ IP. .. bandwidth, TCP/ IP is very capable of providing sufficient bandwidth for voice and video applications Moreover, as we will see in Chapter 9, The Network Layer, IP, ” Linux IP can be configured to do routing based on traffic classes ATM interfaces with TCP/ IP where the enterprise network meets the PSTN ATM is too involved to be covered in this book in detail Refer to the bibliography for more detailed information... including multiple planes for data, management, and control ATM is interfaced to IP through ATM Adaption Layer 5 (AAL5) with the use of a Segmentation and Reassembly (SAR) module to build larger IP packets from the smaller ATM cells when they are received at the interface and to break up the IP packets into cells when they are transmitted Refer to Figure 2.6 for a picture of the ATM stack showing how . using the socket API. Chapter 6, The Linux TCP/ IP Stack, ” covers basic elements of the Linux TCP/ IP stack, including the glue that holds the stack together. Information about general kernel facilities. related to networking and TCP/ IP. The TCP/ IP sources are in the linux/ net directory. Most of the core networking source files that are not specific to either IPv4 or IPv6 are in the linux/ core. Contents The Linux TCP/ IP Stack Networking for Embedded Systems Chapter 1 - Introduction Chapter 2 - Broadband Networking Protocols of Yesterday and Today Chapter 3 - TCP/ IP in Embedded