Software-defined networks (SDN) PA160: Net-Centric Computing II. Tomáš Rebok Institute of Computer Science Masaryk University rebok@ics.muni.cz Motivation Traditional Computing vs Modern Computing Ludek Matyska • SDN • 5/22/2018 3 Traditional vs Modern Computing Provisioning Methods Source: Adopted from Transforming the Network With Open SDN by Big Switch Network Ludek Matyska • SDN • 5/22/2018 4 Modern Networking Complexity http://ww1.prweb.com/prfiles/2004/11/18/180597/map2004-small.gif Ref: Javvin Ludek Matyska • SDN • 5/22/2018 5 Million of lines of source code •6000+ RFCs Barrier to entry Billions of gates Bloated Power Hungry •Many complex functions baked into the infrastructure •OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, MPLS, redundant layers, … • •An industry with a “mainframe-mentality”, reluctant to change • The Ossified Network Specialized Packet Forwarding Hardware Operating System Feature •Feature Routing, management, mobility management, access control, VPNs, … •6 Ludek Matyska • SDN • 5/22/2018 6 Traditional vs Modern Networking Provisioning Methods Source: Adopted from Transforming the Network With Open SDN by Big Switch Network Ludek Matyska • SDN • 5/22/2018 7 Computing vs Networking Source: Adopted from Transforming the Network With Open SDN by Big Switch Network Ludek Matyska • SDN • 5/22/2018 8 Ludek Matyska • SDN • 5/22/2018 9 Ludek Matyska • SDN • 5/22/2018 10 Ludek Matyska • SDN • 5/18/2016 11 Ludek Matyska • SDN • 5/22/2018 12 Ludek Matyska • SDN • 5/22/2018 13 Software-Defined Networking (SDN) The answer to necessary networking evolution –making them able to better (i.e. more flexibly, faster, …) react to current requirements The basic idea: Management of network services through abstraction of lower-level functionality –decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane) –centralized management – 14 Specialized Packet Forwarding Hardware •App •App •App Specialized Packet Forwarding Hardware •App •App •App Specialized Packet Forwarding Hardware •App •App •App Specialized Packet Forwarding Hardware •App •App •App Specialized Packet Forwarding Hardware Operating System Operating System Operating System Operating System Operating System •App •App •App •15 •Current Internet •Closed to Innovations in the Infrastructure •Closed • Ludek Matyska • SDN • 5/22/2018 15 The next 3 slides are a set of animation to show how we enable innovation: - Infrastructure is closed to innovation and only driven by vendors. Consumers have little say - Business model makes it hard for new features to be added Specialized Packet Forwarding Hardware •App •App •App Specialized Packet Forwarding Hardware •App •App •App Specialized Packet Forwarding Hardware •App •App •App Specialized Packet Forwarding Hardware •App •App •App Specialized Packet Forwarding Hardware Operating System Operating System Operating System Operating System Operating System •App •App •App Network Operating System App App App “Software Defined Networking” approach to open it Ludek Matyska • SDN • 5/22/2018 16 •How do we redefine the architecture to open up networking infrastructure and the industry! •By bring to the networking industry what we did to the computing world App Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware App App Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Network Operating System •1. Open interface to hardware •3. Well-defined open API •2. At least one good operating system •Extensible, possibly open-source The “Software-defined Network” Ludek Matyska • SDN • 5/22/2018 17 •Switches, routers and other middleboxes are dumbed down •The key is to have a standardized control interface that speaks directly to hardware Software-defined network (SDN) SDN – Basic Concepts 19 Ludek Matyska • SDN • 5/22/2018 20 •Switches, routers and other middleboxes are dumbed down •The key is to have a standardized control interface that speaks directly to hardware Ludek Matyska • SDN • 5/22/2018 21 Ludek Matyska • SDN • 5/22/2018 22 Ludek Matyska • SDN • 5/22/2018 23 Ludek Matyska • SDN • 5/22/2018 24 Ludek Matyska • SDN • 5/22/2018 25 Ludek Matyska • SDN • 5/22/2018 26 SDN – benefits summary Reducing overhead costs (easier management) –centralized management Easier and faster deployment of new services –from weeks/months to days/hours/minutes Higher flexibility –allowing to support applications with specific needs Higher usage efficiency –lowering over-provisioning Support of new features and applications –including e.g. virtualization/slicing of the network etc. etc. 27 Ondro, jen pro Tebe: overprovisioning je volna kapacita site, kterou musis ponechat, aby sit fungovala (v SDN si muzes diky vysoke flexibilite ty toky planovat efektivneji) OpenFlow protocol SDN/OpenFlow - introduction 29 Ludek Matyska • SDN • 5/22/2018 30 •Switches, routers and other middleboxes are dumbed down •The key is to have a standardized control interface that speaks directly to hardware Ludek Matyska • SDN • 5/22/2018 31 •Switches, routers and other middleboxes are dumbed down •The key is to have a standardized control interface that speaks directly to hardware Ludek Matyska • SDN • 5/22/2018 32 •Switches, routers and other middleboxes are dumbed down •The key is to have a standardized control interface that speaks directly to hardware •Controller • •OpenFlow Switch Flow Table Secure Channel •PC •hw •sw •OpenFlow Switch specification Components of OpenFlow Network 33 * Figure From OpenFlow Switch Specification Ludek Matyska • SDN • 5/22/2018 How does OpenFlow work? •34 Ludek Matyska • SDN • 5/22/2018 34 •Controller •PC •Hardware •Layer •Software •Layer • •Flow Table • •MAC •src • •MAC •dst • •IP •Src • •IP •Dst • •TCP •sport • •TCP •dport • •Action •OpenFlow Client • •* •* •5.6.7.8 •* •* •* •port 1 •port 4 •port 3 •port 2 •port 1 •1.2.3.4 •5.6.7.8 •OpenFlow Example •35 Ludek Matyska • SDN • 5/22/2018 •Controller •PC OpenFlow usage • • •OpenFlow Switch • •OpenFlow Switch • •OpenFlow Switch •Alice’s code • •Decision? •OpenFlow •Protocol •Alice’s Rule •Alice’s Rule •Alice’s Rule Logo-openflow Kopie Logo-openflow Kopie Logo-openflow Kopie •OpenFlow offloads control intelligence to a remote software Ludek Matyska • SDN • 5/22/2018 36 •How the actual protocol works OpenFlow Basics Flow Table Entries • •Switch •Port • •MAC •src • •MAC •dst • •Eth •type • •VLAN •ID • •IP •Src • •IP •Dst • •IP •Prot • •L4 •sport • •L4 •dport • •Rule • •Action • •Stats 1.Forward packet to zero or more ports 2.Encapsulate and forward to controller 3.Send to normal processing pipeline 4.Modify Fields 5.Any extensions you add! •+ mask what fields to match • •Packet + byte counters •37 • •VLAN •pcp • •IP •ToS Ludek Matyska • SDN • 5/22/2018 Now I’ll describe the API that tries to meet these goals. Examples •Switching •* • •Switch •Port • •MAC •src • •MAC •dst • •Eth •type • •VLAN •ID • •IP •Src • •IP •Dst • •IP •Prot • •TCP •sport • •TCP •dport • •Action •* •00:1f:.. •* •* •* •* •* •* •* •port6 •Flow Switching •port3 • •Switch •Port • •MAC •src • •MAC •dst • •Eth •type • •VLAN •ID • •IP •Src • •IP •Dst • •IP •Prot • •TCP •sport • •TCP •dport • •Action •00:20.. •00:1f.. •0800 •vlan1 •1.2.3.4 •5.6.7.8 •4 •17264 •80 •port6 •Firewall •* • •Switch •Port • •MAC •src • •MAC •dst • •Eth •type • •VLAN •ID • •IP •Src • •IP •Dst • •IP •Prot • •TCP •sport • •TCP •dport • •Action •* •* •* •* •* •* •* •* •22 •drop •38 Ludek Matyska • SDN • 5/22/2018 Ludek Matyska • SDN • 5/22/2018 39 Scalability & Robustness •40 Ludek Matyska • SDN • 5/22/2018 40 Centralized vs Distributed Control Both models are possible with OpenFlow •Centralized Control • •OpenFlow •Switch • •OpenFlow •Switch • •OpenFlow •Switch •Controller •Distributed Control • •OpenFlow •Switch • •OpenFlow •Switch • •OpenFlow •Switch •Controller •Controller •Controller •41 Ludek Matyska • SDN • 5/22/2018 Flow Routing vs. Aggregation Both models are possible with OpenFlow •Flow-Based • •Every flow is individually set up by controller •Exact-match flow entries •Flow table contains one entry per flow •Good for fine grain control, e.g. campus networks Aggregated •One flow entry covers large groups of flows •Wildcard flow entries •Flow table contains one entry per category of flows •Good for large number of flows, e.g. backbone •42 Ludek Matyska • SDN • 5/22/20168 Reactive vs. Proactive (pre-populated) Both models are possible with OpenFlow •Reactive • •First packet of flow triggers controller to insert flow entries •Efficient use of flow table •Every flow incurs small additional flow setup time •If control connection lost, switch has limited utility Proactive • •Controller pre-populates flow table in switch •Zero additional flow setup time •Loss of control connection does not disrupt traffic •Essentially requires aggregated (wildcard) rules •43 Ludek Matyska • SDN • 5/22/2018 Basic SDN/OpenFlow principles Basic SDN/OpenFlow principles Basic networking concepts remain unchanged –including all the packet headers & communication protocols however, some configuration protocols and functions (like VRF) are not needed any more –the only change is performed in packet handling and its configuration Major benefits in network management –centralized control & easier management –network segmentation on multiple levels physical and virtual network separation –dynamic response 45 Real-life deployment Traditional approach 46 Real-life deployment SDN/OpenFlow approach 47 Real-life deployment SDN/OpenFlow approach Virtual networks in SDNs – Virtual Tenant Networks 48 Separate VTNs for (MUNI examples): •production network •technology network •sensitive-data network •infected nodes or nodes under attack •experimental network •commercial network •… all of them fully isolated (may run same IPs) Link redundancy is welcomed! Nad tim obrazkem se prosim dukladneji zamysli; tady se da ohledne VTNs okomentovat hodne veci… Real-life deployment SDN/OpenFlow approach Virtual networks in SDN – Virtual Tenant Networks 49 Zduraznit, ze VTNs jsou logickou konfiguraci site, kazda muze slouzit pro jiny ucel… Real-life deployment SDN/OpenFlow approach Virtual network representation / topology (in each VTN may differ) 50 just end ports (statically/dynamically) configured internal configuration of all OFSs computed by the controller OFS = OpenFlow Switch Real-life deployment SDN/OpenFlow approach 51 In case of hybrid switches, part of the HW may serve as control network (traditional approach) Zde jeste dodam obrazek fyzickeho rozdeleni (vcetne moznosti vyuziti pro ridici sit)… SDN/OpenFlow Demo 52 SDN/OpenFlow Demo – VTN representation 53 VTN representation: SDN/OpenFlow Demo 54 Video running… Further examples of real-life use-cases 55 Further examples of real-life use-cases 56 Zde se da zminit, ze neco podobneho lze pouzit pro bezpecnost – definovane toky smerovat na Intrusion Detection System, a tam je analyzovat… Further examples of real-life use-cases 57 Napriklad ochrana prenosu citlivych dat… Further examples of real-life use-cases 58 Network Function Virtualization (NFV) žDiverse network functions (NF). žProviding desired overall functionality or service. žAdding new services •New service instances take weeks to activate •New service types may take months up to years •New service types require either new equipment or upgrading of existing equipment žWe have to simplify network design, increase agility, speed up deployment of new services. Ludek Matyska • SDN • 5/22/2018 60 žNFV – Network Functions Virtualization žLikewise VM žVirtualization – NF and part of the infrastructure is implemented as a software. žResult – from dedicated proprietary appliance to COTS hardware Ludek Matyska • SDN • 5/22/2018 61 http://www.moorinsightsstrategy.com/wp-content/uploads/2013/08/traditional-NFV.png Ludek Matyska • SDN • 5/22/2018 62 SDN controllers SDN controllers Common objectives: –multiple Southbound interface protocol support –well-defined Northbound API support –programmability –high availability & performance –security Open-source vs. commercial Ludek Matyska • SDN • 5/22/2018 64 Ludek Matyska • SDN • 5/22/2018 65 Ludek Matyska • SDN • 5/22/2018 66 OpenDaylight architecture illustration SDNE.png Service Abstraction Layer/Core Base Network Functions - Lithium OpenFlow Enabled Devices DLUX VTN Coordinator OpenStack Neutron SDNI Wrapper Network Applications Orchestrations & Services Open vSwitches Additional Virtual & Physical Devices Data Plane Elements (Virtual Switches, Physical Device Interfaces) Controller Platform Services/Applications OpenFlow Stats Manager OVSDB NETCONF PCMM/COPS SNBI LISP BGP PCEP SNMP SXP Southbound Interfaces & Protocol Plugins OpenFlow OpenFlow Switch Manager USC CAPWAP OPFLEX CoAP HTTP OpenFlow Forwarding Rules Mgr L2 Switch Host Tracker Topology Processing AAA AuthN Filter OpenDaylight APIs REST/RESTCONF/NETCONF Data Store (Config & Operational) Messaging (Notifications / RPCs) LACP Network Services Service Function Chaining Reservation Virtual Private Network Virtual Tenant Network Mgr. Unified Secure Channel Mgr OVSDB Neutron Device Discovery, Identification & Driver Management LISP Service DOCSIS Abstraction SNMP4SDN Network Abstractions (Policy/Intent) ALTO Protocol Manager Network Intent Composition Group Based Policy Service Platform Services Authentication, Authorization & Accounting Neutron Northbound Persistence SDN Integration Aggregator Time Series Data Repository Link Aggregation Ctl Protocol Module 3: OpenDaylight 3-03 67 NETCONF & YANG different SDN view… MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG NETCONF and YANG in Context NETCONF Manager NETCONF Yang Models YANG Models YANG Models YANG Models YANG Models Management Applications MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG What is a Data-Model? What is a Network Management Protocol? •Data-Model •A data-model explicitly and precisely determines the structure, syntax and semantics of the data… •…that is externally visible •Consistent and complete •Protocol •Remote primitives to view and manipulate the data •Encoding of the data as defined by the data-model Data-Model Protocol Standards background, motivation and history RFC 3535: Operators’ problems and requirements on network management (results of IETF’s meeting with network operators) MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG Informational RFC 3535 •SNMP had failed •For configuration, that is •Extensive use in fault handling and monitoring •CLI scripting •“Market share” 70%+ •Abstract •This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. • configuration MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG Operator Requirement #1/14 •1. Ease of use is a key requirement for any network management technology from the operators point of view. • Maybe not assume integrators and software developers for any addition or change Manage MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG Operator Requirement #2-3/14 •Clearly separating configuration •Ability to compare across devices •2. It is necessary to make a clear distinction between configuration data, data that describes operational state and statistics. •3. It is required to be able to fetch separately configuration data, operational state data, and statistics from devices, and to be able to compare these between devices. • $show running-config MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG Operator Requirement #4-5/14 •Service and Network management, not only device management •Network wide transactions •4. It is necessary to enable operators to concentrate on the configuration of the network as a whole rather than individual devices. •5. Support for configuration transactions across a number of devices would significantly simplify network configuration management. • VPN Configuration All or nothing MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG Operator Requirement #6-7/14 •Devices figure out ordering •No unnecessary changes •Finally: backup/restore of configuration •6. Given configuration A and configuration B, it should be possible to generate the operations necessary to get from A to B with minimal state changes and effects on network and systems. It is important to minimize the impact caused by configuration changes. •7. A mechanism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from/to devices are desirable. • • • The litmus-test of a management interface configuration MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG •8. It must be easy to do consistency checks of configurations over time and between the ends of a link in order to determine the changes between two configurations and whether those configurations are consistent. •10. It is highly desirable that text processing tools such as diff, and version management tools such as RCS or CVS, can be used to process configurations, which implies that devices should not arbitrarily reorder data such as access control lists. Operator Requirement #8, 10/14 •Validation of configuration •Validation at network level •Text based configuration VPN Configuration Valid? Text MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG Operator Requirement #9/14 •Standardized data models • •9. Network wide configurations are typically stored in central master databases and transformed into formats that can be pushed to devices, either by generating sequences of CLI commands or complete configuration files that are pushed to devices. There is no common database schema …, although the models used by various operators are probably very similar. •It is desirable to extract, document, and standardize the common parts of these network wide configuration database schemas. Interfaces Data-Model MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG Operator Requirement #13/14 •Support for multiple configuration sets •Delayed, orchestrated activation • • • •13. It is important to distinguish between the distribution of configurations and the activation of a certain configuration. •Devices should be able to hold multiple configurations. Config, Config, Commit MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG •11. … Typical requirements are a role-based access control model and the principle of least privilege, where a user can be given only the minimum access necessary to perform a required task. •12. It must be possible to do consistency checks of access control lists across devices. •14. SNMP access control is data-oriented, while CLI access control is usually command (task) oriented. … As such, it is a requirement to support both data-oriented and task-oriented access control Operator Requirement #11,12,14/14 •Role-Based Access Control (RBAC) •Data oriented •Task oriented MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG NETCONF was designed to conform to RFC 3535. Today many operators require NETCONF and YANG in devices. NETCONF makes a difference on the bottom line. MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG What makes NETCONF/YANG different? SNMP NETCONF SOAP REST Standard IETF IETF W3C - Resources OIDs Paths URLs Data models Defined in MIBs YANG Core Models Data Modeling Language SMI YANG (WSDL, not data) Undefined, (WSDL), WADL, text… Management Operations SNMP NETCONF In the XML Schema, not standardized HTTP operations Encoding BER XML XML XML, JSON,… Transport Stack UDP SSH TCP SSL HTTP TCP SSL HTTP TCP “RESTConf” MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG What makes NETCONF/YANG different? •SNMP •GET •GET-NEXT •SET •TRAP •… • • • •… so what? •NETCONF • • • • • • •… • •… same same? Data-Model MIB Modules YANG Modules Protocol The SNMP Protocol NETCONF MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG What makes NETCONF/YANG different? • Use Case SNMP NETCONF Get collection of status fields Yes Yes. Bulk xfer up to 10x faster. Really. Set collection of configuration fields Yes, up to 64kB Yes Set configuration fields in transaction No Yes Transactions across multiple network elements No Yes Invoke administrative actions Well… Yes Send event notifications Yes Yes, connected Backup and restore configuration Usually not Yes Secure protocol v3 is fair Yes Test configuration before final commit No Yes This is where the difference is: In the supported use cases! MAY 27, 2013 ‹#› ©2013 TAIL-F all rights reserved TUTORIAL: NETCONF AND YANG YANG ? •Data modeling language •Configuration data •State data •Tree structure •Data and Types • acme-box module properties container interfaces container name: string, config name: string, config interface: list, index = name YANG Header Thank you for your attention!