the linux tcp ip stack networking for embedded systems

The Linux TCP/IP Stack: Networking for Embedded Systems Table of Contents The Linux TCP/IP Stack—Networking for Embedded Systems Chapter 1 - Introduction Chapter 2 - Broadband Networking

The Linux TCP/IP Stack: Networking for Embedded Systems

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)

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

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

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 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

open-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 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,

/usr/src/linux-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]

Table 1.1: Events in the History of Data Communication

Year Protocol Technology Purpose

synchronous transmission

This layered networking architecture dominated computer networking before more modern WAN and LAN standards [CISCOa]

1976 X.25 Layered protocol based

on synchronous transmission

Interconnect customer equipment through PSN [X.25]

1.3.3 Character Coded Transmission

In 1874, the French inventor Baudot devised a method of transmitting the characters directly over the circuit rather than having a skilled human operator key the transmissions He came up with what was the first system of encoding Roman characters directly in a telegraph transmission

A skilled telegraph operator would no longer be needed to interpret the dots and dashes in the message His idea, with a few variations, dominated data communications for almost 100 years The invention consisted of a 5-bit code called Baudot code The code used five bits to represent

26 uppercase letters, plus the characters SPACE, CR (Carriage Return), LF (Line Feed), BELL,

and 14 punctuation characters Out of the five bits, two are designated as shift bits, which are

used by the receiving machine to differentiate among groups of characters They are used to differentiate between letters, control characters, and numbers depending on the value represented

by the two shift bits In the first implementations, the Baudot code was punched into paper tape

at the sending machine prior to transmission On the receiving machine it could be directly

punched into paper tape and converted into printed text later using a paper tape reader The tape was punched with holes where a hole represented a digital one and an absence of a hole known

as a space represented a digital zero [ENCBRITa]

The earliest methods of automatic data synchronization required Baudot or some other similar character-coding scheme When it was transmitted, the Baudot bit code was preceded by a start bit and followed by a stop bit These bits were the first system of synchronizing the sending and

receiving machine They were called start and stop bits because the receiving machine was a

mechanical device that would start interpreting bits when the start bit was received, and end its interpretation when the stop bit was received Transmission of each character was separate, and the receiving machine had to wait for the start bit to arrive before beginning to decode the

character and would end the decoding of the character when the stop bit was received On later

machines called teletypes, the reading of the character from the transmission line was done with

an electro-mechanical system This device consisted of a rotating wheel connected by an

electrical clutch to a continuously rotating motor Once a start bit was received, the clutch would engage, the wheel would start rotating, and it would “read” each bit until the stop bit was

received, at which point the clutch would disengage The machine would sit idly humming away

waiting for the beginning of the next character This method became known as asynchronous data transmission Some of you who have actually seen an old teletype machine will notice that

the data rate is slow enough that the character reception can be observed Notice that the wheel starts rotating with the beginning of the train of bits, and stops at the end As each bit is

interpreted, the machine aligns a group of electromagnets to rotate the print wheel to the correct position to print the received character after the stop bit is received and the wheel stops turning

1.3.4 Measuring Data Communication Speeds

For many years, data communication speed was measured in baud rate rather than bits or words

per second The origin of this word has an interesting history The word baud is actually short for

Baudot, who invented the 5-bit code that became known as Baudot code This code was used for many years in telegraphy Baud rate is a way of measuring the speed of asynchronous (character-oriented) data transmission People often incorrectly use this term as if it were synonymous with character transmission rate provided by any type of data transmission Baud rate is actually the number of 0 to 1 state transitions per second This concept does not directly calculate out as characters per second Characters per second can’t be determined precisely by dividing the baud rate by the number of bits per character This is because baud rate includes overhead due to the presence of the stop and start bits To translate baud rate to character rate, you have to take into account the number of bits used to encode each character For example, data transmission was at one time limited to at most 110 baud, which was the fastest rate at which the electro-mechanical teletypewriters could receive the transmission However, the maximum character rate was really much less than 10 characters per second because the 110 baud number includes overhead for the start and stop bits in addition to the 8-bit characters

1.3.5 Data Transmission Over the Telephony Voice Network

The telegraph was in common use for less than 20 years when the telephone was invented in

1876 Then, for more than 100 years from 1876 until at least 1976, the primary user of distance bidirectional information exchange of any type was voice telephony The familiar system of telephones and voice transmission is known as the Plain Old Telephone System

long-(POTS), where the voice signal was transmitted by analog modulation of a carrier tone This system is based on assigning a real twisted pair of wires, or later a conceptual circuit, 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 twentieth century, the number of telephones started to grow rapidly There were too many phone calls to establish the connections by hand A faster method was needed to construct the circuit connecting the phones engaged in the call The improved method was a mechanism to make and break the circuit repeatedly, the dial or pulse

generator When a caller dials the phone, a sequence of pulses is emitted called dial pulses Now,

instead of patch panels, the circuit can be created automatically by electromechanical equipment

at each switching point between the two phones This switching point is called a central office

The request to construct the circuit begins at the central office nearest to the phone initiating the call Relays at the central office forward the request to the next switching station by coupling the input circuit to a specific outgoing circuit, extending the circuit to the next switching station, and eventually to the called party The first telephone switch was known as the Strowger Switch after Almon Strowger [RBHILL]

1.3.6 Multiplexing Data Communication Channels

It is interesting to note that early developments in nineteenth-century mathematics form a basis for twentieth-century data communications theory This is not a single event that can be placed in the timeline presented in Table 1.1, but instead is a critical evolutionary step toward the

development of mid-twentieth-century developments in data communication The theory shows that a waveform can be thought of as a periodic continuous function This complex waveform or

function can be represented by a series of trigonometric functions called the Fourier series The

nineteenth-century French mathematician, Joseph Fourier (1768–1830), developed this idea during his search for a solution for a partial differential equation describing heat diffusion This

is called the Fourier series and allows a continuous function or waveform to be thought of as

component sinusoidal functions The Fourier transform converts the complex function into its

components Application of Fourier transform allows the breaking up of available bandwidth of a carrier to individual components or channels [GALENETb]

Eventually, as technology progressed, voice traffic was aggregated onto common lines called

trunks, named after the cables of bundles of twisted pairs of wires These new trunks were using

Frequency Division Multiplexing (FDM) With the FDM method, an analog broadband carrier is modulated with separate bands of 3-KHz voice channels with a 1-KHz separation Along with FDM came automatic switching equipment that instead of using electromechanical relays could electronically switch circuits using Dual-Tone Multi-Frequency (DTMF) tones generated by

“touch-tone” phones

As computers and peripheral equipment became more spread out, there was increasing interest in data communications A need was becoming prominent for a method of data transmission that could use the ordinary and ubiquitous POTS lines If telephone lines could be used for data transmission, data could be sent from or received anywhere there was an available telephone connection, and telephones were becoming ubiquitous The first modems were developed in the late 1960s They modulated the 3-Khz voice band with digital data Modems permitted data to be transmitted through long distance lines with inductive loading characteristics The digital signals could then be sent over lines originally intended only for transmission of analog voice signals The first commercially available modems for use with POTS could transmit at only 300 baud

Modems got their name because they originally were responsible for the modulation and

demodulation of the analog frequency with digital data Modems modulate the voice band with

data that is encoded as sequences of 8-bit characters This encoding could be in various methods, but in modern use is almost always ASCII, which is very similar to the 5-bit Baudot code used since the telegraph era [ENCBRITc] [ITUTTV21]

