Table of Contents
- Foreword
- Preface
- Chapter 1: Introduction
- Chapter 2: Use Cases
- Chapter 3: Basic Architecture
- Chapter 4: Bare-Metal Switches
- Chapter 5: Switch OS
- Chapter 6: Network OS
- Chapter 7: Leaf-Spine Fabric
- Chapter 8: Network Virtualization
- Chapter 9: Access Networks
- Chapter 10: Future of SDN
- Hands-on Programming
- About The Book
- About The Authors
- Read the Latest!
Clip source: Summary of - Chapter 1: Introduction
Software-Defined Networking (SDN) is an approach to how we implement networks, which matters because it impacts the pace of innovation.
- SDN does not directly address any of the technical challenges of routing, congestion control, traffic engineering, security, mobility, reliability, or real-time communication, but it does open new opportunities to create and deploy innovative solutions to these and similar problems.
- SDN was in part conceived as a way to transform the marketplace, inspired by the transformation that the computing industry went through in previous decades.
- The computing industry was historically structured as a vertical market.
- The introduction of microprocessors and open source OS’s helped transform that vertical market into a horizontal marketplace, with open interfaces spurring innovation at every level.
- SDN is an approach rather than a point solution, so it is helpful to define the design principles at the core of that approach
- There is more than one possible end-state of SDN
- Each network operator is free to pick different design points and build out their network accordingly
- The seminal idea behind SDN is that networks have distinct control and data planes, and the separation of these two planes should be codified in an open interface
- In the most basic terms, the control plane determines how the network should behave, while the data plane is responsible for implementing that behavior on individual packets
- SDN implies the need for a well-defined forwarding abstraction
- A flow rule is a Match-Action pair: Any packet that Matches the first part of the rule should have the associated Action applied to it
- Centralized: Fully independent of the data plane and logically centralized
- Network Operating System (NOS): Provides a set of high-level abstractions that make it easier to implement network control functionality
- Fail to deliver the new networking abstractions envisioned by SDN's pioneers
- Mixed: Some control functionality running on-switch and some running off-switch
- Switch’s main processing loop receives a packet from an input port, does a lookup of the destination address in the FIB, and puts the packet on the output port or port group indicated by the matched table entry.
- Low-end switches use a hardware-based forwarding pipeline, whereas high-performance switches employ a software-based one. The former are referred to as fixed-function pipelines and the latter as programmable pipelines.
- The original definition of SDN was: A network in which the control plane is physically separate from the forwarding plane, and a single control plane controls several forwarding devices.
- Since that original definition, SDN has been interpreted by different stakeholders to mean less and more
- Another way to frame SDN is to think of it as having two phases: Phase 1, network operators took ownership of the control planes and Phase 2, they are taking control of how packets are processed in the data plane.
Clip source: Summary of - Chapter 2: Use Cases
- Cloud providers: Google, Facebook, Microsoft
- Large network operators: AT&T, DT, NTT, Comcast
- Enterprises: network virtualization and SD-WAN have had considerable success in the enterprise
- Pure play SDN is deployed in some Universities, with the goal of supporting research and innovation, but adoption is slower in general
- The first widely-adopted use case for SDN was to virtualize the network.
- Modern clouds required networks that could be programmatically created, managed, and torn down, without a sysadmin having to manually configure, say, VLAN tags on some number of network switches.
- Network virtualization delivered a full set of network services in a programmatic way, delivering a simplification and automation of network provisioning.
- The predominant use case for pure play SDN is within cloud datacenters
- Cloud providers move away from proprietary switches and instead use bare-metal switches built using merchant silicon switching chips
- They control the switching fabric that interconnects their servers entirely in software
- A datacenter switching fabric is a network often designed according to a leaf-spine topology
- Another cloud-inspired use case is traffic engineering applied to the wide-area links between datacenters.
- Google has publicly described their private backbone, called B4, which is built entirely using bare-metal switches and SDN
- Microsoft has described an approach to interconnecting their data centers called SWAN
- A central component of both B4 and SWAN is a Traffic Engineering (TE) control program that provisions the network according to the needs of various classes of applications
- Traffic engineering only really became mainstream for the Internet backbone with the advent of MPLS
- Enterprises have for many years been buying WAN services from telecommunications companies to obtain reliable and private network services to interconnect their many locations-main offices, branch offices, and corporate data centers.
- For most of the 21st century the most common technical approach to building these networks has been MPLS, using a technique known as MPLS-BGP VPNs (virtual private networks).
- With SD-WNA, there was a realization that VPNs lend themselves to centralized configuration. Changes to policy can be input centrally and pushed out to all affected sites.
- Access networks that implement the last mile connecting homes, businesses, and mobile devices to the Internet are another opportunity to apply SDN principles.
- Example access network technologies include Passive Optical Networks (PON), colloquially known as fiber-to-the-home, and the Radio Access Network (RAN) at the heart of the 4G/5G cellular network.
- INT is to program the forwarding pipeline to collect network state as packets are being processed (i.e., "in-band").
- In the INT approach, telemetry “instructions” are encoded into packet header fields, and then processed by network switches as packets flow through the pipeline.
- Traffic sources (e.g., applications, end-host networking stacks, hypervisors) can embed the instructions either in normal data packets or in special probe packets, allowing the traffic sinks to monitor the exact data plane state observed.
Summary | Save 13 min
SDN is an approach to building networks that favors programmable commodity hardware with the intelligence that controls packet forwarding and other network operations implemented in software. Realizing such a design is independent of any particular protocol stack, but instead requires a set of open APIs and a new collection of software components that support those APIs.
- An overview of the software stack is given in Figure 15
- Includes a Bare-Metal Switch running a local Switch OS, controlled by a global Network OS hosting a collection of Control Applications
- Two open interfaces between the Control Apps and the Network OS
- API shims correspond to a combination of gNMI, gNOI and FlowObjective
- gRPC is shown as the transport protocol for these APIs
- Overall architecture of the SDN software stack
- SDN focuses on an end-to-end path through the network, connecting Virtual Machines (VMs).
- The Network OS (ONOS) is network-wide, while the Switch OS (per-switch) is per-switch.
- Part of the SDN software stack runs on the end hosts, in particular, a Virtual Switch (vSwitch).
- The architecture is agnostic as to switch vendor, but the overall network topology is dictated by the Control Applications running at the top of the software stack.
- In the case of both chips, a pair of P4 programs defines the forwarding pipeline. The first (forward.p4) specifies the forwarding behavior. The second specifies the logical architecture of the target forwarding chip. The P4 compiler generates target files that are loaded into both the Network OS and the switch.
- Each switch runs a local Switch OS which is responsible for handling API calls issued to the switch, for example from the Network OS.
- Stratum mediates all interactions between the switch and the outside world, including loading the target files generated by the P4 compiler, which defines a contract between the data plane and the control plane. This contract effectively replaces OpenFlow's flow rule abstraction with an auto-generated specification.
- The Network OS is a platform for configuring and controlling a network of switches. It runs off-switch as a logically centralized SDN controller, and manages a set of switches on a network-wide basis.
- Central to this role is monitoring the state of those switches (e.g., detecting port and link failures).
- It maintains a global view of the topology that reflects the current state of the network, and makes that view available to any interested Control Apps.
- Dictates a particular network topology common to datacenter clusters
- Interconnects servers, VMs, and VMs running on those servers in a multi-rack cluster
- Connects the cluster as a whole upstream to peer networks, including the Internet, using BGP
- Continuously terminates access network technologies like PON and RAN
- SD-Fabric is best viewed as an interconnect running at the network edge
Clip source: Summary of - Chapter 3: Basic Architecture
Clip source: Summary of - Chapter 4: Bare-Metal Switches
The bare-metal switches that provide the underlying hardware foundation for SDN. This chapter discusses both P4 as a language-based approach to programming the switch's data plane, and OpenFlow as the first-generation alternative. We will introduce these two approaches in reverse-chronological order, starting with P4.
- The Network Processing Unit (NPU), a merchant silicon switching chip optimized to parse packet headers and make forwarding decisions, is shown as a combination of SRAM-based memory that buffers packets while they are being processed and an ASIC-based forwarding pipeline that implements a series of (Match, Action) pairs.
- Each switch includes a general-purpose processor, typically an x86 chip, that controls the NPU and a BIOS that provisions and boots a bare-metal switch.
- The main distinction in how a given NPU implements this pipeline is whether the stages are fixed-function (i.e., each stage understands how to process headers for some fixed protocol) or programmable.
- A multi-stage pipeline adds a little end-to-end latency to each packet (measured in nanoseconds), but means that multiple packets can be processed at the same time
- There are three major components to a programmable pipeline: Parser, which defines what header fields (and their location in the packet) are to be recognized and matched by later stages, a sequence of Match-Action Units, which is programmed to match one or more of the identified header fields, and a Deparser which re-serializes the packet metadata into the packet before it is transmitted on the output link
- To account for different switching chips implementing different physical pipelines, you need an abstract (canonical) pipeline that is general enough to fairly represent the available hardware, plus a definition of how the abstract pipeline maps onto the physical pipeline.
- Defining a logical pipeline as a general approach to supporting a pipeline-agnostic control plane is also done with a P4 program, resulting in the situation shown in Figure 22
- The goal is the same as Java: to support a write-once-run-anywhere programming paradigm.
- The architectural model that developers are coding to today is somewhat simpler.
- It does not include a re-parsing step after the Traffic Manager, and implicitly bridges all metadata from ingress to egress processing.
- It includes checksum verification/update block, whereas PSA treats checksums as an extern and supports incremental computations at any point during ingress/egress processing.
- TNA is an architecture model defined by Barefoot for their family of programmable switching chips
- It enables vendors to expose unique capabilities of their ASICs without being constrained by a standardization process
- The P4 language defines a general framework for writing programs, but it’s not until you supply a P4 architecture definition (generically referred to this as arch.p4) that a developer is able to actually write and compile a forwarding program.
- When picking a new architecture model for a new P4 program, ask questions like: Which of the available architectures are supported by 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)?
- Can it rely solely on common/non-differentiating features?
- Similar to the C programming language
- Unlike C, P4 does not include loops, pointers, or dynamic memory allocation.
- P4 "unrolls" the loops we might otherwise need, implementing each iteration in a sequence of control blocks (i.e., stages).
- Protocol header declarations include Ethernet and IP headers, and metadata
- This is also a place to define program-specific metadata associated with the packet being processed
- There are two egress port fields: read-only and valid only in the egress processing stage, and a second field that gets written from the ingress processing stage to pick the output port
- PSA and other architectures solve this by defining different metadata for ingress and egress pipelines
- The underlying programming model for the parser is a state transition diagram including the built-in start, accept, and reject states, plus the state transition logic
- As a side-effect of traversing each state, the corresponding header is extracted from the packet and the values in these in-memory structures are then available to the other routines
- Checksum verification
- Control construct
- P4's version of a procedure call
- At the top level these control blocks match up one-for-one with the pipeline stages defined by the logical pipeline model
- The forwarding algorithm is implemented in the ingress segment of the Match-Action pipeline
- Two actions being defined: drop() and ipv4_foward
- After executing these actions, the headers and metadata associated with this packet contain enough information to properly carry out the forwarding decision
- This is the purpose of the table construct
- In general, replicating a packet to multiple egress ports for multicast can be done by setting the corresponding intrinsic metadata in the ingress processing
- The egress processing will see as many copies of the same packet as those generated by the traffic manager
- Example: If one switch port sends VLAN-tagged packets, the header must be extended with the VLAN id
- Only headers that are marketed as valid will be re-serialized into that packet.
- There is no need to say anything about the rest of the packet (i.e., the payload), since by default, all the bytes beyond where we stopped parsing are included in the outgoing message.
- The P4 program must define the behavior of the switch as a whole
- This is given by the V1Switch package shown below.
- A set of elements in this package is defined by v1model.p4, and consists of references to all the other routines defined above.
- Programmable pipelines can also be configured.
- The distinction between programmable and fixed-function pipelines is not as black-and-white as this discussion implies, since the former can accommodate new functionality while the latter is only able to accommodate existing functionality.
- This is the layer that provides an abstract representation of the Tomahawk ASIC's fixed forwarding pipeline.
- In the programmable case, it's not until you add a program like switch.p4 that you have the functionality that runs in those stages.
- For example, you might want to incorporate both programmable and fixed-function switches in a single network and run a common SDN software stack.
- Switch Abstraction Interface (SAI) focuses on the subset of functionality all vendors can agree on, the least common denominator
- Includes both a configuration interface and a control interface, the latter being most relevant to this section because it abstracts the forwarding pipeline
- P4 architecture models don't define pipelines of match-action tables, but they define the building blocks that can be used by a P4 developer to define a pipeline, whether logical or physical.
- In a sense, then, P4 architectures are equivalent to a traditional switch SDK.
Clip source: Summary of - Chapter 5: Switch OS
- This chapter describes the operating system running on every bare-metal switch.
- The most common foundation for this Switch OS is Open Network Linux (ONL), an open source project of the Open Compute Project (OPT).
- ONL starts with the Debian distribution of Linux and augments it with support for hardware unique to switches.
- This section describes the set of components that implement an SDN-ready Northbound Interface for the Switch OS running on a bare-metal switch.
- Stratum exports three primary Northbound Interfaces: P4Runtime, gNMI, and gNOI
- All three interfaces are gRPC services, which implies there is a corresponding set of Protocol Buffers (protobufs) that specify the API methods and supported parameters of each.
- Generates both the binary that is loaded into each switching chip and the runtime interface used to control the switching chip (indirectly via the Switch OS).
- Compiler does this with the help of a vendor-specific backend.
- The toolchain for generating this contract is shown in Figure 28, where as in earlier figures, we represent the original P4 forwarding program as an abstract graph rather than with actual P4 source code.
- The final piece of the end-to-end story is the connection between the runtime contract and the original program loaded into the data plane.
- A core challenge of configuring and operating any network device is to define the set of variables available for operators to GET and SET on the device, with the additional requirement that this dictionary of variables should be uniform across devices (i.e., be vendor-agnostic).
- The main technical advance that was not prevalent in the early days of SNMP and MIB is the availability of pragmatic modeling languages, where YANG is the leading choice to have emerged over the last few years.
- YANG makes the process of creating, using, and modifying models programmable and hence, adaptable to this iterative process.
- Switch OS that is gaining momentum in the industry
- Leverages SAI as a vendor-agnostic SDK and includes a switch-customized Linux distribution
- Stratum's support for programmable forwarding pipelines (including both P4 and P4Runtime) versus the least common denominator approach taken by SAI
- PINS stands for P4 Integrated Network Stack
- The goal is to enable remote SDN Controllers/Apps to interact with SAI using P4 Runtime and gNMI
- Enable SAI extensions using the P4 program
Clip source: Summary of - Chapter 6: Network OS
Clip source: Summary of - Chapter 6: Network OS
A Network Operating System (NOS) consists of a collection of loosely coupled subsystems-as is often associated with a micro-service architecture-including a scalable and highly available key/value store. The best way to think about a NOS is that it is like any other horizontally scalable cloud application.
- Network OS consists of three layers: a collection of Northbound Interfaces (NBI) that applications use to stay informed about the network state (e.g. traverse topology graph, intercept network packets), a Distributed Core that is responsible for managing network state and notifying applications about relevant changes in that state, and a Southbound Interface (SBI).
- The design is highly modular, with a given deployment configured to include a subset of modules it requires.
- All access to the underlying hardware, whether by a control program or a human operator, is mediated by ONOS. This means the union of all northbound APIs must be sufficient to configure, operate, and control the network.
- The ONOS core consists of a number of subsystems, each responsible for a particular aspect of network state (e.g. topology, host tracking, packet intercept, flow programming).
- Each subsystem maintains its own service abstraction, where its implementation is responsible for propagating the state throughout the cluster.
- Many ONOS services are built using distributed tables (maps), which are implemented using a distributed key/value store.
- Atomix is a Java-based system that includes support for: distributed data structures, distributed communication, distributed coordination, locks, leader elections, and barriers
- It includes AtomicMap and DistributedMap primitives, which extend Java's Map utility with additional methods.
- The primary job of each instance is to monitor and control a subset of the physical switches in the network using the Atomix leader-election primitive
- ONOS builds on Atomix by defining a core set of tables (maps), which are in turn packaged as a collection of services available to control applications (and other services).
- A table and a service are two ways of looking at the same thing.
- The Path Service, which applications can query to learn end-to-end paths between host pairs, depends on both the Topology Service (which tracks the network graph) and a Host Service (track the hosts connected to the network)
- While the service graph depicted in Figure 34 is designed to discover the network topology, there are many scenarios where the topology is fixed and known a priori.
- For such scenarios, ONOS includes a configuration service, called Network Config, which accepts configuration instructions from a control application (or high-level service) sitting above it in the dependency graph.
- There are three types of flow objectives: Filtering, Forwarding, and Next
- Filtering objectives determine whether or not traffic should be permitted to enter the pipeline, based on a traffic Selector
- Forwarding objectives determine what traffic is to be allowed to egress the pipeline generally by matching select fields in the packet with a forwarding table
- Next objectives indicate what kind of Treatment the traffic should receive
- All three stages are agnostic as to exactly what combination of tables in the underlying switch is used to implement the corresponding sequence of match/action pairs
- ONOS is designed to ensure that the core (and the applications written on top of it) are insulated from the specifics of the control protocol.
- The basic approach is based on a plugin architecture, with two types of plugins: Protocol Providers and Device Drivers.
- ONOS defines a Southbound Interface (SBI) plugin framework, where each plugin defines some southbound (network-facing) API.
- Each plugin serves as a proxy between the SBI and the underlying network, where there is no limitation on what control protocol each can use to communicate with the network.
- SBI framework also supports Device Drivers plugins as a mechanism to insulate code (including Providers) from device-specific variations.
- A Device Driver is a collection of modules, each of which implements a very narrow facet of control or configuration capabilities, and no limitations are placed on how the device driver chooses to implement those capabilities.
- ONOS is a logically centralized SDN controller that must be able to respond to a scalable number of control events in a timely manner and remain available in the face of failures
- Scale: 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; 1k topology events/sec
- Production deployments run at least 3 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 Kubernetes, and bundles an identical collection of core services, control applications, and protocol providers
Clip source: Summary of - Chapter 7: Leaf-Spine Fabric
- This chapter describes a leaf-spine switching fabric implemented by a collection of control applications.
- Uses only bare-metal switches, equipped with software described in the previous chapters, to build out the fabric. It can run on a mix of fixed-function and programmable pipelines, but is currently running in production with the former.
- SDN provides an opportunity to customize the network, but for pragmatic reasons, the first requirement for adoption is to reproduce functionality that already exists, and do so in a way that reproduces or improves upon the resilience and scalability of legacy solutions.
- With respect to L2 connectivity, SD-Fabric supports VLANs, Q-in-Q, IPv4 and IPv6 routing for both unicast and multicast addresses, and supports L2 tunnels across the L3 fabric (both single and double tagged).
- It provides high availability in the face of link or switch failures by using a combination of well-known techniques: dual-homing, link binding, and ECMP link groups.
- The term "segment routing" comes from the idea that the end-to-end path between any pair of hosts can be constructed from a sequence of segments.
- SD-Fabric leverages the forwarding plane of Multi-Protocol Label Switching (MPLS).
- Segment routing is a general approach to source routing which can be implemented in a number of ways.
- SD-Fabric takes advantage of Route and Mcast services introduced in Chapter 6
- They determine which of the leaf-spine switches serve each IP prefix, and where to find all the hosts connected to each multicast group, respectively.
- The story with multicast is similar
- Using the ONOS CLI, it is possible to create a new multicast route and add a sink to it.
- Knowing exactly what you want from a network at the outset is an impossibly high bar. Networks evolve based on experience using and operating them.
- If we knew from the outset that a leaf-spine fabric supporting the SD-Fabric feature-set was exactly what we wanted, we might go back to lower layers and tailor them for that purpose.
- Fabric.p4 is a specific example of forward. p4, which we are only now able to describe because of how it relates to the control plane.
Clip source: Summary of - Chapter 8: Network Virtualization
- It sits somewhat apart from SDN but has a lot in common with it
- The fact that network virtualization can be implemented as an overlay on an existing network made it easier to deploy
- However, it left the physical network untouched, thus not impacting the level of innovation in physical networks.
- Network virtualization as we understand it today is closely linked to the evolution of modern datacenters, in which large numbers of commodity servers communicate with each other to solve computational tasks
- To efficiently support high volumes of traffic between any pair of servers in the datacenter, leaf-spine fabrics of the sort described in Chapter 7 became popular due to their high cross-sectional bandwidth and scalable layer-3 forwarding
- The ease of provisioning a VM shrank the time to obtain computational resources from days to minutes or seconds, it exposed the fact that network configuration was now the "long pole"-the slowest task to be completed before a user could put their infrastructure to work
- SDN provided a means to simplify the creation and management of virtual networks, just as much as it simplifies the operation of physical networks
- Network virtualization controller exposes a northbound API that receives inputs describing the intended state of a virtual network.
- It is the responsibility of the controller to determine where those virtual machines are located, and then to send control commands to the appropriate virtual switches to create the virtual network abstraction.
- The vision for virtual networks is more closely analogous to virtual machines
- Virtual machines provide a faithful reproduction of the features of a physical server, complete with processor, memory, peripherals, and so on.
- An unmodified operating system can run on the virtual machine exactly as if it were running on a physical machine, and an unmodified distributed application should be able to run on a virtual network exactly as it would on a real network.
- Modern network virtualization systems expose a northbound API by which virtual networks are created and managed.
- Through calls to this API, the topology and services of a virtual network are specified-either by a human user or by another piece of software such as a cloud automation platform.
- At the heart of the system is the control plane, which sits between the desired state and the actual state, and includes a distributed data plane, a centralized controller, and a management layer.
- With a centralized control plane, we are able to provision and configure these services via an API (or a GUI) in one location and implement them in a distributed manner with the efficiency and performance benefits outlined here.
- A significant side effect of distributing a service in this way is that there is no longer a central bottleneck
- Network virtualization requires some sort of encapsulation so addressing in the virtual network can be decoupled from that of the physical network.
- After many years of experimentation and collaboration among software and hardware vendors and other IETF participants, an encapsulation that combined most of the desired features was developed and standardized
- GENEVE includes an options scheme that could be efficiently processed by hardware while still giving the required extensibility.
- The Virtual Switch is the main component of the data plane, and the richness of its feature set determines the ability of a network virtualization system to accurately reproduce the features of a physical network.
- Most widely deployed virtual switch is Open vSwitch (OVS), used in proprietary systems such as Nicira’s Network Virtualization Platform and VMware NSX, as well as Open Virtual Network (OVN) described in Section 8.4.3
- Designed to have the necessary flexibility to meet the requirements of network real-time virtualization while also providing high performance, it is programmed by the control plane using OpenFlow, and receives configuration information over a separate channel using the Open VSwitch Database (OVSDB).
- As a protocol, OVSDB uses a JSON-based message format, analogous to gNMI/gNOI's use of protobufs.
- The virtual switch sits in the data path for all traffic entering of leaving VMs and containers in a virtual network, so the performance of the virtual switch is critical
- There are a number of performance optimizations that can be applied to improve vSwitch performance
- DPDK (Data Plane Development Kit): a set of libraries developed for the Intel x86 platform to improve performance of data-moving operations, including virtual switching
- SR-IOV (Single Root IO Virtualization): a hardware feature designed to improve IO performance between VM and the outside world
- P4 is gaining traction as a way to program SmartNICs, suggesting convergence in how the data plane-whether implemented as a vSwitch, a SmartNI or a bare-metal switch-exports its capabilities to the control plane
- Open Virtual Network (OVN) is an example of a network virtualization system
- Built as a set of enhancements to OVS
- Leveraging OVS for the data plane and databases (built on OVSDB) for its control and management planes
- The high level architecture of OVN is shown in Figure 49
- Uses two databases (referred to as Northbound and Southbound) to store state
- Used to operate in an environment where a Cloud Management System (CMS) is responsible for the creation of virtual networks
- Remains logically centralized control, so that a single API entry point can be used to create networks, query status, and so on
- Distributes out to each hypervisor the control functions related to physical information such as the location of VMs
- Network virtualization allows for the creation of microsegments, narrowly defined virtual networks that determine both which machines can communicate with each other and how they can do so.
- This enables security features to be implemented in a distributed manner, in software. It also makes it relatively straightforward to create a large number of isolated networks.
- Network virtualization adheres to the core architectural principles laid out by SDN's inventors
- A clear separation between control and data planes with a centralized controller responsible for a distributed set of forwarding elements
- The fact that network virtualization uses a completely programmable forwarding plane places it squarely in the SDN universe
- SDN has always been an approach to building and operating networks applied to isolated domains where it provides value
Clip source: Summary of - Chapter 9: Access Networks
Access Network is the latest emerging use case for SDN: the Access Network. It is still early (production deployments are just now being rolled out), but the opportunity is substantial. This chapter describes two examples-Passive Optical Networks (PON) and Radio Access Networks (RAN)-the technologies at the core of Fiber-to-the-Home and the Mobile Cellular Network.
- The technologies used to implement the last mile networks connecting homes, businesses, and mobile devices to the Internet have evolved independently from the rest of the Internet
- This makes the access network fertile ground for SDN
- ISPs (e.g., Telco or Cable companies) that offer broadband service often operate a national backbone, and connected to the periphery of that backbone are hundreds or thousands of edge sites
- These edge sites are commonly called Central Offices in the Telco world and Head Ends in the cable world.
- A tree-structured fiber-based network, starting with a single device in one of the ISP's edge sites and fanning out to reach up to 1024 homes
- PON gets its name from the fact that the splitters are passive: they forward optical signals downstream and upstream without actively storing-and-forwarding frames
- Upstream and downstream traffic are transmitted on two different optical wavelengths, so they are completely independent of each other
- A RAN implements the last hop by encoding and transmitting data at various bandwidths in the radio spectrum
- Packets are routed through this network to reach the best base station(s) to serve each mobile device (User Equipment or UE) at a given moment in time
- These forwarding decisions are implemented by the base stations
- There are three observations to make about these two network technologies before we get to the question of how to apply SDN principles
- The distinction between the "access network" and the "IP gateway"
- Because the PON is passive, there is no opportunity for software control inside the network
- Applying SDN to PON involves software control of the end-points (i.e., the OLTs and ONUs) and treating everything between these end-point as a passive backplane
- Moreover, because the ONU is a “dumb” device that responds to directives from the OLT, this really boils down to disaggregating the ONT
- The opportunity for applying SDN to PON hinges on the fact that OLTs are essentially glorified L2 switches, outfitted with a different MAC-layer framing protocol running on each switch port.
- A PON requires substantial configuration to be loaded into each OLT so it knows what levels of service the network is to support, the ONUs deployed to homes are limited devices, controlled indirectly through the upstream OLTs they connect to, and network operators don’t necessarily have the luxury of a clean-slate deployment of only bare-metal hardware and must deal with an assortment of legacy devices.
- The set of base stations in a given geographic area coordinate with each other to allocate the shared-and scarce-radio spectrum
- They make hand-off decisions, decide to jointly serve a given user, and make packet scheduling decisions based on continual measurements of the signal quality
- Today these are purely local decisions, but transforming it into a global optimization problem is in SDN's wheelhouse
- Each base station to report locally collected statistics about radio transmission quality back to a central SDN controller
- A suite of control applications can then use this information to make globally optimal decisions
- The next step is to understand how the functionality outlined above is partitioned between physical elements, and hence, "split" across centralized and distributed locations.
- A single Central Unit (CU) running in the cloud serves multiple Distributed Units (DUs), each of which in turn serve multiple Radio Units (RUs).
- RRC (Radio Resource Control) is responsible for configuring the coarse-grain and policy-related aspects of the pipeline. The RRC runs in the RAN's control plane; it does not process packets on the user plane.
- The RRC, shown in Figure 54 as part of each basestation, represents the control plane of the RAN.
- SD-RAN adopts a design that parallels the Network OS / Control App structure used in other domains (and described throughout this book).
- It also introduces two new services: Control and Telemetry.
- The Near-RT RIC uses the E2 interface to control the underlying RAN elements, including the CU, DUs, and RUs.
- Near RT-RIC opens the possibility of introducing policy-based RAN control, whereby interrupts (exceptions) to operator-defined policies would signal the need for the outer loop to become involved.
- Both PON and RAN are paired with an IP gateway that has been augmented with access-specific features.
- The operator at the edge of the network is responsible for authorizing user access, differentiating the level of service delivered to users, and potentially billing those users. The Mobile Core has the added responsibility of tracking mobility as users move from one base station to another.
Clip source: Summary of - Chapter 10: Future of SDN
- Cloud-hosted control planes are being deployed in production networks, but we are only just starting to see SDN being applied to access networks and programmable pipelines being used to introduce new data plane functionality.
- Most networks are still built using closed/proprietary software and complex/fixed-function hardware, whose correctness is hard to prove and whose design has unknown provenance
- If we do not correctly configure and secure these networks, the risk of cyber disasters is much worse than anything experienced to date
- 5G will connect not only phones and people but also everything from doorbells to lights, refrigerators to self-driving cars
- The ability to ensure that every packet in the network follows an operator-specified path and encounters only a set of forwarding rules within every device that the operator intended
- Experience has shown that verification works best in settings where the overall system is constructed in a compositional (i.e., disaggregated) manner
- With disaggregation as the foundation, verifiability follows from the ability to state intent at the network level rather than at the box level
- In addition to building tools for analyzing network programs, it is important to develop technologies that map the high-level intent of the network operator to code that implements that intent
- Phase 2: Operators have been able to take control of their software, via disaggregated control planes, and of their packet processing, via P4-programmable data planes.
- We are in the early stages of phase 3, during which verifiable closed loop control will empower network operators to take full ownership of the software that defines their networks.
Clip source: Summary of - Hands-on Programming
Summary | Save 4 min
A collection of programming exercises provides hands-on experience with the software described in this book. The exercises assume familiarity with Java and Python, although each exercise comes with starter code, so a high level of proficiency is not required. The exercises use the Mininet network emulator, the bmv2 P4-based switch emulator, and the PTF Packet Testing Framework.
- The recommended minimum system requirements for this VM are 4 GB of RAM and a 4-core CPU.
- It takes approximately 8 GB of HDD space. For a smooth experience, we recommend running the VM on a host system that has at least double these resources.
- The VM is in.ova format and has been created using VirtualBox v5.2.32. You can use any modern virtualization system to run the VM.
- Windows users should download and install the provided VM, and log in using the credentials sdn / rocks.
- To work on the exercises, you will need to clone the following repo: https://github.com/opennetworkinglab/ngsdn-tutorial
- The VM may have shipped with an older version of the dependencies than you need for the exercises. You can upgrade to the latest version using the following command: $ cd ~/ngsdn-tutorial $ make deps.
- During the exercises, you will need to write code in multiple languages (e.g., P4, Java, Python).
- The repo you cloned is structured as follows: p4src → Data Plane Implementation (P4) yang → Config Models (YANG) app → Custom ONOS app (Java) mininet → 2x2 leaf-spine (Mininet) util → Utility Scripts (Bash) ptf -> Data plane unit tests (PTF)
- To facilitate working on the exercises, the repo provides a set of make targets to control the different aspects of the process.
- The specific commands are introduced in the individual exercises, but the following is a quick reference:
- make deps → Pull and build all required dependencies
- p4-build → Build P4 program
- Make start → Start Mininet and ONOS containers
- stop → Stop all containers making restart → Restart containers clearing any previous state
- onos-cli → Access the ONOS CLI (password: rocks, Ctrl-D to exit)
- Onos-log → Show ONOS log
- mn-cli -> Access the Mininet CLI
- app-build
- App-reload
- Netcfg → Push netcfg.json file to ONOS
- Stratum exercises focus on Stratum, and are best attempted after reading through Chapter 5.
- ONOS exercises focus ONOS, with best attempts after Chapter 6
- SD-Fabric was previously known as Trellis, and still is in the code. Enabling ONOS Built-in Services
- Graphical interfaces refer to the ONF Cloud Tutorial Portal.
How was this summary?
Save someone 4 min
If you would like to suggest changes to this summary as the original author, click here.