sME_IsYsDE_IUmR_I
`
`.bDDNAG.N.KROmNRE_IUPMOcmsERESuAHEc..IINERD.
`
`802.11 i
`
`802.11 b
`
`
`
`Ex.1071.001001DELL Ex.1071.
`
`DELL
`
`

`

`.3.w?.
`
`A.6========EE3ENam:LyLirn
`5._.I_£_u._._wOOXm
`
`DELL Ex.1071.002
`Ex.1071.002
`
`DELL
`
`

`

`Library of Congress Cataloging-in-Publication Data
`Maufer, Thomas
`A field guide to wireless LAN s: for administrators and power users I Thomas Albert Maufer.
`p. cm. -- (Prentice Hall PTR series in computer networking and distributed systems)
`Includes index.
`ISBN 0-13-101406-4
`1. Wireless LANs. I. T itle. II. Prentice Hall series in computer networking and
`distributed systems
`
`TK5105.78.M38 2003
`004.6'8--dc22
`
`2003060919
`
`Editorial/Production Supervision: Techne Group
`Executive f;ditor: Mary Franz
`Editorial Assistant: Noreen Regina
`Marketing Manager: Dan DePasquale
`Manufacturing Buyer: Maura Zaldivar
`Cover Design Director: ferry Votta
`Full-Service Production Manager: Anne R Garcia
`
`© 2004 Pearson Education, Inc.
`Publishing as Prentice Hall Professional Technical Reference
`PRA~[tCE Upper Saddle River, NJ 07458
`PTR
`
`Prentice Hall PTR offers excellent discounts on this book when ordered in quantity for bulk purchases
`or special sales. For more infonnation, please contact: U.S. Corporate and Government Sales,
`1-800-382-3419, corpsales@pearsontechgr-0up.com. For sales outside of the U.S., please contact:
`International Sales, 1-317-581-3793, intemational@pearsontechgroup.com.
`
`Company and product names mentioned herein are the trademarks or registered trademarks of their
`respective owners.
`
`All rights reserved. No part of this book may be reproduced, in any form or by any means, without
`permission in writing from the publisher.
`
`Printed in the United States of America
`
`First Printing
`
`ISBN 0-13-101406-4
`
`Pearson Education L td.
`Pearson Education Australia PTY, Limited
`Pearson Education Singapore, Pte. Ltd.
`Pearson Education North Asia Ltd.
`Pearson Education Canada, Ltd.
`Pearson Educaci6n de Mexico, S.A. de C. V.
`Pearson Education-Japan
`Pearson Education Malaysia, Pte. Ltd
`
`Ex.1071.003
`
`DELL
`
`

`

`_ Contents
`
`Preface xv
`
`Chapter 1
`
`Wireless LAN Preliminaries 1
`
`Why Wireless? 1
`Rise of Laptops 2
`Networking Became Pervasive 3
`Emergence of Cellular Phones 4
`I nternet Billing: Wireless versus Wired 6
`-Wireless: Applications versus Devices 7
`WLANs Arrive on the scene 9
`Applications of WLAN s 9
`Corporate Deployments 9
`Wireless ''Hot Spots" 10
`D eployments at Home 11
`components of IEEE 802.11 LANs 13 ·
`Infrastructure Mode 14
`IBSS (AdHoc)Mode 17
`Summary: Differences between Wired and Wireless LAN s 18
`
`vii
`
`Ex.1071.004
`
`DELL
`
`

`

`VIII CONTENTS
`
`Where Do Wireless LAN standards come From? 20
`Overview ofIEEE 802.ll's Structure and Output Thus Far 25
`What IS WI-Fl™? IS It the Same as IEEE 802.11? 27
`summary 29
`
`Chapter 2
`
`A Brief History of Networking Standards 33
`
`The Mother of All Networking Standards 35
`Func~ions of the OSI-RM's Layers 38
`The Physical Layer 38
`The Data Link Layer 40
`The Network Layer 42
`The Transport Layer 43
`The Session Layer 44
`The Presentation Layer 44
`The Application Layer 45
`Aside: The IETF and TCP/ IP Standards 45
`IPv4and1Py6 Encapsulation in IEEE 802 LANs 47
`IEEE LAN Standards 48
`Introduction to IEEE 802.11's MAC Sub-layer Frame structure 53
`IEEE 802.11 MAC Sub-lay~r Protocol's Idiosyncrasies 54
`summary 55
`
`Chapter 3
`
`Speeds and Feeds 57
`
`overview of IEEE 802.11 PHYS 58
`Channels within the 2.4 GHz Band 65
`Channel Selection by a STA 69
`Roaming 'Round the World 7 4
`IEEE 802.11.0peration at 5 GHz-IEEE 802.lla 77
`Channel D efinitions within the U-N II Band 78'
`
`Ex.1071.005
`
`DELL
`
`

`

`CONTENTS
`
`IX
`
`Bring on the Noise 81
`The IEEE 802.11 PHY in Context 84
`Supporting Multiple Speeds Simultaneously 87
`summary of IEEE 802.11 PHYS 96
`IEEE 802.l la 97
`IEEE 802.llb 98
`IEEE 802.1 ld 99
`IEEE 802. l l g 99
`The Future's so.Bright... 101
`What about Faster Speeds? 101
`
`Chapter 4 .
`
`IEEE 802.11 's MAC Sub ~ layer Protocol-Frames, etc. 103
`
`IEEE 802.11 MAC Sub-layer Frame structure 106
`The MAC Sub-layer versus the Data Link Layer 107
`structure of the IEEE 802.11 MAC Sub-layer Frame 109
`Summary of the Frame Control Field 113
`structure of the IEEE 802.11 MAC Frames 114
`IEEE 802.11 Control Frames 115
`RTS and CTS 115
`ACK 116
`PS-Poll 116
`"CF-End" and "CF-End+ CF-ACK'' 117
`IEE~ 802.11 Management Frames (MMPDUs) 117
`IEEE 802.11 Data Frames (MPDUs) 118
`IEEE 802.11 with IEEE 802.lQ 119
`Data L ink Protocol Stacks Based on IEEE 802.11 121
`IEEE 802.11 Data Exchange Interfaces 124
`TheMSDU 124
`The MPDU and PSDU 125
`ThePPDU 126
`
`Ex.1071.006
`
`DELL
`
`

`

`X
`
`CONTENTS
`
`Higher-Layer Protocol Encapsulation 126
`Encapsulation of IP over Ethernet and IEEE 802.11 128
`Modes of Operation 128
`summary 130
`
`Chapter s
`
`Dissection of a Probe Response MMPDU 131
`
`Reprise of IEEE 802.11 's MMPDU Structure 131
`What causes a Probe Response? 132
`Dissection of an Actual Probe Response 134
`summary 148
`
`Chapter I
`
`IEEE 802.11 's MAC Sub-layer Protocol-Access, etc. 149
`
`Building Blocks: Joining a Wireless LAN 149
`IEEE 802.11 Frame Types and Usage 151
`Basic ST A State Machine 152
`Addressing in MPDUs 154
`I nfluence ofToDS and FromDS on the M PDU H eader 155
`IEEE 802.11 WLAN Components 157
`Frame Handling--:-Multicast 160
`MAC/PLCP Interactions 160
`A Usage of the CTS Control Frame: CTS-to-Self 164
`DCF, PCF, Time, and Power Management 168
`Wireless versus Wired MAC Protocol Design D ifferences 168·
`Distributed Coordination Function 173
`T iming Is Everything 175
`Time Intervals and Access Methods 176
`D CF, PCF, and Timing 183
`
`Ex.1071.007
`
`DELL
`
`

`

`Power-Save Mode 184
`Power Management Details 186
`summary 188
`
`Chapter 7
`
`Security Mechanisms for Wireless LANs 191
`
`Introduction to Wireless LAN security 192
`security and the OSI Model 196
`The Physical Layer 201
`The Data Link Layer 202
`The Network Layer 203
`The Transport Layer 204
`The Application Layer 204
`A WOrd On P@sswOrdz 206
`H ow Ca:n a User Create a Good Password? 208
`Security Is Hard-Network Security or. Otherwise 210
`Summary of Motivations for ~N Security 212
`Introduction to Wireless LAN security 214
`Non-Cryptographic Security Schemes 214
`Cryptographic Security Schemes 215
`End-User Authentication 215
`M essage Authentication 216
`Message Verification 217
`Message Encryption 219
`Derivation of Encryption and Authentication Keys 220
`Ciphersuite Selection 222
`Wired-Equivalent Privacy <WEP> 222
`Authentication within IEEE 802.ll's MAC-Layer 223
`User A uthentication: "Open System" 225
`User Authentication: "Shared Key" 229
`Association 233
`
`CONTENTS
`
`XI
`
`Ex.1071.008
`
`DELL
`
`

`

`Xii
`
`CONTENTS
`
`Encryption 23 7
`What Can Go Wrong? (Or: What's So Bad about WEP?) 242
`The Post-WEP Era: WLAN Security Evolves 248
`IEEE 802.111-Robust security Network 249
`RSN Authentication and Key Management Mechanisms 250
`EAP Packets and EAPoL Frames 255
`EAP Negotiation Procedure 260
`Filtering (from the STA's Perspective) 262
`The First Message of the Four-Way Handshake 262
`The Second M essage of the Four-Way Handshake 265
`The Third Message of the Four-Way Handshake 269
`The Fourth Message of the Four-Way Handshake 270
`What Can Go Wrong? 271
`We're Not Done Yet 272
`What If You Want Better Security than WEP, but You Don't Have a RADIUS
`Server? 275
`RSN Ciphersuites 277
`Temporal Key Integrity Protocol 277
`AES Counter Mode with CBC-MAC (CCM) Protocol (CCMP) 282
`Wi-Fi Protected Access 284
`
`Chapter a
`
`Applications and Deployment of Wireless Technology 287
`
`IEEE 802.11: Wireless LANs and Beyond 288
`Bluetooth~ and IEEE 802.15.1: Wireless Personal Area Networks
`(WPANs) 289
`IEEE 802.16: Fixed Broadband Wireless Access 292
`IEEE 802.11 Wireless LAN Devices 296
`Wireless LANs at Home 300
`Evolving WLAN Technology Enables Future Applications 302
`Wireless LANs at Home: WLAN-Enabled Gateways 303
`What Is a Home Gateway? 306
`
`Ex.1071.009
`
`DELL
`
`

`

`CONTENTS Xiii
`
`Home Networking: Why? 309
`Home Networking: Who? 311
`Corporate Drivers of Home Networking 311
`Security Aspects of Home WLAN Deployment 313
`Deployment far One's Own Use-Isolated Deployment 313
`Deployment far One's Own Use-in Close Quarters 313
`Deployment far Shared Use-Implicitly in Close Quarters 314
`WLANs in Medium-to-Large Enterprise Networks 314
`Incremental RSN Deployment Using Channel Overlays 319
`Wireless LANs in Public Places 324
`Public Access WLA.Ns: Universities Exploring the Future 327
`Deploying WLANs at Home: A case study 328
`summary 333
`
`Index 335
`
`Ex.1071.010
`
`DELL
`
`

`

`2
`A Brief History of
`Networking Standards
`
`This chapter is meant as background material for readers who may not be
`familiar with all the types of networking standards there are, and the organiza(cid:173)
`tions that produce them. Readers who are already familiar with terms like
`CCITT, OSI, IEEE, IETF, ITU-T, TCP/IP, X.25, and so on can proceed to
`Chapter 3, Speeds and Feeds 1.
`In practice, there are two kinds of standards, de facto and de Jure. The latter are
`formally created by organizations that are specifically chartered with producing
`them, and often have the force of law or treaties behind them. The former were
`perhaps never intended to become standards, but due to popularity or influence
`became entrenched in the marketplace.2 The standards to be discussed next
`were de Jure standards created under the auspices of the international group
`known as the CC ITT. 3
`The original reason for creating them was partly to offer an alternative to
`an emerging proprietary networking protocol suite, namely IBM's Systems
`
`1. The information in this short chapter is provided for completeness. There is an unwritten
`rule that all books that have to do with networking must at some point mention the OSI Refer(cid:173)
`ence M odel.
`2. In the context of this chapter, the standards we discuss are generally the de Jure variety.
`3. The acronym stands for "Comite Consultatif International Ttlegraphique et Telephonique."
`T he group still exists. The portion of the CCITT that standardized networking protocols and
`conducted related activities has been relocated to the International Telecommunications Union,
`Telecommunications Standardization Sector (abbreviated: ITU-T), which is a component of the
`United Nations.
`
`33
`
`Ex.1071.011
`
`DELL
`
`

`

`34 Chapter 2 ® A BRIEF HISTORY OF NETWORKING STANDARDS
`
`Network Architecture (SNA), which for many years did achieve de facto stan(cid:173)
`dard status until it was displaced by TCP/IP. Pre-OSI networking protocols
`of the era (mid-1970s and onward), such as IBM's proprietary SNA, were
`very different from the eventual OSI model in many ways, but shared many
`architectural features in common with OSI's structure, including the number
`of layers, and their basic functionality. Although there was not a perfect func(cid:173)
`tional alignment between the OSI-RM and IBM's SNA, it seems rather clear
`that there was some cross-pollination of ideas among the groups involved in
`the creation of the two protocol stacks.
`One key observation about IBM's SNA is that it had a strong design prefer(cid:173)
`ence for connection-oriented protocols, and it provided for reliable delivery at
`many layers, whereas the OSI protocol stack usually offered either connection(cid:173)
`oriented or connectionless operation for protocols implementing layers above
`the Physical layer, which is (of course) inherently connection-oriented.
`There is no ambiguity in the term de Jure. However, there are multiple ways
`that a standard can be de facto, including the way it was created and the way it is
`used. For example, a de Jure standard could be used in a way that the authors
`never intended. If that usage becomes popular, that particular use of the stan(cid:173)
`dard could be deemed de facto. For example, certain protocols may have been
`designed with a certain scope in mind, for example, LAN protocols are typically
`expected to operate within an area that is "local". However, if that technology
`later evolves such that it is deployed in larger contexts, that might or might not
`align with the protocol designers' intentions.
`Another way that protocols can evolve is exemplified by the way that
`Ethernet is beginning to see so-called "jumbo" frames being supported by
`equipment that supports gigabit Ethernet, however, the IEEE 802.3 com(cid:173)
`mittee (which is the name of the working group that is managing the evolu(cid:173)
`tion of the standards governing what we typically call "Ethernet") does not
`recognize such an implementation as being in compliance with the standard.
`In all other ways, an Ethernet product that supports jumbo frames would be
`interoperable with earlier devices, but mixed networks might exhibit strange
`behavior, ~uch as one-way traffic flows for large frames, and other bizarre
`effects.
`The only reason we mention these examples is that it is important to under(cid:173)
`stand that there are no subtleties in the term de Jure, but the meaning of the term
`
`Ex.1071.012
`
`DELL
`
`

`

`The Mother of All Networking Standards
`
`35
`
`de facto may be context-dependent, and it is possible to have a de facto usage of a de
`Jure standard.
`"-
`
`The Mother of All Networking Standards
`The old ironic aphorism that the great thing about standards is that there are so
`many to choose from is funny because it is so true. The profusion of data net(cid:173)
`working standards partially derives from the many different organizations that
`create such standards, such as ANSI, CCITT, IEEE, IETF, ITU-T, and so
`forth, and partially from the many different layers at which standards may be
`defined. Private companies also espouse their own protocols, and frequently
`"embrace and extend" openly created protocols for their own purposes. The
`main system of classifying data networking standards is the OSI-RM, which
`illustrates an idealized protocol stack that supports functionality distributed
`throughout seven.interdependent layers.
`During the Open Systems Interconnection (OSI) networking protocol suite
`standardization effort, which started in the mid-1970s and continued through
`the late 1980s and early 1990s, a form of division of labor was employed such
`that a different WG designed each protocol layer, in such a way that the details ·
`of the internal operation of any given protocol layer were irrelevant, as long as
`each layer provided a certain set. of well-defined services to the layer above it.
`Each layer likewise depended on a different set of well-defined services that
`would be exposed by the layer below it.
`In the early days of the standardization of the protocols that would eventually
`comprise the seven layers of the OSI Reference Model (OSI-RM), the lower
`layers were understood best, and thus their standardization was completed first.
`These well-understood layers consisted of the Physical4 and Data Link layers
`(some Network layer protocols were already understood as well, such as the con(cid:173)
`nection-oriented Network layer of CCITT X.25). Figure 2-1 shows the com(cid:173)
`plete seven-layer protocol st~ck defined by the OSI-RM'.
`In most cases, a layer has well-defined interfaces that are used to either accept
`data from higher layers, or to indicate the presence of data to a higher layer.
`Typically, there are also control interfaces between the layers that allow a higher
`
`'
`4. A device that implements a Physical layer protocol is frequently referred to verbally and
`written shorthand, namely as a "PHY" device.
`
`Ex.1071.013
`
`DELL
`
`

`

`

`

`The Mother of All Networking Standards
`
`37 ·
`
`·~ Application
`Presentation
`
`Session
`
`Transport
`
`~
`
`Network
`
`Data Link
`
`Physical
`
`"
`'-
`
`~
`
`-
`-
`-
`-
`-
`
`~
`
`-
`
`-
`
`r
`
`T
`
`T
`
`r
`
`Application
`.
`Presentation
`
`'
`
`Session
`
`Transport
`
`Network
`
`Data Link
`
`~
`r
`
`Physical
`
`~
`
`Figure 2-3
`
`Operation of the layered protocol model
`
`of a protocol stack that divides the job of sendi°:g and receiving data over a net(cid:173)
`work into layers, each with its own well-defined function(s). The choice of seven
`layers was somewhat arbitrary, and had as much to do with politics than tech-
`nology. 5
`.
`.
`The OSI- RM's seven abstract layers each perform .a specific function. Layers
`2 through 6 (the middle layers) have a common characteristic, in that they per(cid:173)
`form a service (or set of services) for the layer above, and expect a service (or set
`of services) from the layei: below. In other words, they are simultaneously "cli(cid:173)
`ents" of the layer below, while they offer "services" to the layer above. The reason
`that layer 1 and layer 7 are different is that they have no layer below or no layer ·
`above; respectively. Therefore, layer 1 only provides service( s) to layer 2 because
`layer 1 is at the bottom of the protocol stack, and there is no lower layer; simi(cid:173)
`larly, due to its position at the top of the protocol stack, layer 7 only uses services
`offered by layer 6.
`The protocol stack manifests itself in a nested series of headers that are pre(cid:173)
`fixed to data ·that is passed down from the layer above, as illustrated in Figure 2-4.
`In the ideal case, the extra header added by each layer is treated as if it were data
`by the layer(s) below. In practice, it is occasionally more efficient to peek into
`the next higher-layer protocol's header to make more accurate forwarding
`
`5. There was an existing proprietary protocol suite that was very successful when the OSI
`standardization effort was begun, namely IBM's Systems Network Architecture (SNA). IfIBM
`needed seven layers, then certainly the standard protocol suite couldn't have fewer. Anecdotally,
`there was also a natural structure of the committees that were participating in the OSI standard(cid:173)
`ization effort that favored seven WGs, which mapped nicely to seven layers.
`
`Ex.1071.015
`
`DELL
`
`

`

`

`

`The Mother of All Networking Standards
`
`39
`
`A bit stream may be represented by any of the following physical phenomena:
`• Electrical voltage modulation (analog)
`• Electrical voltage. ~odulation (a.k.a., digital baseband)
`• Optical transmitted power (i.e., brightness or amplituae) fluctuations
`• Optical frequency modulation (i.e., wavelength division multiplexing)
`• Optical phase modulation
`• Optical polarization modulation
`• RF amplitude modulation6
`• RF frequency modulation
`• RF phase modulation
`• RF polarization modulation
`• Semaphores
`• Smoke signals
`• Some combination of RF amplitude, frequency, phase, and/or polariza(cid:173)
`tion modulation
`Finally, a Physical layer typically operates at a given fixed speed (once the sta(cid:173)
`tion has attached to the medium and-discovered that speed), and the bit encod(cid:173)
`ings are typically defined such that the receiver may easily synchronize itself to
`the sender's Physical layer clock, so that the receiver can interpret each bit at the
`proper time, which helps the receiver avoid misinterpreting the data.
`To summarize the features of the Physical layer, we have seen that the
`Physical layer is responsible for tasks that directly relate to sending and receiv(cid:173)
`ing bits over the medium. T he Physical layer defines the encoding of bits on
`the medium, may control the establishment and tear-down of connections,
`and can perform monitoring of the medium, such as when a modem bases its
`modulation on the measured characteristics of a connection, to find the best
`speed for the evolving conditions on the call. The bit. encoding on a Physical
`medium may include support for Forward Error Correction (if the medium is
`expected to be noisy).
`
`6. Radio Frequency signals can be carried over the air (as in a WLAN), or they· can be carried
`over coaxial cable (e.g., 10BROAD36 Ethernet and cable television, for two examples of wired
`RF technologies). This footnote applies to all the RF entries in the bulleted list after the line
`with this footnote reference.
`
`Ex.1071.017
`
`DELL
`
`

`

`40 Chapter 2 ~ A BRIEF HISTORY OF NETWORKING STANDARDS
`
`The Physical layer is fundamentally connection-oriented, since if a device is
`not connected (in some sense) it cannot send or receive bits. There may even be
`Physical layer headers that are transmitted ahead of a frame that describe the
`modulation or other aspects of the succeeding frame. In IEEE 802.11, such a
`PHY protocol exists that allows different stations in a wireless LAN to operate
`at varying speeds.
`
`The Data Link Layer
`Early Data Link protocols tended to be reliable, since early physical data com(cid:173)
`munications media were so error-prone. The earliest reliability mechanisms
`employed by the first Data Link layer protocols tended to use simple "ping(cid:173)
`pong" reliable transmission schemes, in which a new frame may only be trans(cid:173)
`mitted after the current frame has been acknowledged. Later, more advanced
`"sliding window" protocols enabled a station to have multiple unacknowledged
`frames "in flight" to a destination, up to a limit defined by the window size ( typ(cid:173)
`ically at least seven frames).
`These "acknowledgment-oriented" schemes were used to provide for reliable
`transmission of data over the slow and error-prone physical infrastructures that
`were common in the 1970s and 1980s; in particular, the media did not support
`high-speed transmission, and they frequently had very poor signal-to-noise
`ratios. In this timeframe, even digital transmission facilities could be extremely
`noisy (measured by bit-error-rate), and were quite slow.7 It was the job of the
`Data Link layer to take whatever steps were necessary so that the physical
`medium would appear error-free to the Network layer. 8 Early Network layer
`protocols tended to be oriented toward packet-switched "cloud" technologies
`such as X.25.
`By the time that broadcast-capable Data Link layer technologies, such as
`LANs, had matured sufficiently to warrant their incorporation into the OSI(cid:173)
`Rl\1 framework, it was easy to integrate these new types of Data Link layers into
`
`7. In the 1970s, a dedicated 56 kbps digital circuit was considered fast, which is amazing
`when one considers that DSL and cable moderns today offer speeds on the order of 20 times
`faster. So-called "T-1" circuits became more common in the 1980s, but were quite expensive ini(cid:173)
`tially, primarily due to regulatory issues.
`8. As long-haul (MAN and/or WAN) fiber-optic transmission technology was deployed in the
`late 1980s and early 1990s, the quality of data circuit facilities, as measured by signal-to-noise ratio
`or by bit-error-rate, increased by several orders of magnitude.
`
`Ex.1071.018
`
`DELL
`
`

`