Chapter 2, “Broadband Networking Protocols of Yesterday and Today,” includes more detail about synchronous and asynchronous data communication methods in the discussion about broadband and WAN protocols We will see how asynchronous data transmission could be sent digitally directly across carriers without using a modem to convert it into an analog signal

However, because for many years direct digital lines were not available everywhere, modems continued to be widely used In addition, new modem standards became available and allowed for faster transmission of data

1.4 The OSI Seven-Layer Network Model

The Open System Interconnect (OSI) seven-layer model [OSI7498] was first specified in the early 1980s Although neither traditional nor modern networking protocols fit neatly into this model, it has been the common framework to discuss and explain networking protocols for over

20 years The layered model is often called a stack because each layer in the sending computer in

effect has a logical relationship with the corresponding layer in the receiving machine See Table 1.2 for an illustration of the seven-layer model

Table 1.2: The OSI Seven-Layer Model

Layer Number Layer Name

1.4.1 The OSI Lower Layers

The lowest layer, Layer 1, is the physical layer It is concerned with the lowest level of detail

about data transmission This layer worries about issues such as how to indicate the presence of a one bit versus a zero bit on the physical media It also deals with electrical signal levels and other

details related to physical transmission The next layer up, Layer 2, is the data link layer The

data link layer is primarily responsible for establishing and maintaining connections or providing connectionless service It is concerned with how the two endpoints will establish a

communication It also deals with framing or how to differentiate user or payload data from

control data It contains a way for machines to identify each other, generally called station IDs or Media Access Control (MAC) addresses The next layer up, Layer 3, is the network layer It is

responsible for how nodes on the network are named or addressed It is concerned with network topology and how to route packets from one node to another As with the data link layer, the network layer has address information, too However, network addresses are more abstract; they have to do with network topology and at least theoretically are not tied to a particular physical

interface The next layer up, Layer 4, or the transport layer, provides a way for data to be

collected or aggregated for passage across the network In addition, the transport layer provides a simple programming interface to users at higher layers so they don’t have to deal with the

network details of Layer 3 or lower In the world of TCP/IP, we think of the transport layer interface as providing two types of interfaces The first is a streaming interface where the user can send and receive data as a continuous stream of bytes The other interface provides a

chunked or datagram interface to the user where the user must break up the data into discrete packets before sending

1.4.2 The OSI Upper Layers

The higher layers are often thought to be part of the application Layer 5, the session layer, is

primarily about managing access and session control of a user on one machine who wants to

access another machine Layer 6, the presentation layer, is for abstract data representation Data

in network representation is mapped to the user’s view so the application need not worry how the data looks when it is stored on a different machine Architectural details of data representation in

a particular machine are removed at this layer The uppermost layer, Layer 7, is the application

layer Only pure OSI-compliant networking protocols think of this as a separate layer It is

important to point out that the upper layers—Layers 5, 6, and 7—are not part of the TCP/IP stack (See Chapter 3 for a discussion of the upper layers and their relation to the TCP/IP stack.)

1.5 Connection-Oriented and Connectionless Protocols

WAN or broadband protocols are typically connection oriented WANs evolved from the

exploitation of spare capacity of the Public Switched Telephone Network (PSTN) The public network was originally intended to carry voice traffic; therefore, the connections are actually virtual circuits that were intended to provide a path for voice traffic between telephones Before individual packet-switching service was available through the PSTN, each time data was

transmitted between two machines a provisioned connection had to be set up first The

connections used in broadband networks are called virtual circuits (VCs) There are two types of

VCs: permanent virtual circuits (PVCs) are provisioned and maintained as static connections Switched virtual circuits (SVCs) are set up through 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 is

generally used to differentiate the slower POTS-based dial-up line from a faster digital

subscriber line (DSL) or cable modem There is one important differentiating factor between local area networks (LANs) and WANs Every machine on a LAN can see every other machine However, on WANs, the connections are virtual circuits They are set up either specifically as point-to-point connections between two machines or as multicast connections of one-to-many LANs and WANs can also be differentiated by the role played by the data link layer of the OSI model Chapter 2 contains a discussion of the OSI model, and Chapter 3 shows how the OSI model fits in with the TCP/IP protocol The data link (DL) layer for a LAN worries about

framing, transmission, and receiving The data link layer for WANs is far more complex It is also concerned with connection negotiation and management as well as providing configurable degrees of reliability or speed

1.6.1 Local Area Networks

LANs are newer than WANs The concept of LANs was developed about 20 years ago On a LAN, each machine can see every other machine Some type of low-level machine identification scheme is used to identify each computer In addition, LANS include a method of arbitrating

among machines that attempt simultaneous access to the network The first and still the most popular LAN is Ethernet From the standpoint of TCP/IP and some other data communication stacks, the link layer is far simpler in Ethernet and other LANs than it is for WANs This is

because there is no requirement for connection-oriented service However, if the particular

network configuration includes packet filtering, bridging or switching, or address translation, these capabilities will add quite a bit of complexity to the data link layer Almost always, the data link layer for Ethernet consists only of a framing layer and the MAC header All of

Ethernet’s complexity is hidden in the physical layer (PHY) It is at the physical layer where error detection and collision avoidance occur

Generally, most LAN reception and transmission is handled at the device driver level Incoming packets are written directly in a circular buffer by the DMA capability of the Ethernet interface Outgoing packets are queued at the Ethernet chip for transmission There are more complex LANs such as WIFI 802.11 Although these protocols are more complex than Ethernet, the

details are hidden in the physical layer, and the data link layer provides a fairly simple compatible interface Of course, authentication and authorization complicates the picture, but once a user is validated, the interface presents a simple LAN type interface where each machine

Ethernet-on the immediate LAN can see all the other machines

1.6.2 Wide Area Networks

In this book, we look at things from the viewpoint of TCP/IP Essentially, we consider protocols other than TCP/IP from two points of view We will see how some historical protocols

contributed essential technology that later became in corporated in TCP/IP Other protocols are still commonly used for WAN data transmission and often are interfaced to TCP/IP

WANs are concerned with using capacity on the public carrier networks There are many

methods to interface computers to WANs, from simple modems, DSL, and cable modems, up to high-speed optical interfaces such as OC192 Essentially, however, there are two types of WAN interfaces The first is a direct point-to-point connection through a dedicated or private link An example would be a dedicated physical twisted pair or a leased line These will be interfaced as a network interface driver with hardware support for the interface The other more complex type of WAN interface involves a complete separate protocol suite with elements of the protocol

provided to manage negotiated bandwidth and data traffic classes These protocols are for use in

a public network where data traffic is merged with other rate-payer’s data or where data packets are submodulated on a shared carrier along with other data or voice traffic An example of this protocol would be Frame Relay or ATM Interfacing protocols such as these to TCP/IP involves one or more network interfaces without low-level hardware support Examples of these

interfaces might be IP over Frame Relay, or Classical IP over ATM (CLIP) Some examples of WAN data communication protocols are discussed in more detail in Chapter 2

1.7 Packets and Frames

When discussing computer networking, there is confusion between when to call a chunk of data

a packet and when to call it a frame Often, when IP-based networking is discussed over Ethernet,

the difference between these two terms is blurred even though there is a difference between them

When discussing data transmission at the data link layer or the physical layer, the term frame is

used to describe a unit of data A frame is thought to consist of a beginning sequence of

