Jan Lindblad's presentation at Layer123 SDN and OpenFlow World Congress in Bad Homburg, Germany. Focusing on a multi-vendor SDN deployment at a Tier 1 Service Provider in Asia. Tail-f Network Control System (NCS) use case: • Dynamic control of L3-L7 devices using service- oriented network API • Service chaining using OpenFlow • Virtualized appliances

1. Dynamic Service Chaining
SDN OpenFlow World Congress, Oct 2013
Jan Lindblad, Tail-f
October 10, 2013
1

2. About Tail-f
• 90+ customers since foundation in 2005
• Roughly equal numbers in US, Europe and Asia
• HQ in Stockholm, US Office in Santa Clara
• Software products company targeting
• Service Providers
• Enterprise Data Centers
• Network Equipment Vendors
• Strong activity in standardization
October 10, 2013
2

3. About the Presenter
Jan Lindblad is the Principal Solutions Architect at
Tail-f Systems where he advises on the design of
devices and network management solutions. He is a
device and network management system expert
with extensive knowledge in information and data
modeling in Yang, XML Schema, UML and interfaces
include carrier class Command Line Interface (CLI),
NETCONF, WebUI and SNMP.
Jan is an active member of TeleManagement Forum (TMF), Internet
Engineering Task Force (IETF), Service Availability Forum (SAF). For
more than 25 years, he has worked as developer, applications engineer
and product manager for IBM, Ericsson, Enea.
Jan received his Masters in Computer Science from the Royal Institute
of Technology (KTH) in Stockholm, 1995. He has taught hundreds of
training classes in various programming languages, operating systems,
high availability, and network management and acted as long term
Swedish government industry advisor for the Vinnova program on
Advanced Software Technology (ASTEC).
October 10, 2013
3

4. Use Case: VPN with Service Chaining
Customer
Customer
A
B
Service
Provider
FW
APP
FILTER
IDS
Internet
WAN
ACCEL
Customer
C
POP
1
Customer
C
POP
2
To
sell
a
bit-­‐pipe
is
nice.
To
sell
a
bit-­‐pipe
plus
value
added
services
is
nicer.
If
you
can
scale.
October 10, 2013
4

5. Use Case: VPN with Service Chaining
Traffic
Shaper
A
Content
Filtering
WAN
acceleration
Firewall
A
B
IPS/IDS
B
How would you implement this?
• with short time to market
• in existing networks
• consisting of multiple-vendors
• across multiple technology
domains
• providing end-to-end visibility
from customer to network
resources
• and back from resources to
customer and SLA
October 10, 2013
• allowing gradual introduction of
future technologies like
OpenFlow
• permitting service changes with
minimal network impact
• automatically cleaning up unused
resources at service retirement
• in a highly-available
configuration
• at low cost
5

6. Use Case: VPN with Service Chaining
Traffic
Shaper
A
Content
Filtering
WAN
acceleration
Firewall
A
B
IPS/IDS
B
ImplementaMon
steps
and
opMons:
Implement
service
chain
and
configure
flow
route:
-­‐ Policy
based
rouMng
-­‐ OpenFlow
applicaMon
Select
L4-­‐L7
devices
and
set
Set
flow
ow
each:
up
up
fl on
on
each
-­‐ Many
brands
available
L4-­‐L7
device
-­‐ Physical
or
virtual
That’s
enough
to
add
flows.
Maybe
also
think
about
the
life-­‐cycle?
Once
setup,
what
if
a
parMcular
service
chain
needs
to
be
reconfigured?
Or
decommissioned?
October 10, 2013
What
if
the
VPN
service
definiMon
is
upgraded
with
more
opMons?
What
if
one
of
the
service
chain
devices
is
replaced
with
a
different
brand
device?
So
how
can
SDN
and
OpenFlow
help
us?
6

7. SDN Architecture
SpecificaMon
Layer
Logically
centralized,
transacMonal,
global
specificaMon
model
SDN
Inventors
and
Gurus
Casado,
Shenker,
McKeown,
Koponen,
et
al.
describe
the
SDN
architecture
like
this:
Network
OperaMng
System
Layer
Logically
centralized,
transacMonal,
global
device
model
Forwarding
Layer
Distributed
mulM-­‐
protocol
flow
forwarding
October 10, 2013
www.slideshare.net/marMn_casado/sdn-­‐abstracMons
7

8. SDN Specification Layer
VPN
Service
AcMvaMon
Portal:
Add
Flow
Flow
Profile
Name:
HQDC
Inbound
From
Networks:
Internet
To
Networks:
116.54.16.128/26
Reserved
bandwidth:
2.5
Gb/s
QoS
profile:
RealMme
SLA
Level:
Gold
✓
WAN
Accelera@on
Content
filtering
Office
✓
SAP
Citrix
Backup
Skype
Video
File
Transfer
✓
Firewall
Configure…
Cancel
AcMvate
October 10, 2013
8

9. Service Application: Model-to-model mapper
VPN
Service
Model
Flow
Profile
Name:
unique
string
Key
SDN
ProperMes
• Logically
centralized
APIs
• Model-­‐to-­‐model
mapping
• Transac@ons
VPN
Service
AcMvaMon
Portal:
Add
Flow
From
Networks:
[
IP-­‐address/mask
]
To
Networks:
[
IP-­‐address/mask
]
Reserved
bandwidth:
integer
>
0
Service
ApplicaMon
Traffic
Steering
Device
Model
db
Nice
if
APIs,
UIs,
DB
schemas
are
rendered
from
service
model
Firewall
Device
Model
Port:
unique
integer
0..47
Src:
IP-­‐address/mask
Dst:
IP-­‐address/mask
AcMon:
drop
|
output(N)
|
…
October 10, 2013
Src:
IP-­‐address/mask
Dst:
IP-­‐address/mask
Port:
integer
1..65535
AcMon:
drop
|
allow
9

