lectures.alex.balgavy.eu

Lecture notes from university.
git clone git://git.alex.balgavy.eu/lectures.alex.balgavy.eu.git
Log | Files | Refs | Submodules

commit 39535b597dbad843cd9578d06ace717723ef81a0
parent 427d986811f6c2c442902c335d347a17b839c64a
Author: Alex Balgavy <alex@balgavy.eu>
Date:   Mon, 29 Nov 2021 12:14:46 +0100

Update ACN notes

Diffstat:
Mcontent/acn-notes/_index.md | 2++
Acontent/acn-notes/network-automation.md | 57+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Acontent/acn-notes/software-defined-networking/covisor-design-overview.png | 0
Acontent/acn-notes/software-defined-networking/index.md | 96+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Acontent/acn-notes/software-defined-networking/network-planes-diagram.png | 0
Acontent/acn-notes/software-defined-networking/openflow-diagram.png | 0
Acontent/acn-notes/software-defined-networking/openflow-example.png | 0
Acontent/acn-notes/software-defined-networking/sdn-architecture.png | 0
Acontent/acn-notes/software-defined-networking/slicing-layer.png | 0
Acontent/acn-notes/software-defined-networking/traditional-vs-sdn.png | 0
10 files changed, 155 insertions(+), 0 deletions(-)

