Software-defined networks (SDN)
PA160: Net-Centric Computing II.
Tomáš Rebok
Institute of Computer Science Masaryk University
rebok@ics.muni.cz
Motivation
Traditional Computing vs Modern
Computing
Ludek Matyska • SDN •
5/18/2016
3
Traditional Computing vs Modern
Computing
Ludek Matyska • SDN •
5/18/2016
3
Traditional Computing vs Modern
Computing
Ludek Matyska • SDN •
5/18/2016
3
Traditional vs Modern Computing
Provisioning Methods
Source: Adopted from Transforming the Network With Open SDN by Big Switch NetworkLudek Matyska • SDN •
5/18/2016
4
Modern Networking Complexity
Ref: JavvinLudek Matyska • SDN •
5/18/2016
5
The Ossified Network
Specialized Packet
Forwarding Hardware
Operating
System
Feature Feature
8
Ludek Matyska • SDN •
5/18/2016
6
The Ossified Network
Specialized Packet
Forwarding Hardware
Operating
System
Feature Feature
Routing, management, mobility management,
access control, VPNs, …
9
Ludek Matyska • SDN •
5/18/2016
6
Million of lines
of source code
6000+ RFCs Barrier to entry
Billions of gates Bloated Power Hungry
The Ossified Network
Specialized Packet
Forwarding Hardware
Operating
System
Feature Feature
Routing, management, mobility management,
access control, VPNs, …
10
Ludek Matyska • SDN •
5/18/2016
6
Million of lines
of source code
6000+ RFCs Barrier to entry
Billions of gates Bloated Power Hungry
Many complex functions baked into the infrastructure
OSPF, BGP, multicast, differentiated services,
Traffic Engineering, NAT, firewalls, MPLS, redundant layers, …
An industry with a “mainframe-mentality”, reluctant to change
The Ossified Network
Specialized Packet
Forwarding Hardware
Operating
System
Feature Feature
Routing, management, mobility management,
access control, VPNs, …
11
Ludek Matyska • SDN •
5/18/2016
6
Traditional vs Modern Networking
Provisioning Methods
Source: Adopted from Transforming the Network With Open SDN by Big Switch NetworkLudek Matyska • SDN •
5/18/2016
7
Traditional vs Modern Networking
Provisioning Methods
Source: Adopted from Transforming the Network With Open SDN by Big Switch NetworkLudek Matyska • SDN •
5/18/2016
7
Computing vs Networking
Source: Adopted from Transforming the Network With Open SDN by Big Switch NetworkLudek Matyska • SDN •
5/18/2016
8
Computing vs Networking
Source: Adopted from Transforming the Network With Open SDN by Big Switch NetworkLudek Matyska • SDN •
5/18/2016
8
Ludek Matyska • SDN •
5/18/2016
9
Ludek Matyska • SDN •
5/18/2016
10
Ludek Matyska • SDN •
5/18/2016
11
Ludek Matyska • SDN •
5/18/2016
12
Ludek Matyska • SDN •
5/18/2016
13
Software-Defined Networking (SDN)
The answer to necessary networking evolution
– making them able to better (i.e. more flexibly,
faster, …) react to current requirements
The basic idea: Management of network services
through abstraction of lower-level functionality
– decoupling the system that makes decisions about
where traffic is sent (the control plane) from the
underlying systems that forward traffic to the
selected destination (the data plane)
– centralized management
14
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
Operating
System
Operating
System
Operating
System
Operating
System
Operating
System
App App App
22
Current Internet
Closed to Innovations in the Infrastructure
Closed
Ludek Matyska • SDN •
5/18/2016
15
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
Operating
System
Operating
System
Operating
System
Operating
System
Operating
System
App App App
“Software Defined Networking” approach
to open it
Ludek Matyska • SDN •
5/18/2016
16
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Network Operating System
“Software Defined Networking” approach
to open it
Ludek Matyska • SDN •
5/18/2016
16
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Network Operating System
App App App
“Software Defined Networking” approach
to open it
Ludek Matyska • SDN •
5/18/2016
16
App
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
App App
Simple Packet
Forwarding
Hardware Simple Packet
Forwarding
Hardware
Network Operating System
The “Software-defined Network”
Ludek Matyska • SDN •
5/18/2016
17
App
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
App App
Simple Packet
Forwarding
Hardware Simple Packet
Forwarding
Hardware
Network Operating System
1. Open interface to hardware
The “Software-defined Network”
Ludek Matyska • SDN •
5/18/2016
17
App
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
App App
Simple Packet
Forwarding
Hardware Simple Packet
Forwarding
Hardware
Network Operating System
1. Open interface to hardware
2. At least one good operating system
Extensible, possibly open-source
The “Software-defined Network”
Ludek Matyska • SDN •
5/18/2016
17
App
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
App App
Simple Packet
Forwarding
Hardware Simple Packet
Forwarding
Hardware
Network Operating System
1. Open interface to hardware
3. Well-defined open API
2. At least one good operating system
Extensible, possibly open-source
The “Software-defined Network”
Ludek Matyska • SDN •
5/18/2016
17
Software-defined network (SDN)
SDN – Basic Concepts
Software-Defined Networking = a modern buzzword 
– like Software-Defined Anything…
Several SDN concepts have been proposed
– all of them follow the basic ideas
centralized control, programmability, flexibility, …
– could be based on:
uniform configuration of (more or less) traditional devices
− RESTconf, NETconf, specialized protocols, …
novel networking paradigm (requiring novel devices)
− OpenFlow
19
Ludek Matyska • SDN •
5/18/2016
20
Ludek Matyska • SDN •
5/18/2016
21
Ludek Matyska • SDN •
5/18/2016
22
Ludek Matyska • SDN •
5/18/2016
23
Ludek Matyska • SDN •
5/18/2016
24
Ludek Matyska • SDN •
5/18/2016
25
Ludek Matyska • SDN •
5/18/2016
26
SDN – benefits summary
Reducing overhead costs (easier management)
– centralized management
Easier and faster deployment of new services
– from weeks/months to days/hours/minutes
Higher flexibility
– allowing to support applications with specific needs
Higher usage efficiency
– lowering over-provisioning
Support of new features and applications
– including e.g. virtualization/slicing of the network
etc. etc.
27
OpenFlow protocol
SDN/OpenFlow - introduction
A novel networking paradigm
– first standard communication interface between the
control and forwarding layers
vendor-independent
− forwarding HW has to comply with the OpenFlow specification
– allows direct access to and manipulation of the
forwarding plane of network devices
− besides basic OpenFlow SW client, the devices contain packet
forwarding tables (flow tables)
define packet matching rules and packet actions
29
Ludek Matyska • SDN •
5/18/2016
30
Ludek Matyska • SDN •
5/18/2016
31
Ludek Matyska • SDN •
5/18/2016
32
Controller
OpenFlow Switch
Flow
Table
Secure
Channel
PC
hw
sw
OpenFlow Switch specification
Components of OpenFlow Network
33
* Figure From OpenFlow Switch Specification
Ludek Matyska • SDN •
5/18/2016
How does OpenFlow work?
46
Ludek Matyska • SDN •
5/18/2016
34
Controller
PC
Hardware
Layer
Software
Layer
Flow Table
MAC
src
MAC
dst
IP
Src
IP
Dst
TCP
sport
TCP
dport
Action
OpenFlow Client
port 4port 3port 2port 1
1.2.3.45.6.7.8
OpenFlow Example
35
Ludek Matyska • SDN •
5/18/2016
Controller
PC
Hardware
Layer
Software
Layer
Flow Table
MAC
src
MAC
dst
IP
Src
IP
Dst
TCP
sport
TCP
dport
Action
OpenFlow Client
**5.6.7.8*** port 1
port 4port 3port 2port 1
1.2.3.45.6.7.8
OpenFlow Example
35
Ludek Matyska • SDN •
5/18/2016
Controller
PC
OpenFlow usage
OpenFlow Switch
OpenFlow Switch OpenFlow Switch
OpenFlow offloads control intelligence to a remote softwareLudek Matyska • SDN •
5/18/2016
36
Controller
PC
OpenFlow usage
OpenFlow Switch
OpenFlow Switch OpenFlow Switch
Alice’s code
OpenFlow offloads control intelligence to a remote softwareLudek Matyska • SDN •
5/18/2016
36
Controller
PC
OpenFlow usage
OpenFlow Switch
OpenFlow Switch OpenFlow Switch
Alice’s code
OpenFlow offloads control intelligence to a remote softwareLudek Matyska • SDN •
5/18/2016
36
Controller
PC
OpenFlow usage
OpenFlow Switch
OpenFlow Switch OpenFlow Switch
Alice’s code
OpenFlow offloads control intelligence to a remote softwareLudek Matyska • SDN •
5/18/2016
36
Controller
PC
OpenFlow usage
OpenFlow Switch
OpenFlow Switch OpenFlow Switch
Alice’s code
Decision?
OpenFlow
Protocol
OpenFlow offloads control intelligence to a remote softwareLudek Matyska • SDN •
5/18/2016
36
Controller
PC
OpenFlow usage
OpenFlow Switch
OpenFlow Switch OpenFlow Switch
Alice’s code
OpenFlow
Protocol
Alice’s Rule
Alice’s Rule Alice’s Rule
OpenFlow offloads control intelligence to a remote softwareLudek Matyska • SDN •
5/18/2016
36
Controller
PC
OpenFlow usage
OpenFlow Switch
OpenFlow Switch OpenFlow Switch
Alice’s codeAlice’s Rule
Alice’s Rule Alice’s Rule
OpenFlow offloads control intelligence to a remote softwareLudek Matyska • SDN •
5/18/2016
36
OpenFlow Basics
Flow Table Entries
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
L4
sport
L4
dport
Rule Action Stats
1. Forward packet to zero or more ports
2. Encapsulate and forward to controller
3. Send to normal processing pipeline
4. Modify Fields
5. Any extensions you add!
+ mask what fields to match
Packet + byte counters
37
VLAN
pcp
IP
ToS
Ludek Matyska • SDN •
5/18/2016
Examples
Switching
*
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
* 00:1f:.. * * * * * * * port6
Flow Switching
port3
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port6
Firewall
*
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
* * * * * * * * 22 drop
38
Ludek Matyska • SDN •
5/18/2016
Ludek Matyska • SDN •
5/18/2016
39
Scalability & Robustness
59
Ludek Matyska • SDN •
5/18/2016
40
Centralized vs Distributed Control
Both models are possible with OpenFlow
Centralized Control
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
Controller
Distributed Control
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
Controller
Controller
Controller
41
Ludek Matyska • SDN •
5/18/2016
Flow Routing vs. Aggregation
Both models are possible with OpenFlow
Flow-Based
• Every flow is individually
set up by controller
• Exact-match flow entries
• Flow table contains one
entry per flow
• Good for fine grain
control, e.g. campus
networks
Aggregated
• One flow entry covers large
groups of flows
• Wildcard flow entries
• Flow table contains one
entry per category of flows
• Good for large number of
flows, e.g. backbone
42
Ludek Matyska • SDN •
5/18/2016
Reactive vs. Proactive (pre-populated)
Both models are possible with OpenFlow
Reactive
• First packet of flow
triggers controller to insert
flow entries
• Efficient use of flow table
• Every flow incurs small
additional flow setup time
• If control connection lost,
switch has limited utility
Proactive
• Controller pre-populates
flow table in switch
• Zero additional flow setup
time
• Loss of control connection
does not disrupt traffic
• Essentially requires
aggregated (wildcard) rules
43
Ludek Matyska • SDN •
5/18/2016
Basic SDN/OpenFlow principles
Basic SDN/OpenFlow principles
Basic networking concepts remain unchanged
– including all the packet headers & communication
protocols
however, some configuration protocols and functions (like VRF)
are not needed any more
– the only change is performed in packet handling and its
configuration
Major benefits in network management
– centralized control & easier management
– network segmentation on multiple levels
physical and virtual network separation
– dynamic response
45
Real-life deployment
Traditional approach
Let’s illustrate a few basic real-life concepts on MUNI
network
(simplified description)
– interconnects several sites (faculties) using MPLS core
employes further complex technologies (like VRF, BGP, …)
– on each site, several separate networks exist
separated using VLANs (isolation of different-purpose network –
Windows/Linux hosts, printers, specific segments etc.)
– very complex ecosystem with limited
flexibility
and very hard to maintain
− many technologies
used
46
Real-life deployment
SDN/OpenFlow approach
The SDN/OF network consists of several “dumb” network
devices (forwarding elements)
– the logical network view dynamically configured by the
controller
Several layers of network separation
– Virtual Tenant Networks (VTNs)
for networks separation based on e.g. the purpose
– Virtual network representations
simplified configuration of L2/L3 networks
– Physical separation
allows multiple network instances, controlled by different
controllers
− each of them further separated into VTNs, L2/L3 network, etc.
47
Real-life deployment
SDN/OpenFlow approach
Virtual networks in SDNs – Virtual Tenant Networks
48
Real-life deployment
SDN/OpenFlow approach
Virtual networks in SDNs – Virtual Tenant Networks
48
Separate VTNs for (MUNI examples):
• production network
• technology network
• sensitive-data network
• infected nodes or nodes under attack
• experimental network
• commercial network
• … all of them fully isolated (may run same IPs)
Real-life deployment
SDN/OpenFlow approach
Virtual networks in SDNs – Virtual Tenant Networks
48
Separate VTNs for (MUNI examples):
• production network
• technology network
• sensitive-data network
• infected nodes or nodes under attack
• experimental network
• commercial network
• … all of them fully isolated (may run same IPs)
Link redundancy
is welcomed!
Real-life deployment
SDN/OpenFlow approach
Virtual networks in SDN – Virtual Tenant Networks
49
Real-life deployment
SDN/OpenFlow approach
Virtual networks in SDN – Virtual Tenant Networks
49
Real-life deployment
SDN/OpenFlow approach
Virtual network representation / topology (in each VTN may
differ)
50
Real-life deployment
SDN/OpenFlow approach
Virtual network representation / topology (in each VTN may
differ)
50
just end ports (statically/dynamically) configured
internal configuration of all OFSs computed by the
controller
Real-life deployment
SDN/OpenFlow approach
Physical network separation
– allows to divide
OpenFlow HW switches into
separate (SDN) worlds
− controller by own
SDN controllers
− e.g. production,
experimental controller
and control network
51
In case of hybrid switches,
part of the HW may serve as
control network (traditional
approach)
SDN/OpenFlow Demo
FTP client and FTP server
Two physical paths through the network exist
one path is congested (allows for a lower speed)
− emulated using increased packet drop & delay
the other one is free (thus faster)
Two users: ondra & sven
user “sven” is privileged
− his transmission speed is monitored and – if too low – the FTP server
contacts SDN controller, which forces his flows to use the free/faster link
(monitoring in 2sec. interval)
− all the other users remain on the congested link
52
SDN/OpenFlow Demo – VTN representation
53
VTN representation:
SDN/OpenFlow Demo
54
SDN/OpenFlow Demo
54
Further examples of real-life use-cases
55
Further examples of real-life use-cases
56
Further examples of real-life use-cases
57
Further examples of real-life use-cases
Further use-case examples related to university usage
– prioritize traffic / enforce lower priority (backups)
– security applications
centralized monitoring probes (monitoring just specific traffic)
− e.g. HTTP traffic through DPI, FTP through common probes
isolation of infected nodes and monitoring the attacker
distribution of filtering rules
− in cooperation with stateful firewall
– connection redundancy, high-capacity links
deployment, …
– etc. etc.
58
Network Function Virtualization
(NFV)
 Diverse network functions (NF).
 Providing desired overall functionality or