`The Mother of All Networking Standards
`
`41
`
`the OSI-RM without needing to make substantial changes to the definition of
`the Network layer due to the layer abstraction. As long as the new LAN s
`exposed the control and~ data interfaces that the Network layer expects, the Net(cid:173)
`work layer will be satisfied with the situation. The changes necessary to integrate
`LANs into the OSI-RM framework were primarily isolated to the Physical
`and Data Link layers, although Network layer protocols might need small
`changes to accommodate the availability of certain optional Data Link layer
`features (or to avoid trying to use features that are not currently available). In
`order to accommodate certain Data Link layers that do not provide reliable
`transport, higher layer protocols may provide their own forms of error recovery
`mechanisms.
`The IEEE LMSC (a.k.a. Project 802) is now in its third decade of operation,
`and has made substantial contributions to the Physical and Data Link layers,
`defining over a half-dozen MAC sub-layer protocols, and specifying the associ(cid:173)
`ated PHY s over which these MAC sub-layer protocols operate. This group has
`generated, and continues to make progress on, the standards for wireless LAN s,
`namely IEEE 802.11.
`As conceived by the OSI-RM, the Data Link layer is responsible for enabling
`long frames (up to thousands or tens of thousands of bits) to be received intact
`across an unreliable Physical layer. The Data Link layer protocol's job is to
`delimit frames and it will typically provide a capability for error detection on a
`per-frame basis, but may optionally also include a capability for forward error
`correction or for robust delivery (through retransmissions). Even lacking the
`capability of forward error correction, different Data Link protocols provide for
`varying degrees of robustness in their ability to detect (and correct for) errors.
`The amount of effort expended will be inversely proportional to the expected
`performance of the associated Physical layer medium (i.e., reliable media might
`not need really robust error detection, whereas noisy channels may need more
`sophisticated algorithms, or combinations of algorithms). The Data Link layer
`is also responsible, where appropriate, for defining mechanisms to allow a Phys(cid:173)
`ical medium to be shared among a set of stations.
`The Data Link layer is the lowest layer to incorporate the concept of an
`"address," which is in this case limited to use within the span of the underlying
`physical medium, or perhaps more broadly within the domain of operation of
`the Data Link layer protocol. In the IEEE's model, the addressing occurs at
`
`Ex.1071.019
`
`DELL
`
`

`

