commit 39535b597dbad843cd9578d06ace717723ef81a0
parent 427d986811f6c2c442902c335d347a17b839c64a
Author: Alex Balgavy <alex@balgavy.eu>
Date: Mon, 29 Nov 2021 12:14:46 +0100
Update ACN notes
Diffstat:
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.