service.
 Adding new services
• New service instances take weeks to activate
• New service types may take months up to years
• New service types require either new equipment or
upgrading of existing equipment
 We have to simplify network design,
increase agility, speed up deployment of
new services.
Ludek Matyska • SDN • 5/18/2016
60
NFV – Network Functions Virtualization
Likewise VM
Virtualization – NF and part of the
infrastructure is implemented as a
software.
Result – from dedicated proprietary
appliance to COTS hardware
Ludek Matyska • SDN • 5/18/2016
61
Ludek Matyska • SDN • 5/18/2016
62
SDN controllers
SDN controllers
Common objectives:
– multiple Southbound interface protocol support
– well-defined Northbound API support
– programmability
– high availability &
performance
– security
Open-source vs. commercial
Ludek Matyska • SDN • 5/18/2016 64
Ludek Matyska • SDN •
5/18/2016
65
Ludek Matyska • SDN •
5/18/2016
66
OpenDaylight architecture illustration
Service Abstraction Layer/Core
Base Network Functions
- Lithium
OpenFlow Enabled
Devices
DLUX VTN
Coordinator
OpenStack
Neutron
SDNI
Wrapper
Network Applications
Orchestrations & Services
Open vSwitches
Additional Virtual &
Physical Devices
Data Plane Elements
(Virtual Switches, Physical
Device Interfaces)
Controller Platform
Services/Applications
OpenFlow Stats Manager
OVSDB NETCONF PCMM/C
OPS
SNBI
LIS
P
BGP PCEP SNM
PSXP Southbound Interfaces &
Protocol Plugins
OpenFlow
OpenFlow Switch Manager
USCCAPWAP OPFLEX CoAPHTTP
OpenFlow Forwarding Rules
Mgr
L2 Switch
Host Tracker
Topology Processing
AAA AuthN Filter
OpenDaylight APIs REST/RESTCONF/NETCONF
Data Store (Config & Operational) Messaging (Notifications / RPCs)
LACP
Network Services
Service Function Chaining
Reservation
Virtual Private Network
Virtual Tenant Network Mgr.
Unified Secure Channel Mgr
OVSDB Neutron
Device Discovery,
Identification & Driver
Management
LISP Service
DOCSIS Abstraction
SNMP4SDN
Network Abstractions
(Policy/Intent)
ALTO Protocol Manager
Network Intent Composition
Group Based Policy Service
Platform Services
Authentication, Authorization
& Accounting
Neutron Northbound
Persistence
SDN Integration Aggregator
Time Series Data RepositoryLink Aggregation Ctl Protocol
Module 3: OpenDaylight 3-0367
NETCONF & YANG
different SDN view…
MAY 27, 2013 93©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
NETCONF and YANG in Context
NETCONF
Manager
NETCONF
Yang
Models
YANG ModelsYANG Models
YANG Models
YANG Models
Management
Applications
MAY 27, 2013 94©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
What is a Data-Model? What is a Network Management Protocol?
• Data-Model
• A data-model explicitly and precisely
determines the structure, syntax and
semantics of the data…
• …that is externally visible
• Consistent and complete
• Protocol
• Remote primitives to view and manipulate the
data
• Encoding of the data as defined by the data-
model
Data-Model
Protocol
Standards background, motivation and history
RFC 3535: Operators’ problems and requirements on network
management
(results of IETF’s meeting with network operators)
MAY 27, 2013 96©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
Informational RFC 3535
• SNMP had failed
• For configuration, that is
• Extensive use in fault handling
and monitoring
• CLI scripting
• “Market share” 70%+
Abstract
This document provides an overview of a
workshop held by the Internet Architecture
Board (IAB) on Network Management. The
workshop was hosted by CNRI in Reston,
VA, USA on June 4 thru June 6, 2002. The
goal of the workshop was to continue the
important dialog started between
network operators and protocol
developers, and to guide the IETFs focus
on future work regarding network
management.
configuration
MAY 27, 2013 97©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
Operator Requirement #1/14
1. Ease of use is a key requirement for
any network management technology
from the operators point of view.
Maybe not assume integrators and
software developers for any addition
or change
Manage
MAY 27, 2013 98©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
Operator Requirement #2-3/14
• Clearly separating configuration
• Ability to compare across devices
2. It is necessary to make a clear
distinction between configuration
data, data that describes operational
state and statistics.
3. It is required to be able to fetch
separately configuration data,
operational state data, and statistics from
devices, and to be able to compare these
between devices.
$show running-config
MAY 27, 2013 99©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
Operator Requirement #4-5/14
• Service and Network management, not
only device management
• Network wide transactions
4. It is necessary to enable operators to
concentrate on the configuration of the
network as a whole rather than
individual devices.
5. Support for configuration
transactions across a number of devices
would significantly simplify network
configuration management.
VPN Configuration
All or nothing
MAY 27, 2013 100©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
Operator Requirement #6-7/14
• Devices figure out ordering
• No unnecessary changes
• Finally: backup/restore of
configuration
6. Given configuration A and configuration
B, it should be possible to generate the
operations necessary to get from A to B
with minimal state changes and effects on
network and systems. It is important to
minimize the impact caused by
configuration changes.
7. A mechanism to dump and restore
configurations is a primitive operation
needed by operators. Standards for pulling
and pushing configurations from/to
devices are desirable.
The litmus-test of a management interface
configuration
MAY 27, 2013 101©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
8. It must be easy to do consistency
checks of configurations over time and
between the ends of a link in order to
determine the changes between two
configurations and whether those
configurations are consistent.
10. It is highly desirable that text
processing tools such as diff, and version
management tools such as RCS or CVS,
can be used to process configurations,
which implies that devices should not
arbitrarily reorder data such as
access control lists.
Operator Requirement #8, 10/14
• Validation of configuration
• Validation at network level
• Text based configuration
VPN Configuration
Valid?
Text
MAY 27, 2013 102©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
Operator Requirement #9/14
• Standardized data models
9. Network wide configurations are
typically stored in central master
databases and transformed into formats
that can be pushed to devices, either by
generating sequences of CLI commands
or complete configuration files that are
pushed to devices. There is no common
database schema …, although the
models used by various operators are
probably very similar.
It is desirable to extract, document, and
standardize the common parts of these
network wide configuration
database schemas.
Interfaces Data-Model
MAY 27, 2013 103©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
Operator Requirement #13/14
• Support for multiple configuration sets
• Delayed, orchestrated activation
13. It is important to distinguish between
the distribution of configurations and the
activation of a certain configuration.
Devices should be able to hold multiple
configurations.
Config, Config, Commit
MAY 27, 2013 105©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
NETCONF was designed to
conform to RFC 3535.
Today many operators require
NETCONF and YANG in devices.
NETCONF makes a difference on
the bottom line.
MAY 27, 2013 106©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
What makes NETCONF/YANG different?
SNMP NETCONF SOAP REST
Standard IETF IETF W3C Resources
OIDs Paths URLs
Data models Defined in
MIBs
YANG Core
Models
Data
Modeling
Language
SMI YANG (WSDL, not
data)
Undefined,
(WSDL),
WADL, text…
Management
Operations
SNMP NETCONF In the XML
Schema, not
standardized
HTTP
operations
Encoding BER XML XML XML,
JSON,…
Transport
Stack
UDP SSH
TCP
SSL
HTTP
TCP
SSL
HTTP
TCP
“RESTConf”
MAY 27, 2013 107©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
What makes NETCONF/YANG different?
SNMP
• GET
• GET-NEXT
• SET
• TRAP
• …
… so what?
NETCONF
• <get-config>
• <edit-config>
• <copy-config>
• <delete-config>
• <get>
• <lock>
• …
… same same?
Data-Model
MIB Modules
YANG Modules
Protocol
The SNMP Protocol
NETCONF
MAY 27, 2013 108©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
What makes NETCONF/YANG different?
Use Case SNMP NETCONF
Get collection of status fields Yes Yes. Bulk xfer up to
10x faster. Really.
Set collection of configuration fields Yes, up to 64kB Yes
Set configuration fields in transaction No Yes
Transactions across multiple network elements No Yes
Invoke administrative actions Well… Yes
Send event notifications Yes Yes, connected
Backup and restore configuration Usually not Yes
Secure protocol v3 is fair Yes
Test configuration before final commit No Yes
This is where the difference is:
In the supported use cases!
MAY 27, 2013 109©2013 TAIL-F all rights reserved
TUTORIAL: NETCONF AND YANG
YANG ?
• Data modeling language
• Configuration data
• State data
• Tree structure
• Data and Types
acme-box module
properties container
interfaces container
name: string, config
name: string, config
interface: list, index = name
oper-state: enum, config
YANG Header
Thank you for your attention!