characters or bits defining the start of the frame This is followed by a sequence of characters or bits containing the payload data and followed by a sequence of characters or bits defining the end

of the frame When discussing data transmission at the network layer or above, we consider the unit of data transmission a packet A packet is a data chunk following a header, and we think of the header as encapsulating the data The header typically includes a length field because packets are generally considered variable length In contrast to a packet, a frame is a data unit delineated

by a starting sequence of bits or flags and terminated by a stream of specific bits or flags

Another important difference is that a packet is intended to be processed by higher-level software, and a frame is intended to be processed by lower-level hardware

1.8 The Digital Data Rate Hierarchy in The Public Network

Most of the protocols included in this chapter are for transmitting data across the public network

As discussed earlier, the public network evolved from early hardwired voice circuits and evolved over many years to be able to provide a variety of services and different rates Originally, a

separate twisted pair of wires was used for each voice channel In the mid-twentieth century, the demand for voice circuits rose rapidly and telephone companies looked for a way to combine voice channels in trunk lines without having to use huge cables consisting of bundles of twisted pairs Voice channels were multiplexed using analog methods across a single modulated

broadband carrier using a method called frequency domain multiplexing (FDM) With FDM,

each voice channel is modulated on a specific frequency band within the broadband carrier using frequency modulation (FM) techniques This technique continued to be used for about 20 years until it became apparent that it was not the most efficient use of broadband channel capacity Moreover, FDM required expensive analog switching equipment in the telephone company’s switching stations and therefore was not scalable to ever-increasing demands for increased

circuit carrying capacity [EDWAR00a]

Later, in the 1960s and 1970s, the public network was converted from analog to digital Voice

phone calls were transmitted over individual channels modulated using pulse code modulation

(PCM) over a base band carrier The voice information is modulated and divided into frames where the local analog loop terminates at the phone company’s central office (CO) Each voice channel can be transmitted using time division modulation (TDM) techniques It was known that

to maintain minimum fidelity for voice transmission, each channel requires 3 kHz of bandwidth

It was determined that 64 K bits per second was required to transmit a single voice line

Therefore, the fundamental unit of bandwidth for the public network is 64 KB, and all digital data rates are calculated in units of 64 KB of capacity Table 1.3 shows the hierarchy of digital channel capacity carried across electrical networks in North America Table 1.4 shows the

equivalent hierarchy in use in Europe Table 1.5 shows the Sonet and SDH Optical Hierarchy [MCDYSO99]

Table 1.3: TDM Digital Hierarchy in North America

Name Multiplexing Level Number of Voice

Channels

Rate in Bits per Second

Table 1.3: TDM Digital Hierarchy in North America

Name Multiplexing Level Number of Voice

Table 1.4: TDM Digital Hierarchy in Europe

Name Multiplexing Level Number of Voice

Table 1.5: Sonet and SDH Optical Hierarchy

Carriers also provided specially provisioned twisted pairs to customers for carrying digital data

Each of these lines, called leased lines, was specially provisioned to carry more than the 64KB of

bandwidth that was typical for a single channel intended for voice Originally, there was no standard to determine the bandwidth and capacity for these leased lines Eventually, these

nonregulated channels were replaced with standard channels based on available standard rates

1.10 Summary

This chapter gathered some basic concepts and history that will help to build a basis of

understanding of data communication, and TCP/IP in particular We presented an introduction to data communication Some of the early history of data communication was discussed We

learned how modern data communication was inspired by the need for a printing telegraph We saw how it evolved with a series of steps up to modern high-speed optical switched networking

In Chapter 2, we will see more about non-TCP/IP standards that form the evolutionary basis for modern data communications We will learn how the OSI model serves as a basic framework to discuss computer networking In Chapter 3, we will apply the knowledge to TCP/IP Chapters 4,

5, and 6 cover the TCP/IP infrastructure in Linux in detail

Chapter 2: Broadband Networking Protocols

of Yesterday and Today

In Chapter 1, “Introduction,” we discussed the basics of data communication and presented 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 when we want to send IP datagrams across a broadband or public network Others are included because they are significant in a historical context and have concepts that were later borrowed by TCP/IP Still others are included because they extend the reach of IP packets into broadband realm and allow IP packets to be forwarded over the public networks

it to see how it differs from X.25 The last but far from the least important protocol is

Asynchronous Transmission Mode (ATM) It is the most recent of the broadband protocols and

is important because it forms the basic infrastructure in the public telephony network that is the basis for most voice and data communication In addition, ATM provides a common point of interface for sending TCP/IP traffic to the world outside our LANs

The material in this chapter will include some important concepts that should help in the detailed examination of Linux TCP/IP in later chapters It is important to note that most of the broadband protocols we cover are primarily concerned with providing reliable or connection-oriented

service As we will see, when we go into more detail in the chapters on TCP/IP, IP traffic was intended to be carried over connectionless networks TCP, which runs over IP, is depended on to provide a connection-oriented transport for most of the common application layer protocols However, we will see by examining the lower layer protocols in this chapter that the connection-oriented protocols here are analogous to TCP’s implementation of connection management

2.2 Connection-Oriented and Connectionless Protocols

WAN or broadband protocols are typically connection oriented because they provide sequenced reliable delivery service As we saw earlier, WANs were intended to use excess capacity in the Public Switched Telephone Network (PSTN) The PSTN evolved from the earlier discretely wired telephone system that was in use well into the last century The virtual circuits have to maintain the audio signal quality, and they work the same way as a physically connected pair of telephones does The same public network, originally designed to carry voice traffic, evolved to

a mixed traffic network where it is asked to carry data simultaneously as it carries voice data in connections implemented as virtual circuits This orientation to voice traffic naturally led to the development of connection-oriented protocols, which are also circuit oriented The simpler of the connection-oriented or WAN protocols use the network in the way for which it was designed: to carry voice channels over the public network

In a similar fashion to circuit-based voice traffic, connection-oriented pro tocols work over virtual circuits (VCs) The part of the protocols that establish the circuits is implemented at Layer

2 or higher in the protocol stack (Refer to Chapter 1 for a description of the OSI seven layer model.) The VCs are either configured at startup time or are dynamically set up When they are established at startup time, they are called provisioned virtual circuits (PVCs) When they are set

up dynamically by a signaling protocol, they are called switched virtual circuits (SVCs) The signaling methods are actually implemented as separate protocols that negotiate the connection between pairs of switches Once they are set up, the VCs are actually full-duplex paths between pairs of nodes

LANs can be contrasted to WANs by the way in which the neighboring machines are connected Machines on WANs don’t really have neighbors; every connection between two nodes is either pre-provisioned or separately negotiated However, machines on LANs physically near each other don’t need to run special software to negotiate a connection with other nodes before they can talk to each other On a LAN, every machine can see all its neighbors The machines on a LAN are all peers; every machine has the equal right to transmit to another machine The

physical layer arbitrates in some fashion between the transmitting machines based on their link layer addresses, and the upper layers are responsible for filtering out unwanted packets

2.3 Broadband Networking Versus Local Area Networking

In this chapter and elsewhere in the book, we use the terms broadband and WAN as synonyms

Although not precisely correct, this is the terminology in common use at the time of publication WAN network interfaces faster than analog modems are called “broadband” connections As discussed in earlier sections, the simpler broadband or WAN protocols with some exceptions establish point-to-point connections They rely on higher layer protocols to provide multicast or broadcast capability In contrast, LANs are democratic All the machines on a LAN share the same chunk of bandwidth They can all talk at once or at least try to talk at once They can all see each other’s transmissions Therefore, LANs provide a mechanism at the physical layer to