10. Service Application executing
Network-wide Transaction
Service
ApplicaMon
Network-­‐wide
Transac@on
Rule
#46:
Port=1,
Src=*,
Dst=116.54.16.128/26,
AcMon=output(6)
Rule
#117:
Src=*,
Dst=116.54.16.128/26,
Port=80,
AcMon=allow
Rule
#47:
Port=7,
Src=*,
Dst=116.54.16.128/26,
AcMon=output(8)
Rule
#118:
Src=*,
Dst=116.54.16.128/26,
Port=*,
AcMon=drop
Network
OperaMng
System
Internet
October 10, 2013
1
2
3
4
5
6
7
8
9
10
Customer
A
In
Customer
B
Out
10

11. Network Operating System executing
Network-wide Transaction
Network-­‐wide
Transac@on
Rule
#117:
Src=*,
Dst=116.54.16.128/26,
Port=80,
Rule
#46:
Port=1,
Src=*,
Dst=116.54.16.128/26,
AcMon=allow
Rule
#117:
Src=*,
Dst=116.54.16.128/26,
Port=80,
AcMon=output(6)
Rule
#46:
Port=1,
Src=*,
Dst=116.54.16.128/26,
Rule
#118:
Src=*,
Dst=116.54.16.128/26,
Port=*,
AcMon=allow
Rule
#47:
Port=7,
Src=*,
Dst=116.54.16.128/26,
AcMon=output(6)
AcMon=drop
Rule
#118:
Src=*,
Dst=116.54.16.128/26,
Port=*,
AcMon=output(8)
Rule
#47:
Port=7,
Src=*,
Dst=116.54.16.128/26,
AcMon=drop
AcMon=output(8)
October 10, 2013
Cisco
CLI
NETCONF
Cisco
CLI
Network
OperaMng
System
OpenFlow
Key
SDN
properMes
• Transac@ons
extend
to
devices
• Model-­‐to-­‐
mul@ple
protocols
• Device
type,
vendor
and
protocol
irrelevant
to
operators
and
network
apps
11

12. SDN and OpenFlow
October 10, 2013
OSPF
Learning
Switch
Controller
Controller
Controller
Behavior
Behavior
Behavior
OpenFlow
OpenFlow
• Pure
OpenFlow
networks
are
and
will
remain
rare
• New
OpenFlow
behaviors
very
convenient
for
solving
specific
network
problems
Service
Chaining
OpenFlow
Key
SDN
properMes
• Controller
implements
a
specific
behavior
• In
NOS,
each
behavior
appears
as
a
device
type
Network
OperaMng
System
12

13. Tail-f NCS solution:
SDN and OpenFlow controller
October 10, 2013
13

14. Asia Tier 1 SP: Managed Services for Enterprise customers
NCS use case:
Business drivers:
•
•
•
Value-added services to
enterprise customers
More agile and dynamic
service provisioning
NCS
•
•
SW
SW
SW
SW
SW
SW
HW
Dynamic control of L3-L7
devices using serviceoriented network API
Service chaining using
OpenFlow
Virtualized appliances
HW
HW
SW
Branches
Core/Edge (Data Center)
October 10, 2013
14

15. SDN Use Case: Service Chaining
Management
Applications
NETCONF, REST, Java
Network
Engineer
Network-wide CLI, WebUI
Tail-f Network Control System
Service
Models
Service Manager
Flowlet
Models
Flowlets
Device
Models
Device Manager
OpenFlow Controller Cluster
Network Element Drivers
Flowlets
Flowlets
Traffic
Shaper
A
October 10, 2013
Content
Filtering
WAN
acceleration
Firewall
A
B
IPS/IDS
B
15

16. SDN Technology Summary
SDN is about Network Evolvability, splitting the Network Problem into
manageable pieces
The Specification Layer, a.k.a. Service Layer provides a business-level
interface for operators and applications. The interface
• is logically centralized to hide the complexities of distributed systems
• feeds a model-to-model mapping taking high-level concepts to specific device objects
• is transactional to protect operators and applications from having to deal with the
complexities of error recovery and activation orchestration
The Network Operating System Layer provides a device-level interface for
operators and applications. The interface
•
is transactional to protect from error recovery and activation orchestration complexity
•
feeds a model-to-multiple protocols mapping where device type, vendor and
management protocol is irrelevant to operators and applications
The Forwarding Layer can be controlled through OpenFlow or traditional
protocols like Cisco CLI
• In reality there is a mix of traditional and OpenFlow devices
• Speaking multiple device protocols is key in real networks
• All device behaviors are described with device data models
October 10, 2013
16

17. Customer Quote: DT TeraStream SDN Goal
The reason for us doing SDN is that we can
program services instead of re-architecting
the network and the OSS for every new
service.
We are not necessarily interested in
programming the network, but
programming the network services is key
for us - this concept drastically reduces our
time to market from years to weeks.
- Axel Clauberg
VP & CTO, Deutsche Telekom (the TeraStream project)
October 10, 2013
17

18. October 10, 2013
18

19. Further information
Service Provider Links (Deutsche Telekom, AT&T)
• www.pipelinepub.com/webinars
• www.layer123.com/download&doc=ATT-SDNVirtualization_Webinar_final
SDN Links
• www.nec-labs.com/~lume/sdn-reading-list.html
• www.youtube.com/watch?v=YHeyuD89n1Y
• www.slideshare.net/martin_casado/sdn-abstractions
NETCONF & YANG Links
• www.tail-f.com/education/what-is-netconf
• www.tail-f.com/education/what-is-yang
Tail-f Links
• www.tail-f.com/education
October 10, 2013
19