The document discusses software defined networking (SDN) from the perspective of network engineers. It describes how SDN aims to provide more choice and control over networks similar to how virtualization has transformed computing. SDN separates the control plane, which directs traffic, from the forwarding plane, which sends packets. This allows network administrators to program how traffic flows using a centralized controller and OpenFlow protocol. The document also covers related topics like network functions virtualization, overlay networks, and white-box networking using Linux.

1. NETWORKING VIEW
FOR THE DEVOPS CREW
A
SOFTWARE
DEFINED
NETWORKING
Jeremy Schulman
2014 FEBRUARY
@nwkautomaniac
nwkautomaniac@gmail.com

2. ABOUT JEREMY
20 Years in Networking
my.com
(7)
SW Eng
Sales Eng
(12)
Junos "EZ"
Ruby, Python
Puppet, Chef,
Ansible, Salt
IT
Automation
(8)
(2)
Strategic
Alliances
(3)
Bizdev
Open Source
nwkautomaniac@gmail.com
(5)
Juniper Networks
jschulman@juniper.net

3. DISCLAIMER
This is a community presentation. Views
expressed in this post are the original thoughts
posted by Jeremy Schulman, Director of
Automation Concept Engineering at Juniper
Networks.
These views are his own, and in no way
represent the views of the company he works for.

4. SDN TOPICS
 Why all the fuss?
 A bit of history
 Just enough networking (no TLAs!)
 Where's Waldo (=Software)
 Mind the (Reality) Gap

5. ECONOMICS AND INNOVATION
CHOICE
and
CONTROL

6. HISTORY
Two separate, unrelated, but timely events
Google
~~~
OpenFlow

7. MARKET SEGMENTATION
Networking vendor perspective
MSDC
SERVICE
PROVIDER
"LARGE"
ENTERPRISE
ENTERPRISE

8. QUICK REVIEW
SERVERS
Copyright © 2013 Juniper Networks, Inc.

9. SERVER HARDWARE
ARCHITECTURE BLOCKS
Choice and Control is largely determined by the end-customer
EXTERNAL
S/W
CPU
MEMORY
INTERNAL
NETWORK
PHYSICAL
STORAGE
INTERFACES
ENCLOSURE
STORAGE

10. SERVER SOFTWARE
ARCHITECTURE BLOCKS
Software running in the CPU determines the purpose of the server/VM
Choice and Control are determined by the end-customer (Linux example)
S/W
CPU
App
App
App
Middleware
Middleware
Middleware
Operating
System

11. JUST ENOUGH
NETWORKING
Copyright © 2013 Juniper Networks, Inc.

12. NETWORK HARDWARE
ARCHITECTURE BLOCKS
Choice and Control is largely determined by the manufacturer (vendor)
Leads to "appliance" based approaches for specific networking functions
S/W
CPU
MEMORY
S/W
INTERNAL
ASIC
STORAGE
FPGA, NPU
NETWORK
S/W
INTERFACES
PHYSICAL
ENCLOSURE

13. NETWORK SOFTWARE
ARCHITECTURE BLOCKS
Networking "software" is designated into "planes" of execution that is
distributed across the CPU, ASICs, FPGAs, NPUs, etc.
Leads to highly integrated (tested) vertical stacks of software
Choice and Control determined by manufacturer
S/W
Management
Services
Plane
Plane
Control
Plane
Forwarding
Plane

14. NETWORK SOFTWARE
FORWARDING PLANE




Packet processing "engines"
Typically done in hardware
Specific functions - switching, routing, load-balancing
Generally at wire-speed
S/W
Forwarding
packet in
packet(s) out
Plane
db
db
db
packet lookup "databases" for specific
functions, such as L2, L3, L4-L7

15. NETWORK SOFTWARE
MANAGEMENT PLANE
S/W runs on CPU / Operating System
Central point for all operations such as configuration and troubleshooting
Interfaces with external systems via CLI, SNMP, programming APIs
APIs
CLI
Management
Plane
SNMP
SYSLOG
S/W
Significant interest in the context of "SDN" around network automation using
vendor APIs (REST, XML, JSON, etc.)
Interest in adapting existing DevOps tools for networking: Puppet, Chef, etc.
DevOps use-cases are still different from Networking

16. DevOps FOR NetOps?
DevOps Evolution / Revolution
• Server Virtualization and Cloud
• History over +7 years
• Open-Source Community
physical,
virtual, cloud
orchestration
manually
configured
ad-hoc bash
perl scripting
puppet, chef
salt, ansible,
other IT
frameworks
infra.apps
built on IT
frameworks
DevOps
paradigm pivot-point!