`42 Chapter 2 ® A BRIEF HISTORY OF NETWORKING STANDARDS
`
`the MAC sub-layer, which is why these addresses are often referred to as
`"MAC addresses."
`The Data Link layer protocol is also responsible for providing a label indicat(cid:173)
`ing which Network layer protocol owns the encapsulated payload within the
`frame, and therefore which Network layer protocol should handle the frame at
`the receiver. For example, two Data Link layer entities could be exchanging
`frames, with some of the frames being associated with the Apple Talk Datagram
`Delivery Protocol (DDP), others with the IP (IPv4), and still others with the
`Address Resolution Protocol (ARP). Without some form of label, a receiving
`Data Link entity would have no idea how to pass the contents of the frame up
`the protocol stack.
`This de-multiplexing concept repeats itself in certain higher-layer protocols,
`in that a given layer may have- several possible higher-layer client protocols, and
`there must be either an implicit or explicit means to indicate which of the possi(cid:173)
`ble higher-layer protocols is actually contained in the frame payload portion of
`this Data Link layer frame.
`The OSI Data Link layer may be connection-oriented or connectionless.
`Many examples of connection-oriented Data Link protocols happen to support
`reliable delivery, but it is not mandatory that this be the case. In fact, IEEE
`802.11 is one example of a MAC sub-layer protocol that supports a primitive
`type of reliability, yet it is a connectionless protocol.
`
`The Network Layer
`The Physical layer is completely unconcerned with the structure of the bit(cid:173)
`stream that it is carrying. In that respect, the Physical layer is unaware of its
`payload. The Data Link layer is similarly unaware of a frame's payload, which
`is commonly a Network layer protocol, or some other "client" protocol of the
`Data Link layer, such as a control or setup protocol. For example, certain pro(cid:173)
`tocols only need to send Data Link layer frames. They are, in a sense, simple
`"applications" that are operating directly over the Data Link layer. Even in
`this latter case, however, the Data Link layer is unaware of the structure or
`contents of the frame.
`- The Network layer provides for end-to-end addressing, and a Network layer
`path can encompass many different types of Data Link layers. The Network
`layer protocol can be either connection-oriented or connectionless. Due to the
`
`Ex.1071.020
`
`DELL
`
`

`