diff --git a/content/acn-notes/_index.md b/content/acn-notes/_index.md @@ -9,3 +9,5 @@ title = 'Advanced Computer Networks' 4. [Network transport](network-transport) 5. [Datacenter networking](datacenter-networking) 6. [Datacenter transport](datacenter-transport) +7. [Software-defined networking](software-defined-networking) +8. [Network automation](network-automation) diff --git a/content/acn-notes/network-automation.md b/content/acn-notes/network-automation.md @@ -0,0 +1,57 @@ ++++ +title = 'Network automation' ++++ +# Network automation +## Fibbing: centralised control over distributed routing +Fibbing combines benefits of distributed protocols (scalable by design & robust) with those of a centralized controller (manageable, flexible). + +You get centralised control over distributed routing by lying to th routing protocols: +- get requirements from network operator (routing, load balancing, failover) + - provides high-level language: + ``` + ((E, C, D1) and (E, G, D1); // traffic between E and D1 load balanced on two paths + ((A, *, B, * D2) or (A, *, C, *, D2)); // traffic between A and D2 should cross B or C + (F, G, *, D3) as backupof ((F, H));) // traffic between F and D3 should be reroutd via G if link (F,H) fails + ``` + +- compute expected paths centrally +- fibbing controller sends fake control messages to routers +- distributed protocols generate the expected paths with augmented network based on fake messages + +Any set of forwarding directed acyclic graphs can be enforced by fibbing. + +## Synthesizing network configurations: Propane +- Language for expressing network-wide objectives: + - regular expressions with extensions +- Compiler for purely distributed implementation + - generate BGP configs for each router + - compiler guarantees policy compliance + - use graph-based intermediate representation + +Goal: compile network-wide routing objectives into low-level configurations of devices running distributed protocols. + +Example: + +``` +define Ownership = +{PG1 => end(A) // path of traffic with prefix PG1 must end at A + PG2 => end(B) // path of traffic with prefix PG2 must end at B + true => end(out)} // traffic with any other prefixes can leave the datacenter + +define Locality = {PL1 | PL2 => only(in)} // traffic with prefixes PL* is only allowed in datacenter +``` + +When compiling, BGP control graph safety analysis is done with the topology. + +## Autocompleting partial network configurations: Net Complete +Problems with existing synthesizers: +- do not provide operators with fine-grained control over synthesized configurations +- can produce configurations very different from human-generated, lowering confidence of using it +- can produce very different configurations given slightly different requirements +- cannot flexibly adapt to operational requirements + +NetComplete allows operators to flexibly express intents through configuration sketches with "holes" +- holes can identify specific attributes (IP addresses, link costs, BGP local preferences) or entire pieces of configuration +- reduce autocompletion to constraint satisfaction problem: + - encode protocol semantics + high-level reqs + partial configuraions as logical formula in SMT + - use a solver to find an assignment to configuration variables diff --git a/content/acn-notes/software-defined-networking/covisor-design-overview.png b/content/acn-notes/software-defined-networking/covisor-design-overview.png Binary files differ. diff --git a/content/acn-notes/software-defined-networking/index.md b/content/acn-notes/software-defined-networking/index.md @@ -0,0 +1,96 @@ ++++ +title = 'Software-defined networking' ++++ +# Software-defined networking +Network planes: + +![Diagram of network planes](network-planes-diagram.png) + +Control plane has complex goals: connectivity, inter-domain policy, isolation, access control... + +We need abstractions to extract simplicity; ultimately we should be able to program the network as we do computers. + +First attempt: demultiplexing packets to software programs: +- in-band: packet has small piece of code that can execute on router +- out-band: user injects the code to be executed beforehand + +Software-defined network: +- control plane physically separate from data plane +- single control plane controls several forwarding devices + +![Traditional network vs SDN](traditional-vs-sdn.png) + +## Abstractions in SDN +![SDN architecture diagram](sdn-architecture.png) + +### Forwarding - OpenFlow +express intent independent of implementation. + +OpenFlow is API for controlling packet forwarding. +Configuration in terms of flow entries `<header, action>`. +No hardware changes needed, only firmware update. + +![OpenFlow diagram](openflow-diagram.png) + +Flow tables +- contain rows of flows +- contain: rule (exact/wildcard) + action + statistics + priority +- match+action + - match: on arbitrary fields in headers, or new header → allows any flow granularity + - action: forward to port, or drop, or send to controller, or overwrite header, or forward at specific bit-rate + - no support for deep packet inspection (payload-related) + +![OpenFlow protocol example](openflow-example.png) + +### Network state +Global network view is annotated graph, provided through API. +Control program is a function applied on the view (graph). +Implementation is "network operating systems", runs on servers in network. + +Info goes both ways: +- info from routers/switches to create view +- configuration to routers/switches to control forwarding + +### Specification abstraction +Control mechanism expresses desired behavior, and should not be responsible for implementing it on physical network infrastructure. + +Abstract view of network, only enough detail to specify goals. + +## SDN for network slicing +It's hard to realistically evaluate new network services. + +So, network slicing: divide network into logical slices +- each slice controls its own packet forwarding +- users pick which slice controls their traffic, as opt-in +- existing production services run in their own slice +- enforce strong isolation: actions in one slice do not affect others +- allow this testbed to mirror production network - real hardware, performance, etc. + +![Slicing layer diagram](slicing-layer.png) + +Slicing policies specify resource limit for each slice (bandwidth, max number of forwarding rules on switches, topology, fraction of switch/router CPU). + +For OpenFlow, FlowVisor allows network slicing -- intercepts control messages from OpenFlow to enforce the slicing. +- checks who controls packet/flow +- check if rules allowed or not + +## Composing network control programs in SDN +CoVisor is compositional hypervisor: +- clean interface for composing multiple controllers on same network (e.g. POX + Ryu + Floodlight...) + +Operators: +- `+`: parallel packet processing +- `>>`: sequential packet processing +- `▷`: overrie, one controller acts or defers processing to another controller + +- constraints on individual controllers: + - network visibility - virtual topology to each controller (so controllers can't operate on whole network) + - many-to-one primitive: one virtual node to many physical + - one-to-many primitive: one node in physical, several virtual (e.g. MAC learner + gateway + IP router) + - packet handling capability - fine-grained access control to each controller + - constraint on pattern: header fields, match type + - constrain on action: actions to take on matched packets + +Design overview: + +![CoVisor design overview](covisor-design-overview.png) diff --git a/content/acn-notes/software-defined-networking/network-planes-diagram.png b/content/acn-notes/software-defined-networking/network-planes-diagram.png Binary files differ. diff --git a/content/acn-notes/software-defined-networking/openflow-diagram.png b/content/acn-notes/software-defined-networking/openflow-diagram.png Binary files differ. diff --git a/content/acn-notes/software-defined-networking/openflow-example.png b/content/acn-notes/software-defined-networking/openflow-example.png Binary files differ. diff --git a/content/acn-notes/software-defined-networking/sdn-architecture.png b/content/acn-notes/software-defined-networking/sdn-architecture.png Binary files differ. diff --git a/content/acn-notes/software-defined-networking/slicing-layer.png b/content/acn-notes/software-defined-networking/slicing-layer.png Binary files differ. diff --git a/content/acn-notes/software-defined-networking/traditional-vs-sdn.png b/content/acn-notes/software-defined-networking/traditional-vs-sdn.png Binary files differ.