negotiate access to the physical network to make sure that there is only one speaker at a time In general, LANs have a fairly complicated physical layer but very simple data link layers LANs will checksum packets to make sure that bit-level communications are okay Although packet integrity is usually guaranteed, errors will result in dropped packets

WANs usually have relatively simple direct serial interfaces at the physical layer Higher layers, usually the data link layer, have to do all the work of arbitrating bandwidth and negotiating the connections Therefore, when compared to LANs, WANs have simpler physical layers but more complicated data link layers The data link layers will compensate for transmission problems at the physical layer provided sufficient bandwidth is available

From 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, as we will see in later chapters, TCP can’t entirely

compensate for low-quality links

2.3.1 Local Area Networks

LANs are newer than WANs The first and still the most popular LAN is Ethernet The link layer

is far simpler in Ethernet than it is in broadband protocols A basic Ethernet Layer 2 interface consists only of a framing layer and the Media Access Control (MAC) header In its simplest form, the MAC header contains the source address, the destination address, and the protocol number of the payload The complexity of the LANs is hidden in the physical layer (PHY)

LANs have the characteristic where each machine can see the transmissions of all the other

machines that are directly reachable There is no allocated bandwidth or channels Instead, LAN protocols provide a way to negotiate access to the network by allowing only one machine to transmit at a time There have been various schemes and we don’t intend to cover them all here However, the most popular LAN, Ethernet provides a method called Carrier Sense Multiple Access with Collision Detect (CSMA/CD) where each machine waits for a clear carrier before starting to transmit a packet In addition, each machine generates a Frame Check Sequence (FCS) code, and the recipient machine will drop the packet if the FCS is bad

Generally, all the transmission details, including collision detection and error detection, are done

in hardware or low-level firmware This hardware is the physical layer and it is hidden from the data link layer and all other layers With most Ethernet interfaces, the data link layer is

responsible for receiving the incoming packets, which are placed directly in a circular buffer by the Direct Memory Access (DMA) capability of the Ethernet interface Incidentally, many

Ethernet interfaces can place the packets arriving sequentially in noncontiguous locations and

this is known as scatter-gather capability When available on an Ethernet interface, Linux makes

use of scatter-gather by minimizing expensive copying of packets received from Ethernet

interfaces Similarly, outgoing packets are queued at the Ethernet chip for transmission, and if the interface has scatter-gather capability, these packets are transmitted directly from a linked list

so they don’t have to be copied separately by software into a separate buffer

Most LAN protocols, although they might be far more complex than Ethernet, present a fairly simple Ethernet-compatible interface at the data link layer This type of interface is specified by 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 machines that are directly reachable

2.3.2 Wide Area Networks

Broadband interfaces generally involve public carrier networks, including everything from DSL and cable modems to high-speed optical interfaces such as OC192 Essentially, from the

standpoint of this book, there are two types of WAN interfaces The first is a long-range, reliable, point-to-point link through a dedicated or private line An example would be a dedicated-

physical twisted pair or a leased T1 line, and although of less interest, this type of interface will

be discussed briefly in order to build an understanding of basic data transmission methods The other more complex type of WAN interface attaches to a public network where data traffic is merged with other rate payers’ data or where IP packets are submodulated on a shared carrier along with other data or voice traffic This second type of interface includes IP over Frame Relay, (IPOA), or DSL, and any other interface where IP traffic is carried on another network type

2.4 Asynchronous Versus Synchronous Data Transmission

It is important to differentiate between asynchronous and synchronous methods of data

transmission Asynchronous data transmission has more overhead and doesn’t scale to higher rates the way synchronous methods do The early methods discussed in Chapter 1 on the history

of data communications were done by sending sequences of characters in a sequential linear fashion If transmission is done this way, every character transmitted adds to the overhead Each character has framing bits adding to the amount of data that needs to be transmitted In addition, with asynchronous methods, there are no synchronizing external clock sources, nor are there are any synchronizing pulses embedded within the data stream Each character is separately framed with start and stop bits The receiving station must resynchronize on each character, which is why the maximum speeds are limited

In contrast, synchronous data transmission methods don’t frame every character with individual start and stop bits Instead, the characters are grouped together in sequence into frames, and the frames are transmitted as a stream of bits or characters Each frame consists of a sequence of beginning bits or characters, followed by a data payload and then followed by a terminating sequence of bits or characters The overhead is far higher for asynchronous methods and could

be as high as 25% depending on the character length and how many framing bits there are for each character However, the overhead for synchronous protocols is far lower and could be as little as 5%

2.4.1 Flow Control and Reliable Transmission

Flow control and reliable transmission are really two topics In this section, we discuss these topics in the context of low-level transmission control At the lower layers, we are concerned with how to provide acknowledged frames for error recovery and sequenced delivery In addition,

we maintain queues at the transmission side to accumulate data waiting to be sent and provide an even flow of information Before we begin, it is important to note that TCP/IP does not require either reliable or sequenced packet delivery service TCP/IP is designed to work with LANs that don’t implement retransmission in the case of dropped packets at the lower layers

The method of low-level flow control used is different with simple character-oriented protocols than when it is used with faster synchronous-oriented protocols Character-oriented protocols in their simplest form provide the most basic method of flow control The sending station must wait for an Acknowledge (ACK) from the receiving station before sending the next character This

mechanism is known as stop and wait acknowledgment With this method, it is impossible to

fully use the channel’s bandwidth because one station sometimes has to send empty sync

characters or otherwise mark time while waiting to receive an acknowledgment of an earlier

frame This problem is solved with bit-synchronous protocols by using a technique called sliding windows, which is far more efficient The sliding windows technique has less overhead by using

multiple acknowledgments where one ACK can collectively acknowledge multiple incoming frames After sending the first frame, the sending station can continue to send additional frames without stopping to wait for the receiving station to acknowledge the first frame An example of sliding windows is explained in more detail in Section 2.8 in this chapter The TCP protocol also implements a version of sliding windows, and Chapters 8 and 11 include how it is implemented

in the Linux TCP/IP stack

The data link layer typically provides a link status indication to be used with flow control

Queues of frames waiting for transmission are maintained below the network layer but above the data link layer When the higher layer has a packet ready, it is added to the end of the queue When the lower layer is ready to transmit a packet, it removes the next packet from the bottom of the queue This ensures that higher layers continue processing independently from the lower-layer link status

2.5 Synchronous Data Transmission

In the previous section about asynchronous data transmission, we discussed how there is higher overhead associated with asynchronous character-oriented methods This is because each

character must be acknowledged separately to maintain reliable transmission In addition, there is higher overhead associated with asynchronous transmission because each transmitted character is preceded by start bits and terminated by stop bits However, with synchronous forms of data transmission, the overhead is far lower Instead of sending each byte of data as an individual transmission, the data is gathered into frames and transmitted together as either a stream of bits

or a stream of characters Each frame is preceded by a flag sequence and is followed by a flag sequence Because of less stopping and less extra bits, synchronous methods have far less

overhead than asynchronous methods do

2.5.1 Synchronous Character-based Data Transmission

The primary advantage of synchronous methods of data transmission is that they have lower overhead when compared with asynchronous methods, and therefore are better suited for high-speed transmission However, to understand the more recent high-speed methods, it is important

to take a moment and look at an earlier method The first binary synchronous protocol in

