diff --git a/README.rst b/README.rst index ad81d42..4cdd44a 100644 --- a/README.rst +++ b/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 `__ Read the Book @@ -28,18 +28,18 @@ This book is part of the `Systems Approach Series at `https://sdn.systemsapproach.org `__. + To track progress and receive notices about new versions, you can follow the project on -`Facebook `__ -and `Mastodon `__. To read a running -commentary on how the Internet is evolving, follow the `Systems Approach -on Substack `__. +`Mastodon `__. 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 `__. -Releases and Editions +Releases and Editions --------------------- We continually release open source content in GitHub, with `print and -ebook editions `__ +ebook editions `__ published from time-to-time. The latest print and ebook (2nd Printing) corresponds to the ``v2.0`` tag. diff --git a/access.rst b/access.rst index bf3f362..39afd78 100644 --- a/access.rst +++ b/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 `__. - 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 - `__. - Open Networking Foundation. August 2020. - +.. admonition:: Further Reading + + `SD-RAN Project + `__. + 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 `__. Linux Foundation. 2021. - `SD-Core Project `__. + `SD-Core Project `__. 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 `__. @@ -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 `__. + `Aether: 5G-Connected Edge `__. Open Networking Foundation. 2021. diff --git a/arch.rst b/arch.rst index 2b196e9..38fcf1f 100644 --- a/arch.rst +++ b/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 ` 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 diff --git a/code/onos2.txt b/code/onos2.txt index f7e6a66..2912009 100644 --- a/code/onos2.txt +++ b/code/onos2.txt @@ -1,3 +1,3 @@ onos> route-add -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 diff --git a/conf.py b/conf.py index 7ba6354..a026b71 100644 --- a/conf.py +++ b/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 ------------------------------------------------- diff --git a/dict.txt b/dict.txt index 685bc50..a448f4c 100644 --- a/dict.txt +++ b/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 diff --git a/exercises.rst b/exercises.rst index 7c1c5c3..1d23c02 100644 --- a/exercises.rst +++ b/exercises.rst @@ -177,17 +177,17 @@ order. .. [#] SD-Fabric was previously known as Trellis, and still is in the code. UPF was previously known as SPGW, and still is in the code. - - -1. `P4Runtime Basics `__ -2. `YANG, OpenConfig, gNMI Basics `__ -3. `Using ONOS as the Control Plane `__ -4. `Enabling ONOS Built-in Services `__ -5. `Implementing IPv6 Routing with ECMP `__ -6. `Implementing SRv6 `__ + + +1. `P4Runtime Basics `__ +2. `YANG, OpenConfig, gNMI Basics `__ +3. `Using ONOS as the Control Plane `__ +4. `Enabling ONOS Built-in Services `__ +5. `Implementing IPv6 Routing with ECMP `__ +6. `Implementing SRv6 `__ 7. `SD-Fabric (Trellis) Basics `__ -8. `GTP Termination with fabric.p4 `__ +8. `GTP Termination with fabric.p4 `__ You can find solutions for each exercise in the ``solution`` subdirectory for the repo you cloned. Feel free to compare your diff --git a/future.rst b/future.rst index f34f287..ea2d464 100644 --- a/future.rst +++ b/future.rst @@ -57,12 +57,12 @@ value SDN brings to the table, which leads to optimism that .. _reading_pronto: -.. admonition:: Further Reading - +.. admonition:: Further Reading + N. Foster, et. al. `Using Deep Programmability to Put Network Owners in Control `__. - ACM SIGCOMM Computer Communication Review, October 2020. + ACM SIGCOMM Computer Communication Review, October 2020. :numref:`Figure %s ` illustrates the basic idea. The software stack described in this book is augmented with the @@ -85,7 +85,7 @@ reason about correctness-by-construction. control loop that verifies the network’s behavior. .. sidebar:: Top-Down Verification - + *The approach to verifying networks described in this chapter is similar to the one used in chip design. At the top is a behavioral model; then at the register-transfer level is a Verilog or VHDL @@ -112,7 +112,7 @@ processed; these programs are compiled to run on the forwarding plane elements. Such an approach represents a fundamental new capability that has not been possible in conventional designs, based on two key insights. - + First, while network control planes are inherently complicated, a P4 data plane captures *ground truth* for the network—i.e., how it forwards packets—and is therefore an attractive platform for deploying @@ -195,6 +195,6 @@ implementing their intent. Just as the hardware industry has developed high confidence that chips will work as intended before they go into manufacturing, network operators will have confidence that their networks are reliable, secure, and meeting their specified -objectives. +objectives. diff --git a/index.rst b/index.rst index 9d333ca..646dbbd 100644 --- a/index.rst +++ b/index.rst @@ -1,10 +1,10 @@ .. image:: _static/SystemsApproachLogoURL.png :width: 300px :align: center - :target: https://systemsapproach.org + :target: https://systemsapproach.org | - + Software-Defined Networks: A Systems Approach ============================================= @@ -14,11 +14,11 @@ Peterson, Cascone, O’Connor, Vachuska, and Davie | .. toctree:: - :maxdepth: 2 - :caption: Table of Contents + :maxdepth: 2 + :caption: Table of Contents - foreword.rst - preface.rst + foreword.rst + preface.rst intro.rst uses.rst arch.rst diff --git a/intro.rst b/intro.rst index 5951091..cb8a19f 100644 --- a/intro.rst +++ b/intro.rst @@ -90,13 +90,13 @@ the underlying hardware (including processor chips), to the operating system running on that hardware, to the application itself. .. _fig-market1: -.. figure:: figures/Slide01.png - :width: 600px - :align: center +.. figure:: figures/Slide01.png + :width: 600px + :align: center - Transformation of the vertical mainframe market to a horizontal - marketplace with open interfaces and multiple options available at - every level. + Transformation of the vertical mainframe market to a horizontal + marketplace with open interfaces and multiple options available at + every level. As shown in :numref:`Figure %s `, the introduction of microprocessors (e.g., Intel x86 and Motorola 68000) and open source @@ -131,7 +131,7 @@ in turn enable a rich marketplace of networking applications. The value of such a transformation is clear. Opening a vertically integrated, closed, and proprietary market creates opportunities for innovation that would not otherwise be available. Or to put it another -way: by opening up these interfaces, it becomes possible +way: by opening up these interfaces, it becomes possible to shift control from the vendors that sell networking equipment to the network operators that build networks to meet their users' needs. @@ -221,7 +221,7 @@ switches in more detail. .. [#] By our count, over 15 open-source and proprietary disaggregated control planes are available today. - + Disaggregating the control and data planes implies the need for a well-defined *forwarding abstraction*, that is, a general-purpose way for the control plane to instruct the data plane to forward packets in @@ -327,7 +327,7 @@ disaggregation implied by SDN would not be viable. At the same time, operators are accustomed to configuring their switches and routers. This has historically been done using a *Command Line Interface (CLI)* or (less commonly) a management protocol like -SNMP. +SNMP. Looking back at :numref:`Figure %s `, this corresponds to the northbound interface to the RIB (as opposed to the interface between the RIB and the FIB). This interface is capable of installing new routes, which on @@ -340,7 +340,7 @@ The answer is likely no, and it comes down to hitting the mark on both generality and performance. While a well-defined programmatic configuration interface is certainly an improvement over legacy CLIs, they are intended for modifying various settings of the control plane -(such as RIB entries) and +(such as RIB entries) and other device parameters (e.g., port speeds/modes) rather than modifying the data plane’s FIB. As a consequence, such configuration interfaces are (a) unlikely to support the full range of @@ -440,7 +440,7 @@ of distributed algorithms like Link-State and Distance-Vector routing protocols) and the app is free to simply run the shortest path algorithm on this graph and load the resulting flow rules into the underlying switches. An introduction to Link-State and -Distance-Vector routing algorithms is available online. +Distance-Vector routing algorithms is available online. .. _reading_routing: .. admonition:: Further Reading @@ -487,57 +487,57 @@ endpoints" then it is quite reasonable to make that request part of an automated configuration system. This is precisely what happens in many modern clouds, where the provisioning of network resources and policies is automated along with all sort of other operations such as spinning up -virtual machines or containers. +virtual machines or containers. .. sidebar:: Domain of Control - *The “Centralized vs Decentralized” framing of this section is - intended to characterize one dimension of the SDN design - space, not to indicate that network operators face an - either-or situation. There are many factors that impact where - a given operator comes down on this spectrum, but one place to - start is to scope the domain to which SDN is being applied. We - discuss example use cases in Chapter 2, but there is a natural - evolution of networking that highlights the thought process.* - - *Historically, there has been one control plane instance per - switch and they both run together on the same box. As simple - routers grew into chassis routers, there were typically N - control plane instances for M line cards. They ran on discrete - hardware and talked to each other through a management - network. As chassis routers grew into a multi-rack fabric - built from commodity switches, SDN suggested a design that - aggregates forwarding elements under a control plane running - anywhere and structured as a distributed system. The advantage - is that such a system can use modern techniques for state - distribution and management, rather than being tied to - standards. The key is to find domains for which it is possible - to optimize performance with a logically centralized control - plane. This book describes several such domains where SDN is - providing value.* - -Returning to the original question of centralized versus distributed -control plane, proponents of the latter often base their rationale on -the historical reasons the Internet adopted distributed routing -protocols in the first place: scale, and survival in the face of failures. The + *The “Centralized vs Decentralized” framing of this section is + intended to characterize one dimension of the SDN design + space, not to indicate that network operators face an + either-or situation. There are many factors that impact where + a given operator comes down on this spectrum, but one place to + start is to scope the domain to which SDN is being applied. We + discuss example use cases in Chapter 2, but there is a natural + evolution of networking that highlights the thought process.* + + *Historically, there has been one control plane instance per + switch and they both run together on the same box. As simple + routers grew into chassis routers, there were typically N + control plane instances for M line cards. They ran on discrete + hardware and talked to each other through a management + network. As chassis routers grew into a multi-rack fabric + built from commodity switches, SDN suggested a design that + aggregates forwarding elements under a control plane running + anywhere and structured as a distributed system. The advantage + is that such a system can use modern techniques for state + distribution and management, rather than being tied to + standards. The key is to find domains for which it is possible + to optimize performance with a logically centralized control + plane. This book describes several such domains where SDN is + providing value.* + +Returning to the original question of centralized versus distributed +control plane, proponents of the latter often base their rationale on +the historical reasons the Internet adopted distributed routing +protocols in the first place: scale, and survival in the face of failures. The concern is that any centralized solution results in a bottleneck that -is also a single -point-of-failure. Distributing the centralized control plane over a +is also a single +point-of-failure. Distributing the centralized control plane over a cluster of servers mitigates both these concerns, as techniques developed in the distributed systems world can ensure both high availability and scalability of such clusters. -A secondary concern raised about control plane centralization is -that, since the control plane is remote (i.e., off-switch), the link -between the two planes adds a vulnerable attack surface. The -counter-argument is that non-SDN networks already have (and depend on) -out-of-band management networks, so this attack surface is not a new -one. These management networks can be used by off-switch controllers +A secondary concern raised about control plane centralization is +that, since the control plane is remote (i.e., off-switch), the link +between the two planes adds a vulnerable attack surface. The +counter-argument is that non-SDN networks already have (and depend on) +out-of-band management networks, so this attack surface is not a new +one. These management networks can be used by off-switch controllers just as readily as by other management software. There is also the argument that a small number of centralized controllers can present a smaller attack surface than a large number of distributed controllers. Suffice it to say, opinions differ, but there is certainly a wealth of support for the -centralized approach. +centralized approach. 1.2.3 Data Plane: Programmable vs Fixed-Function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -651,7 +651,7 @@ done changing the protocol stack, but that's unlikely. For example, QUIC is gaining momentum as an alternative to TCP when used with HTTP. Another example on the horizon is MPLS vs SRv6. Even VXLAN is now being superseded in some settings by a new, more flexible encapsulation -called GENEVE. +called GENEVE. Programmable forwarding pipelines, coupled with a high-level language that can be used to program the pipeline, is one viable response to @@ -667,9 +667,9 @@ includes the possibility of a programmable data plane. To summarize, the original definition of SDN is simple to state: - *A network in which the control plane is physically separate - from the forwarding plane, and a single control plane - controls several forwarding devices*.\ [#]_ + *A network in which the control plane is physically separate + from the forwarding plane, and a single control plane + controls several forwarding devices*.\ [#]_ This is a succinct way of saying what Sections 1.2.1 and 1.2.2 explain in long-form. Since that original definition, SDN has been interpreted @@ -706,4 +706,4 @@ predictions about the next phase of the SDN journey in Chapter 10. March 2021. - + diff --git a/latest.rst b/latest.rst index ad1405b..273e413 100644 --- a/latest.rst +++ b/latest.rst @@ -3,10 +3,11 @@ :pop:`Read the Latest!` ======================== -`Substack Newsletter: `__ Stay -up-to-date with the latest developments by following the authors on -`Substack `__, where they -connect the concepts and lessons in this book to what's happening in +`Systems Approach Newsletter: +`__ Stay up to date with the +latest developments by subscribing to the `Systems Approach Newsletter +`__, where the authors +connect the concepts and lessons in this book to what’s happening in the Internet today. `Book Series: `__ Also check out @@ -14,10 +15,10 @@ our companion books that cover emerging topics in more depth. * `Private 5G: A Systems Approach `__ -* `TCP Congestion Control: A Systems Approach `__ +* `TCP Congestion Control: A Systems Approach `__ * `Edge Cloud Operations: A Systems Approach `__ .. * `Software-Defined Networks: A Systems Approach `__ - + diff --git a/netvirt.rst b/netvirt.rst index 9fc3803..246b962 100644 --- a/netvirt.rst +++ b/netvirt.rst @@ -34,11 +34,11 @@ system to implement network virtualization. .. _reading_NVP: .. admonition:: Further Reading - + T. Koponen et al. `Network Virtualization in Multi-tenant Datacenters `__. NSDI, April, 2014. - + The following sections show how a particular set of technology challenges, combined with the new capabilities offered by SDN, set the @@ -269,7 +269,7 @@ the management plane. .. figure:: figures/Slide46.png :width: 450px :align: center - + The Three Planes of a Network Virtualization System. At the bottom of :numref:`Figure %s ` is the data @@ -333,7 +333,7 @@ detects that the actual state no longer corresponds to the desired state. That triggers a fresh computation to determine the updates that need to be pushed to the data plane, such as new forwarding rules to the appropriate set of vSwitches, and deletion of data plane state at -the hypervisor that no longer hosts one of the VMs. +the hypervisor that no longer hosts one of the VMs. With this architecture, we can implement a rich set of features for virtual networks. Provided the data plane has sufficient richness to @@ -492,7 +492,7 @@ vSwitch (OVS).* B. Pfaff, et al, `The Design and Implementation of Open vSwitch `__, - USENIX NSDI 2015. + USENIX NSDI 2015. Open vSwitch has been used in proprietary systems such as Nicira’s Network Virtualization Platform and VMware NSX, as well as open source @@ -529,7 +529,7 @@ is also worth noting that OVSDB has taken on a life of its own, beyond the role shown in :numref:`Figure %s `, as a general way to represent network forwarding state. We'll see an example of this broader role in Section 8.4. - + As for the OVS data plane, performance has been achieved via a long series of optimizations described in the Pfaff paper, notably a @@ -614,7 +614,7 @@ with a potential performance gain. The challenge is in trading flexibility for performance, as SmartNICs are still more resource-constrained than general-purpose CPUs. The latest generation of SmartNICs is reaching a level of sophistication where offloading -some or all of the vSwitch functions could be effective.\ [#]_ +some or all of the vSwitch functions could be effective.\ [#]_ .. [#] As an aside, P4 is gaining traction as a way to program SmartNICs, suggesting the possibility of convergence in how the @@ -631,7 +631,7 @@ by Davie, *et al.* .. _reading_OVSDB: .. admonition:: Further Reading - + B. Davie, et al. `A Database Approach to SDN Control Plane Design `__. Computer Communications Review, January 2017. @@ -715,7 +715,7 @@ Database*. We can see how logical flows work with an example shown in :align: center Logical and Physical Flows in OVN. - + Logical data path flows provide an abstract representation of the forwarding rules that are populated in the data @@ -739,7 +739,7 @@ location of VMs and report it up to the database. So we see that the controller on ``HV1`` (hypervisor 1) has reported into the ``Chassis`` table that it can be reached using the Geneve encapsulation at IP address ``10.0.0.10``. And that same hypervisor has reported into the -``Port_Binding`` table that it is hosting the VM with ``LP1``. +``Port_Binding`` table that it is hosting the VM with ``LP1``. In order to program the data plane, the OVN controller for @@ -767,10 +767,10 @@ Southbound databases. .. _reading_OVN: .. admonition:: Further Reading - + Open Virtual Network. `OVN Reference Guide `__. - + Everything discussed up to this point has assumed that we are talking about VMs as the endpoints for our virtual networks, but everything @@ -797,7 +797,7 @@ delivering infrastructure as a service. May eventually generalize to "Impact of Network Virtualization" with multiple subsections, but at this point there is only one impact, so we make it a top-level section. - + One of the interesting side-effects of network virtualization is that it enabled a change in the way security is implemented in the datacenter. As noted above, network virtualization enables security @@ -853,7 +853,7 @@ impossible before the arrival of network virtualization. Microsegmentation has become an accepted best practice for datacenter networking, providing a starting point for "zero-trust" networking. This illustrates the far-reaching impact of network -virtualization. +virtualization. 8.6 Is Network Virtualization SDN? ---------------------------------- @@ -863,7 +863,7 @@ Virtualization is the most successful early application of SDN. But is it really SDN? There has been considerable debate on this topic, which reflects that there has been plenty of argument about exactly what SDN is. - + The main argument against Network Virtualization's inclusion in SDN is that it didn't change the way physical networks are built. It simply runs as an overlay on top of a standard L2/L3 network, which might run diff --git a/onos.rst b/onos.rst index d5e03cc..7a02fc2 100644 --- a/onos.rst +++ b/onos.rst @@ -32,14 +32,14 @@ Using ONOS as our model, the architecture of a Network OS is shown in and notifying applications about relevant changes in that state. Internal to the core is a scalable key/value store called Atomix. - + 3. A Southbound Interface (SBI) constructed from a collection of plugins including shared protocol libraries and device-specific drivers. - + .. _fig-onos: -.. figure:: figures/Slide26.png - :width: 700px - :align: center +.. figure:: figures/Slide26.png + :width: 700px + :align: center Three-layer architecture of ONOS, hosting a set of control applications. @@ -87,9 +87,9 @@ privileged kernel and multiple user domains. In other words, ONOS currently operates in a single trust domain. .. _fig-ztp: -.. figure:: figures/Slide28.png - :width: 500px - :align: center +.. figure:: figures/Slide28.png + :width: 500px + :align: center Example of a Zero-Touch Provisioning (ZTP) application taking a “role spec” for a switch being installed as input, with ONOS @@ -112,9 +112,9 @@ forwarding pipelines is a complexity ONOS is explicitly designed to address. .. _fig-layers: -.. figure:: figures/Slide27.png - :width: 500px - :align: center +.. figure:: figures/Slide27.png + :width: 500px + :align: center ONOS manages the mapping of an abstract specification of network-wide behavior to a collection of per-device instructions. @@ -153,7 +153,7 @@ Ongaro and John Ousterhout. The website also provides a helpful visualization tool. .. _reading_p4: -.. admonition:: Further Reading +.. admonition:: Further Reading D. Ongaro and J. Ousterhout. `The Raft Consensus Algorithm `__. @@ -244,9 +244,9 @@ where the middle three components—Topology, Link, and Device—are example ONOS services. .. _fig-services1: -.. figure:: figures/Slide29.png - :width: 350px - :align: center +.. figure:: figures/Slide29.png + :width: 350px + :align: center ONOS provides a set of services, such as the Topology, Device, and Link Services, on top of a corresponding table (Map) implemented @@ -265,12 +265,12 @@ As a whole, ONOS defines an interconnected graph of services, with subgraph. :numref:`Figure %s ` expands on that view to illustrate some other aspects of the ONOS core, this time simplified to show the Atomix maps as an attribute of some (but not all) of the -services. +services. .. _fig-services2: -.. figure:: figures/Slide33.png - :width: 550px - :align: center +.. figure:: figures/Slide33.png + :width: 550px + :align: center Dependency graph of services (some with their own key/value maps) involved in building a Path Service. @@ -322,9 +322,9 @@ from :numref:`Figure %s `. Network Config Service when there is a discrepancy. .. _fig-services3: -.. figure:: figures/Slide34.png - :width: 300px - :align: center +.. figure:: figures/Slide34.png + :width: 300px + :align: center Network Config Service, supporting both provisioning applications and human operators. @@ -443,7 +443,7 @@ extensions in the next Chapter when we take a closer look at SD-Fabric. 6.3 Northbound Interface ------------------------ -The ONOS NBI has multiple parts. First, there is a corresponding API +The ONOS NBI has multiple parts. First, there is a corresponding API for every service included in a given configuration of ONOS. For example, the “Topology” interface shown in :numref:`Figure %s ` is exactly the API offered by the Topology Service shown @@ -491,9 +491,9 @@ address, VLAN tag, and IP address combination, without regard for the exact sequence of pipeline tables that implement that combination. .. _fig-flowobj: -.. figure:: figures/Slide39.png - :width: 500px - :align: center +.. figure:: figures/Slide39.png + :width: 500px + :align: center Flow Objective Service manages the mapping of pipeline-agnostic objectives onto pipeline-specific rules. @@ -572,12 +572,12 @@ between ONOS applications and core services (above) and the network environment (below), as illustrated in :numref:`Figure %s `. .. _fig-plugins: -.. figure:: figures/Slide35.png - :width: 550px - :align: center +.. figure:: figures/Slide35.png + :width: 550px + :align: center ONOS Southbound Interface (SBI) is extended by Provider Plugins. - + :numref:`Figure %s ` includes two general kinds of Provider plugins. The first type is protocol-specific, with OpenFlow and gNMI being typical examples. Each of these Providers effectively @@ -616,17 +616,17 @@ ensure that it is able to respond to a scalable number of control events in a timely way. It must also remain available in the face of failures. This section describes how ONOS scales to meet these performance and availability requirements. We start with some scale -and performance numbers to provide a sense of the state-of-the-art +and performance numbers to provide a sense of the state-of-the-art in centralized network control (at the time of writing): * **Scale:** ONOS supports up to 50 network devices; 5000 network ports; 50k subscribers, 1M routes; and 5M flow rules/groups/meters. - + * **Performance:** ONOS supports up to 10k configuration ops/day; 500k flow ops/sec (sustained); 1k topology events/sec (peak); 50ms to detect port/switch up events; 5ms to detect port/switch down events; 3ms for flow ops; and 6ms for hand-over events (RAN). - + Production deployments run at least three instances of ONOS, but this is more for availability than performance. Each instance runs on a 32-Core/128GB-RAM server and is deployed as a Docker container using @@ -638,13 +638,13 @@ configuration that scales the key/value store independently from the rest of ONOS. .. _fig-ha: -.. figure:: figures/Slide42.png - :width: 600px - :align: center +.. figure:: figures/Slide42.png + :width: 600px + :align: center Multiple ONOS instances, all sharing network state via Atomix, - provide scalable performance and high availability. - + provide scalable performance and high availability. + :numref:`Figure %s ` illustrates ONOS scaling across multiple instances, where the set of instances shares network state via Atomix Maps. The figure also shows that each instance is responsible for a diff --git a/preface.rst b/preface.rst index e25e45f..afa146e 100644 --- a/preface.rst +++ b/preface.rst @@ -1,4 +1,4 @@ -Preface +Preface ======= The Internet is in the midst of a transformation, one that moves away diff --git a/stratum.rst b/stratum.rst index f5b74e5..f0e82ce 100644 --- a/stratum.rst +++ b/stratum.rst @@ -2,7 +2,7 @@ Chapter 5: Switch OS ====================== This chapter describes the operating system running on every bare-metal -switch. +switch. A good mental model is to think of this as analogous to a server OS: there is a general-purpose processor running a Linux-based OS, plus a “packet forwarding accelerator” similar in @@ -42,8 +42,8 @@ section only as a way of grounding the description of an end-to-end workflow for developers implementing SDN-based solutions. .. _fig-stratum: -.. figure:: figures/Slide17.png - :width: 500px +.. figure:: figures/Slide17.png + :width: 500px :align: center High-level schematic of Stratum, a Thin Switch OS running on top @@ -128,8 +128,8 @@ original P4 forwarding program as an abstract graph rather than with actual P4 source code. .. _fig-toolchain: -.. figure:: figures/Slide18.png - :width: 600px +.. figure:: figures/Slide18.png + :width: 600px :align: center P4 toolchain achieves ASIC-independence and auto-generates @@ -182,7 +182,7 @@ elements and their attributes as defined in the source P4 program.\ [#]_ The table element is one obvious example, but there are others, including ``counters`` and ``meters``, which are used to report status information up to the controller and to allow the -controller to specify a QoS rate, respectively. However, neither of +controller to specify a QoS rate, respectively. However, neither of these are included in our example program. .. [#] In principle, this P4Info file is not strictly required, as the @@ -251,21 +251,21 @@ models programmable and hence, adaptable to this iterative process. .. sidebar:: Cloud Best Practices - *Our commentary on OpenConfig vs. NETCONF is grounded in a - fundamental tenet of SDN, which is about bringing best - practices in cloud computing to the network. It involves big - ideas like implementing the network control plane as a - scalable cloud service, but it also includes more narrow - benefits, such as using modern messaging frameworks like - gRPC and protobufs.* - - *The advantages in this particular case are tangible: (1) - improved and optimized transport using HTTP/2 and - protobuf-based marshalling instead of SSH plus hand-coded - marshalling; (2) binary data encodings instead of text-based - encoding; (3) diff-oriented data exchange instead of - snapshot-based responses; and (4) native support for server - push and client streaming.* + *Our commentary on OpenConfig vs. NETCONF is grounded in a + fundamental tenet of SDN, which is about bringing best + practices in cloud computing to the network. It involves big + ideas like implementing the network control plane as a + scalable cloud service, but it also includes more narrow + benefits, such as using modern messaging frameworks like + gRPC and protobufs.* + + *The advantages in this particular case are tangible: (1) + improved and optimized transport using HTTP/2 and + protobuf-based marshalling instead of SSH plus hand-coded + marshalling; (2) binary data encodings instead of text-based + encoding; (3) diff-oriented data exchange instead of + snapshot-based responses; and (4) native support for server + push and client streaming.* This is where an industry-wide standardization effort, called *OpenConfig*, comes into play. OpenConfig is a group of network @@ -325,8 +325,8 @@ languages (Stratum happens to use C++), where the client and server sides of the gRPC need not be written in the same language. .. _fig-yang: -.. figure:: figures/Slide25.png - :width: 550px +.. figure:: figures/Slide25.png + :width: 550px :align: center YANG toolchain used to generate gRPC-based runtime for gNMI. @@ -349,8 +349,8 @@ definitions supported by the device. The ``Get`` and ``Set`` methods are used to read and write the corresponding variable defined in some models. The ``Subscribe`` method is used to set up a stream of telemetry updates from the device. The corresponding arguments and -return values (e.g., ``GetRequest``, ``GetResponse``) are defined -by a protobuf ``Message`` and include various fields from the YANG +return values (e.g., ``GetRequest``, ``GetResponse``) are defined +by a protobuf ``Message`` and include various fields from the YANG models. A given field is specified by giving its fully qualified path name in the data model tree. diff --git a/switch.rst b/switch.rst index 651f496..bbd7703 100644 --- a/switch.rst +++ b/switch.rst @@ -1,4 +1,4 @@ -Chapter 4: Bare-Metal Switches +Chapter 4: Bare-Metal Switches =============================== This chapter describes the bare-metal switches that provide the @@ -37,11 +37,11 @@ figure. As of this writing, the state-of-the-art for these chips is 25.6 Tbps with 400-Gbps ports. .. _fig-switch: -.. figure:: figures/Slide10.png - :width: 500px - :align: center +.. figure:: figures/Slide10.png + :width: 500px + :align: center - High-Level schematic of a bare-metal switch. + High-Level schematic of a bare-metal switch. Note that our use of the term NPU might be considered a bit non-standard. Historically, NPU was the name given to more narrowly-defined network processing @@ -50,7 +50,7 @@ packet inspection. They were not as general-purpose as the NPUs we are discussing in this chapter, nor were they as high-performance. The long-term trend, however, has been toward NPUs that match the performance of -fixed-function ASICs while providing a much higher degree of flexibility. +fixed-function ASICs while providing a much higher degree of flexibility. It seems likely that the current merchant silicon switching chips will make the earlier generation of purpose-built network processors obsolete. The NPU nomenclature used here is consistent with the @@ -89,7 +89,7 @@ switch. A standard BIOS called the *Open Network Install Environment (ONIE)* has emerged under the OCP’s stewardship, and so we assume ONIE throughout the rest of the chapter. -4.2 Forwarding Pipeline +4.2 Forwarding Pipeline ---------------------------------- High-speed switches use a multi-stage pipeline to process packets. The @@ -291,7 +291,7 @@ What exactly does ``arch.p4`` define? Essentially three things: the output signals to influence the behavior of the following blocks (e.g., the output queue/port where a packet has to be directed). - + 2. Type declarations for *externs*, which can be seen as additional fixed-function services that are exposed by the target and which can be invoked by a P4 programmer. Examples of such externs are @@ -299,7 +299,7 @@ What exactly does ``arch.p4`` define? Essentially three things: ciphers to encrypt/decrypt the packet payload, and so on. The implementation of such externs is *not* specified in P4 by the architecture, but their interface is. - + 3. Extensions to core P4 language types, including alternative match types (e.g., ``range`` and ``lpm`` described in Section 4.4.3). @@ -337,13 +337,13 @@ respective ASICs. Until that happens, PSA will remain a mostly “on paper” artifact. .. _fig-v1model: -.. figure:: figures/Slide22.png - :width: 650px - :align: center +.. figure:: figures/Slide22.png + :width: 650px + :align: center - V1Model used in practice to abstract away the details of different - physical forwarding pipelines. Developers write P4 to this - abstract architectural model. + V1Model used in practice to abstract away the details of different + physical forwarding pipelines. Developers write P4 to this + abstract architectural model. When we say P4 developers “write to this model” we are being more descriptive than you might think. In practice, every P4 program starts @@ -405,7 +405,7 @@ the switches I intend to program? Does my program need access to chip-specific capabilities (e.g., a P4 extern to encrypt/decrypt packet payload) or can it rely solely on common/non-differentiating features (e.g., simple match-action tables or a P4 extern to count -packets)? +packets)? As for that forwarding program (which we've been generically referring to as ``forward.p4``), an interesting tangible example is a program @@ -426,34 +426,34 @@ discover we need a new feature. .. sidebar:: Is the Complexity Worth It? - *At this point you may be wondering if all the complexity - being introduced is worth it, and we haven't even gotten to - the control plane yet! What we've covered so far is complex - with or without SDN. That's because we're working at the SW/HW - boundary, and the hardware is designed to forward packets at - rates measured in Terabits-per-second. This complexity use to - be hidden inside proprietary devices. One thing SDN has done - is put pressure on the marketplace to open up that space so - others can innovate.* - - *But before anyone can innovate, the first step is to reproduce - what we had running before, except now using open interfaces - and programmable hardware. Even though this chapter uses - forward.p4 as a hypothetical new data plane function - someone might write, it's really programs like switch.p4 - (plus the Switch OS described in the next chapter) that - establish parity with legacy networking gear. Once we have - that in place, we are ready to do something new. But what?* - - *It is not our goal to answer that question with any - certainty. The VNF off-loading and INT examples introduced in - Chapter 2 are a start. Software-defined 5G networks - (Chapter 9) and closed-loop verification (Chapter 10) are - potential killer-apps. But history teaches us that killer-apps - are impossible to predict with any accuracy. On the other - hand, history also includes many examples of how opening - closed, fixed-function systems leads to qualitatively new - capabilities.* + *At this point you may be wondering if all the complexity + being introduced is worth it, and we haven't even gotten to + the control plane yet! What we've covered so far is complex + with or without SDN. That's because we're working at the SW/HW + boundary, and the hardware is designed to forward packets at + rates measured in Terabits-per-second. This complexity use to + be hidden inside proprietary devices. One thing SDN has done + is put pressure on the marketplace to open up that space so + others can innovate.* + + *But before anyone can innovate, the first step is to reproduce + what we had running before, except now using open interfaces + and programmable hardware. Even though this chapter uses + forward.p4 as a hypothetical new data plane function + someone might write, it's really programs like switch.p4 + (plus the Switch OS described in the next chapter) that + establish parity with legacy networking gear. Once we have + that in place, we are ready to do something new. But what?* + + *It is not our goal to answer that question with any + certainty. The VNF off-loading and INT examples introduced in + Chapter 2 are a start. Software-defined 5G networks + (Chapter 9) and closed-loop verification (Chapter 10) are + potential killer-apps. But history teaches us that killer-apps + are impossible to predict with any accuracy. On the other + hand, history also includes many examples of how opening + closed, fixed-function systems leads to qualitatively new + capabilities.* To summarize, the overarching goal is to enable the development of control apps without regard to the specific details of the device @@ -517,7 +517,7 @@ block, this standard metadata structure includes such fields as ``ingress_port`` (port the packet arrived on), ``egress_port`` (port selected to send the packet out on), and ``drop`` (bit set to indicate the packet is to be dropped). These fields can be read or written by -the functional blocks that make up the rest of the program.\ [#]_ +the functional blocks that make up the rest of the program.\ [#]_ .. [#] A quirk of the V1Model is that there are two egress port fields in the metadata structure. One (``egress_port``) is read-only and @@ -601,7 +601,7 @@ example, PSA also defines ``range`` and ``selector`` matches. The final step of the ingress routine is to “apply” the table we just defined. This is done only if the parser (or previous pipeline stage) marked the IP header as valid. - + .. literalinclude:: code/ingress.p4 4.4.4 Egress Processing @@ -618,7 +618,7 @@ will see as many copies of the same packet as those generated by the traffic manager. As a second example, if one switch port is expected to send VLAN-tagged packets, the header must be extended with the VLAN id. A simple way of dealing with such a scenario is by creating a -table that matches on the ``egress_port`` of the +table that matches on the ``egress_port`` of the metadata. Other examples include doing ingress port pruning for multicast/broadcast packets and adding a special “CPU header” for intercepted packets passed up to the control plane. @@ -698,15 +698,15 @@ proprietary. :numref:`Figure %s ` then depicts what the OF-DPA pipeline looks like. .. _fig-ofdpa1: -.. figure:: figures/Slide15.png - :width: 200px +.. figure:: figures/Slide15.png + :width: 200px :align: center - Software stack for Tomahawk fixed-function forwarding pipeline. + Software stack for Tomahawk fixed-function forwarding pipeline. .. _fig-ofdpa2: -.. figure:: figures/Slide14.png - :width: 700px +.. figure:: figures/Slide14.png + :width: 700px :align: center Logical fixed-function pipeline defined by OF-DPA. @@ -742,8 +742,8 @@ forwarding pipelines—it necessarily focuses on the subset of functionality all vendors can agree on, the least common denominator, so to speak. -SAI includes both a configuration interface and a control interface, -where it's the latter that is most relevant to this section because +SAI includes both a configuration interface and a control interface, +where it's the latter that is most relevant to this section because it abstracts the forwarding pipeline. On the other hand, there is little value in looking at yet another forwarding pipeline, so we refer the interested reader to the SAI specification for more details. @@ -791,7 +791,7 @@ examples in :numref:`Figure %s `. Five example Pipeline/SDK/ASIC stacks. The two leftmost stacks, plus the fourth stack, exist today; the middle stack is hypothetical; and the rightmost stack is a work-in-progress. - + Each example in :numref:`Figure %s ` consists of three layers: a switching chip ASIC, a vendor-specific SDK for programming the ASIC, and a definition of the forwarding pipeline. By providing a diff --git a/trellis.rst b/trellis.rst index 536e1ee..1016ca7 100644 --- a/trellis.rst +++ b/trellis.rst @@ -250,7 +250,7 @@ Packet Service (similar to how the Host service intercepts ARP and DHCP packets). So the next time you use your TV remote to change channels, you may be triggering procedure invocations up and down the SDN software stack described throughout this book! - + 7.4 Customized Forwarding -------------------------- @@ -354,7 +354,7 @@ level: from a combination of forwarding functions, and we now have more options as to what hardware chip is the most appropriate target for implementing each such function.* - + For example, a companion file, ``upf.p4`` (not shown), implements the forwarding plane for the UPF extension, which includes the GTP tunnel encapsulation/decapsulation required by the 3GPP cellular standard to @@ -368,10 +368,10 @@ the *filtering objective* (``filtering.apply``), then applies the *forwarding objective* (``forwarding.apply`` and ``acl.apply``), and finally applies the *next objective* (``next.apply``). -In addition to selecting which extensions to include, the pre-processor -also defines several constants, including the size of each logical -table. Clearly, this implementation is a low-level approach to -building configurable forwarding pipelines. Designing higher-level -language constructs for composition, including the ability to -dynamically add functions to the pipeline at runtime, is a subject of -ongoing research. +In addition to selecting which extensions to include, the pre-processor +also defines several constants, including the size of each logical +table. Clearly, this implementation is a low-level approach to +building configurable forwarding pipelines. Designing higher-level +language constructs for composition, including the ability to +dynamically add functions to the pipeline at runtime, is a subject of +ongoing research. diff --git a/uses.rst b/uses.rst index 1d870aa..cdeca7d 100644 --- a/uses.rst +++ b/uses.rst @@ -51,7 +51,7 @@ appearance of having their own private LAN. However, these early forms of virtualization were quite limited in scope and lacked many of the advantages of SDN. You could think of them as virtualizing the address space of a network but not all its other properties, such as firewall -policies or higher-level network services like load balancing. +policies or higher-level network services like load balancing. The original idea behind using SDN to create virtual networks is widely credited to the team at Nicira, whose approach is described in @@ -91,7 +91,7 @@ As microservices and container-based systems such as Kubernetes have gained in popularity, network virtualization has continued to evolve to meet the needs of these environments. There are a range of open source network "plugins" (Calico, Flannel, Antrea, -etc.) that provide network virtualization services for Kubernetes. +etc.) that provide network virtualization services for Kubernetes. Because network virtualization set out to deliver a full set of network services in a programmatic way, its impact went beyond the @@ -112,35 +112,35 @@ impact of attacks spreading throughout an enterprise or data center. .. sidebar:: Bringing SDN to Life - *As we saw in Chapter 1, the ideas behind SDN had been in the - works for years, but there were two related events - that, looking back, had a significant impact in bringing the - concept of programmable networks from theory to practice. First - was the 2007 founding of the commercial startup Nicira - Networks. Nicira was founded by three of the acknowledged - pioneers of SDN: Martin Casado, Scott Shenker, and Nick - McKeown. While Nicira was founded to make commercial use of - SDN, as with many startups, it took a while to find the ideal - product for the marketplace. In the end, it was Network - Virtualization that became the industry's first successful - application of SDN. Nicira's network virtualization platform - first shipped in 2011, establishing the category and - ultimately paving the way for VMware's acquisition of the - company and subsequent development of VMware NSX.* - - *At around the same time, McKeown and Shenker also created - three non-profit organizations to catalyze the SDN - transformation across the networking industry: the Open - Networking Foundation (ONF) took on responsibility for - advancing the cause of network disaggregation, including - development of the OpenFlow standard; the Open Networking - Laboratory (ON.Lab) was created to produce open source - SDN-based solutions and platforms; and the Open Networking - Summit (ONS) was created as a conference platform to bring - together academics and practitioners interested in SDN. In - 2018, ONF and ON.Lab merged, and the combined organization has - focused on building the open source software that is - highlighted throughout this book.* + *As we saw in Chapter 1, the ideas behind SDN had been in the + works for years, but there were two related events + that, looking back, had a significant impact in bringing the + concept of programmable networks from theory to practice. First + was the 2007 founding of the commercial startup Nicira + Networks. Nicira was founded by three of the acknowledged + pioneers of SDN: Martin Casado, Scott Shenker, and Nick + McKeown. While Nicira was founded to make commercial use of + SDN, as with many startups, it took a while to find the ideal + product for the marketplace. In the end, it was Network + Virtualization that became the industry's first successful + application of SDN. Nicira's network virtualization platform + first shipped in 2011, establishing the category and + ultimately paving the way for VMware's acquisition of the + company and subsequent development of VMware NSX.* + + *At around the same time, McKeown and Shenker also created + three non-profit organizations to catalyze the SDN + transformation across the networking industry: the Open + Networking Foundation (ONF) took on responsibility for + advancing the cause of network disaggregation, including + development of the OpenFlow standard; the Open Networking + Laboratory (ON.Lab) was created to produce open source + SDN-based solutions and platforms; and the Open Networking + Summit (ONS) was created as a conference platform to bring + together academics and practitioners interested in SDN. In + 2018, ONF and ON.Lab merged, and the combined organization has + focused on building the open source software that is + highlighted throughout this book.* *Of course there have been many other startups, conferences, and consortia that have driven the development of SDN to where @@ -173,8 +173,8 @@ networks can be created, monitored and modified. It connects to virtual switches running on hosts–in this case, hypervisors supporting virtual machines. Virtual networks are created by programming the virtual switches to forward packets, with appropriate encapsulation, -from host to host across the underlay network. - +from host to host across the underlay network. + There have been reasonable debates about whether network virtualization is really SDN. Certainly it displays many of the @@ -199,7 +199,7 @@ This observation about different aspects of SDN being implemented in switches versus end hosts is an important one that we return to in Section 3.1 (where we outline the overall SDN architecture), and again in Chapter 8 (where we describe Network Virtualization in more detail). - + 2.2 Switching Fabrics ---------------------------- @@ -298,10 +298,10 @@ is no central view of traffic. .. figure:: figures/Slide53.png :width: 600px :align: center - + Example of non-optimal traffic engineering (left) and optimal placement (right). - + B4 and SWAN recognize this shortcoming and move the path calculation to a logically centralized SDN controller. When a link fails, for example, the controller calculates a new mapping of traffic demands onto @@ -341,7 +341,7 @@ insightful about the thought process in adopting SDN. .. _reading_b4: .. admonition:: Further Reading - A. Vahdat, D. Clark, and J. Rexford. `A Purpose-built Global Network: + A. Vahdat, D. Clark, and J. Rexford. `A Purpose-built Global Network: Google's Move to SDN `__. ACM Queue, December 2015. @@ -396,7 +396,7 @@ cloud service from all branch offices"*. The idea is illustrated in out to edge switches at various sites. The switches build an overlay of tunnels over the Internet or other physical networks, and implement policies including allowing direct access to cloud - services. + services. Note that the "private" part of the VPN is generally achieved by the @@ -432,7 +432,7 @@ for innovation because both the edge devices and the control planes are implemented in software, and centralization has offered new ways of tackling an old problem. Furthermore, there is plenty of competition among the players in the SD-WAN marketplace. - + 2.5 Access Networks -------------------------