Transcript SDN APIs - TNC15

Whither SDN?
Abstraction, Data Models, APIs
TERENA 2015, Porto
Kireeti Kompella
CTO, JDI
Agenda
•
•
•
•
Three (plus one) aspects of SDN
How did we get here?
Abstraction: some details
Conclusion
Three (plus one) aspects of SDN
– Programmability (SDN as a Network OS)
– Automation
– Abstraction (SDN as a Compiler)
Programmability
• Your software vendor gives you a nice OS and some nice apps
• But these don’t do all you need
• You want to improve performance or scale
• Or you want to add a new feature
• Or you just want to play
• Usually, the vendor gives you an API
• The rest is up to you 
SDN for Programmability: Network OS
Network
Application
Network State
Transform via
Network Apps
Network
Application
Network
Application
Network Operating System
Control
Control
Data
Plane
Data
Plane
Control
…
Data
Plane
Automation
• You know what you want to do
• You do it manually for a device or two
• Now, you want to do it for 100s or 10s of 1000s of devices
• You need to parametrize what you did at a small scale
• You need mechanisms whereby devices can ask for help, or send
telemetry to your Automation Agent
• You need rules (“policy”) to handle exceptions or to adapt to situations
• The vendor gives you a framework, tools, mechanisms to enable
and/or simplify your task
• Again, the rest is up to you 
Abstraction
• You have a nice language: high-level, abstract, device-independent
• Programming languages are primarily imperative (C, Java, Python)
• But many are declarative (LISP, SNOBOL, Haskell, …)
• You define what you want to have happen
• Imperative: state how you want things done
• Declarative: state what you want done
• The language compiler translates this to a lower-level language that
your devices can understand and carry out
SDN as a Compiler
Say what you want, not how to do it
service
reqts
High-level, declarative
specification of service requirements
Process,
SDN system
place &
compile
Device 1
Device 2
Device 3
Device 4
Device 5
Parse specification
Process telemetry
Device 6
The Following is Not a Value Judgment!
Programmability
Automation
Abstraction
These are different concepts
There is some overlap
None is intrinsically better
Their value depends on the goal
“Operational Aspects of SDN”
• However, note that Automation and Abstraction really aim at easing
operations by reducing human error and improving delivery …
• … of existing features, maybe packaged in new ways
• Whereas programmability offers new or improved features
• This can fill in vital gaps in your service offering
• … but it can be “operationally challenging”
• … if everyone in the network wants their own shiny new control plane or
data plane
(Plus One)
• People sometimes forget that networks were entirely run as software
• Cisco’s earliest routers were completely general-purpose MIPS processors
running control plane, data plane and management as software
• The idea of building “custom ASICs” really started for switching
• Routing (IP forwarding) was deemed too complex for ASICs
• Some of those who do remember find delicious irony in the term
“Software Defined Networking”
How did we get here?
– Routers in toto
– Restoring agility, introducing abstraction
– SDN as a Compiler: the full picture
– Unified SDN
Is a Router Just Control and Data Plane?
Interoperable
(more so than not)
Academic
view of
a router
This is also
where services
live, where
agility is needed
Not
standardized;
not at all
interchangeable!
Config
Control
Config
Control
Data
Plane
Data
Plane
Config
Control
…
Data
Plane
Actuality
of a
router
Restoring Agility:
Separate Config From Rest of Router
The goal: service agility
via orchestration:
freedom from “physics”,
process, bureaucracy
RESTful APIs
Orchestration Layer
Config
Control
Config
Control
Data
Plane
Data
Plane
Config
Control
…
Data
Plane
What is New about this Approach?
• Service definition is based on abstract data models (DMs)
•
•
•
•
These are high-level: device and OS and version independent
They are standardized, with provider-specific enhancements
They are modular: a service is a composition of service elements
Check out OpenConfig.net for the start of such an initiative
• Service deployment is transformation of an abstract service
definition to device-specific DMs
• Device-specific DMs can also be standardized (yet extensible)
• Service placement (and motion) is driven by real-time telemetry
SDN as a Compiler
Say what you want, not how to do it
service
reqts
Service
configuration
lives here
Device configs are kept here
High-level, declarative
specification of service requirements
S
DB
D
DB
Process,
SDN system
place &
compile
Parse specification
Process telemetry
T
Network
DB Telemetry
Configuration is sent
to chosen device
Device 1
Device 2
Device 3
Device 4
Device 5
Device 6
Unified SDN
OSS/Orchestration
Service
model 1
Service
model 2
Service
model 3
Abstract
SDN Transformation Engine
Device
model 1
Device 1
Device 2
Access
Device
model 2
Device 3
Edge/NFV/DC
Device
model 3
Device level
Device 4
Device n
Core/Inter-DC
Abstraction: some details
– Two examples
– Data models; YANG; xml
– Telemetry
Service Data Model
• A Service Data Model is a template of a service element
• E.g.: Closed User Group (aka Virtual Private Network)
•
•
•
•
Endpoints: _ _ _
Layer at which CUG operates: _ _ _ (IP, Ethernet, …)
CUG Topology: _ _ _ (any-to-any, hub-and-spoke, dual-hub-and-spoke)
Connection bandwidth: _ _ _
• Note on abstraction:
•
•
•
•
Want to specify just the above details
Don’t want to say: technology – MPLS, BGP, VRF, VPLS/VLAN/EVPN
Also don’t want to say: which PEs, which interfaces, RTs, …
Definitely don’t want: device OS-specific details
Service Instance: Fill in details for customer
• A Service Instance is an instantiation of a service element
• derived by filling in details in a template
• E.g.: CUG for BofA
•
•
•
•
Endpoints: A, B, C, D, …
Layer at which CUG operates: Ethernet
CUG Topology: any-to-any
Connection bandwidth: all nodes get 1G except HO which gets 10G
• Note: still no mention of
• Technology: MPLS, BGP, VPLS, …
• Specific details: PEs, RTs, …
• Device OS
Device Instance:
Fill in More Details To Implement Service
CUG for BofA
• Endpoints: A, B, C, D, …
• Layer at which CUG operates: Ethernet
• Encap: MPLS; Signaling: BGP; technology: E-VPN
• CUG topology: any-to-any
• Route Target: RT-BofA
• Connection bandwidth: 1G, 10G
• PEs & interfaces: (PE1, ge-0/1/2); (PE2, ge-2/2/2); (PE3, xe-0/1/3); …
• Other device-specific config
Infrastructure Service Data Model
• A Service Data Model is a template of a service element
• E.g.: Point-to-point connection from _ _ _ to _ _ _
•
•
•
•
•
Aggregate bandwidth: _ _ _ (at each QoS level)
Number of paths: _ _ _ Max path bandwidth: _ _ _
Local protection: Yes/No? At each hop?
Path constraints _ _ _
Resilience requirements _ _ _
• Note:
• Want to specify from where to where, bandwidth, constraints, …
• But: don’t want to say: technology – MPLS, RSVP-TE, FRR, …
• Don’t want: specific details: ERO, number of LSPs, …
Service Instance: Fill in Details
• A Service Instance is an instantiation of a service element
• derived by filling in details in a template
• E.g.: Point-to-point connection from PoP A to DC B
•
•
•
•
•
Aggregate bandwidth: 12G (2G EF, rest best effort)
Number of paths: 3 – 8; Max path bandwidth: 5G
Local protection: Yes, at each hop
Path constraints: Don’t use trans-border or trans-oceanic links
Resilience reqts: node- and link-disjoint standby connection
• Note: still no mention of
• Specific entry and exit routers
• Technology: MPLS, RSVP-TE, FRR, …
• Specific details: ERO, number of LSPs, …
Device Instance:
Fill in More Details To Implement Service
• Point-to-point connection from PoP A to DC B
• Encap: MPLS; Signaling: RSVP-TE
• Aggregate bandwidth: 12G (2G EF, rest best effort)
• Number of paths: 3 – 8; actual: 3; Max path bandwidth: 5G
• LSP1: from A-P1 to B-G3, 4G (1G EF), ERO: xyz
• LSP2: from A-P2 to B-G2, 5G (1G EF), ERO: pqr
• LSP3: from A-P2 to B-G7: 3G (0G EF), EFO: mno
• Local protection: Yes, at each hop
• Use RSVP-TE FRR with node protection
• Don’t use trans-border or trans-oceanic links
• Standby connection that is node and link disjoint
used in
path
• Standby LSP4: from A-P1 to B-G2, 6G (1G EF), ERO: uvw computatio
• Standby LSP5: from A-P2 to B-G3, 6G (1G EF), ERO: abc n
Expressing Service and Device Data Models
• Juniper has always described configuration as XML stanzas
• XML has these nice properties:
• Is easy-to-read (for humans, via rendering), yet easy-to-manipulate (for
computers)
• Has well-typed elements with hierarchical organization
• Allows for easy extensibility with backward compatibility
• Allows the use of features like XPath to identify an element, and XSLT for
manipulation of configuration or operational data
• Enables consistency checking of configurations
• Supports treating configuration updates as transactions
• Supports config versioning, roll back, backup and restore
YANG: a Language for Expressing Data Models
• These XML stanzas underpinned the IETF netconf WG
• From that beginning came the YANG language to model configuration
and operational state, RPCs and notifications
• Kept many of the features of xml stanzas, but domain-specific to
configuration and operational data
• Separates configuration and operational state
• Strongly typed, hierarchical, extensible (via “augment”)
• Powerful: express abstract service and low-level device models
• Easily translated to xml, but can express many more things
• Many things that were “understood” in xml are explicit in YANG
• Supports consistency checking, transactions and version control
Telemetry
• Lots of different types of telemetry
•
•
•
•
Events
Statistics
Packet data
… each with its own characteristics and requirements
• Lots of uses of telemetry, most still untapped
• Difficult to come up with a single, all-encompassing data model for all
the various types of telemetry
• The goal is to collect all telemetry all the time from everywhere (!)
Interacting with an SDN system
– APIs to an SDN system
– Generating APIs from data models
– APIs between SDN systems
Interacting with an SDN System: API
With all the talk of programmable
networks, the focus is on
Application Programming Interfaces
Thus, everyone asks about
the API with which to
interact with an SDN system
Indeed, an API is needed to
write a program to interact
with the SDN system
API
S
DB
Process
place &
compile
D
DB
API
SDN
system
R
DB
T
DB
Interacting with an SDN System: Data Models
APIs are language-specific.
The focus is on syntax, since
it must match the language’s
syntactic requirements.
Data models capture syntax,
semantics and structure, all in
a language independent way
Data models have enough
structure that language-specific
APIs can be automatically
generated from them
Data
Model
S
DB
Process
place &
compile
D
DB
In the Contrail system, Python, C++ and REST
APIs are generated from the data models
Data
Model
SDN
system
R
DB
T
DB
Interacting with other SDN Systems (For Further Study)
Data
Models
S
DB
Process
place &
compile
D
DB
Data
Models
Data
Models
SDN
system
R
DB
T
DB
?
Can be
peer-to-peer,
hierarchical,
or other …
S
DB
Process
place &
compile
D
DB
Data
Models
SDN
system
R
DB
T
DB
Conclusion
The SDN-as-a-Compiler Paradigm
• Separate service configuration from devices
• Specify services abstractly, via device- and technology-independent
data models
• Based on up-to-date telemetry, optimize service placement
• Compile services to device-specific data models
• Monitor services continuously, and respond to changes in real-time
Interacting with SDN
• Interact with the SDN system to provision services
• using RESTful or other APIs
• SDN system acquires telemetry via data models
• and uses this, for example, to optimize service placement
• SDN system interacts with devices via low-level data models
• using netconf, RESTconf, or other rpc mechanisms
• We have to figure out how SDN systems talk to each other
• Data models are key throughout
• Standardizing service and device data models is crucial!
Thank You!