![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
gdtNetworks perform many tasks
- could use a monolithic application (count, route, firewall, load balance, etc). Difficult to program, test, debug, reuse, port.
- solution: modularise control. monitor program, routing program, firewall program, etc.
- getting modules to play nice
- controller has to arbitrate between modules. These aren't "tenants" with parts of the network to themselves. Different modules affect the same traffic.
- solution: composition
- parallel composition. Multiple operations simultaneously. eg: counting and forwarding.
- sequential composition. One operation, then another. eg: firewall, then switch.
Example application of parallel composition: monitor arriving traffic, route traffic by dst prefix
- parallel composition: do both simultaneously
- note that the rules can be installed in any order
Example application of sequential composition: server load balancer
Sequence is:
- split traffic based on client's ip src addr
- rewrite server dst ip addr
- route traffic to replica
Can use a predicate to control which modules see which traffic
eg: if port 80 then load balance, then forward; else count and forward
A module should not specify everything:
- leave flexibility to allow other modules to exist
- avoid trying module to a specific setting
- eg: a load balancer spread the traffic across the replicas, but leaves determining network paths to the routing.
A module should have a abstract view of the topology
- "separations of concerns" by "information hiding", as per programming languages, for the same reasons
- so present a simple network rather than the complex reality
eg: a load balancer doesn't see any routing changes
Summary:
- SDN control programs perform many tasks on the same traffic
- this requires
1. compositional operators. How to compose the policies
2. logical switch abstraction. Hiding irrelevant details.
- could use a monolithic application (count, route, firewall, load balance, etc). Difficult to program, test, debug, reuse, port.
- solution: modularise control. monitor program, routing program, firewall program, etc.
- getting modules to play nice
- controller has to arbitrate between modules. These aren't "tenants" with parts of the network to themselves. Different modules affect the same traffic.
- solution: composition
- parallel composition. Multiple operations simultaneously. eg: counting and forwarding.
- sequential composition. One operation, then another. eg: firewall, then switch.
Example application of parallel composition: monitor arriving traffic, route traffic by dst prefix
- parallel composition: do both simultaneously
srcip == 5.6.7.8, dstip == 1.2.0.0/16 ---> fwd(1), count srcip == 5.6.7.8, dstip == 3.4.5.0/25 ---> fwd(2), count ...
- note that the rules can be installed in any order
Example application of sequential composition: server load balancer
Sequence is:
- split traffic based on client's ip src addr
- rewrite server dst ip addr
- route traffic to replica
Can use a predicate to control which modules see which traffic
eg: if port 80 then load balance, then forward; else count and forward
A module should not specify everything:
- leave flexibility to allow other modules to exist
- avoid trying module to a specific setting
- eg: a load balancer spread the traffic across the replicas, but leaves determining network paths to the routing.
A module should have a abstract view of the topology
- "separations of concerns" by "information hiding", as per programming languages, for the same reasons
- so present a simple network rather than the complex reality
eg: a load balancer doesn't see any routing changes
Summary:
- SDN control programs perform many tasks on the same traffic
- this requires
1. compositional operators. How to compose the policies
2. logical switch abstraction. Hiding irrelevant details.