whitespace, links, spelling fixes

README.rst

@@ -15,9 +15,9 @@ parties. Please reach out to
 If you make use of this work, the attribution should include the
 following information:
 
-| *Title: Software-Defined Networks: A Systems Approach* 
-| *Authors: Larry Peterson, Carmelo Cascone, Brian O'Connor, Thomas Vachuska, and Bruce Davie* 
-| *Source:* https://github.com/SystemsApproach/SDN 
+| *Title: Software-Defined Networks: A Systems Approach*
+| *Authors: Larry Peterson, Carmelo Cascone, Brian O'Connor, Thomas Vachuska, and Bruce Davie*
+| *Source:* https://github.com/SystemsApproach/SDN
 | *License:* \ `CC BY-NC-ND 4.0 <https://creativecommons.org/licenses/by-nc-nd/4.0>`__
 
 Read the Book
@@ -28,18 +28,18 @@ This book is part of the `Systems Approach Series
 at `https://sdn.systemsapproach.org
 <https://sdn.systemsapproach.org>`__.
 
+
 To track progress and receive notices about new versions, you can follow
 the project on
-`Facebook <https://www.facebook.com/Computer-Networks-A-Systems-Approach-110933578952503/>`__
-and `Mastodon <https://discuss.systems/@SystemsAppr>`__. To read a running
-commentary on how the Internet is evolving, follow the `Systems Approach
-on Substack <https://systemsapproach.substack.com>`__.
+`Mastodon <https://discuss.systems/@SystemsAppr>`__. To read a running
+commentary on how the Internet is evolving, and for updates on our writing projects, you can sign up for the
+`Systems Approach newsletter <https://systemsapproach.org/newsletter/>`__.
 
-Releases and Editions 
+Releases and Editions
 ---------------------
 
 We continually release open source content in GitHub, with `print and
-ebook editions <https://www.systemsapproach.org/books.html>`__
+ebook editions <https://www.systemsapproach.org/books/>`__
 published from time-to-time. The latest print and ebook (2nd Printing)
 corresponds to the ``v2.0`` tag.
 

access.rst

@@ -43,7 +43,7 @@ edge of the ISP’s network—the ISP-side of the last-mile that directly
 connects to customers. The PON and RAN-based access networks are
 anchored in these facilities.
 
-9.1.1 Passive Optical Network 
+9.1.1 Passive Optical Network
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A PON is a tree-structured, fiber-based network, starting with a
@@ -64,13 +64,13 @@ to the Internet. The BNG is a piece of Telco equipment that, in
 addition to forwarding packets, also authenticates users,
 differentiates the level of service delivered to each customer, and
 meters traffic for the sake of billing.
-  
+
 .. _fig-pon:
 .. figure:: figures/Slide54.png
    :width: 600px
    :align: center
 
-   An example PON that connects OLTs in the Central Office 
+   An example PON that connects OLTs in the Central Office
    to ONUs in homes and businesses.
 
 Because the splitters are passive, PON implements a multi-access
@@ -116,7 +116,7 @@ across base stations, and so on).
    :width: 700px
    :align: center
 
-   A Radio Access Network (RAN) connecting a set of cellular devices 
+   A Radio Access Network (RAN) connecting a set of cellular devices
    (User Equipment—UEs) to a Mobile Core hosted in a Central Office.
 
 The figure shows the Mobile Core and set of base stations
@@ -183,11 +183,11 @@ mobile networks so they can be implemented in software, we recommend
 the following companion book.
 
 .. _reading_5g:
-.. admonition:: Further Reading  
+.. admonition:: Further Reading
 
    L. Peterson and O. Sunay.
    `5G Mobile Networks: A Systems Approach <https://5g.systemsapproach.org/>`__.
-   June 2020. 
+   June 2020.
 
 
 9.2 SD-PON