common use was developed by IBM and was known as BISYNC, or BSC This protocol was the

basis of what was to become the Systems Network Architecture (SNA) protocol suite Although

it was only available as part of IBM’s product line at the time, SNA was an early attempt for diverse computers and telecommunications equipment to exchange data using one basic standard

As with asynchronous character-oriented protocols, BISYNC and other character-oriented

synchronous protocols must have a specific character coding specified for the particular protocol

The data is framed by using special characters called control characters The control characters

are used to indicate the start of a frame, the header and control information, and the end of a data frame Table 2.1 shows the specific control characters used with the BISYNC protocol Table 2.2

shows the framing used with BISYNC and how the control characters are used for framing The

start of a frame is indicated by two consecutive syn characters; the presence of the stx character

in the data stream indicates the beginning of payload data The etx character is used to terminate

the frame The character coding method used with BISYNC was called EBCDIC, which was used with IBM and IBM-compatible products Other character-oriented protocols used American Standard Characters for Information Exchange (ASCII) The ASCII character set is still the basis

of almost all 8-bit character representations used for representing European languages

Table 2.1: BISYNC Control Characters

etb End of data block Terminates a block of data 17

eot End of transmission Indicates end of transmission 04

enq Enquiry used for polling

by controlling station

Used by polling station to query for a response

05

nak Negative acknowledge Acknowledges a frame to

indicate errors were received

15

the next character is a control character

10

syn Synchronous idle Maintains synchronization

without sending data

16 soh Start of header Indicates start of the header 01

stx Start of text Indicates the end of the header

and the start of the data

02

Table 2.2: BISYNC Frame

One of the problems with character-oriented protocols is the lack of data transparency The ASCII and EBCDIC character sets represent a subset of all the bit combinations in one byte There is a problem when we must communicate data that includes nonprintable characters We need a method to encode data that happens to contain bit patterns that correspond to one of the control characters Originally, the character coding schemes were only intended to represent actual characters corresponding to printed text Unfortunately, not all transmitted data consists of data that can be represented in characters from a particular coding scheme When there is a need

to exchange unrestricted binary data, which is most of the time, the data must be encoded as hex characters or some other method that only requires characters from within the encoding set used for the protocol When data bytes are represented randomly in a set like ASCII, occasionally an individual byte of data can be identical to a control character In this case, character-oriented

protocols must use a scheme called escaping Each of the common character encoding schemes contains an escape character The escape used in EBCDIC was the DLE character In ASCII, it is

the same as the familiar escape character still found on everyone’s computer keyboard today The purpose of the escaping is to indicate to the receiving station that the byte immediately

following the escape should be interpreted as data and not as a control character This prevents the receiving station from dropping the connection or making some other misjudgment when it encounters a byte in the data stream that it mistakes for a control character in the data stream If the receiving station gets two escape characters in sequence, it interprets these as a single escape

2.5.2 Count-oriented Synchronous Protocols

Count-oriented protocols solve the data transparency problem inherent in character-oriented protocols As discussed previously, the problem occurs when the data field of a frame contains a byte of data that happens to be identical to one of the control characters normally marking the end of frame or beginning of a control message The count-oriented protocols solve the problem

by inserting a length field before the payload data In this way, all possible binary types of data could be included in the user payload data Overhead is reduced because, unlike character-

oriented methods, the transmitting station does not have to sift through all the data in the

transmission inserting escapes before each occurrence of a binary data character Count-oriented

protocols introduced a new type of framing with a framing header that includes a length field Incidentally, the type of framing used in these protocols is the most popular; it forms the basis for most modern data framing techniques used in electrical transmission As we will see in

Chapter 3, “TCP/IP in Embedded Systems,” TCP/IP makes extensive use of this framing

technique A side effect of the count-oriented protocols is that since they have a header

containing a length field, they can have variable-length frames, where the other methods in this chapter have fixed-length frames

2.5.3 Bit-oriented Synchronous Transmission

In this section, we discuss a family of protocols that are closer to the WAN protocols used in modern electrical and, to some lesser degree, in modern optical networks today The growth in demand for bandwidth in the late 1970s and 1980s necessitated the need for better data

communication protocols Both count-oriented protocols and character-oriented protocols have disadvantages when they are used with higher-speed data transmission Both types of protocols required the use of a character encoding scheme such as EBCDIC or ASCII as well as the

escaping technique discussed earlier Particularly when implemented in the hardware available when the protocols were developed, the count-oriented and character-oriented protocols were inherently slow Bit-oriented transmission methods addressed the performance issue by using a

technique called bit stuffing Bit stuffing provides a more efficient method for the receiving

station to differentiate among flags marking the beginning of a frame, flags for the end of a frame, errors, and user payload data One of the earlier protocols that used bit-oriented data transmission is called Synchronous Data Link Control (SDLC) SDLC was eventually used by IBM to replace BISYNC as the basis for SNA SDLC is also called a link control protocol and could be considered a member of the family of the High Level Data Link protocols, (HDLC) Of course, these protocols aren’t really “high level.” Today, we consider anything below the

network layer low-level protocols, but at the time HDLC was first envisioned, most data

communication techniques were very low level—they didnuse any framing techniques at all SDLC and other link control protocols became widely used along with bit-oriented synchronous transmission methods

2.5.4 Bit Stuffing

One of the challenges faced by data transmission methods is the encoding of binary data A data transmission consists of seemingly random data that must be processed by the receiving station while it simultaneously detects error conditions along with frame start and end sequences from among the stream of bits As discussed earlier, other encoding schemes required binary data to

be preceded by escapes when binary data was to be transmitted as part of the user payload data Bit synchronous protocols, however, use a method called bit stuffing to address this problem

Bit-oriented protocols indicate the start and end of a frame with a sequence of six 1 bits or a hex 7E In the payload part of the frame, the transmitting machine inserts a single 0 bit after every sequence of five 1 bits While it is processing the received data, if the receiving station receives five 1 bits and then sees a 0 bit, it simply removes the 0 bit from the data frame If it encounters five 1 bits followed by a sixth 1 bit, it interprets these as the start or end of a frame because it is equivalent to a hex 7E If the receiving station sees between 7 and 15 1 bits in order, it flags this

as an error condition When more than 15 consecutive 1 bits are received in sequence, the

receiving station interprets this as an idle channel

terrestrial radio connections In addition, it sometimes is used at higher speeds than originally specified for certain specialized applications X.25 is important to include in our discussion of foundational data communication protocols It is the first example of a truly layered protocol in common use in the public network outside of a particular vendor’s control X.25 actually

incorporates the first three layers of the OSI model, the PHY, link layer, and network layer It was designed for low-quality physical transmission lines so it has error control and correction at both the link and network layers This redundant error checking is really no longer needed for reliable modern optical or even electrical transmission lines Currently, X.25 is only used to provide reliable data delivery for low-quality wireless links for certain specialized aviation and military communications applications

X.25 was the first protocol to use the concept of a virtual circuit (VC) for data transmission The purpose of VCs is to connect customer equipment in one location across the common carrier’s PSTN to customer equipment at another location by using negotiated connections that are

analogous to voice circuits VCs can be multiplexed by combining many separate streams of data packets into a single stream over the public network The X.25 protocol defines a service access point where 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 virtual circuits (SVCs) or permanent virtual circuits (PVCs) The packet layer is responsible for establishing and breaking down these connections,

