Fabric: A Retrospective on Evolving SDN

1. Fabric: A Retrospective on Evolving SDN Author : Martín Casado,TeemuKoponen, Scott Shenker, Amin Tootoonchian Publisher : Presenter : Pei-Hua Huang Date : 2013/10/02

2. Introduction • Current networks are too expensive, too complicated to manage, too prone to vendor-lockin, and too hard to change • Network infrastructure has two components: • the underlying hardware • the software that controls the overall behavior of the network

3. Introduction • Ideal hardware : Simple: inexpensive to build and operate Vendor-neutral: easy to switch between hardware vendors Future-proof: as much as possible to accommodate future innovation • Ideal software : Flexible: should support the wide variety of requirements

4. Background • Network infrastructure design is guided by network requirements and network interfaces • Network requirements come from two sources: • Host : want their packets to travel to a particular destination (ii) Network operator : traffic engineering, virtualization, tunneling and isolation

5. There are three relevant interfaces • Host -Network : inform the network of host’s requirements • Operator-Network : inform the network of operator’s requirements • Packet-Switch : identify packet to a switch

6. Original Internet • The goal is to merely carry the packet from source to destination • Every router would independently interpret the host requirements and take the appropriate forwarding action • Host-Network and Packet-Switch interfaces were identical, and no Operator-Network interface

7. MPLS • MPLS introduced an explicit distinction between the network edge and the network core • Edge routers inspect the incoming packet headers and then attach a label onto the packet which is used for all forwarding within the core • Distinguished Host-Network and Packet-Switch interfaces, but no Operator-Network interface

8. SDN • provide a fully programmatic Operator-Network interface • In OpenFlow each switch within the network exports an interface that allows a remote controller to manage its forwarding state • do not distinguish between the Host-Network interface and the Packet-Switch interface

9. SDN • three problems • no simplified hardware • no sufficient flexibility • it unnecessarily couples the host requirements to the network core behavior

10. Extending SDN

11. Extending SDN • the key properties for fabrics • Separation of Forwarding : external addresses are not used in forwarding decisions within the fabric both to simplify the fabric forwarding elements, but also to allow for independent evolution of fabric and edge • Separation of Control : Separating the control planes allows them each to evolve separately, focusing on the specifics of the problem

12. Fabric Service Model • a fabric should be able to support any number of edge designs including different addressing schemes and policy models

13. Fabric Path Setup • two methods are commonly used today • use a standard IGP (like OSPF) and ECMP to build a fabric • MPLS, requires the explicit provisioning of an LSP by the provider

14. Addressing and Forwarding in the Fabric • A forwarding element in the fabric is not required to use end-host addresses for forwarding, they are only responsible for delivering a packet to its destination(s) • Two approaches can be optimized the implementation of the fabric forwarding • follow MPLS • limit the packet operations to a destination address lookup with a longest prefix match with ECMP-based forwarding

15. Mapping the Edge Context to the Fabric • The complexity in an edge/fabric architecture lies in mapping the edge context to network addresses or paths • two primary mechanisms • Address translation : swapping out addresses in situ • Encapsulation

16. Questions and Implications • Isn’t this just another approach to layering? • What does this mean for OpenFlow? • Why is simplicity so important? • What does this mean for networking more generally?