@@ -226,10 +226,10 @@ described in Chapter 7.  The following describes the high-points of
 the rest of SD-PON architecture.
 
 .. _fig-sdpon:
-.. figure:: figures/Slide61.png 
+.. figure:: figures/Slide61.png
     :width: 500px
     :align: center
-	    
+
     Software-Defined PON architecture.
 
 First, a hardware abstraction layer, called *VOLTHA (Virtual OLT
@@ -296,12 +296,12 @@ velocity. Because of this, mobile network operators are working to
 make Software-Defined RAN (SD-RAN) happen.
 
 .. _reading_sdran:
-.. admonition:: Further Reading  
-   
-   `SD-RAN Project  
-   <https://opennetworking.org/sd-ran/>`__. 
-   Open Networking Foundation. August 2020. 
-   
+.. admonition:: Further Reading
+
+   `SD-RAN Project
+   <https://opennetworking.org/open-ran/>`__.
+   Open Networking Foundation. August 2020.
+
 To understand the technical underpinnings of SD-RAN, it is important
 to recognize that the base stations that make up the RAN are, for all
 practical purposes, specialized packet switches. The set of base
@@ -339,10 +339,10 @@ the base station as a pipeline (running left-to-right for packets sent
 to the UE) but it is equally valid to view it as a protocol stack.
 
 .. _fig-basestation:
-.. figure:: figures/Slide56.png 
+.. figure:: figures/Slide56.png
     :width: 600px
     :align: center
-	    
+
     RAN processing pipeline, including both user and
     control plane components.
 
@@ -387,7 +387,7 @@ multiple split-points, with the partition shown in :numref:`Figure %s
 this chapter.
 
 .. _fig-split-ran:
-.. figure:: figures/Slide57.png 
+.. figure:: figures/Slide57.png
     :width: 600px
     :align: center
 
@@ -404,10 +404,10 @@ part of the MAC stage is responsible for all real-time scheduling
 decisions.
 
 .. _fig-ran-hierarchy:
-.. figure:: figures/Slide58.png 
+.. figure:: figures/Slide58.png
     :width: 350px
     :align: center
-	    
+
     Split-RAN hierarchy, with one CU serving multiple DUs,
     each of which serves multiple RUs.
 
@@ -420,7 +420,7 @@ to a small cell, many of which might be spread across a modestly-sized
 geographic area (e.g., a mall, campus, or factory), then a single DU
 would likely service multiple RUs. The use of mmWave in 5G is likely
 to make this later configuration all the more common.
-    
+
 9.3.2 RAN Intelligent Controller
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -581,7 +581,7 @@ implies the xApps must be aware of the available Service Models. This
 is problematic in that it implicitly couples applications with
 devices, but defining a device-agnostic version is still a
 work-in-progress.
- 
+
 9.4  Role of SD-Fabric
 -----------------------------------
 
@@ -635,7 +635,7 @@ speaking, AMF is responsible for mobility management, SMF is
 responsible for session management, and AUSF is responsible for
 authentication. All the other functional blocks correspond to
 low-level processes that AMF, SMF, and AUSF call to do their job, but
-for our purposes, you can think of the entire set as 
+for our purposes, you can think of the entire set as
 microservices running on commodity servers. For more details about the
 Mobile Core control plane, as well as examples of specific
 implementation choices, we recommend the *Magma* and *SD-Core* open
@@ -647,7 +647,7 @@ source projects.
    `Magma Core Project <https://www.magmacore.org/>`__.
    Linux Foundation. 2021.
 
-   `SD-Core Project  <https://opennetworking.org/sd-core/>`__. 
+   `SD-Core Project  <https://opennetworking.org/sd-core/>`__.
    Open Networking Foundation. 2021.
 
 What is important to our discussion is that while the UPF can also be
@@ -673,7 +673,7 @@ SmartNIC connected to those servers. MacDavid and colleagues describe
 the mechanism for doing this is more detail.
 
 .. _reading_upf:
-.. admonition:: Further Reading  
+.. admonition:: Further Reading
 
    R. MacDavid, *et al.* `A P4-based 5G User Plane Function
    <https://www.cs.princeton.edu/~macdavid/media/up4-sosr21.pdf>`__.
@@ -694,7 +694,7 @@ package that can be deployed in enterprises and managed as a cloud
 service.
 
 .. _reading_aether:
-.. admonition:: Further Reading  
+.. admonition:: Further Reading
 
-   `Aether: 5G-Connected Edge  <https://opennetworking.org/aether/>`__. 
+   `Aether: 5G-Connected Edge  <https://opennetworking.org/aether/>`__.
    Open Networking Foundation. 2021.

arch.rst

@@ -44,10 +44,10 @@ components, correspond to a combination of *gNMI*, *gNOI* and
 and either *P4Runtime* or *OpenFlow* in the second case.  gRPC, an
 open source remote procedure call framework, is
 shown as the transport protocol for these APIs—an implementation
-choice, but one that we will generally assume from here 
+choice, but one that we will generally assume from here
 on. (Note that OpenFlow, unlike the other protocols, does not run over
 gRPC.) We discuss all of these acronyms and interfaces in further
-detail below. 
+detail below.
 
 
 .. _fig-stack:
@@ -101,7 +101,7 @@ per-switch.
 
 The second is that part of the SDN software stack runs on the end
 hosts. In particular, there is a *Virtual Switch (vSwitch)*—typically
-implemented in software as part of the hypervisor 
+implemented in software as part of the hypervisor
 running on the server—that is responsible for forwarding packets to
 and from the VMs. (Of course, not every end-host runs VMs, but a
 similar architecture applies to containers hosts or bare-metal servers.)
@@ -112,27 +112,27 @@ connected to physical machines.
 
 .. sidebar:: Host-Centric Perspective
 
-	*This book adopts a network-oriented perspective of SDN, one
-	that treats the end-host (both the virtual switch running in
-	the host OS and the NIC connecting the host to the network) as
-	an extension of the network, running under the control of a
-	Network OS. A more host-centric perspective is equally valid,
-	and perhaps more importantly, comes with a robust ecosystem of
-	open source software that runs as part of the host OS.*
-
-	*DPDK is one example, but another gaining traction is the
-	combination of eBPF (extended Berkeley Packet Filter) and XDP
-	(eXpress Data Path). When used together, they provide a way to
-	program generalized Match-Action rules in the OS kernel, or
-	potentially even on a SmartNIC.  This is similar in spirit to
-	OpenFlow and P4, except they allow for the Action part to be
-	an arbitrary program. In contrast, OpenFlow defines a fixed
-	set of Actions, and P4 is a restricted language for expressing
-	Actions (e.g., it does not include loops). This is necessary
-	when the Action must execute within a fixed cycle budget, as
-	is the case for a switch-based forwarding pipeline. It also
-	enables formal verification of the data plane, a promising
-	opportunity discussed in Chapter 10.*
+     *This book adopts a network-oriented perspective of SDN, one
+     that treats the end-host (both the virtual switch running in
+     the host OS and the NIC connecting the host to the network) as
+     an extension of the network, running under the control of a
+     Network OS. A more host-centric perspective is equally valid,
+     and perhaps more importantly, comes with a robust ecosystem of
+     open source software that runs as part of the host OS.*
+
+     *DPDK is one example, but another gaining traction is the
+     combination of eBPF (extended Berkeley Packet Filter) and XDP
+     (eXpress Data Path). When used together, they provide a way to
+     program generalized Match-Action rules in the OS kernel, or
+     potentially even on a SmartNIC.  This is similar in spirit to
+     OpenFlow and P4, except they allow for the Action part to be
+     an arbitrary program. In contrast, OpenFlow defines a fixed
+     set of Actions, and P4 is a restricted language for expressing
+     Actions (e.g., it does not include loops). This is necessary
+     when the Action must execute within a fixed cycle budget, as
+     is the case for a switch-based forwarding pipeline. It also
+     enables formal verification of the data plane, a promising
+     opportunity discussed in Chapter 10.*
 
 Fortunately, we can view a vSwitch as behaving just like a physical
 switch, including the APIs it supports. That a vSwitch is implemented
@@ -161,7 +161,7 @@ forwarding pipeline found on the network switches. Again, there are a
 range of possible implementation choices, including both FPGA and
 ASIC, as well as whether the NIC is fixed-function or programmable
 (using P4). For our purposes, we will treat such Smart NICs as yet
-another switching element along the end-to-end path.	
+another switching element along the end-to-end path.
 
 3.2 Bare-Metal Switch
 -------------------------
@@ -245,17 +245,17 @@ Stratum-managed API is defined as follows:
   forwarding model and how the control plane interacts with it.
   (For completeness, :numref:`Figure %s
   <fig-stack>` also lists OpenFlow as an alternative control interface.)
-  
+
 * **gNMI (gRPC Network Management Interface):** Used to set and
   retrieve configuration state. gNMI is usually paired with OpenConfig
   YANG models that define the structure of the configuration and state
   tree.
-  
+
 * **gNOI (gRPC Network Operations Interfaces):** Used to set and
   retrieve operational state, for example supporting certificates
   management, device testing, software upgrades, and networking
   troubleshooting.
-  
+
 If you recall the distinction between Control and Configuration
 introduced in Chapter 1, then you will recognize P4Runtime as the
 Control API and the gNMI/gNOI combination as a modern version of a
@@ -289,18 +289,18 @@ things:
 * **Managing Topology:** Tracks inventory of network infrastructure
   devices and their interconnection to provide a shared view of the
   network environment for the rest of the platform and applications.
-  
+
 * **Managing Configuration:** Facilitates issuing, tracking, rolling
   back, and validating atomic configuration operations on multiple
   network devices. This effectively mirrors the per-switch
   configuration and operation interfaces (also using gNMI and gNOI),
   but does so at the network level rather than the device level.
-  
+
 * **Controlling Switches:** Controls the data plane packet
   processing pipelines of the network switches and provides subsequent control
   of flow rules, groups, meters and other building blocks within those
   pipelines.
-  
+
 With respect to this last role, ONOS exports a northbound
 *FlowObjectives* abstraction, which generalizes Flow Rules in a
 pipeline-independent way.\ [#]_ This interface, which Chapter 6
@@ -366,7 +366,7 @@ supports several control plane features, including:
 * Dual-homing of servers and upstream routers
 * QinQ forwarding/termination
 * MPLS-based pseudowires.
-  
+
 For each of these features, the corresponding Control App interacts
 with ONOS—by observing changes in the network topology and issuing
 Flow Objectives—rather than by using any of the standard protocol

code/onos2.txt

@@ -1,3 +1,3 @@
 onos> route-add <prefix> <nexthop>
-onos> route-add 1.1.0.0/18 10.0.1.20 
+onos> route-add 1.1.0.0/18 10.0.1.20
 onos> route-add 2020::101/120 2000::1

conf.py

@@ -103,9 +103,9 @@ def get_version():
     }
 
 # Ignore link check for the following websites
-# linkcheck_ignore = [
-#     'https://SDN.systemspproach.org/',
-# ]
+linkcheck_ignore = [
+     'https://amzn.to/', 'https://amazon.com'
+]
 
 # -- Options for HTML output -------------------------------------------------
 

dict.txt

@@ -112,6 +112,7 @@ commoditized
 compositional
 config
 cyber
+cyberattacks
 datapath
 de
 di
@@ -180,7 +181,7 @@ subgraph
 subnet
 subnets
 syscall
-tized 
+tized
 toolchain
 toolchains
 toolset