and this connection negotiation is also termed call management or signaling It is interesting to point out that the terms signaling and call management come from voice telephony See Chapter

1 for background on the evolutionary nature of data communication and how it evolved from telegraphy and voice telephony The packet layer supports two types of packets, control packets and data packets The control packets are used for call management and the data packets contain user payload data X.25 also provides an individual packet delivery service This service consists

of transmitting individual user datagrams without first doing connection negotiation to establish

a connection or circuit As implied earlier, X.25 provides for support of PVCs, which are VCs that are provisioned rather than set up dynamically with a signaling protocol Refer to Figure 2.1

for an illustration of the layers of X.25

Figure 2.1: X.25

The middle layer in the X.25 protocol stack is the equivalent of Layer 2, the link layer It

incorporates a protocol called Link Access Protocol Balanced (LAPB) LAPB is another variant

of HDLC The types of HDLC are described in more detail in Section 2.7 In the X.25 protocol stack, the link layer provides both a connection-oriented service and a user datagram service Even though X.25 contains its own network layer—when X.25 or for that matter, other WAN protocol stacks are interfaced to TCP/IP—the entire stack sits under TCP/IP’s network layer and appears as a Layer 2 interface

2.7 High Level Data Link Protocol

X.25 was the first protocol suite to incorporate a generic Layer 2 protocol for its link layer definition The generic family of Layer 2 protocols used for WANs are called High Level Data Link Protocols (HDLCs) Originally, when layered protocols were new, “high level” meant that the protocol was dealing with anything more abstract than the electrical details of physical transmission HDLC is still the basis of many data communication protocols in common use today with the exception of ATM and optical protocols There are a few variants on the basic theme of HDLC, and most of these variants are governed by ISO standards However, there are also a few HDLC-type protocols specified by ITU and IEEE standards ISO 3300 and ISO 4335 See Table 2.3 for a list of various HDLC derivative protocols It is important to point out that although these HDLC variants are similar in the way they work, they do not expect

interoperation between variants because the framing details are different

Table 2.3: HDLC Protocol Variants

protocols in modems

802.2 LLC Logical Link Control Basis of data link provider

interface in STREAMS

LAPF Q.922 Link Access Protocol for Frame

Relay

Frame relay bearer service

2.7.1 HDLC Types and Configurations

This section shows the HDLC protocol in more detail All the variants of HDLC are functionally similar They might differ in the precise lengths of the address, control, or FCS fields, but this section is largely applicable to each variant HDLC supports three types of stations and two types

of configuration The three types of stations are:

Primary: Controlling station on the link

Secondary: Slaves to primary stations

Combined: Act as either primary or secondary stations

In addition to the three types of stations, HDLC specifies two types of configurations The

configurations can be thought of as modes of service The two types of configurations are:

Balanced: In a balanced configuration, there are two stations connected with a point-to-point

link In this configuration, each station acts as a combined station

Unbalanced: With the unbalanced configuration, there are two or more stations One station acts

as a primary station Two or more other stations act as secondary stations

Figure 2.2 illustrates the unbalanced configuration, and Figure 2.3 shows the balanced

configuration With the balanced configuration, the stations are peers Each station can send both commands and responses The balanced configuration is used primarily for point-to-point links

In contrast, with the unbalanced configuration, the primary station is the controlling station on the link and the secondary stations are slaves The primary station is the only one that can send commands, and the secondary stations answer with responses

Figure 2.2: HDLC unbalanced configuration

Figure 2.3: HDLC balanced configuration

2.7.2 HDLC Framing

As we have seen, there are many variants of HDLC The HDLC framing detailed in this section shows framing that is generally common to all of the HDLC variants Table 2.4 shows HDLC framing that applies to most of the variants There are three types of formats in an HDLC frame:

• Information format for carrying user data

• Supervisory format for control functions

• Unnumbered format for control and management

Table 2.4: General HDLC Framing

Field Flag Address Control Information FCS Flag

The primary distinguishing factor for each type of frame is the control field The control field has different values for each type of framing, which is determined by the first 2 bits in the control field In the 8-bit control format, bit 5 is the poll/final bit It is treated as the poll bit if it is part of

a frame sent by the primary station, and it is called the final bit if it is encountered in a frame sent

by the secondary station Although the HDLC variants are similar, the specific use of the control field is somewhat different for each type of HDLC For example, Section 2.9 on PPP shows a specific variant of HDLC called 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 response frames include expected sequence numbers

Table 2.5: Information Format

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

Table 2.6: Supervisory Format

The format for commands used with the supervisory format is shown in Table 2.7

Table 2.7: Supervisory Format Commands

Table 2.8 shows the unnumbered format of HDLC This format is used for control functions and management functions such as link establishment Table 2.9 shows some key unnumbered format commands

Table 2.8: Unnumbered Format

Table 2.9: Unnumbered Commands

Command Response un Field

Value

Command Name

Response Name

Purpose

information

Unnumbered information

Information field contains

datagram for connectionless service

response mode

Table 2.9: Unnumbered Commands

Command Response un Field

Value

Command Name

Response Name

Disconnect mode

Also used by secondary station

sta tions are equals

2.8 Sliding Windows

One of the important functions of data link protocols is to provide a connection-oriented or

reliable transmission service A reliable service guarantees ordered packet delivery by doing retransmission of lost or damaged packets Elsewhere in this chapter, we discussed several data communication protocols Some of these protocols are used to carry IP datagrams, and if so, they would be interfaced to IP at the link layer However, it is important to note that TCP/IP does not require connection-oriented service at the link layer The TCP transport protocol actually

includes its own version of sliding windows, which in theory works almost identically to the protocol described in this section However, later we will see that the TCP state machine is far more complex In addition, we will see that TCP has had many enhancements such as slow start

to reduce congestion in busy networks

Sliding windows provides a means of recovering from lost, erroneous, or out-of-sequence frames Earlier protocols had to use a system called start-and-stop acknowledgment to manage the

integrity of the connection This system wasted bandwidth because the sending station had to wait for an acknowledgment before sending another frame In contrast, sliding windows provides

a better mechanism for acknowledging transmissions The receiving station sends an

accumulative acknowledgment This is more efficient because a response from the receiving station can acknowledge multiple packets from the sending station, and the sending station need not wait for the ACK frame before sending more frames When used in conjunction with packet queuing, this method can provide an excellent mechanism for flow control Most modern

communication protocols use a method that is in some way fundamentally derived from sliding windows

The sliding windows method uses a window size determined by the size of the sequence number n(s) and the acknowledgment number n(r) fields of the particular HDLC variant The window size becomes the number of unacknowledged transmit frames that can be sent before receiving

an ACK frame Originally, HDLC reserved 3 bits for the sequence and acknowledgment fields in the information format frame and supervisory format frames, which allows for a window size of

7 Later variants of HDLC increased this field width, subsequently increasing the window size

Figure 2.4 demonstrates a typical sequence for HDLC sliding windows In each transmitted frame, the n(s) field is set to a consecutive sequence number The sending station responds by sending acknowledgment frames with n(r) set to the next expected value of n(s) in a received frame

Figure 2.4: Sliding windows

2.9 HDLC as Used in Point-to-Point Protocol

The point-to-point protocol (PPP) [RFC 1661] is widely used for providing connection for

carrying TCP/IP traffic over serial links, modems, and other types of transmission links It is perceived as a communications protocol for dial-up connections, but is also widely used for tunneled connections over Ethernet in the form of PPP over Ethernet (PPPoE) and other