`The Mother of Al l Networking Sta ndards
`
`43
`
`ever-increasing deployment of the IP (which is connectionless), it is becoming
`more difficult to find real-world examples of connection-oriented Network layer
`protocols. There are pn!bably still many networks that use X.25, which is a
`WAN-oriented Network l~yer protocol that emerged in the late 1970s that hap(cid:173)
`pens to be an example of a Network layer protocol that is connection-oriented
`and supports reliable delivery. In addition to addressing information, the header
`of a Network-layer protocol will include some way to indic.ate the proper
`higher-layer client protocol.
`
`The Transport Layer
`The Transport layer is used to create logical connections or· associations between
`software entities on two communicating devices. In the OSI-RM, this is the
`lowest layer that creates a formal binding between two network endpoints for
`exchanging data between them. It is possible for the Transport layer protocol to
`be either connection-oriented or connectionless.
`In the TCP/IP protocol suite, the TCP is the Transport layer protocol that pro(cid:173)
`vides a (connection-oriented) reliable octet stream service to the communicating
`endpoints. The User Datagram Protocol (UDP) provides a connectionless Trans(cid:173)
`port layer service that supports certain. applications, but is also used as a multiplex(cid:173)
`ing layer over which other Transport layer protocols are operated. There are
`Transport layer protocols in the OSI protocol suite, but they do not provide useful
`examples because they are much less well known than TCP and UDP.
`In the case of IP, the "Protocol" :field in the IP header is only one octet in
`length, so there is a limit of 256 unique protocols that may be carried by IP. By
`using UDP as a de-multiplexing layer, that number can be expanded consider(cid:173)
`ably. For example, the Real-time Transport Protocol (RTP), which is by its very
`name clearly a transport protocol, is layered over UDP, which is another trans(cid:173)
`port protocol.
`All UDP-based protocols together only consume the one IP "protocol" value
`(UDP is IP protocol number Oxll), and there are 216 UDP ports by which to
`identify applications. Examples of UDP-based applications include certain
`types of Domain Name Service (DNS) traffic, Dynamic Host Configuration
`Protocol (DHCP), Network Time Protocol (NTP), Routing Information ~ro­
`tocol (RIP) and RIP Next Generation (RIPng), the Simple Network Manage(cid:173)
`ment Protocol (SNMP), and the Trivial File Transport Protocol (TFTP).
`
`Ex.1071.021
`
`DELL
`
`

`

