| 24 | | The main activity in this quarter was centered around redesigning the SCAFFOLD architecture to run on top of IP rather than using its own network layer. This redesign came about for two main reasons: deployability and third-party software dependencies. Obviously, designing a new network layer (as our initial SCAFFOLD proposal aimed to) comes at great costs in terms of deployment. Although a "clean-slate" design gives great opportunities for innovation, every router in the network needs to be updated. Our approach around this problem was to leverage the proliferation of programmable OpenFlow-based networks and routers. However, despite allowing great flexibility in the control plane, OpenFlow did not give us the flexibility needed in the data plane (e.g., to match on new network layer headers), and updates to the OpenFlow specification that would address these shortcomings were slow to reach actual hardware. The limitations of the OpenFlow platform therefore forced us to make our own modifications to the OpenVSwitch software router, while still not addressing the significant trade-offs we had to make in our stack implementation (e.g., we had to rely on repurposed IPv4 headers for our network layer format, and this simply didn't give us enough bits for our needs). This gave us the worst of two worlds: a significant deployment hurdle, and a dependency on third-party software that was slow to update. After having re-assessed our situation and architecture design, we came to realize that we could meet most of the goals set |
| | 24 | The main activity in this quarter was centered around redesigning the SCAFFOLD architecture to run on top of IP rather than using its own network layer. This redesign came about for two main reasons: deployability and third-party software dependencies. Obviously, designing a new network layer (as our initial SCAFFOLD proposal aimed to) comes at great costs in terms of deployment. Although a "clean-slate" design gives great opportunities for innovation, every router in the network needs to be updated. Our approach around this problem was to leverage the proliferation of programmable OpenFlow-based networks and routers. However, despite allowing great flexibility in the control plane, OpenFlow did not give us the flexibility needed in the data plane (e.g., to match on new network layer headers), and updates to the OpenFlow specification that would address these shortcomings were slow to reach actual hardware. The limitations of the OpenFlow platform therefore forced us to make our own modifications to the OpenVSwitch software router, while still not addressing the significant trade-offs we had to make in our stack implementation (e.g., we had to rely on repurposed IPv4 headers for our network layer format, and this simply didn't give us enough bits for our needs). This gave us the worst of two worlds: a significant deployment hurdle, and a dependency on third-party software that was slow to update. After having re-assessed our situation and architecture design, we came to realize that we could meet most of the goals set up for our architecture while retaining IP compatibility. Some loss of functionality (e.g., network-layer anycast service resolution) could be regained by alternative mechanism in a layer 3.5, sitting in-between the network and transport layers. |