protocols In this section, we are interested in how it incorporates the HDLC protocol When PPP

is carried over serial links, HDLC is generally used as the framing layer [RFC 1663] It uses a version of HDLC called Link Access Protocol Balanced (LAPB) [RFC 1662] LAPB changes the basic HDLC protocol shown in earlier sections by increasing the window size by increasing the size of the n(s) and n(r) fields This effectively reduces the overhead for acknowledges because the window size governs how many packets can be transmitted before receiving an ACK

In addition, PPP changes the LAPB protocol to allow either station to demand an immediate response from the peer by setting the p bit to 1 in the p/f field Remember that the p/f field has two meanings, one for a command packet and a separate one for the response packet In a

command packet, it is called the p bit, and in the response packet, it is called an f bit A response

packet with the p/f field set to 1 clears the p bit state For an example, consider the following sequence If a receiving station detects an error in a received frame, it can send a REJ

supervisory frame to the peer station with the n(r) field set to the sequence number of the frame with the error and set the p bit to 1 Since sliding windows includes implicit rejection, the n(r) value actually tells the sender that all frames previously received with a value higher n(s) value than the n(r) value are rejected The sending station can then resend the rejected frames

2.10 Frame Relay Bearer Service

As discussed in Section 2.6, X.25 has a performance disadvantage in that it has multiple layers with error correction The Frame Relay Bearer Service (FR) eventually replaced X.25 for most data traffic over public networks This was because X.25 was intended for low-quality physical links where its redundant error checking and correction at both Layers 2 and 3 is appropriate Frame Relay eliminates the extra layer of error correction; it is intended for PHYs with far

greater intrinsic reliability than the early copper-based transmission circuits that were

predominant when X.25 was first used The elimination of extra error correction makes FR more suitable than X.25 for high data rates such as those found in fast optical links up to OC-3 It is important to point out that TCP/IP traffic does not require a reliable link layer The TCP/IP protocol has its own error checking and correction as part of the TCP protocol at the transport layer

The PHY for Frame Relay includes support for DS0, DS1, DS3, E1, or E3 (These rate classes are shown in Chapter 1.) FR’s framing layer uses Link Access Protocol Frame Relay (LAPF) The framing is similar to the HDLC framing used in X.25 but is simpler This is because FR does not provide the error correction that is part of the X.25 packet layer protocol See Figure 2.5 for the framing details for all three types of frames used in FR As in HDLC framing, the FR frame

is preceded by a flag consisting of a 0 bit followed by five consecutive 1 bits, which is a value of 0x7e This flag is used to indicate the frame start The frame is also terminated with a similar flag having the same value of 0x7e The reason for 0x7e is that it used to differentiate control data,

payload data, and detected errors similar to the bit stuffing technique used in HDLC Refer to

Section 2.5.4 for more details about basic HDLC and bit stuffing Table 2.10 shows the frame format for FR

Figure 2.5: Frame Relay header formats

Table 2.10: Frame for Frame Relay Bearer Service

Sequence

Flag

FR allows multiple virtual circuits to be multiplexed across the same physical link The virtual circuits are differentiated by the FR header field which contains a field known as Data Link Connection Indicator (DLCI) This field is used by FR routers to determine how to send a frame

to its destination There are four different DLCI lengths: 10, 16, 17, or 23 bits The values of the D/C and EA bits determine the type of DLCI field Because of the varying DLCI field, there are three different header formats for HR: 2 byte, 3 byte, and 4 byte The multiplexing techniques make use of a field in the header called the Data Link Connection Indicator (DLCI) The

function of the DLCI field is to be a virtual circuit identifier This is similar to the address field

in a LAN network packet FR packets are switched among channels by the FR routers based on the value of the DLCI field Specific descriptions of each of the fields in the Frame Relay header format are shown in Table 2.11

Table 2.11: Explanation of Fields in Frame Relay Header

DLCI Data Link Connection

Indicator

The identifier of the SVC or PVC to which this frame belongs

C/R Command or Not used by the Core Frame Relay Protocol

EA Extended Response bit

Address

Allows for multiple DLCI or address lengths Zero indicates that another header byte is to follow One means that this header byte is the last

Table 2.11: Explanation of Fields in Frame Relay Header

DLCI Data Link Connection

Used for congestion avoidance and traffic control

BECN Backward Explicit

Congestion Notification

Used for congestion avoidance and traffic control

DE Discard Eligible Discardable packets are marked with this bit if

congestion exceeds a threshold

Indicator

One indicates that DLCI bits in the last byte are used for DL-Core functions Zero means that DLCI bits in the lowest byte extend the DLCI address space

Frame Relay includes a signaling protocol for managing SVCs, but FR service can be provided over PVCs as well The frames that actually do the negotiation to control the SVCs don’t travel

in the same link as the frames carrying data traffic This signaling method is called out-of-band signaling when the signaling frames are transmitted over a special channel In addition, signaling

frames use a different form of the header than the header format for data frames The signaling protocol used with FR is ITU standard Q.931

As discussed earlier, the mechanism for reliable service used in X.25 was based on HDLC and its sliding windows protocol FR does not provide reliable or connection-oriented service or a

specific mechanism for flow control at Layer 2; instead, it provides a mechanism called traffic engineering FR establishes a Committed Information Rate (CIR) for each channel based on the

nominal amount of available bandwidth The traffic engineering is provided by the use of three fields in the CR frame header Frames with the DE bit set to 1 can be discarded if the

transmission rate during a burst period exceeds the CIR The Forward Explicit Congestion Notification (FECN) field indicates to the sender that there is congestion on the network

Likewise, the Backward Explicit Congestion Notification (BECN) field indicates to a receiving station that there is congestion on the network A node on the network can start flow control if it detects the FECN or BECN bits in a frame The flow can be maintained until adjacent nodes have time to clear out the congestion

2.11 Asynchronous Transmission Mode (ATM)

ATM is one of the most recent of the broadband or WAN protocols We should point out that Packet over Sonet (PoS) is more recent, scales to the highest optical speeds, and has a well-defined interface for IP datagrams However, we will confine our discussion to ATM in this chapter because it is interesting in that it attempts to provide all kinds of imaginable service, data rates, and traffic classes ATM has similarities to the Frame Relay Bearer Service or even the earlier X.25 ATM is a complex protocol, so we will not be able to discuss it in detail here It provides the basic infrastructure for the modern PSTN In the 1990s, it was thought that it would replace TCP/IP for most data transmission because of its capability to support Quality of Service (QoS) However, with the amount of dark fiber and widely available 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 on the history and evolution of this complex protocol suite However, it is important

to point out a few facts from this history In the 1980s, the telephone companies were looking for

a way to deliver differentiated digital services to customers using the PSTN They came up with

a suite of protocols called ISDN that specified how a user would interface to the PSTN to access various services with different capacities and degrees of reliability ATM was originally called Broadband ISDN (B-ISDN) to specify available services on bit rates higher than what was available with ISDN ATM is entirely scalable from a single DS0 all the way to OC192 ATM defines a complete complex protocol stack, and can provide telephony-type voice circuits as well

as connectionless data services It can provide different needs for quality of data transmission (QoS)

ATM is designed to deal with transmitting data, voice, and video simultaneously Instead of being based on frames or packets, it is implemented with a small Protocol Data Unit (PDU)

called a cell The ATM cell is 53 bytes and includes a 5-byte header and a 48-byte payload This