`44 Chapter 2 @ A BRlEF HISTORY OF NETWORKING STANDARDS
`
`Other examples of Transport layer protocols exist in the TCP/IP suite,
`including the new Stream Control Transmission Protocol (SCTP), which is a
`new protocol that was designed to carry signaling information for telephone
`switching over IP networks, but which is being considered as a transport for
`iSCSI (SCSI over IP), and for other uses.
`
`The Session Layer
`The TCP/IP suite has no specific protocols that map to either layer 5 or layer 6
`of the OSI-RM. Layer 5, the OSI Session layer, is used to create a higher-level
`abstraction of a Transport layer connection. There are· certain requirements of
`iSCSI that could benefit from an Internet-standard Session layer protocol.
`Because such a protocol does not exist, the iSCSI protocol designers had to
`invent what is effectively a Session layer protocol specifically for iSCSI, to
`enable peer entities to use multiple TCP connections (for performance reasons)
`and still be able to preserve the SCSI commands and responses in the proper
`order. The IETF has considered creating Session layer abstractions in the past,
`but these efforts have not gained much traction, except in certain limited set(cid:173)
`tings (iSCSI is one, and HTTP version 1.1 is another). In each case, the "Ses(cid:173)
`sion Layer" protocol that was created is highly specific to the application.
`Perhaps there is no generically useful set of Session layer protocol primitives that
`could serve a broad class of applications, and it is better to design new Session
`layer protocols as needed.
`
`The Presentation Layer
`The OSI Presentation layer is responsible for encoding higher-layer (Appli(cid:173)
`cation layer) data structures into a form suitable for transmission. This could
`involve using a self-describing encoding such as Abstract Syntax Notation
`One (ASN.1), or it could involve the definition of data structures that sup(cid:173)
`port certain types of application needs. The point of the Presentation layer
`was to provide a set of data representation types that can be leveraged by var(cid:173)
`ious applications. Many p·opular IETF protocols seem to prefer ASCII(cid:173)
`coded human-readable protocol exchanges, such as are used to exchange
`commands between peer entities using the File Transfer Protocol (FTP),