SOURCE: Scott Shenker – Professor, University of Berkeley, California.
We know that Abstractions are keys to extracting simplicity. Classic example of abstractions in networking is LAYERS. Layers deal with the data-plane, and there is a need for ‘strong’ control-plane abstractions.
Network Control Problem:
- Operating Without communication guarantee
- Computing the configuration of each (physical) devices.
- Operate within the given network protocol
The below three abstractions are based on the above ‘Decomposition’ of the ‘Network Control Problem’.
- Distributed State Abstraction – Control mechanisms should only be able to access the Network-state and it should be shielded from the ‘unexpected changes’ of the network-state. Ex: A global network view, where a well-defined network graph is exposed as an API – and control mechanisms work on (uses) these API(s).
- Specification Abstraction: Control mechanisms should just be able express desired behavior, instead of implementing that behavior on network infrastructure. Ex: Abstract view of the network, that models only enough details to specify goals – Pflow's VTN?
- Forwarding Abstraction: Should focus on freedom from dataplane limitations and vendor-specific solution. Ex: Openflow. Flexible forwarding model - Abstractions supporting whatever forwarding behavior that is needed, and not constraining the control mechanisms. It should hide underlying hardware details – crucial to go beyond vendor-specific solutions.
No comments:
Post a Comment