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

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: (i) the underlying hardware (ii) the software that controls the overall behavior of the network 1

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 2

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

There are three relevant interfaces (i) Host -Network : inform the network of host’s requirements (ii) Operator-Network : inform the network of operator’s requirements (iii) Packet-Switch : identify packet to a switch 4

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 5

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 6

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 7

SDN three problems (i) no simplified hardware (ii) no sufficient flexibility (iii) it unnecessarily couples the host requirements to the network core behavior 8

Extending SDN 9

the key properties for fabrics (i) 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 (i) Separation of Control : Separating the control planes allows them each to evolve separately, focusing on the specifics of the problem 10

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

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

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 1. follow MPLS 2. limit the packet operations to a destination address lookup with a longest prefix match with ECMP-based forwarding 13

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 1. Address translation : swapping out addresses in situ 2. Encapsulation 14

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? 15