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

Victor Lopez

Towards a Network Operating System

2 TPI – GCTO Unit Telefónica I+D

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

3 TPI – GCTO Unit Telefónica I+D

Out of the Boxes

• The network does not need to be

seen any longer as a composition

• f individual elements
• User applications interact with the

network controller(s)

• The network becomes a single

entity

§ Suitable to be programmed § 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

FEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWARE FEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWARE FEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWARE FEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWARE

4 TPI – GCTO Unit 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

5 TPI – GCTO Unit Telefónica I+D

A Stored Program Model for the Network

• The SDN concepts bring into play the processing capabilities
• And the stored program

6 TPI – GCTO Unit Telefónica I+D

The Network Is *A* Computer

• So we can apply software

development techniques and tools

• Software development and
• peration being multifaceted

§ Different tools for different tasks

• Static and dynamic verification
• Translation: assemblers, compilers,

interpreters, linkers

• Testing and debugging
• Version and configuration control
• Dynamic composition and linking
• Development flows
• And abstraction capabilities

OpenFlow Controller OpenFlow Switch

OVS OVS OVS OVS

7 TPI – GCTO Unit 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

8 TPI – GCTO Unit Telefónica I+D

Network OS. SDN in the Widest Sense

• Providing a consistent interface to

control, data and management plane

§ A layered model § The first take could follow an analogy with existing OS

• The kernel is realized by control plane

mechanisms

• Data plane is associated with the file

system

• The management plane is mapped to

the system tools

§ Remember the shell

• Specific services to enforce policy and

security

• And the APIs

Network Abstraction Layer

Openflow SNMP NetConf PCEP

Virtual Netwok Layer

Distributed NetOS/ State Security / Accounting / Namespaces Dist IF OpenStack Neutron Bandwidth Scheduling SDN App TE vSwitch Topology vRouter …

App Execution Environment (s)

User space NetOS Kernel Drivers & devices NetOS

9 TPI – GCTO Unit 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

10 TPI – GCTO Unit Telefónica I+D

Net-wide, POSIX Style

Application Application System Interface - APIs

System Tools

• Mgmt

Plane

Filesystem – Data Plane Kernel

• Control Plane

Application

OpenFlow

*MPLS (LDP/ RSVP)

. . .

L2VPN v6 LISP IP …

Policy

• Security

11 TPI – GCTO Unit 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

12 TPI – GCTO Unit 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

13 TPI – GCTO Unit Telefónica I+D

Upper Layers of Abstraction

• NaaS beyond itself

§ Current models are still very much box-

• riented

§ 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 />

14 TPI – GCTO Unit Telefónica I+D

Southbound interfaces for Optical Networks

• SNMP problems with proprietary MIBs that

keeps this technology as monovendor.

• PCEP extended to support provisioning and

trigger the control plane.

• NETCONF is a standard to configure

equipment.

§ Protocol is standard (RFC 6241), but data models are not defined (drafts). § Once these information models are standardized this can make easier the integration with proprietary tools.

• OpenFlow requires extensions to work with
• ptical networks (on-going work).

§ Resilience mechanisms are required for realistic implementations.

Network Abstraction Layer

Openflow SNMP NetConf PCEP

Virtual Netwok Layer

Distributed NetOS/ State Security / Accounting / Namespaces Dist IF OpenStack Neutron Bandwidth Scheduling SDN App TE vSwitch Topology vRouter …

App Execution Environment (s)

User space NetOS Kernel Drivers & devices NetOS

15 TPI – GCTO Unit Telefónica I+D

Southbound interfaces for Optical Networks

Applica'on*Service*Orchestrator*

ABNO*Controller*

Policy* Agent* I2RS* Client*

L2* PCE*

VNTM*

L0* PCE*

Provisioning*Manager*

OAM* Handler*

GMPLS*Domain*

OF interface

Topology* Module* ALTO* Server*

tn1* tn9*

PCEP

16 TPI – GCTO Unit Telefónica I+D

Soutbound interfaces for Optical Networks

Flow ¡ Programmer ¡ REST ¡API ¡ ¡ Topology ¡ Rest ¡API ¡ PCEP ¡ BGP-­‑LS ¡

OP S OP S OP S OP S OP S OP S OP S OP S OP S OP S SDN Controller REST API OpenFlow

GMPLS ¡ Controller ¡ ¡

TED ¡ LSPDB ¡

SDN Controller REST API

GMPLS ¡ Controller ¡ ¡

TED ¡ LSPDB ¡

GMPLS ¡ Controller ¡ ¡

TED ¡ LSPDB ¡

GMPLS ¡ Controller ¡ ¡

TED ¡ LSPDB ¡

OpenFlow Orchestra@on ¡Controller ¡ ¡ Provisioning ¡ Manager ¡ PCE ¡

TED ¡ TED ¡

Topology ¡ Manager ¡ Active Stateful PCE

TED ¡ LSPDB ¡ TED ¡

Topology ¡ ¡ Server ¡

17 TPI – GCTO Unit Telefónica I+D

Abstraction models for Optical Networks

User Space NetOS Kernel Network Abstraction Layer Openflow

SNMP

NetConf PCEP Drivers & devices NetOS

Abstracted Models

Generic Node

18 TPI – GCTO Unit 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.

19 TPI – GCTO Unit Telefónica I+D