Lecture 4 - SDN Planes Flashcards
What is flow based forwarding?
Forwarding defined on flows rather than only IP or MAC addresses
Theory: any information of a packet that identifies a communication relation
Practical: combinations of selected layer 2 to 4 header fields
Ex.: IP + Ports + protocol ids
Fine-grained forwarding of selected flows or coarse-grained aggregation
What do the control and data planes do?
Control Plane: define routes, manage network graph
Data Plane: forward packets
How does physical distribution of controllers ensure availability and scalability?
Redundant controllers
Load distribution between controller instances
What’s the definition of the Network Services Abstraction Layer?
An abstraction layer is a mechanism that translates a high-level request into the low-level commands required to perform the request.
What’s the purpose of the Network Services Abstraction Layer?
- Shields the implementation details of a lower level of abstraction from software at a higher level
- Represents the basic properties or characteristics of network entities in such a way network programs can focus on the desired functionality without having to program the detailed actions.
What issues arise in designing specification abstractions?
How much detail to expose?
How much detail to maintain?
Give some examples of network abstractions
Single network view
- Auth with respect to a network
- Consistent model provides
— Number of connected devices
Full Network View
- More benefit from the full network view?
- Consistent model
—Exhibits
—– Number of connected devices
—– Number of switching elements
—– Topology information
What are the 3 basic network interfaces (important abstractions for SDN)?
- Specification
- Shields control program from details of physical network - Distribution
- Shield higher layers from state dissemination/collection - Forwarding
- Shield higher layers from forwarding rules
Explain the pipeline abstraction
In the general service model packet goes in, then layer by layer to ACL and then packet out
Given pipeline specification:
- The pipeline is automatically installed in the network
- At multiple switching devices, e.g.
— All switches: L2 functionality
— Switch #5: L3 Forwarding
— Switch #2 and #4: ACL
What’s the goal of Frenetic/Pyretic design, and name some variants
Goal:
- High level abstractions
— Direct control over the network
- Modular constructs and compositional reasoning
- Can do multiple things
Variants:
- Frenetic-OCaml (OCaml)
- Pyretic (python)
How does Pyretic design handle modularity?
Apps usually do more than one task (routing, monitoring, load balancing)
Code that affects one part must not affect others
With “low-level” APIs speaking only of flow rules, leads to large applications where everything is connected with everything else
- Difficult to develop, deploy and maintain
Modularity is NOT the slicing up of the network
The goal is to build a single app out of reusable components all processing the same traffic
- Components specify traffic handling partially
- App = components
+ how components interact (composition)
+ on what traffic (topology abstraction)
What types of composition exist in Pyretic design?
Sequential
- Components see modifications from preceding component
- Looks like a pipeline
Parallel
- Components have the illusion of each acting on its own private copy of the traffic
Explain topology abstraction in pyretic design
Network objects allow each module to work on its own abstract view of the network
Can be constrained to limit what traffic each module can see and do:
- Subgraph of actual topology
- Giant switch comprising the whole network
Suppots:
- Multiple nesting levels, physical and virtual machines
- “Many-to-one”: many switches appear as one virtual
- “One-to-many”: one switch appears as several virtual
Explain what do packets look like in Pyretic design?
They are an extensible packet model
Packet is not a fixed structure, unlike, e.g. TCP
Dictionary that maps field names to values:
- Field name “srcip” mapped to source IP address
- Field name “dstport” mapped to destination port
- If p is a packet and f a field name, you write p[f]
Some fields are about packet location
- Switch name, port, direction (in or out)
In addition to standard fields, also virtual fields which can hold arbitrary data structures
Every field can hold a stack of values (top is current value)
Values can be popped or pushed
Stacking can be applied to all header fields in Pyretic only constraint is that standard OpenFlow headers cannot be empty
What are field stacks in packets within pyretic design useful for?
Anonymize packet while packet is inside network
- Must remember original source/destination addresses
- Push anonymized values for src/dst address on ingress
- Pop original values on egress
Stacks are useful for VMs:
- Packet enters virtual switch: push location of virtual switch
- Packet leaves switch: pop location
Presents the illusion of a packet travelling through multiple levels of abstract networks
How is mapping extended packet model to OpenFlow-supported model done in Pyretic?
It’s done by Pyretic run-time system.
What do Pyretic policies do? What are the typical ones? What kinds exist and what these kinds are?
Policies say what is to be done with a packet
Typical:
- Flood
- Drop
Types: Constant (static) and changing (dynamic) policies
Static - “snapshot” of a network’s global forwarding behavior
Dynamic - sequence of static policies, important to adapt the network
Show examples of static policy syntax and semantics in Pyretic
It’s on slide 99 in lecture 4, go find it urself, I am not paying to upload pics nor am I writing all that shit here.
Primitive actions in pyretic?
Receive a packet with location info as input
Return a set of located packets as output
Example:
- Input is { switch: A, inport: 3}
- Output could be {{ switch: A, outport: 4}}
Action Types:
- drop - produces the empty set (no packet is output)
- passthrough - produces the input packet as output
- fwd(port) - changes outport
- flood - floods packet using minimum spanning tree
- push, pop, move - change packet value stacks
Predicates in pyretic?
If C is a policy and P is a predicate, then P[C] means to apply C to all packets for which P is true
all_packets, no_packets return true or false, resp.
ingress, egress return true if packet enters (leaves)
match(h=v) return true if header h has value v
Predicates can be composed:
- Conjuction: true if both true
- Disjunction: true if one is true
- Negation: true if P is false
What are query policies used for?
Direct information/statistics from physical network to controller
Maintained in form of buckets on controller
Example:
- counts: packet goes to counts bucket
- packets: packet goes to packets bucket
— Applications are informed about arrival of packets
- packets: entire packets, counts: packet counts
— packets (every, [‘scrip’]) passes each packet with new src address
- counts(every, [‘scrip’]) calls listeners every ‘every’ seconds with number of times each source IP has been seen
How can policies be composed?
Policies can be simple actions (flood etc.)
Conditional P[C]
- Applies policy C if the packet satisfies predicate P
Composed so that they either act in parallel
- C1|C2 (C1 and C2 together)
or in sequence
- C1»C2 (first C1, then C2)
or conditionally
- if_(P,C1,C2) (if P, then C1, else C2)
Give some example pyretic applications
- ARP responder
- Firewalls
- Gateways
- Load Balancers
- Monitoring
- Big switch
- Spanning tree
How is publish/subscribe implemented Time Sensitive Networking
Time Sensitive Networking (TSN):
- Central Controller
— Scheduling flows
— Providing QoS guarantees
— SDN concept
- Publish Subscribe:
— Ethernet-based Multicast
— “brokerless design” –> TSN Switch == broker
