Transcription
SDN ArchitectureBased on “OpenFlow: EnablingInnovation in Campus Networks”Michael Rausch and Benjamin UjcichCS 538 – October 16, 2014
“OpenFlow: Enabling Innovationin Campus Networks” Published in 2008 “A way for researchers to runexperimental protocols in thenetworks they use every day” University campus audience inmind First implemented at StanfordUniversity
Motivation Introducing innovations into networks isdifficult Network administrators don’t want to risk running experiments on their network adopt untested protocols Researchers cannot test new protocols inrealistic environments at scale and with realtraffic
One Solution: VirtualizedProgrammable Networks Pros: Programmable switches and routers thatcan process traffic for multipleexperiments GENI as an example Lower the barrier to entry for new ideas Cons: Most plans for nationwide at-scaleimplementation are ambitious and costly
One Solution: Open andProgrammable Hardware Pros Persuade hardware vendors to open uptheir hardware to an open, programmableplatform Cons Unlikely in the short term Costly for vendors to build and developtheir hardware platforms Lowers the barrier-to-entry for newcompetitors
A Platform Compromise The authors’ approach was to compromiseby wanting a switch that possesses: High performance and low costimplementation Support for broad and diverse research Isolation mechanisms to clearly separateexperimental traffic from production traffic Consistent with vendors’ need for closedplatforms
How to Implement the Platform Convince vendors to provide the platform? Use existing platforms? PC-based solutions: low performance Supercharged PlanetLab Platform: highcost NetFPGA: only four network interfaces Create new platform?
Solution: OpenFlow Key idea: Exploit the fact that many Ethernetswitches and routers have flow tables withternary content-addressable memory(TCAM), which can ordinarily be used tohelp with the implementation of firewalls,NAT, and QoS Create a common open protocol (OpenFlow)that allows for programming the flow tableswithin networking devices
OpenFlow Components1. Flow table2. Controller3. Secure channelSource:http://web.engr.illinois.edu/ pbg/courses/cs598fa10/readings/mabpprst08.pdf
Flow Entries Each datapath has a flow entry and anassociated action 10 header fields matched in an OpenFlow(v1.0) switch: Ingress port VLAN ID Ethernet: source, destination, type IP: source, destination, protocol TCP: source, destination
Actions Actions that can be performed on trafficmatching a flow entry:1. Forward traffic to a given port or ports(at line rate)2. Encapsulate and forward traffic to thecontroller for inspection (either firstpacket in a flow of traffic or all packets)3. Drop traffic4. Forward traffic through switch’s normalprocessing pipeline
Flow Entries and ActionsSource: http://arxiv.org/pdf/1406.0440v3.pdf
Dedicated OpenFlow Switches vs.OpenFlow-enabled Switches Dedicated OpenFlow Switches Dumb datapath element that forwardspackets between ports OpenFlow-enabled Switches Re-use existing hardware and software TCAMs in hardware Secure channel and OpenFlow protocol insoftware Perform OpenFlow experiments while notinterfering with normal production traffic
Controllers Static controller: Statically establish flow entries in switchesfor the duration of an experiment Generalized VLAN More sophisticated controllers: Allow for simultaneous experiments fromdifferent experimenters Dynamically add or remove flows as anexperiment progresses
Controllers and Flow Entries Proactive flow entry instantiation: Flow entries are pre-determined Useful when traffic type is known before No disruption if controller goes down Reactive flow entry instantiation: Flow entries are determined by sendingtraffic to controller to decide what to do Additional latency due to first packet inthe flow being processed More limited if controller goes down
Popular Controllers (2014)Source: DF/hal final.pdf
Use Cases The authors mentioned several use cases: Network Management and Control VLANs Mobile wireless VOIP clients A non-IP network Processing packets instead of flows Any others?
Thoughts: A Generalized SDNArchitecture OpenFlow is a particular approach (by far themost popular) but it is not the same thing asSDN In “Software-Defined Networking: AComprehensive Survey,”1 four criteria are givenfor SDN: Control and data planes are decoupled Forwarding decisions are flow-based, notdestination based Control logic is handled by controller Network is programmable1Source: http://arxiv.org/abs/1406.0440
A Generalized SDN ArchitectureSource: http://arxiv.org/pdf/1406.0440v3.pdf
A Generalized SDN ArchitectureSource: http://arxiv.org/pdf/1406.0440v3.pdf
A Generalized SDN ArchitectureSource: http://arxiv.org/pdf/1406.0440v3.pdf
A Generalized SDN Architecturevs. Conventional NetworkSource: http://arxiv.org/pdf/1406.0440v3.pdf
Thoughts: The “PragmaticCompromise” Perhaps one of the reasons why OpenFlowdevelopment succeeded after this paper waswritten Hardware vendors could more easilyimplement OF by adding support for theprotocol without exposing the internalworkings of their devices Network administrators could more easilytest out OF in their networks while stillhaving the confidence that experimental andproduction traffic would remain isolated
Thoughts: Use in Campuses The authors of the paper had a very narrowfocus on providing research opportunities byimplementing OpenFlow on campusnetworks SDN and OpenFlow, however, are veryflexible and powerful and are now beingused in enterprise systems
Thoughts: “Fabric: A Retrospectiveon Evolving SDN” Decouple the edge of a network from its coreinternal fabric Separate forwarding decisions so that theedge and fabric can evolve independently Separate control decisions so that the edge isresponsible for network policy (security,isolation, mobility, etc.) and the fabric isresponsible for packet transport Extends SDN concepts while leveragingSDN’s control plane flexibility
Thoughts: “Fabric: A Retrospectiveon Evolving m/2012/paper/hotsdn/p85.pdf
Discussion Where would an SDN architecture not beappropriate? Why? What are the security implications for anSDN architecture? How do they differ fromthe requirements of a conventional networkarchitecture? How should multiple controllers besupported? Does the centralized concept inSDN change because of this?
Thoughts: A Generalized SDN Architecture OpenFlow is a particular approach (by far the most popular) but it is not the same thing as SDN In "Software-Defined Networking: A Comprehensive Survey,"1 four criteria are given for SDN: Control and data planes are decoupled Forwarding decisions are flow-based, not
