Towards a Network Operating System Victor Lopez Shifting Paradigms - PowerPoint PPT Presentation

Towards a Network Operating System Victor Lopez

Shifting Paradigms • SDN is a dramatic shift in the mechanisms to design and operate networks Make network behaviour programmable beyond individual boxes § • Changes the vision from configuration to programming § Compiling, scripting, rapid prototyping, debugging, profiling, IDEs … • Convergence of application and network APIs § Clearer, more comprehensive interfaces • Provides a powerful toolset to deepen network virtualization TPI – GCTO Unit 2 Telefónica I+D

Out of the Boxes • The network does not need to be FEATURE FEATURE seen any longer as a composition OPERATING SYSTEM of individual elements SPECIALIZED PACKET • User applications interact with the FORWARDING HARDWARE FEATURE FEATURE FEATURE FEATURE OPERATING SYSTEM OPERATING SYSTEM network controller(s) • The network becomes a single SPECIALIZED PACKET SPECIALIZED PACKET FORWARDING HARDWARE FORWARDING HARDWARE FEATURE FEATURE OPERATING SYSTEM entity SPECIALIZED PACKET § Suitable to be programmed FORWARDING HARDWARE § Aligned with current IT practices • We can apply different levels of abstraction § Network processor and storage § Network Operating System § Network Abstract APIs • And think of a network design flow § And even an IDE TPI – GCTO Unit 3 Telefónica I+D

The Network and the Computer • Back in 2009 • The idea of dealing with the network as a computing device has been around for quite some time TPI – GCTO Unit 4 Telefónica I+D

A Stored Program Model for the Network • The SDN concepts bring into play the processing capabilities • And the stored program TPI – GCTO Unit 5 Telefónica I+D

The Network Is *A* Computer • So we can apply software OpenFlow Controller development techniques and tools • Software development and operation being multifaceted Different tools for different tasks § • Static and dynamic verification OpenFlow • Translation: assemblers, compilers, Switch interpreters, linkers • Testing and debugging OVS OVS • Version and configuration control • Dynamic composition and linking • Development flows • And abstraction capabilities OVS OVS TPI – GCTO Unit 6 Telefónica I+D

Tools on Their Way • Considering those beyond extended controllers and simulation • Mostly at prototype stage • Debugging: ndb § Network breakpoints § Packet backtrace • Verification: NICE § Model checking plus symbolic execution § Check against correctness properties • Languages § Policy: FML, Procera § Functional: Frenetic • Configuration control: Kinetic § Update mechanisms that preserve global network behaviors TPI – GCTO Unit 7 Telefónica I+D

Network OS. SDN in the Widest Sense • Providing a consistent interface to control, data and management plane OpenStack Bandwidth SDN App Neutron Scheduling A layered model § The first take could follow an analogy § User Topology vSwitch vRouter space TE … with existing OS • The kernel is realized by control plane App Execution Environment (s) mechanisms NetOS • Data plane is associated with the file Virtual Netwok Layer NetOS Dist IF Security / system Distributed NetOS/ Kernel Accounting / State • The management plane is mapped to Namespaces Network Abstraction Layer Drivers & the system tools devices Openflow SNMP NetConf PCEP Remember the shell § • Specific services to enforce policy and security • And the APIs TPI – GCTO Unit 8 Telefónica I+D

The Network OS Ecosystem • The users § Network operators • Manage the network, create services and locate problems in a more efficient manner § Application providers • Reduced time to market for new applications, value added services, abstracted view of the network • The networks § Need to address a wide variety of devices and protocols • The goal § To simplify use and management of heterogeneous E2E networks § Access, core, datacenter … . • The POSIX reference model TPI – GCTO Unit 9 Telefónica I+D

Net-wide, POSIX Style Application Application Application System Interface - APIs System Tools - OpenFlow Filesystem Kernel Mgmt Policy *MPLS Plane – - (LDP/ - RSVP) Security Data Plane Control Plane . . . L2VPN LISP v6 … IP TPI – GCTO Unit 10 Telefónica I+D

