Telefónica I+D 10 .12.2012

Telefónica I+D

10.12.2012

For a More Efficient and Fair Network Usage

Applying Abstraction

2TPI – GCTO UnitTelefónica I+D

Network Plasticity

• User-centric connectivity experience Collaboration among the applications and the network(s) Networks based on different technologies Networks in different realms

• Mutual awareness between network and IT Bidirectional flows

• Blurring the limits Software in the network Networks in software Northbound

• Application-to-network Eastbound

• Network-realm-to-network-realm

• Abstraction ability is key Complexity hiding Coopetition


SDN: 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


Out of the Boxes

• The network does not need to be seen any longer as a composition of 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 Think of a network design flow And even an IDE

FEATURE FEATURE

OPERATING SYSTEM

SPECIALIZED PACKET FORWARDING HARDWARE

FEATURE FEATURE

OPERATING SYSTEM


FEATURE FEATURE

OPERATING SYSTEM


FEATURE FEATURE

OPERATING SYSTEM



SDN Principles

• Make network behaviour programmable Beyond individual boxes

• Fully decouple data and control planes Simple packet processing elements

(switches) Software-based controlling components

(controllers)

• Functions are split between per-packet rules on the switch and high-level decisions at the controller

• Open interface between control and data plane

• Open interface to the control plane• Controllers actually program the network

Even bypassing conventional layered protocols and their configuration

Switch

Switch

Switch

Switch

Switch

SDN Control Plane Software

.

App

App

App

App


SDN at Work: OpenFlow

• The controller drives the switch by means of updating its flow tables

• A flow table is a set of rules consisting of Match fields (per packet) Instructions (output, drop, Set tag or

field…) If no match, ask controller by default

• A channel connects a controller and a switch through messages

• Controllers can prepopulate instructions or dynamically take decisions on switch queries


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


A Stored Program Model for the Network

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


The Network Is *A* Computer

• So we can apply software development techniques and tools

• Software development and operation 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


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


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


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 v6LISPIP …

Policy -

Security


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


Acting at the Dataplane

• Network slicing Essential for physical infrastructure sharing

• Specific appliance access by traffic steering Content filtering and dynamic firewalling Encryption and privacy Access control Transport optimization

• OF-enabled appliances Controlled as another

switch Closer integration


And Supporting Network Function Virtualization

• Base sophisticated services on open standard hardware And rely on virtual appliances running on datacenters

• Do not require expensive redeployments Just change controllers and appliances Aligned with central policies

• Define a new way of addressing network functionality Dynamic connection of virtualized components Grow as requirements grow

SwitchAccess Point Módem

CPE FW

TR-069NAT

UPnP

DHCP

IPv4/IPv6

STBHome environment

Network environment


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 Security Metering and auditing Monetization


Know Who Does What

• First packets in any flow can be always routed to the controller And identity of the user established Several options for doing this en-

route Different flavours of EAP transport,

like 802.1x or PANA

• The controller can apply policies Derived from any source At any layer(s)

• And define sessions By means of specific rules Triggered by time or flow properties

• Default behaviour for plain access


Go beyond the User-behind-a-portal

• Do not require a leap of faith to the network infrastructure Current models do not allow to

positively identify the user behind a request

• Forward identity information down to the controller Decouple decision points And allow autonomous decisions

• Break blind trust relationships So services can be individualised

at any layer And different trust links

established with a variety of partners


Converged Authorization

• Controllers are programmable entities They can rely on any set of services

for policy enforcement and security

• Including authorization engines And even federated identity systems Specific authorisations recorded Access and usage rules Dynamic contract enforcement Pay-as-you-go for network services

• Mix-and-match with current technologies in IT space Outer identities permeate the network

infrastructure

NSP Community

of Registration

“NSP customer”

Community of Interest

“Local government” Community of

Interest

“Health services”

Community of Interest


Providing the Third ‘A’

• Whenever required, flows can be mirrored to additional switch ports Associated with identity At any relevant level and layer

• Mirroring rules can be associated with different events Network session Security

• Accountability is the word Much better security Detailed metering Technical auditing Lawful interception . . .


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


The Road to a Network IDE

• The natural consequence of applying concepts and tools related to software development

• Supporting a complete design flow High-level definition and

manipulation Validation from simulation to actual

debugging Beta versions by slicing Phased deployment Integrated with parallel IT

development

• Proof of concept OpenFlow-in-a-Box More to come


ALTO: The What

• Application-Layer Traffic Optimization• A mechanism for providing information on the network

To modify the patterns of network resource consumption And maintain or even improve performance

• Based on abstract networks maps And properties associated with those maps Associated with costs

• Maps are based on PIDs Provider-defined Network Location identifier General, network-agnostic, identifying a set of related endpoints

• An IETF WG defining these mechanisms and the current ALTO protocol RESTful interface JSON syntax

• P2P and CDN as initial use cases• Extensible by design• Sounds like a natural companion to support SDN abstractions


ALTO: The How

• An ALTO server collects data on topology And, to some extent, state No real-time service

