Applying Abstraction
For a More Efficient and Fair
Network Usage
Telefónica
I+D
10.12.2012
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
TPI – GCTO Unit
Telefónica I+D
2
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
TPI – GCTO Unit
Telefónica I+D
3
Out of the Boxes
•
•
•
•
FEATURE
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
OPERATING SYSTEM
FEATURE
FEATURE
SPECIALIZED PACKET
FORWARDING HARDWARE
OPERATING SYSTEM
SPECIALIZED PACKET
FORWARDING HARDWARE
FEATURE
FEATURE
SPECIALIZED PACKET
FORWARDING HARDWARE
We can apply different levels of
abstraction
 Think of a network design flow
 And even an IDE
4
FEATURE
FEATURE
OPERATING SYSTEM
OPERATING SYSTEM
 Suitable to be programmed
 Aligned with current IT practices
TPI – GCTO Unit
Telefónica I+D
FEATURE
SPECIALIZED PACKET
FORWARDING HARDWARE
SDN Principles
App
 Beyond individual boxes
App
.
•
•
•
Make network behaviour programmable
App
•
App
•
•
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
TPI – GCTO Unit
Telefónica I+D
5
SDN Control Plane Software
Switch
Switch
Switch
Switch
Switch
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
TPI – GCTO Unit
Telefónica I+D
6
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
Telefónica I+D
7
A Stored Program Model for the Network
•
•
The SDN concepts bring into play the processing capabilities
And the stored program
TPI – GCTO Unit
Telefónica I+D
8
The Network Is *A* Computer
•
•
•
•
•
•
•
•
•
OpenFlow
Controller
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
TPI – GCTO Unit
Telefónica I+D
OpenFlow
Switch
OVS
OVS
OVS
9
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
TPI – GCTO Unit
Telefónica I+D
10
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
•
The goal
•
The POSIX reference model
 Need to address a wide variety of
devices and protocols
 To simplify use and management of
heterogeneous E2E networks
 Access, core, datacenter….
TPI – GCTO Unit
Telefónica I+D
11
Net-wide, POSIX Style
Application
Application
Application
System Interface - APIs
OpenFlow
Filesystem
–
Data Plane
L2VPN
TPI – GCTO Unit
Telefónica I+D
IP
*MPLS
(LDP/RSVP
)
...
LISP
Kernel
Control Plane
v6
12
…
Policy
Security
System
Tools
Mgmt
Plane
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
Telefónica I+D
13
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
TPI – GCTO Unit
Telefónica I+D
14
And Supporting Network Function Virtualization
Network environment
Home environment
STB
CPE
UPnP
IPv4/IPv6
Access Point Switch Módem
TR-069
DHCP
•
•
•
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


TPI – GCTO Unit
Telefónica I+D
FW
Dynamic connection of virtualized components
Grow as requirements grow
15
NAT
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
TPI – GCTO Unit
Telefónica I+D
16
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 enroute
 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
TPI – GCTO Unit
Telefónica I+D
17
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
TPI – GCTO Unit
Telefónica I+D
18
Converged Authorization
•
•
•
Controllers are programmable entities
“NSP
customer”
Community of
Interest
 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
NSP
Community
of
Registration
Mix-and-match with current
technologies in IT space
“Health
services”
Community of
Interest
 Outer identities permeate the network
infrastructure
TPI – GCTO Unit
Telefónica I+D
19
“Local
government”
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
...
TPI – GCTO Unit
Telefónica I+D
20
Upper Layers of Abstraction
•
•
•
•
NaaS beyond itself
 Current models are still very much boxoriented
 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




TPI – GCTO Unit
Telefónica I+D
SQL
OO
Garbage collectors
<YourPreferredITConstruct />
21
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
TPI – GCTO Unit
Telefónica I+D
22
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
TPI – GCTO Unit
Telefónica I+D
23
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
TPI – GCTO Unit
Telefónica I+D
24
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
TPI – GCTO Unit
Telefónica I+D
25
"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



•
2
1


4
ALTO becomes the standard
mechanisms for retrieving certain
networks properties
And combine then with application
state and requirements
Especially in mixed environments
Network
Network
Element
Network
Element
Network
Element
Element
2
Topology
Abstraction
Engine
(ALTO)
A
1
C
26
3
B
D
Achieving Cross-Stratum
Orchestration
ALTO as part of the Northbound API
TPI – GCTO Unit
Telefónica I+D
Network
Orchestrator
(SDN)
3
The SDN controller takes advantage
of the ALTO server

•
•
The only one, if full SDN is
achieved
A relevant aggregator otherwise
An open update protocol would be
of great help
Application
Orchestrator
4
CSO-based Express Lanes
Data
Center 2
Client
B1
Client
B2
Client
B3
…
Client
A1
“Region A”
“Region B”
Client
BN
Client
A2
Data
Center 3
Client
A3
…
Client
AN
Client
C2
Client
C3
Data
Center 1
Client
CN
•
•
…
Traffic engineered between data centers and end user regions
Requires additional data in ALTO maps


TPI – GCTO Unit
Telefónica I+D
Network capacity, latency…
And temporal aspects
27
Client
C1
“Region C”
Cross-Domain Scenarios
2
Application
Orchestrator
1
Application
Orchestrator
3
4
2
2
1
Network
Orchestrator
(SDN)
1
3
Network
Orchestrator
(SDN)
Network
Network
Element
Element
4
4
Network
Network
Element
Network
Element
Network
Element
Element
2
Topology
Abstraction
Engine
(ALTO)
Topology
Abstraction
Engine
(ALTO)
2
A
1
C
B
A
D
1
C
3
B
D
•
•
•
•
4
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
TPI – GCTO Unit
Telefónica I+D
28
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
TPI – GCTO Unit
Telefónica I+D
29
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
TPI – GCTO Unit
Telefónica I+D
30
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
Policed (aggregated)
information
Policy
ALTO Server
Policy
Policy
SDN controllers
TPI – GCTO Unit
Telefónica I+D
31
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…
TPI – GCTO Unit
Telefónica I+D
32
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…
TPI – GCTO Unit
Telefónica I+D
33
TPI – GCTO Unit
Telefónica I+D
34