Kernel and Filesystem • OpenFlow as the default mechanism And kernel drivers for other control plane § technologies • Strict control on kernel-mode access Restricted API § • A filesystem for the data plane A naming schema equivalent to directories plus § filenames Overlay transparent integration § Interaction with other Network OS instances § Consistent security model § • A neutral data model for internal representations YANG is a clear candidate § TPI – GCTO Unit 11 Telefónica I+D

Policy and Management • Management plane is mapped to the system process idea Shell § Monitoring § Accounting § Policy definition § • A dedicated subset of services for policy enforcement and security Converged authorization § Mapping from outer identities and § roles • Accountability becomes key Security § Metering and auditing § Monetization § TPI – GCTO Unit 12 Telefónica I+D

Upper Layers of Abstraction • NaaS beyond itself Current models are still very much box- § oriented Virtual view of current elements § • And beyond OpenFlow An excellent practical base § As much as processor instruction sets § • A first step: consider the fabric Extend OpenFlow to deal with overlay § control • And start thinking of the equivalents to SQL § OO § Garbage collectors § <YourPreferredITConstruct /> § TPI – GCTO Unit 13 Telefónica I+D

Southbound interfaces for Optical Networks • SNMP problems with proprietary MIBs that keeps this technology as monovendor. OpenStack Bandwidth • PCEP extended to support provisioning and SDN App Neutron Scheduling User Topology vSwitch vRouter trigger the control plane. space TE … • NETCONF is a standard to configure App Execution Environment (s) equipment. NetOS Virtual Netwok Layer Protocol is standard (RFC 6241), but data § NetOS Dist IF Security / Distributed NetOS/ Kernel Accounting / models are not defined (drafts). State Namespaces Once these information models are § Network Abstraction Layer Drivers & devices standardized this can make easier the Openflow SNMP NetConf PCEP integration with proprietary tools. • OpenFlow requires extensions to work with optical networks (on-going work). Resilience mechanisms are required for § realistic implementations. TPI – GCTO Unit 14 Telefónica I+D

Southbound interfaces for Optical Networks Applica'on*Service*Orchestrator* Policy* ABNO*Controller* Agent* OAM* Handler* ALTO* VNTM* L2* Server* PCE* I2RS* Client* L0* Topology* PCE* Module* Provisioning*Manager* PCEP OF interface tn9* tn1* GMPLS*Domain* TPI – GCTO Unit 15 Telefónica I+D

Soutbound interfaces for Optical Networks Orchestra@on ¡Controller ¡ ¡ Provisioning ¡ Topology ¡ PCE ¡ Manager ¡ Manager ¡ TED ¡ TED ¡ BGP-­‑LS ¡ PCEP ¡ Topology ¡ ¡ Active Stateful Flow ¡ Server ¡ PCE Programmer ¡ Topology ¡ Rest ¡API ¡ REST ¡API ¡ ¡ TED ¡ TED ¡ LSPDB ¡ REST API REST API SDN Controller SDN Controller GMPLS ¡ Controller ¡ ¡ OpenFlow OpenFlow TED ¡ LSPDB ¡ GMPLS ¡ GMPLS ¡ Controller ¡ ¡ Controller ¡ ¡ TED ¡ LSPDB ¡ GMPLS ¡ TED ¡ LSPDB ¡ Controller ¡ ¡ TED ¡ LSPDB ¡ OP OP OP S OP S S S OP OP S S OP OP OP S OP S S S TPI – GCTO Unit 16 Telefónica I+D

Abstraction models for Optical Networks NetOS User Space NetOS Kernel Network Abstraction Layer Abstracted Drivers & devices Models Openflow SNMP NetConf PCEP Generic Node TPI – GCTO Unit 17 Telefónica I+D

Conclusions • The network does not need to be seen any longer as a composition of individual elements. • The network can be seen as a computer. • We can apply software development techniques and tools. • A environment is required to work on this direction à NetOS Different abstraction models can be used. § Applications can run on top of the Operating System § Kernel of the system can grow as far as functions are required. § • South bound interfaces to optical networks are required. Protocols should be extended to support remote instantiation § Abstracted models can help to have a common driver where we can plug any § network element. TPI – GCTO Unit 18 Telefónica I+D

TPI – GCTO Unit 19 Telefónica I+D