521 lines
No EOL
40 KiB
HTML
521 lines
No EOL
40 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
|
||
|
||
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
||
<title>5.6. Link Layer — Computer Systems Fundamentals</title>
|
||
|
||
<link rel="stylesheet" href="_static/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous" />
|
||
<link rel="stylesheet" href="_static/css/pygments.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/normalize.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../JSAV/css/JSAV.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaMOD-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/jquery-1.11.4-smoothness-ui.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaStyle-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/csf.css" type="text/css" />
|
||
|
||
<style>
|
||
.underline { text-decoration: underline; }
|
||
</style>
|
||
|
||
<script type="text/javascript">
|
||
var DOCUMENTATION_OPTIONS = {
|
||
URL_ROOT: './',
|
||
VERSION: '0.4.1',
|
||
COLLAPSE_INDEX: false,
|
||
FILE_SUFFIX: '.html',
|
||
HAS_SOURCE: true
|
||
};
|
||
</script>
|
||
|
||
<script type="text/x-mathjax-config">
|
||
MathJax.Hub.Config({
|
||
tex2jax: {
|
||
inlineMath: [['$','$'], ['\\(','\\)']],
|
||
displayMath: [ ['$$','$$'], ["\\[","\\]"] ],
|
||
processEscapes: true
|
||
},
|
||
"HTML-CSS": {
|
||
scale: "80"
|
||
}
|
||
});
|
||
</script>
|
||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="index" title="Computer Systems Fundamentals" href="index.html" />
|
||
<link rel="next" title="7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee" href="Wireless.html" />
|
||
<link rel="prev" title="5. Internet Layer: IP" href="NetLayer.html" />
|
||
|
||
</head><body>
|
||
|
||
<nav class="navbar navbar-expand-md navbar-dark navbar-custom fixed-top">
|
||
|
||
<a class="navbar-brand py-0" href="index.html"><img src="_static/CSF-Logo-Square-Text.png" alt="OpenCSF Logo" height="40em" class="py-1 px-2 mb-0 align-center rounded-lg bg-white" /></a>
|
||
<!-- Show a navbar toggler on mobile -->
|
||
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#defaultNavbars" aria-controls="defaultNavbars" aria-expanded="false" aria-label="Toggle navigation">
|
||
<span class="navbar-toggler-icon"></span>
|
||
</button>
|
||
<div class="collapse navbar-collapse" id="defaultNavbars">
|
||
<ul class="navbar-nav mr-auto">
|
||
<li class="nav-item dropdown">
|
||
<a class="nav-link dropdown-toggle jmu-gold rounded" href="LinkLayer.html#" id="navbarDropdownChapters" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">Contents</a>
|
||
<div class="dropdown-menu scrollable-menu" role="menu" aria-labelledby="navbarDropdownChapters">
|
||
<a class="dropdown-item" tabindex="-1" href="LinkLayer.html#"><b>Chapter 1</b></a>
|
||
<a class="dropdown-item" href="IntroConcSysOverview.html"> 1.1. Introduction to Concurrent Systems</a>
|
||
<a class="dropdown-item" href="SysAndModels.html"> 1.2. Systems and Models</a>
|
||
<a class="dropdown-item" href="Themes.html"> 1.3. Themes and Guiding Principles</a>
|
||
<a class="dropdown-item" href="Architectures.html"> 1.4. System Architectures</a>
|
||
<a class="dropdown-item" href="StateModels.html"> 1.5. State Models in UML</a>
|
||
<a class="dropdown-item" href="SequenceModels.html"> 1.6. Sequence Models in UML</a>
|
||
<a class="dropdown-item" href="StateModelImplementation.html"> 1.7. Extended Example: State Model Implementation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 2</b></a>
|
||
<a class="dropdown-item" href="ProcessesOverview.html"> 2.1. Processes and OS Basics</a>
|
||
<a class="dropdown-item" href="Multiprogramming.html"> 2.2. Processes and Multiprogramming</a>
|
||
<a class="dropdown-item" href="KernelMechanics.html"> 2.3. Kernel Mechanics</a>
|
||
<a class="dropdown-item" href="Syscall.html"> 2.4. System Call Interface</a>
|
||
<a class="dropdown-item" href="ProcessCycle.html"> 2.5. Process Life Cycle</a>
|
||
<a class="dropdown-item" href="UnixFile.html"> 2.6. The UNIX File Abstraction</a>
|
||
<a class="dropdown-item" href="EventsSignals.html"> 2.7. Events and Signals</a>
|
||
<a class="dropdown-item" href="Extended2Processes.html"> 2.8. Extended Example: Listing Files with Processes</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 3</b></a>
|
||
<a class="dropdown-item" href="IPCOverview.html"> 3.1. Concurrency with IPC</a>
|
||
<a class="dropdown-item" href="IPCModels.html"> 3.2. IPC Models</a>
|
||
<a class="dropdown-item" href="Pipes.html"> 3.3. Pipes and FIFOs</a>
|
||
<a class="dropdown-item" href="MMap.html"> 3.4. Shared Memory With Memory-mapped Files</a>
|
||
<a class="dropdown-item" href="POSIXvSysV.html"> 3.5. POSIX vs. System V IPC</a>
|
||
<a class="dropdown-item" href="MQueues.html"> 3.6. Message Passing With Message Queues</a>
|
||
<a class="dropdown-item" href="ShMem.html"> 3.7. Shared Memory</a>
|
||
<a class="dropdown-item" href="IPCSems.html"> 3.8. Semaphores</a>
|
||
<a class="dropdown-item" href="Extended3Bash.html"> 3.9. Extended Example: Bash-lite: A Simple Command-line Shell</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 4</b></a>
|
||
<a class="dropdown-item" href="SocketsOverview.html"> 4.1. Networked Concurrency</a>
|
||
<a class="dropdown-item" href="FiveLayer.html"> 4.2. The TCP/IP Internet Model</a>
|
||
<a class="dropdown-item" href="NetApps.html"> 4.3. Network Applications and Protocols</a>
|
||
<a class="dropdown-item" href="Sockets.html"> 4.4. The Socket Interface</a>
|
||
<a class="dropdown-item" href="TCPSockets.html"> 4.5. TCP Socket Programming: HTTP</a>
|
||
<a class="dropdown-item" href="UDPSockets.html"> 4.6. UDP Socket Programming: DNS</a>
|
||
<a class="dropdown-item" href="AppBroadcast.html"> 4.7. Application-Layer Broadcasting: DHCP</a>
|
||
<a class="dropdown-item" href="Extended4CGI.html"> 4.8. Extended Example: CGI Web Server</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 5</b></a>
|
||
<a class="dropdown-item" href="InternetOverview.html"> 5.1. The Internet and Connectivity</a>
|
||
<a class="dropdown-item" href="AppLayer.html"> 5.2. Application Layer: Overlay Networks</a>
|
||
<a class="dropdown-item" href="TransLayer.html"> 5.3. Transport Layer</a>
|
||
<a class="dropdown-item" href="NetSec.html"> 5.4. Network Security Fundamentals</a>
|
||
<a class="dropdown-item" href="NetLayer.html"> 5.5. Network Layer: IP</a>
|
||
<a class="dropdown-item" href="LinkLayer.html"> 5.6. Link Layer</a>
|
||
<a class="dropdown-item" href="Wireless.html"> 5.7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee</a>
|
||
<a class="dropdown-item" href="Extended5DNS.html"> 5.8. Extended Example: DNS client</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 6</b></a>
|
||
<a class="dropdown-item" href="ThreadsOverview.html"> 6.1. Concurrency with Multithreading</a>
|
||
<a class="dropdown-item" href="ProcVThreads.html"> 6.2. Processes vs. Threads</a>
|
||
<a class="dropdown-item" href="RaceConditions.html"> 6.3. Race Conditions and Critical Sections</a>
|
||
<a class="dropdown-item" href="POSIXThreads.html"> 6.4. POSIX Thread Library</a>
|
||
<a class="dropdown-item" href="ThreadArgs.html"> 6.5. Thread Arguments and Return Values</a>
|
||
<a class="dropdown-item" href="ImplicitThreads.html"> 6.6. Implicit Threading and Language-based Threads</a>
|
||
<a class="dropdown-item" href="Extended6Input.html"> 6.7. Extended Example: Keyboard Input Listener</a>
|
||
<a class="dropdown-item" href="Extended6Primes.html"> 6.8. Extended Example: Concurrent Prime Number Search</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 7</b></a>
|
||
<a class="dropdown-item" href="SynchOverview.html"> 7.1. Synchronization Primitives</a>
|
||
<a class="dropdown-item" href="CritSect.html"> 7.2. Critical Sections and Peterson's Solution</a>
|
||
<a class="dropdown-item" href="Locks.html"> 7.3. Locks</a>
|
||
<a class="dropdown-item" href="Semaphores.html"> 7.4. Semaphores</a>
|
||
<a class="dropdown-item" href="Barriers.html"> 7.5. Barriers</a>
|
||
<a class="dropdown-item" href="Condvars.html"> 7.6. Condition Variables</a>
|
||
<a class="dropdown-item" href="Deadlock.html"> 7.7. Deadlock</a>
|
||
<a class="dropdown-item" href="Extended7Events.html"> 7.8. Extended Example: Event Log File</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 8</b></a>
|
||
<a class="dropdown-item" href="SynchProblemsOverview.html"> 8.1. Synchronization Patterns and Problems</a>
|
||
<a class="dropdown-item" href="SynchDesign.html"> 8.2. Basic Synchronization Design Patterns</a>
|
||
<a class="dropdown-item" href="ProdCons.html"> 8.3. Producer-Consumer Problem</a>
|
||
<a class="dropdown-item" href="ReadWrite.html"> 8.4. Readers-Writers Problem</a>
|
||
<a class="dropdown-item" href="DiningPhil.html"> 8.5. Dining Philosophers Problem and Deadlock</a>
|
||
<a class="dropdown-item" href="CigSmokers.html"> 8.6. Cigarette Smokers Problem and the Limits of Semaphores and Locks</a>
|
||
<a class="dropdown-item" href="Extended8ModExp.html"> 8.7. Extended Example: Parallel Modular Exponentiation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 9</b></a>
|
||
<a class="dropdown-item" href="ParallelDistributedOverview.html"> 9.1. Parallel and Distributed Systems</a>
|
||
<a class="dropdown-item" href="ParVConc.html"> 9.2. Parallelism vs. Concurrency</a>
|
||
<a class="dropdown-item" href="ParallelDesign.html"> 9.3. Parallel Design Patterns</a>
|
||
<a class="dropdown-item" href="Scaling.html"> 9.4. Limits of Parallelism and Scaling</a>
|
||
<a class="dropdown-item" href="DistTiming.html"> 9.5. Timing in Distributed Environments</a>
|
||
<a class="dropdown-item" href="DistDataStorage.html"> 9.6. Reliable Data Storage and Location</a>
|
||
<a class="dropdown-item" href="DistConsensus.html"> 9.7. Consensus in Distributed Systems</a>
|
||
<a class="dropdown-item" href="Extended9Blockchain.html"> 9.8. Extended Example: Blockchain Proof-of-Work</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Appendix A</b></a>
|
||
<a class="dropdown-item" href="CLangOverview.html"> A.1. C Language Reintroduction</a>
|
||
<a class="dropdown-item" href="Debugging.html"> A.2. Documentation and Debugging</a>
|
||
<a class="dropdown-item" href="BasicTypes.html"> A.3. Basic Types and Pointers</a>
|
||
<a class="dropdown-item" href="Arrays.html"> A.4. Arrays, Structs, Enums, and Type Definitions</a>
|
||
<a class="dropdown-item" href="Functions.html"> A.5. Functions and Scope</a>
|
||
<a class="dropdown-item" href="Pointers.html"> A.6. Pointers and Dynamic Allocation</a>
|
||
<a class="dropdown-item" href="Strings.html"> A.7. Strings</a>
|
||
<a class="dropdown-item" href="FunctionPointers.html"> A.8. Function Pointers</a>
|
||
<a class="dropdown-item" href="Files.html"> A.9. Files</a>
|
||
</div>
|
||
</li>
|
||
|
||
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<ul class="navbar-nav flex-row ml-md-auto d-none d-md-flex">
|
||
<li class="nav-item"><a class="nav-link jmu-gold" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/source/LinkLayer.rst"
|
||
target="_blank" rel="nofollow">Show Source</a></li>
|
||
|
||
</ul>
|
||
</nav>
|
||
|
||
|
||
<div class="container center">
|
||
«  <a id="prevmod" href="NetLayer.html">5.5. Internet Layer: IP</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod" href="Wireless.html">5.7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee</a>  »
|
||
|
||
</div>
|
||
<br />
|
||
|
||
|
||
|
||
<script type="text/javascript" src="_static/js/jquery-2.1.4.min.js"></script>
|
||
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||
<script type="text/javascript" src="_static/js/jquery-1.11.4-ui.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/forge-0.7.0.min.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/jquery.transit.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/raphael.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/build/JSAV-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/config.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaUtils-min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaMOD-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-4.13.0.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-selection-multi.v1.min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/dataStructures.js"></script>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<script>ODSA.SETTINGS.DISP_MOD_COMP = true;ODSA.SETTINGS.MODULE_NAME = "LinkLayer";ODSA.SETTINGS.MODULE_LONG_NAME = "Link Layer";ODSA.SETTINGS.MODULE_CHAPTER = "The Internet and Connectivity"; ODSA.SETTINGS.BUILD_DATE = "2021-06-11 17:38:24"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script><div class="section" id="link-layer">
|
||
<h1>5.6. Link Layer<a class="headerlink" href="LinkLayer.html#link-layer" title="Permalink to this headline">¶</a></h1>
|
||
<p>The Internet layer determines the logical path that packets will traverse through a local network
|
||
and the Internet as a whole. The link layer defines the protocols that control how the bits are
|
||
transmitted across an underlying physical technology. For example, the network shown previously in
|
||
<a href="NetLayer.html#netdijkstra">Figure 5.5.3</a> places an emphasis on <a class="reference internal" href="Glossary.html#term-routing"><span class="xref std std-term">routing</span></a> a packet through a series
|
||
of routers in an AS. These routers may be part of distinct networks that use different underlying
|
||
technologies. For instance, each router may be operated and administered by separate departments
|
||
that are part of the same organization; some links may consist of wireless connections, while other
|
||
logical links are created by a chain of <a class="reference internal" href="Glossary.html#term-switch"><span class="xref std std-term">switches</span></a>—router-like devices that are connected by
|
||
cables. The link layer, then, focuses on the task of <a class="reference internal" href="Glossary.html#term-forwarding"><span class="xref std std-term">forwarding</span></a> packets across
|
||
point-to-point connections between routers and end-point devices.</p>
|
||
<p>The distinction of routing and forwarding, like the distinction between routers and switches, is
|
||
subtle and can be misunderstood. In essence, the classification of routing/routers is used to
|
||
describe the communication between heterogeneous networks that may rely on different types of
|
||
communication technologies. One network might employ a <a class="reference internal" href="Glossary.html#term-packet-switching"><span class="xref std std-term">packet switching</span></a> technology (e.g.,
|
||
Ethernet) that uses a structured message format that allows any device to send and receive data at
|
||
any time. A router might connect that network to one that uses <a class="reference internal" href="Glossary.html#term-circuit-switching"><span class="xref std std-term">circuit switching</span></a> (e.g., FDDI
|
||
or token ring), in which two devices communicate directly over a dedicated channel; other devices
|
||
may be connected to the network, but they have to wait until it is their turn to control the
|
||
transmission channel. In contrast, the classification of forwarding/switches refers to communication
|
||
within a homogeneous network with a single underlying technology. A switch does not receive a
|
||
message from one technology (Ethernet) and forward it using another (FDDI). Switches only serve as
|
||
the links between hosts in a single network.</p>
|
||
<p>The switching that occurs at the link layer creates another possible source of packet loss that
|
||
TCP’s reliability is intended to address. When a packet arrives, there is a <a class="reference internal" href="Glossary.html#term-processing-delay"><span class="xref std std-term">processing delay</span></a>
|
||
associated with the work to compute checksums, determine the higher-level protocol, and so on.
|
||
<a class="reference internal" href="Glossary.html#term-queueing-delay"><span class="xref std std-term">Queueing delays</span></a> occur while the packet is waiting to be processed or
|
||
transmitted. <a class="reference internal" href="Glossary.html#term-transmission-delay"><span class="xref std std-term">Transmission delays</span></a> are imposed by the work to encode the
|
||
data into light signals or radio waves. Since the light signals and radio waves must travel across
|
||
physical space, the packet also experiences <a class="reference internal" href="Glossary.html#term-propagation-delay"><span class="xref std std-term">propagation delays</span></a>. These
|
||
delays occur at every switching link in the network, accumulating to create increasingly greater
|
||
round-trip times. Consequently, link-layer protocols strive to balance correctness (ensuring limited
|
||
re-transmissions) with efficient processing in order to avoid causing packet losses.</p>
|
||
<div class="section" id="lan-packet-transmission-ethernet">
|
||
<h2>5.6.1. LAN Packet Transmission: Ethernet<a class="headerlink" href="LinkLayer.html#lan-packet-transmission-ethernet" title="Permalink to this headline">¶</a></h2>
|
||
<p>Given the ubiquity of the technology, many readers probably associate the term <a class="reference internal" href="Glossary.html#term-ethernet"><span class="xref std std-term">Ethernet</span></a> with the
|
||
cable. In actuality, Ethernet is a collection of standards defined and maintained by the
|
||
<a class="reference internal" href="Glossary.html#term-ieee-802-3"><span class="xref std std-term">IEEE 802.3</span></a> working group. That is, Ethernet is not defined as a stand-alone protocol defined in an RFC;
|
||
Ethernet involves several protocols that are co-designed with the physical cable technology that
|
||
they use. These physical technologies can range from <em>twisted-pair</em> copper wires to
|
||
<em>fiber-optic</em> wires made of glass or plastic.</p>
|
||
<p>Regardless of the type of the physical medium used, all Ethernet frames maintain the same basic
|
||
structure, shown in <a class="reference external" href="LinkLayer.html#tbl5-12">Table 5.12</a>. Note the use of the term <em>octet</em> rather than <em>byte</em>.
|
||
Although modern systems have generally settled on the use of the term byte to denote eight bits,
|
||
this connotation was not always true; some technologies used byte to refer to a basic addressable
|
||
unit of memory, which was not necessarily eight bits in size. An octet, however, must be exactly
|
||
eight bits. <a class="footnote-reference" href="LinkLayer.html#f38" id="id1">[1]</a></p>
|
||
<center>
|
||
<table class="table table-bordered">
|
||
<thead class="jmu-dark-purple-bg text-light">
|
||
<tr>
|
||
<th class="py-0 center">8 octets</th>
|
||
<th class="py-0 center">6 octets</th>
|
||
<th class="py-0 center">6 octets</th>
|
||
<th class="py-0 center">2 octets</th>
|
||
<th class="py-0 center">varies</th>
|
||
<th class="py-0 center">4 octets</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="py-0 center"><code>Preamble</code></td>
|
||
<td class="py-0 center"><code>Destination</code></td>
|
||
<td class="py-0 center"><code>Source</code></td>
|
||
<td class="py-0 center"><code>Type</code></td>
|
||
<td class="py-0 center"><code>Payload</code></td>
|
||
<td class="py-0 center"><code>CRC</code></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p>
|
||
Table 5.12: Structure of an Ethernet frame
|
||
</p>
|
||
</center><p>The <code class="docutils literal notranslate"><span class="pre">preamble</span></code> of an Ethernet frame consists of seven octets of <code class="docutils literal notranslate"><span class="pre">10101010</span></code> followed by a single
|
||
octet of <code class="docutils literal notranslate"><span class="pre">10101011</span></code>. The purpose of the <code class="docutils literal notranslate"><span class="pre">preamble</span></code> is to declare to a device intends to send a
|
||
frame and to synchronize the other devices to listen as receivers. The destination and source
|
||
addresses are 48-bit (6-octet) <a class="reference internal" href="Glossary.html#term-media-access-control-address"><span class="xref std std-term">media access control (MAC) addresses</span></a>. <a class="footnote-reference" href="LinkLayer.html#f39" id="id2">[2]</a> Unlike IP
|
||
addresses, MAC addresses are persistently associated with a hardware device and do not provide any
|
||
implication of the device’s logical location in the network. MAC addresses are determined by the
|
||
device manufacturer and are stored in either firmware or hard-wired storage. The type field of the
|
||
Ethernet frame determines which Ethernet protocol standard is being used. The payload contains the
|
||
Internet-layer data (e.g., an IP packet); the maximum size varies based on the version of Ethernet,
|
||
but most have a <a class="reference internal" href="Glossary.html#term-maximum-transmit-unit"><span class="xref std std-term">maximum transmit unit</span></a> (MTU) size of approximately 1500 octets. Finally, the
|
||
frame ends with the <code class="docutils literal notranslate"><span class="pre">field</span> <span class="pre">checksum</span></code> (<code class="docutils literal notranslate"><span class="pre">FCS</span></code>), which is a 32-bit <a class="reference internal" href="Glossary.html#term-cyclic-redundancy-check"><span class="xref std std-term">cyclic redundancy check</span></a>
|
||
(CRC) calculation that provides a more robust error detection mechanism than checksums. As one
|
||
example of the difference, CRC values can detect when the order of the octets has been changed,
|
||
while checksums cannot.</p>
|
||
<p>The MTU size implies that a lot of network traffic requires multiple frames. Consider an HTTP
|
||
request to load a GIF containing an Internet meme showing a short video of cats (people on the
|
||
Internet love cat videos!). Image files tend to be multiple MB in size. If a single video is 3 MB in
|
||
size, that image alone would require 2098 blocks of 1500 bytes. However, each frame must also have
|
||
the TCP/UDP and IP headers attached, so some of the 1500 bytes is already accounted for. Using the
|
||
bare minimum of 20 bytes for TCP and 40 for IP, the image would now require 2185 frames. This
|
||
fragmentation exacerbates the reliability service of TCP, as all of these frames must be
|
||
successfully transmitted (repeatedly) before the RTT timeout occurs. If any frame fails to arrive on
|
||
time, the TCP client (i.e., the web browser) declares the entire image lost and provides the user
|
||
with a (generally unhelpful) error message that the connection timed out. Hence the reason that
|
||
OSPF, RIP, and BGP prioritize finding the shortest, most efficient path possible.</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3" id="linkethernet">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Example.png"><img alt="Decorative example icon" src="_images/CSF-Images-Example.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Example 5.6.1 </p><hr class="mt-1" />
|
||
<p>To illustrate the structure of an Ethernet frame, the following header extends the IPv4 datagram
|
||
from <a href="NetLayer.html#netipexample">Example 5.5.1</a> (which extends the TCP segment from <a href="TransLayer.html#transtcpexample">Example 5.3.2</a>).</p>
|
||
<center>
|
||
<table class="table table-bordered">
|
||
<thead class="jmu-dark-purple-bg text-light">
|
||
<tr>
|
||
<td class="py-0 center">Preamble</td>
|
||
<td class="py-0 center">Destination</td>
|
||
<td class="py-0 center">Source</td>
|
||
<td class="py-0 center">Type</td>
|
||
<td class="py-0 center">Payload</td>
|
||
<td class="py-0 center">FCS</td>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="py-0 center"><code>aaaaaaaaaaaaaaab</code></td>
|
||
<td class="py-0 center"><code>f0def12cc22b</code></td>
|
||
<td class="py-0 center"><code>f45c89bd332d</code></td>
|
||
<td class="py-0 center"><code>0800</code></td>
|
||
<td class="py-0 center"><code>...</code></td>
|
||
<td class="py-0 center"><code>64713722</code></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</center><p>The destination field is the MAC address <code class="docutils literal notranslate"><span class="pre">f0-de-f1-2c-c2-2b</span></code>, and the source field is the address
|
||
<code class="docutils literal notranslate"><span class="pre">4f-5c-89-bd-33-2d</span></code>. These identifiers are persistently associated with the networking hardware
|
||
components. The type 0800 indicates that this frame is using Ethernet II, the most common style of
|
||
Ethernet framing. Finally, the FCS is the 32-bit CRC calculation over the entire frame.</p>
|
||
<p>The figure below illustrates the complete structure of the Ethernet frame by combining this example
|
||
with <a href="TransLayer.html#transtcpexample">Example 5.3.2</a> and <a href="LinkLayer.html">NetIPExample</a>. The frame begins with the Ethernet
|
||
header. The Ethernet payload combines the IPv4 header, TCP header, and HTTP header. (As a <code class="docutils literal notranslate"><span class="pre">GET</span></code>
|
||
request, the HTTP message body is empty and only the header is sent.) At the same time, the IPv4
|
||
payload consists of the TCP and HTTP headers, whereas the HTTP header is the payload of the TCP
|
||
segment.</p>
|
||
<div class="figure mb-2 align-center">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images.5.EX.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="Anatomy of a complete Ethernet frame with IPv4, TCP, and HTTP data" src="_images/CSF-Images.5.EX.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p>Anatomy of a complete Ethernet frame with IPv4, TCP, and HTTP data</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="lan-packet-transmission-arp">
|
||
<h2>5.6.2. LAN Packet Transmission: ARP<a class="headerlink" href="LinkLayer.html#lan-packet-transmission-arp" title="Permalink to this headline">¶</a></h2>
|
||
<div class="figure mb-2 align-right" id="id3" style="width: 40%">
|
||
<span id="linkarp"></span><a class="reference internal image-reference" href="_images/CSF-Images.5.11.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="Devices connected to the same Ethernet segment" src="_images/CSF-Images.5.11.png" style="width: 95%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 5.6.3: Devices connected to the same Ethernet segment</span></p>
|
||
</div>
|
||
<p>The previous discussion of Ethernet introduced a new form of addressing to locate hosts within a
|
||
network. <a href="LinkLayer.html#linkarp">Figure 5.6.3</a> shows a simple Ethernet segment with two end devices and a
|
||
router; each of these three hosts has both a MAC address and an IP address. MAC addresses do not
|
||
have any logical relationship to the network topology itself, while IP addresses are logical
|
||
identifiers that are not tied to the hardware. As such, routers need some way to translate an IP
|
||
address into a MAC address. Without such a mapping, routers would not be able to encapsulate the IP
|
||
packet in an Ethernet frame for the intended host device.</p>
|
||
<p>The <a class="reference internal" href="Glossary.html#term-address-resolution-protocol"><span class="xref std std-term">Address Resolution Protocol</span></a> (ARP) is a simple protocol for establishing this mapping, as
|
||
defined in RFC 826. Assume that the two end host devices in <a href="LinkLayer.html#linkarp">Figure 5.6.3</a> need to communicate, with
|
||
the 192.168.1.2 host sending data to 192.168.1.3. The sender broadcasts an Ethernet frame containing
|
||
an ARP query to the reserved MAC address <code class="docutils literal notranslate"><span class="pre">ff-ff-ff-ff-ff-ff</span></code>. All nodes receive the query, but
|
||
only the intended recipient, 192.168.1.3, replies. At that point, the 192.168.1.2 host stores this
|
||
mapping in a local cache for a period of time. After doing this, 192.168.1.2 can use the appropriate
|
||
destination MAC address to transmit the IP packets as needed.</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Note.png"><img alt="Decorative note icon" src="_images/CSF-Images-Note.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Note</p><hr class="mt-1" />
|
||
<p>ARP is an insecure protocol that assumes all connected devices behave correctly. In an <a class="reference internal" href="Glossary.html#term-arp-cache-poisoning"><span class="xref std std-term">ARP
|
||
cache poisoning</span></a> attack, an adversary that has access to a network can respond to ARP queries with
|
||
its own MAC address. The protocol defines no authentication mechanism to confirm that the response
|
||
is correct. This weakness is often acceptable if networks are secured so that only authorized
|
||
devices can be used. However, in public settings, such as a free café Wi-Fi network, the assumption
|
||
of trust can break down, allowing devices to intercept messages intended for others.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="what-lies-beneath-carrier-signals">
|
||
<h2>5.6.3. What Lies Beneath: Carrier Signals<a class="headerlink" href="LinkLayer.html#what-lies-beneath-carrier-signals" title="Permalink to this headline">¶</a></h2>
|
||
<p>To summarize the Internet model up to this point, the application layer uses transport-layer
|
||
protocols to create a process-to-process logical communication channel. The transport layer
|
||
encapsulates this information in a host-to-host link using Internet-layer routing between
|
||
potentially heterogeneous networks. The link layer then provides the mechanism for point-to-point
|
||
data transmission in a homogeneous network using the same underlying physical technology. These
|
||
layers of abstraction leave one question remaining: How do the bits actually get transmitted from
|
||
one device to another?</p>
|
||
<p><a href="LinkLayer.html#linkcarrier">Figure 5.6.5</a> illustrates the basic principles involved in the physical data
|
||
transmission. Fundamentally, all of the physical networking technologies are transmitting either
|
||
light or radio signals, both of which can be modeled as an oscillating waveform. The default signal
|
||
with no encoded information is called a <a class="reference internal" href="Glossary.html#term-carrier-signal"><span class="xref std std-term">carrier signal</span></a>. This signal can be <em>modulated</em>
|
||
to encode information by manipulating one of three characteristics of waves:
|
||
frequency, amplitude, or phase. The frequency refers to the number of
|
||
oscillations in a given time, as illustrated by how many times the wave oscillates between a maximum
|
||
and minimum value. The amplitude denotes the height of the wave. The phase refers to the timing of
|
||
when the wave begins and ends, illustrated by the alignment of the maximum and minimum values.</p>
|
||
<div class="figure mb-2 align-center" id="id4">
|
||
<span id="linkcarrier"></span><a class="reference internal image-reference" href="_images/CSF-Images.5.12.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="Three techniques for modulating a carrier signal to encode bits" src="_images/CSF-Images.5.12.png" style="width: 70%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 5.6.5: Three techniques for modulating a carrier signal to encode bits</span></p>
|
||
</div>
|
||
<p>In <a class="reference internal" href="Glossary.html#term-phase-shift-keying"><span class="xref std std-term">phase shift keying</span></a> (PSK), the carrier wave operates at a fixed frequency, but its phase
|
||
is manipulated by changing the sine and cosine of the inputs. The precise calculations depend on the
|
||
particular scheme being used, but these techniques generally all map the measurement values to
|
||
points on the complex number plane. In binary PSK (BPSK), there are two possible points to indicate
|
||
the values 0 or 1. Other schemes use more points to map multiple bits. For instance, each
|
||
measurement in quadrature PSK (QPSK) maps to one of four points to encode two bits; 8-PSK uses eight
|
||
points to encode three bits.</p>
|
||
<p>In <a class="reference internal" href="Glossary.html#term-frequency-modulation"><span class="xref std std-term">frequency modulation</span></a> (FM), the frequency is changed to be either faster or slower than
|
||
the carrier wave. If this technique were used on sound waves that were in a range audible to humans,
|
||
FM would correspond to making the pitch higher or lower than the default range. <a class="reference internal" href="Glossary.html#term-amplitude-modulation"><span class="xref std std-term">Amplitude
|
||
modulation</span></a> (AM) keeps the frequency the same as the carrier wave but increases or decreases the
|
||
magnitude of the difference between the maximum and minimum values. In the audible range, this would
|
||
correspond to making the sound louder or softer.</p>
|
||
<p>FM and AM have long been used for analog signal transmission. Readers may associate these terms with
|
||
radio stations, and for good reason: Radio stations with AM channels use amplitude modulation to
|
||
encode sound in the range of 540 kHz to 1600 kHz (kHz = 1,000 cycles per second). FM radio stations
|
||
use frequency modulation to encode sound between 88 MHz and 108 MHz (MHz = 1,000,000 cycles per
|
||
second). So, a radio station that advertises itself as FM 101.1 is sending a stream of bits by
|
||
changing the frequency to be slightly above and slightly below 101.1 MHz. Note, though, that FM and
|
||
AM are not restricted to analog radio signals. All three techniques are used to modulate digital
|
||
signals, as well.</p>
|
||
<p>Consequently, when we say that Ethernet is sending the preamble of a frame by changing the
|
||
transmitted bit from 1 to 0, it means that the network device is using one of these techniques to
|
||
manipulate the signal it is transmitting. The received performs the corresponding de-modulation to
|
||
restore the carrier wave and records the transmitted bit. By coordinating this signal transmission,
|
||
the link layer can transmit a packet from one network device to another. These links can then be
|
||
chained together to establish network routing, leading to higher levels of communication protocols.</p>
|
||
<table class="docutils footnote" frame="void" id="f38" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="LinkLayer.html#id1">[1]</a></td><td>The bit ordering in Ethernet can be confusing to interpret. Ethernet writes the most
|
||
significant <em>octet</em> first, but the least significant <em>bit</em> within the octet is written first. For
|
||
example, the hexadecimal value <code class="docutils literal notranslate"><span class="pre">0xa7</span></code> would be written as <code class="docutils literal notranslate"><span class="pre">1110</span> <span class="pre">0101</span></code> rather than <code class="docutils literal notranslate"><span class="pre">1010</span>
|
||
<span class="pre">0111</span></code>. We ignore this detail in <a href="LinkLayer.html#linkethernet">Example 5.6.1</a> for simplicity.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<table class="docutils footnote" frame="void" id="f39" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="LinkLayer.html#id2">[2]</a></td><td>There is no relationship between a MAC address as described here and the cryptographic
|
||
notion of MAC—message authentication code.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<div
|
||
id="InterLinkSumm"
|
||
class="embedContainer"
|
||
data-exer-name="InterLinkSumm"
|
||
data-long-name="Link layer questions"
|
||
data-short-name="InterLinkSumm"
|
||
data-frame-src="../../../Exercises/Internet/InterLinkSumm.html?selfLoggingEnabled=false&localMode=true&module=LinkLayer&JXOP-debug=true&JOP-lang=en&JXOP-code=java"
|
||
data-frame-width="950"
|
||
data-frame-height="775"
|
||
data-external="false"
|
||
data-points="1.0"
|
||
data-required="True"
|
||
data-showhide="show"
|
||
data-threshold="5"
|
||
data-type="ka"
|
||
data-exer-id="">
|
||
|
||
<div class="center">
|
||
<div id="InterLinkSumm_iframe"></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<div class="mt-4 container center">
|
||
«  <a id="prevmod1" href="NetLayer.html">5.5. Internet Layer: IP</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod1" href="Wireless.html">5.7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee</a>  »
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
<br />
|
||
|
||
<div class="row jmu-dark-purple-bg">
|
||
<div class="col-md-12">
|
||
<center>
|
||
<a id="contact_us" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="mailto:webmaster@opencsf.org" role="button">Contact Us</a>
|
||
<a id="license" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/lib/license.html" target="_blank">License</a>
|
||
</center>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<script src="_static/js/popper.js-1.14.7-min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
|
||
<script src="_static/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
|
||
</body>
|
||
</html> |