• Aggregates data and builds the maps According to provider policy Privacy Confidentiality Network intelligence No single view required

• The servers publishes the available endpoints

• Clients attach to the endpoints and collect the maps

ALTO


ALTO: The Looks

• Simple JSON syntax for requests and responses

• Maps contain PIDs and the endpoints they group

• Cost maps contain relationships between PIDs

• Clients make explicit requests for particular maps Or properties of specific combinations of PIDs

• JSON makes data easily extensible and suitable for integrating them with additional sources Much more flexible than current signalling

protocols

"data”:{ "map-vtag”:"1266506139", "map”:{ ”mypid1”:{ "ipv4”:["10.0.0.0/8”,"15.0.0.0/8”]}, "transitpid1”:{ "ipv4”:["132.0.0.0/16”]},. . . "defaultpid”:{ "ipv4”:["0.0.0.0/0”], "ipv6”:["::/0”]} }}

"data" : { "cost-mode" : "ordinal", "cost-type" : "routingcost", "map-vtag" : "1266506139", "map" : { "mypid1”:{ "mypid1”:0, "mypid2”:0, "mypid3”:0, "peeringpid1”:1, "peerinpid2”:1, "transitpid1”:4, "transitpid2”:4, "defaultpid”:5}, }. . . }}


The (Not So) Obvious: One-to-One

• Co-locate ALTO servers and SDN controllers

• The SDN controller is an excellent source for the ALTO server The only one, if full SDN is achieved A relevant aggregator otherwise An open update protocol would be of

great help

• The SDN controller takes advantage of the ALTO server ALTO becomes the standard

mechanisms for retrieving certain networks properties

And combine then with application state and requirements

Especially in mixed environments

• Achieving Cross-Stratum Orchestration

• ALTO as part of the Northbound API

NetworkOrchestrator

(SDN)

ApplicationOrchestrator

1

2

3

4

1

2

3

D

A

BC

4

Topology Abstraction

Engine (ALTO)

NetworkElement

NetworkElement

NetworkElement

NetworkElement


CSO-based Express Lanes

• Traffic engineered between data centers and end user regions• Requires additional data in ALTO maps

Network capacity, latency… And temporal aspects

Data Center 1

Data Center 2

Data Center 3

…

ClientB3

ClientA1

ClientCN

ClientC3

ClientB2

ClientC2

ClientC1

ClientA2

ClientB1

ClientA3

ClientAN

…

ClientBN

…

“Region B”

“Reg

ion

A”

“Region C”


Cross-Domain Scenarios

• Cross-connection of clients (controllers) to servers• ALTO server adapts abstract views to each client• Cross-domain maps become and additional input for controller policies• ALTO as part of the Eastbound API

NetworkOrchestrator

(SDN)


1

2

4

1

2

D

A

B

C


Engine(ALTO)

NetworkElement

NetworkElement

NetworkElement

NetworkElement

NetworkOrchestrator

(SDN)


1

2

3

4

1

2

3

D

A

B

C

4


Engine (ALTO)

NetworkElement

NetworkElement

1

2

3

4


Inter-NSP ASQ

• Abstraction to avoid exposing data not necessary for interconnection• Extensions to accomplish SLA matching and verification

In addition to network capacity and temporal constraints


SDN Realm Partitioning

• SDN partitioning is inevitable A large network is likely to be divided into multiple SDN realms Each SDN realm with its own controller• Some reasons Scalability Manageability Privacy

• Privacy policies applied to tenants or special applicable policies Incremental deployment• Partitioning is already a common practice SDN-enabled slices• SDNi: An interface mechanism between SDN controllers

30


ALTO SDNi

• SDN controllers communicate by exporting and importing network information through an ALTO server

• Information exchange is subject to realm-specific policies• The ALTO server acts as network data orchestrator

Control decisions are autonomously taken by controllers

• ALTO as part of an evolved Eastbound (North-East-bound?) API

ALTO Server

Policy Policy Policy

Policed (aggregated) information

SDN controllers


Making Orchestration Work

• The ALTO server becomes a “soft” orchestrator No need for a controller hierarchy, mesh, chain, or… Policy driven

• Flexible arrangements Controllers retain autonomy “Multi-homing” is possible And different policies at each attachment link

• Neutrality With respect to positioning in the realm(s) With respect to SDN flavor

• We need to Decide on extensions to ALTO data models Enhance two-way interactions, session management and timely updates Explore mechanisms for security, discovery, policy declaration, attachment

modes…


The Struggle for the Right Abstractions

• We are witnessing a paradigm shift in networking The possibility of interacting with the network as a

whole And to reason about that

• Taking the first steps IT is an interesting source of inspiration Its models are limited as well And convergence requires additional effort

• The future of network design and operation lies in building the right abstractions Validation and acceptance are not short processes You can only learn to walk by walking

• Experience shows abstraction is extremely powerful in supporting resource sharing Just look your laptops, tablets, smartphones…

Telefónica I+D 10 .12.2012

Documents

Transcript of Telefónica I+D 10 .12.2012