particular cell size is used because it is the optimum size for individual submodulation of the carriers used with the digital data hierarchy found in all the public networks of the world, North America, Europe, and Asia The small cell size allows for the interrupted transmission of

individual voice packets, but is also scalable to far higher data rates Because of the small cell size and high speeds, header manipulation and cell switching is done in hardware or firmware instead of in slower software However, because of the small cell size and 5-byte header, it has more than 10% overhead

2.11.1 The ATM Stack

The ATM stack is far more complex than TCP/IP It defines both User-to-Network Interfaces (UNI) and Network-to-Network Interfaces (NNI) ATM includes a signaling protocol for

negotiating connections It provides a management interface to allow for provisioning of PVCs and gathering of cell-level statistics The UNI specification includes definitions of classes of service and how to specify service types when interfacing to an ATM network The different service classifications are provided for video, voice, and data

Because of the complexity of ATM, it is shown in a layered model that is similar to OSI but is three dimensional, 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 it interfaces to IP

Figure 2.6: ATM stack

The lowest layer in the ATM stack is the PHY It is divided into upper and lower sublayers The lower sublayer handles the physical transmission details for the optical or electrical interface and generally consists of an interface to the Universal Test and Operations PHY Interface (UTOPIA) bus, which is a parallel interface that hides the implementation details of the TDM multiplexing from the PHY layer of ATM The upper sublayer in the PHY is the Transmission Convergence (TC) sublayer, and there are TCs defined for each of the supported PHYs, DS1, DS3, up to OC3 The TC layer maps individual ATM cells onto a TDM data stream

2.11.2 ATM Network Interfaces

The next higher layer in the ATM stack is the ATM layer This layer is responsible for

differentiating among the different types of cells during routing and switching There are two types of ATM layers: one implements the Network-to-Network Interface (NNI), and the other implements the User-to-Network Interface (UNI) The NNI ATM layer is actually a switch that moves individual ATM cells from one or more input data stream ingress points to one or more

output data stream egress points The NNI ATM switch is also known as an Intermediate System

(IS); it controls the circuit connections from ingress point to egress point In the IS, cells are switched on an individual level because cells are individually multiplexed among different virtual channels depending on the type of channels and cells The switching needs to be very fast

to handle the high data rates and therefore is usually implemented in hardware called an ATM

switching fabric The ATM switches or ISs include the management plane but they don’t include

the AAL layer

ATM is connection oriented; therefore, before any cells can be transmitted, an endpoint connection must be established As in other protocols discussed earlier, each connection becomes a VC Each VC is full duplex or bi directional The circuits are built by the ISs in the network by building two end-to-end chains of connections A connection for each direction is built from Virtual Channel Links (VCL) and Virtual Path Links (VPL) See Figure 2.7 for a picture of the ATM UNI cell format Figure 2.8 shows the ATM NNI cell format

endpoint-to-Figure 2.7: ATM UNI

Figure 2.8: ATM NNI

2.11.3 ATM UNI Service Class Definitions

The UNI, also known as an End System (ES), includes the ATM Adaption Layer (AAL) The ES also has an ATM layer but it is simpler than the ATM layer in the IS AAL is defined as five sublayers: AAL1 through AAL5 The AAL is further sub divided into a Service Specific

Convergence Function (SSCF) and Service Specific Convergence Sublayers (SSCS) The

Segmentation and Re-assembly (SAR) firmware looks at the cell headers and subdivides the cells by class and passes them to the ATM stack through a specific SSCS, depending on the service class and which AAL level interface is required for each service class Refer to Table 2.12 for a summary of the ATM UNI traffic class definitions

Table 2.12: ATM UNI Traffic Classes

Class Sender—Receiver

synchronization

Bit Rate

Connection AAL Content Type

Rt-VBR

CO 2 Time critical packets,

voice signaling, video

Table 2.12: ATM UNI Traffic Classes

Class Sender—Receiver

synchronization

Bit Rate

Connection AAL Content Type

As can be seen, the ATM protocol is very complex Some IP-based data such as Voice over IP (VoIP) and other applications demanding specific QoS must interface to the ATM stack in more complex ways However, for most pure data applications, the actual interface from IP to ATM is fairly simple conceptually It consists of the AAL5 layer and the SAR The internal

implementation of the SAR is complicated, but in most applications it is implemented in

firmware or hardware as part of a PHY chip

2.12 Summary

In this chapter, we discussed the differences between LAN and WAN or broadband protocols

We covered some significant broadband protocols in more detail We saw how these protocols evolved We covered X.25, HDLC, and Frame Relay in some detail We covered ATM in more detail and showed how it is the most complex of the family of broadband protocols In Chapter 3,

we will introduce the basics of TCP/IP We will cover some implementation details of the link layer, Layer 2 on the OSI model, and show how attention paid to Layer 2 will help us understand how TCP/IP can be made to interface to some of the protocols covered in this chapter

Chapter 3: TCP/IP in Embedded Systems

TCP/IP is the dominant protocol suite in modern networking However, TCP/IP is far from new technology; its origins go back to the 1970s The popularity of Linux is the result of an

evolutionary process that dates back around the same length of time The third trend is the

growth in embedded systems These two trends have merged, so now Linux is one of the most popular operating systems (OSs) to be deployed in embedded systems today A major advantage

of Linux is the mature and stable implementation of its TCP/IP stack and the fact that the Linux implementation has proved to be one of the most successful platforms for modern networked devices This chapter builds on Chapters 1 and 2 by exploring the TCP/IP protocol stack and discussing some aspects of the TCP/IP of particular importance to embedded systems engineers and other people who care about the internal implementation

3.1 Introduction

To understand the events that led up to the current popularity and near dominance of the Linux implementation of TCP/IP, it is important to divert our attention a little to the history of the protocol suite, the open source movement, and the Linux operating system TCP/IP networking goes back to earlier days of government-funded computer-related research in the 1970s

Academic and research institutions scattered across the United States were using computers that needed to talk to each other, and researchers looked into new open protocols to exchange generic information This research led to the development of the first protocols in the TCP/IP suite At the time of development of TCP/IP, the Unix system was in wide use as an alternative to

proprietary operating systems in common use These proprietary OSs were only available from computer manufacturers such as DEC and IBM and ran only on the respective vendor’s hardware architecture The first version of Unix was developed by AT&T Bell Labs as a platform for developments in telephony In the late 1970s and early 1980s, the University of Berkeley

Computer Systems Research Group (CSRG) began distributing a version of Unix available for DEC hardware called BSD (Berkeley Software Distribution)

During this time, ARPANET, the forerunner of the TCP/IP protocol suite, was already in use at United States Defense Advanced Research Projects Agency (DARPA) funded research labs DARPA contracted with BBN to have TCP/IP integrated into the BSD OS as part of a

government contract Since the BSD OS was already being distributed to universities in source form, TCP/IP suddenly became available in source form to students, researchers, and engineers

It quickly became an accepted industry standard and was ported into all sorts of small and

embedded systems running proprietary OSs In the meantime, various Unix derivatives were in use in embedded systems, and these OSs were the first ones to introduce TCP/IP to the

embedded systems engineer

3.2 A Note on TCP/IP Implementation

It is important to draw a distinction between the networking protocol and its implementation The networking protocol is a specification where a sequence of exchanges between computers is specified in detail Let’s look at a simple example without specifying any particular OS In

Figure 3.1, machine A broadcasts a packet requesting the address of machine B in order to send a