Mina Tahmasbi Arashloo (Princeton University)
Yaron Koral (Princeton University)
Michael Greenberg (Pomona College)
Jennifer Rexford (Princeton University)
David Walker (Princeton University)
While early implementations of SDN only supported forwarding rules and counters at each switch, recent SDN proposals support general purpose persistent state at each switch (not just the controller). Programming against this model is hard however, as network operators have to correctly program a stateful distributed system.
SNAP provides network operators with a high level language, which creates the illusion that the network is a single switch with local state. SNAP then compiles a program written in this language to multiple programs running distributed across the real network with local state at each switch.
SNAP was evaluated on 7 campus and ISP topologies with hundreds of switches and links. SNAP compiled about 20 program for these topologies in 5sec - 6min each.
This work is exciting because it shows a way to extend the various existing high-level SDN programming languages to SDN with state. This work may also be interesting to high-level languages for other networking protocols, like the Border Gateway Protocol which requires persistent state at each router.
Q: (Aurojit Panda) When a switch fails, what happens with its state?
A: SNAP does not currently support failure; the switch loses its state.
Q: Do situations arise where state has to be transferred between switches?
A: If a switch accesses multiple states, all states are stored on the same switch.
Q1: If there is a bug in a SNAP program, will it take down the entire network?
A1: Yes, a bug might bring down the entire network.
Q2: Joint optimization leads to lack of robustness!
Q: Can you do load balancing?
A: Imagine that a switch keeps some state for each IP address. You can shard this state across several switches by the IP address. We have not done this yet.
Link to paper.
Yaron Koral (Princeton University)
Michael Greenberg (Pomona College)
Jennifer Rexford (Princeton University)
David Walker (Princeton University)
While early implementations of SDN only supported forwarding rules and counters at each switch, recent SDN proposals support general purpose persistent state at each switch (not just the controller). Programming against this model is hard however, as network operators have to correctly program a stateful distributed system.
SNAP provides network operators with a high level language, which creates the illusion that the network is a single switch with local state. SNAP then compiles a program written in this language to multiple programs running distributed across the real network with local state at each switch.
SNAP was evaluated on 7 campus and ISP topologies with hundreds of switches and links. SNAP compiled about 20 program for these topologies in 5sec - 6min each.
This work is exciting because it shows a way to extend the various existing high-level SDN programming languages to SDN with state. This work may also be interesting to high-level languages for other networking protocols, like the Border Gateway Protocol which requires persistent state at each router.
Q: (Aurojit Panda) When a switch fails, what happens with its state?
A: SNAP does not currently support failure; the switch loses its state.
Q: Do situations arise where state has to be transferred between switches?
A: If a switch accesses multiple states, all states are stored on the same switch.
Q1: If there is a bug in a SNAP program, will it take down the entire network?
A1: Yes, a bug might bring down the entire network.
Q2: Joint optimization leads to lack of robustness!
A: Imagine that a switch keeps some state for each IP address. You can shard this state across several switches by the IP address. We have not done this yet.
Link to paper.
No comments:
Post a Comment