17. NETWORK SOFTWARE
CONTROL PLANE
S/W runs on CPU, often in the FORWARDING PLANE as well
Responsible for Network Protocols: Spanning Tree, OSPF, BGP, MPLS, etc
A means for networking devices to converge on L2 and L3 infrastructure
services (basic switching and routing, e.g.)
Plane
Forwarding
Plane
Control
Plane
Forwarding
Plane
Router-C
Management
Plane
Control
Router-B
Management
Plane
Management
Plane
Router-A
Control
Plane
Forwarding
Plane
"The Network"
Each CONTROL PLANE protocol maintains its own separate "database"
of configuration and operational (ephemeral) state

18. NETWORK SOFTWARE
SERVICE PLANE
S/W runs on CPU and FORWARDING PLANE
A Service is generally a unit of function that provides a capability with a
agreed measure of success / failure. Typically multiple end-points.
• Layer-2 Virtual Private Network ... Metro Ethernet Service
• Layer-3 Virtual Private Network ... Wide Area Networking
• IPSec (secured) Private Networks
• Multi-Tenant Datacenter / Cloud Virtual Networks
• "Underlay" for "Overlay"
Services are delivered when the
CONTROL PLANE protocols provide
the necessary and sufficient
infrastructure; e.g. routing reachability

19. WHAT IS
SDN? ...
Copyright © 2013 Juniper Networks, Inc.

20. SDN IS TO NETWORKING
AS CLOUD IS TO SERVERS ....
Depends who you ask and their point of reference ...
But there are emerging "patterns" around CHOICE and CONTROL ....

21. CENTRALIZED CONTROLLERS AND
OpenFlow
Separation of Control Plane,
Forwarding Plane, and Services Plane
The "Controller" instructs each of the
network device endpoints using the
OpenFlow protocol. The Northbound
"Well-defined Open API" is used by
the SERVICES PLANE, i.e. enable
3rd-parties to create their own network
services
OpenFlow is a CONTROL PLANE
protocol that instructs the
FORWARDING PLANE packet
processing engine

22. OVERLAY AND UNDERLAY
 Overlay is a Virtual Networking construct
and managed separately from the physical
infrastructure ("underlay")
Contrail (Juniper Networks)
 Hypervisor based software to perform
packet "tunneling" [encap/decap]
 Centralized "Controller" to orchestrate
tunnels
 Northbound APIs into other IT systems like
OpenStack, Cloudstack, etc.
NSX (VMware)
Nuage Networks (ALU)

23. WHITE-BOX NETWORKING
AND LINUX AS A NETWORK OS
•
Buy hardware direct from Original Direct Manufacturer (ODM) rather than
traditional networking vendor (Cisco, Juniper, HP, etc.) - promoted as a
significant Capital Expense (CapEx) saving + Choice and Control of hardware
•
Obtain a Linux distribution that works for that hardware, e.g. Cumulus Linux.
Generally a yearly license fee - promoted as a "open" platform to enable endcustomer Choice and Control of software
•
End-customer is responsible for selecting, integrating, validating, and deploying
"software stack" specific to their business needs
•
No "one throat to choke" for support - think Linux pre-Red Hat
•
Configuration Management tends to be a good fit for DevOps tools like Puppet,
Chef, Ansible, Salt
•
Network Operational Management not necessarily a good fit; troubleshooting
complex CONTROL PLANE and SERVICE PLANE interactions not well
understood or proven

24. NETWORK FUNCTIONS
VIRTUALIZATION (NFV)
•
Originated out of the Service Provider market
as a means to deliver Services utilizing
standard virtualization technologies, as
opposed to vendor specific appliances
•
Complimentary to the aspirations of SDN. The
originators identified NFV as independent and
orthogonal to SDN developments.
•
Open Daylight (ODL) is a industry
wide, multi-vendor, open-source project
to create a framework and platform for
NFV solutions

25. RESOURCES
 Software Defined Networking (Wiki)
http://en.wikipedia.org/wiki/Software-defined_networking
 SDN Central
http://www.sdncentral.com/
 Open Networking Foundation
https://www.opennetworking.org
 Open Daylight
http://www.opendaylight.org/
 Network Functions Virtualization (Wiki)
http://en.wikipedia.org/wiki/Network_Functions_Virtualization

26. Q&A
Copyright © 2013 Juniper Networks, Inc.

27. THANK YOU
Copyright © 2013 Juniper Networks, Inc.
www.juniper.net