Real World Networks in Spring 2020
Explore the roles of network switches, separation of data vs control plane, and the concept of a centralized control plane within software-defined networks. Delve into the architecture of SDNs and how switches are programmed via APIs for efficient management.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
14-760: ADV. REAL WORLD NETWORKS SPRING 2020 * KESDEN
SOFTWARE DEFINED NETWORKS (SDNS) Consider the roles of network switches Figure out what the network looks like Make good forwarding decisions given the topology of the network Originally, there was little architectural distinction within the switch w.r.t.performing these roles Switches ran routing algorithms and made forwarding decisions, but there wasn t a clear, externally well-defined interface separating these two roles
DATA VS CONTROL PLANE Over time, as with anything complex, modularization became important This made sense from an architectural perspective. This was also necessary because forwarding need be a low-latency reactive process and routing is continuous and interactive. The control plane and the data plane were clearly defined and separated Control plane runs routing algorithms and figures things out, giving forwarding tables to data plane Data plane forwards packets according to the forwarding tables. The structure probably took longer to become outwardly visible than it should have because the relatively few major vendors didn t want to define clear interfaces for others to emulate, which would open the door to competition.
CENTRALIZED CONTROL PLANE? The data plane need exist on each and every switch Each switch needs to forward packets But, does the control plane need to exist on each and every switch? In a multi-party internet, there may not be a central place from which to manage a network But, within an organization s own fabric, wouldn t life be simpler and the network more agile if management could be centralized?
SOFTWARE DEFINED NETWORK (SDN) Each switch maintains its own data plane Each switch gets a standardized programmable interface for configuring it Higher level management is performance in a centralized way
SDN ARCHITECTURE Switches maintain data plane Programmed via Southbound API Control plane becomes a software service Programmed via the Northbound API Some call this the network operating system Application level software provides the interface to humans Enables the expression of requirements in a model understandable by a human working in the application domain Source: Software-Defined Networking: A Comprehensive Survey , Kreutz et al., https://arxiv.org/pdf/1406.0440.
OPENFLOW ARCHITECTURE OpenFlow Switch specification Controller OpenFlow Switch PC Secure Channe l sw Flow T able hw IANA port for OpenFlow Switch- Controller connection: 6653 Source: The Stanford Clean Slate Program, http://cleanslate.stanford.edu Via https://conferences.sigcomm.org/sigcomm/2016/tutorial-sdnnfv5g.php ACM SIGCOMM Tutorial | 2016-08-22 | Page42
OPENFLOW 1.0 F L OW TABLE & FIELDS Ethernet VLAN TCP/UDP IP Ingress Port Header Fields Src Dst SA DA ID Priority SA DA Proto TOS Type Classifier Classifier Classifier Action Action Action Statistics Statistics Statistics FlowTable OF1.0style Classifier Action Statistics Physical Port ALL CONTROLLER Virtua l Port Actions Forward LOCAL TABLE IN_PORT Mandatory Action Drop Optional Action Virtua l Port Enqueue Modify Field NORMAL Forward FLOOD Source: https://conferences.sigcomm.org/sigcomm/2016/tutorial-sdnnfv5g.php
OPENFLOW TABLE Each Flow Table entry has twotimers: idle_timeout seconds of no matching packets after which the flow is removed zero means never times-out hard_timeout seconds after which the flowis removed zero mean never times-out If both idle_timeout and hard_timeout are set, then the flow is removed when the first of the two expires. Source: https://conferences.sigcomm.org/sigcomm/2016/tutorial-sdnnfv5g.php
OPENFLOW: BIG PICTURE https://www.researchgate.net/figure/OpenFlow-switch-atchitecture-An-OpenFlow-Switch-consists-of-one-or-more-flow-tables-and-a_fig4_320346909
MIDDLE BOXES, A.K.A. NETWORK APPLIANCES There are many network devices other than switches. These are often called Middleboxes Examples: Firewalls, Intrusion Detection/Prevention Proxies Optimizers Billing
MIDDLE BOXES: COMMON ELEMENT Middle boxes examine and react to network traffic But aren t performing routing
PROMISE AND PERIL OF MIDDLEBOXES Promise Robust, efficient, canned solutions to important problems Peril Specialized = inflexible They do what they do and only what they do They can t be repurposed or shared. Vendor solutions Not interoperable. Act to cause customers to buy more and more expensive specialized hardware Not upgradable
IF SERVERS WORKED THIS WAY? Imagine if computers were treated as appliances and you had to buy them fully configured as hardware devices? Yeah. No.
NETWORK FUNCTION VIRTUALIZATION (NFV) Think of network appliances as composed of two parts A hardware host A virtual network device running as a virtual machine on the host Robust, efficient, canned solutions to important problems are still possible But, the limitations of unmalleable hardware go away This is the idea of Network Function Virtualization (NFV)
THE PROMISE OF NFV More flexible, agile deployment Shorter development-deployment cycle Lower cost Higher utilization
RETHINKING LAYERING Source: https://conferences.sigcomm.org/sigcomm/2016/tutorial-sdnnfv5g.php
VS VIRTUALIZING COMPUTING? The network differs from the computing environment in 2 key factors 1 Data planeworkloads (which are huge!) HIGH PRESSUREON PERFORMANCE 2 GLOBAL NETWORK VIEW IS REQUIRED FOR MANAGEMENT Network requires shape (+ E2E interconnection) which are big challenges for vanilla cloud computing. AN ADAPTED VIRTUALISATION ENVIRONMENT IS NEEDED TO OBTAIN CARRIER-CLASS BEHAVIOUR Source: Adapted from D. Lopez Telefonica I+D, NFV via https://conferences.sigcomm.org/sigcomm/2016/tutorial-sdnnfv5g.php
WHAT TO VIRTUALIZE? Source: SDN and NFV Stepping Stones to the Telco Cloud Prodip Sen (ONS 2016) via https://conferences.sigcomm.org/sigcomm/2016/tutorial-sdnnfv5g.php
HOW TO VIRTUALIZE? https://conferences.sigcomm.org/sigcomm/2016/tutorial-sdnnfv5g.php
NFV CHALLENGES How well will virtualized functions perform? Understanding is not as easy as looking at an appliances benchmark Orchestration How does one manage the instantiation and retirement of network functions? How does one manage their configuration? How are they placed into the network? How does one secure the bits and configuration? Interoperability?
NFV VS SDN Independent, potentially complementary technologies NVF allows the use of generic hardware in place of role-specific appliances SDN provides a paradigm for managing a network as a whole SDNs can include virtual and/or physical appliances Virtual functions can be incorporated with fixed-configuration or software defined networks
NFV VS SDN: VISUALIZING THE SPACE Source: Ahmad Rostami, Ericsson Research (Kista): http://www.itc26.org/fileadmin/ITC26_files/ITC26-Tutorial-Rostami.pdf Via https://conferences.sigcomm.org/sigcomm/2016/tutorial-sdnnfv5g.php
