@@ -44,10 +44,10 @@ components, correspond to a combination of *gNMI*, *gNOI* and
4444and either *P4Runtime * or *OpenFlow * in the second case. gRPC, an
4545open source remote procedure call framework, is
4646shown as the transport protocol for these APIs—an implementation
47- choice, but one that we will generally assume from here
47+ choice, but one that we will generally assume from here
4848on. (Note that OpenFlow, unlike the other protocols, does not run over
4949gRPC.) We discuss all of these acronyms and interfaces in further
50- detail below.
50+ detail below.
5151
5252
5353.. _fig-stack :
@@ -101,7 +101,7 @@ per-switch.
101101
102102The second is that part of the SDN software stack runs on the end
103103hosts. In particular, there is a *Virtual Switch (vSwitch) *—typically
104- implemented in software as part of the hypervisor
104+ implemented in software as part of the hypervisor
105105running on the server—that is responsible for forwarding packets to
106106and from the VMs. (Of course, not every end-host runs VMs, but a
107107similar architecture applies to containers hosts or bare-metal servers.)
@@ -112,27 +112,27 @@ connected to physical machines.
112112
113113.. sidebar :: Host-Centric Perspective
114114
115- *This book adopts a network-oriented perspective of SDN, one
116- that treats the end-host (both the virtual switch running in
117- the host OS and the NIC connecting the host to the network) as
118- an extension of the network, running under the control of a
119- Network OS. A more host-centric perspective is equally valid,
120- and perhaps more importantly, comes with a robust ecosystem of
121- open source software that runs as part of the host OS.
122-
123- *DPDK is one example, but another gaining traction is the
124- combination of eBPF (extended Berkeley Packet Filter) and XDP
125- (eXpress Data Path). When used together, they provide a way to
126- program generalized Match-Action rules in the OS kernel, or
127- potentially even on a SmartNIC. This is similar in spirit to
128- OpenFlow and P4, except they allow for the Action part to be
129- an arbitrary program. In contrast, OpenFlow defines a fixed
130- set of Actions, and P4 is a restricted language for expressing
131- Actions (e.g., it does not include loops). This is necessary
132- when the Action must execute within a fixed cycle budget, as
133- is the case for a switch-based forwarding pipeline. It also
134- enables formal verification of the data plane, a promising
135- opportunity discussed in Chapter 10.
115+ *This book adopts a network-oriented perspective of SDN, one
116+ that treats the end-host (both the virtual switch running in
117+ the host OS and the NIC connecting the host to the network) as
118+ an extension of the network, running under the control of a
119+ Network OS. A more host-centric perspective is equally valid,
120+ and perhaps more importantly, comes with a robust ecosystem of
121+ open source software that runs as part of the host OS.
122+
123+ *DPDK is one example, but another gaining traction is the
124+ combination of eBPF (extended Berkeley Packet Filter) and XDP
125+ (eXpress Data Path). When used together, they provide a way to
126+ program generalized Match-Action rules in the OS kernel, or
127+ potentially even on a SmartNIC. This is similar in spirit to
128+ OpenFlow and P4, except they allow for the Action part to be
129+ an arbitrary program. In contrast, OpenFlow defines a fixed
130+ set of Actions, and P4 is a restricted language for expressing
131+ Actions (e.g., it does not include loops). This is necessary
132+ when the Action must execute within a fixed cycle budget, as
133+ is the case for a switch-based forwarding pipeline. It also
134+ enables formal verification of the data plane, a promising
135+ opportunity discussed in Chapter 10.
136136
137137Fortunately, we can view a vSwitch as behaving just like a physical
138138switch, 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
161161range of possible implementation choices, including both FPGA and
162162ASIC, as well as whether the NIC is fixed-function or programmable
163163(using P4). For our purposes, we will treat such Smart NICs as yet
164- another switching element along the end-to-end path.
164+ another switching element along the end-to-end path.
165165
1661663.2 Bare-Metal Switch
167167-------------------------
@@ -245,17 +245,17 @@ Stratum-managed API is defined as follows:
245245 forwarding model and how the control plane interacts with it.
246246 (For completeness, :numref: `Figure %s
247247 <fig-stack>` also lists OpenFlow as an alternative control interface.)
248-
248+
249249* **gNMI (gRPC Network Management Interface): ** Used to set and
250250 retrieve configuration state. gNMI is usually paired with OpenConfig
251251 YANG models that define the structure of the configuration and state
252252 tree.
253-
253+
254254* **gNOI (gRPC Network Operations Interfaces): ** Used to set and
255255 retrieve operational state, for example supporting certificates
256256 management, device testing, software upgrades, and networking
257257 troubleshooting.
258-
258+
259259If you recall the distinction between Control and Configuration
260260introduced in Chapter 1, then you will recognize P4Runtime as the
261261Control API and the gNMI/gNOI combination as a modern version of a
@@ -289,18 +289,18 @@ things:
289289* **Managing Topology: ** Tracks inventory of network infrastructure
290290 devices and their interconnection to provide a shared view of the
291291 network environment for the rest of the platform and applications.
292-
292+
293293* **Managing Configuration: ** Facilitates issuing, tracking, rolling
294294 back, and validating atomic configuration operations on multiple
295295 network devices. This effectively mirrors the per-switch
296296 configuration and operation interfaces (also using gNMI and gNOI),
297297 but does so at the network level rather than the device level.
298-
298+
299299* **Controlling Switches: ** Controls the data plane packet
300300 processing pipelines of the network switches and provides subsequent control
301301 of flow rules, groups, meters and other building blocks within those
302302 pipelines.
303-
303+
304304With respect to this last role, ONOS exports a northbound
305305*FlowObjectives * abstraction, which generalizes Flow Rules in a
306306pipeline-independent way.\ [# ]_ This interface, which Chapter 6
@@ -366,7 +366,7 @@ supports several control plane features, including:
366366* Dual-homing of servers and upstream routers
367367* QinQ forwarding/termination
368368* MPLS-based pseudowires.
369-
369+
370370For each of these features, the corresponding Control App interacts
371371with ONOS—by observing changes in the network topology and issuing
372372Flow Objectives—rather than by using any of the standard protocol
0 commit comments