POWERING ENTERPRISE COMMUNICATIONS WITH … · Slide: Nick McKeown, ... (CCIE test question) ......
79
Copyright 2014 1 POWERING ENTERPRISE COMMUNICATIONS WITH SOFTWARE-DEFINED NETWORKS Terry Slattery Chesapeake Netcraftsmen Principal Consultant CCIE #1026
Transcript of POWERING ENTERPRISE COMMUNICATIONS WITH … · Slide: Nick McKeown, ... (CCIE test question) ......
Copyright 20141
POWERING ENTERPRISE COMMUNICATIONS WITH
SOFTWARE-DEFINED NETWORKS
Terry SlatteryChesapeake Netcraftsmen
Principal ConsultantCCIE #1026
Copyright 2014
Agenda• Introductions & Objective• What is SDN?
– Attributes of SDNs• SDN Architecture• SDN Standards• How SDN Works• Detractors• SDN and UC• Network Topologies for SDN• Troubleshooting and Management• Getting Started with SDN
2
Copyright 2014
Objective: Become Conversant in SDN• What is SDN?
– Why should you care
• How SDN works– General overview
• SDN and Unified Communications– How SDN will affect UC
• SDN Operations– Changes to management and troubleshooting
3
Copyright 2014
My Introduction to SDN• Learned about it around 2010-2011
• Positioned to be a way for researchers to experiment with new protocols
• Customer asked me to look into it - saw a lot of progress
• More importantly, I saw several major benefits– Virtualized networking– Agility– Efficiency
This will change networking!4
Copyright 2014
SDN Is Not New• Ipsilon General Switch Management
Protocol 1996
• IETF ForCES (Forwarding and Control Element Separation) 2003
• IETF Path Computation Element 2005
• Clean Slate 4D 2005
• Ethane – Stanford research 2006
Good reading:Jennifer-Rexford-The-road-to-SDN-programming-language
5
Copyright 2014
Why SDN?• Protocol research mechanism
– Develop new protocols– Evaluate on production networks (at least a part of a
production network)
• Networks are hard to manage and evolve– Element management (vs network management)– Need agile networks that adapt at compute & storage
virtualization speeds– Network changes are slow– Few organizations use automation
• No single device knows the network state
6 BradHedlund.com image
Copyright 2014
Why SDN?• Need ways to validate network
connectivity– Validate security– Can A talk to B after a network topology change?– Detect loops– Prove that two groups isolated
• Need conceptual models that hide the complexity of networking– New abstractions– Simplify thinking about networking
• Treat the network as a system, not a collection of devices
7
Copyright 2014
Definition of SDN• SDN is a vague term
– Network hardware uses extensive software– So what's different?
• Separation of control and data plane– Logically centralized control– Has a view of the entire network– Better forwarding decisions
“SDN is the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.”
Open Networking Foundation
• Low-cost switches perform forwarding– New forwarding path selection algorithms
8
Copyright 2014
Forwarding Table
EgressInterface
IngressInterface
Control Plane
Data Plane
Lexicon: Data Plane• Fast, efficient packet forwarding machinery
– Lookup in the forwarding table• Packet filtering, tagging, queuing, and
forwarding• Control packets sent up to controller
9
Copyright 2014
Lexicon: Control Plane• Loads forwarding entries into the data plane• Participates in routing and switching protocols• Provides configuration and troubleshooting
interface
10
Forwarding Table
EgressInterface
IngressInterface
Control Plane
Data Plane
Copyright 2014
Who Runs a Wireless Network?
11
Copyright 2014
Who Uses Lightweight APs and Wireless
Controllers?
12 Cisco image
Copyright 2014
You’ve Been Using a SDN• Easier to manage
– Centralized control and management– LWAPP communication protocol– Policies and configuration on the controller– Improved RF management
• Easier to deploy new access points– Touchless install
• Lower cost APs– Higher cost controller
13 Cisco image
Copyright 2014
Panel Discussion Points• Why is SDN such a hot topic?
• What can SDN (or SDN-like) provide?
• Are there alternatives to, or other variants of SDN?
Reading: http://resources.idgenterprise.com/original/AST-0110940_SDN_Challenge_doc_FINAL.pdf
14
Copyright 2014
What We’re Seeking with SDN• Agility
• Simplicity
• Provability
• Innovation
• New Abstractions
Decoupling from the hardware provides these
15
Copyright 2014
Agility• Based on either central or distributed control
• Match compute and storage configuration times
• Some proponents stop here– SDN is more than agility and programmability
16
SiSiSiSi SiSiSiSi SiSiSiSi SiSiSiSi
Copyright 2014
Agility• Based on either central or distributed control
• Match compute and storage configuration times
• Some proponents stop here– SDN is more than agility and programmability
17
SiSiSiSi SiSiSiSi SiSiSiSi SiSiSiSi
Copyright 2014
Simplicity – Is This It?
18 Image from David Meyer, Brocade CTO
Copyright 2014
Networking by “Bag of Protocols”• L2
– PPP, STP, TRILL, ACLs, VXLAN, NVGRE
• L3– ARP, IP, NAT, ACLs, IPv6, GRE
• Routing– OSPF, EIGRP, EBGP, MP-BGP, MPLS
• L4– UDP, TCP, Stateful Firewall, IPSEC
• Have a new problem?– Create a new protocol
• This is not the path to simpler networking!
19
Copyright 2014
Provability• Connectivity validation
– Prove that A can or can not talk to B – Prove group isolation (e.g., PCI compliance)– Identify the communication paths
• What-if analysis– Does redundancy really exist?– Do communication paths traverse desired control
points (firewalls, load balancers, etc)?– What happens after a failure?
20PSTN
GatewayCallController
X
X
Copyright 2014
Innovation• Hardware innovation cycles are long
– 1-1.5 years ASIC development– 1-3 years hardware design & deployment– Expensive hardware replacement and upgrade
• Software innovation can be fast– 3-6 months– Software upgrade– Hardware fast enough
to make softwareviable
21 Coherent Logix image
Copyright 2014
Lexicon: Abstractions• "In computer science, abstraction is the
process by which data and programs are defined with a representation similar in form to its meaning, while hiding away the implementation details." – Wikipedia
• Allow thinking at a higher level while hiding complex details
• Provide ways to think about networks in ways that can be used to validate them
Note: Someone has to understand the internals
22
Copyright 2014
New Abstractions• Forwarding domains
– Equivalent to MPLS L3VPN– Hides implementation details (VLAN, ACLs, MP-BGP,
MPLS VRF)
• Profile definitions– Collection of characteristics about an entity– Interface profiles: identify forwarding domain– Application profiles: flow processing definitions
• Device models– Simplifies and standardizes configurations– Detractor: limits functionality to common functions
23
Copyright 2014
Memory Management Analogy
24
• Memory management used to be manual– Limited physical memory
(PDP11: 64KB – 256KB)– Programmer manually designed overlays– Root module code controlled overlays
Copyright 2014
Memory Management Analogy• Virtual memory eliminated manual
process– Memory manager code
controls overlays– Program contents automatically
read from disk or saved to disk– Increased programmer
productivity– Enabled new innovation
in software– Required memory management
hardware and some CPU cycles
• Abstraction:Large memory space
25
Copyright 2014
Disk System Virtualization• Partitioning and layouts
– Similar to memory management– Now done by storage virtualization– Abstraction: LUNs
• Flexible partitioning– Grow/shrink partitions– GUI interface
• Decoupled from the hardware– Logical partitions can span drives– Improve utilization– Facilitates new functionality
• De-duplication• RealTime backups
26
Copyright 2014
Compute virtualization• Decoupled from the hardware
– Hypervisor provides common virtual compute instances
• Abstraction: Virtual Machines (VMs)– Less administration, more consistency– Increase utilization (greater ROI)
27
Copyright 2014
Common Themes• Hide complexity
– Internals are complex, perhaps even more so– Those internals are hidden during normal use– Provides new ways to think of the systems– Enables innovation
• Avoid manual processes– More flexible and dynamic– No longer functions at human speeds– Machines take care of the details
(that humans don’t handle well)
• Seems to imply unacceptable overhead– Automated processes often provide gains– Productivity gain is worth the cost
28
Copyright 2014
We Need to Virtualize Networks
29 Midokura image
• Provide a simple, logical topology for the apps
Copyright 2014
Panel Discussion Points
• What else does SDN bring to the table?
• Why do New Abstractions rarely surface as a key factor?
• Do we really need to virtualize networking?
• Will performance suffer by decoupling from hardware?
30
Copyright 2014
An SDN Architecture
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
Static Checker
Global Network View
Network Virtualization
PacketForwarding
PacketForwarding
PacketForwarding
PacketForwarding
PacketForwarding
PacketForwarding
PacketForwarding
PacketForwarding
Abstract Network View
ControlPrograms
ControlPrograms
ControlPrograms
PacketForwarding
PacketForwarding
Network OS1. <Match,
Action>2. <Match,
Action>3. <Match,
Action>4. <Match,
Action>5. <Match,
Action> 6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …7. …
“A can talk to B”
“Guests can’t reach
PatientRecords”
Policy
Slide: Nick McKeown, Stanford Univ
Copyright 2014
Why Separate Control and Data Plane?• Forwarding based on more than destination
address– More optimal path selection: Valiant Load Balancing*– Improves network utilization:
• Google reports nearly 100% WAN utilization• Time critical traffic gets priority• Remaining bandwidth filled with bulk data
• Better routing due to higher level network view• Avoid special protocols/configuration for policy
routing– Simplifies configuration– Easier troubleshooting
* Valiant Load Balancing is discussed later
32
Copyright 2014
Why Separate Control and Data Plane?• Run Control software on modern, multi-core
processors– Faster processing– Update the control algorithms more frequently
• Simpler data plane implementation– Lower cost switches
• Platform for protocol development
33
Copyright 2014
Data Plane Abstractions• We already have them
• Separation of layers– Changes in one layer don’t
affect other layers– Details of lower layers are hidden
from upper layers
• Reasonable conceptual model
• Caveat: L2 VLAN and L3 subnetmust be congruent
34
ApplicationApplication
PresentationPresentation
SessionSession
TransportTransport
NetworkNetwork
Data LinkData Link
Physical
Copyright 2014
Control Plane Abstractions• Abstractions or mechanisms?
• Bag of protocols– Protocol de jour– Mixing protocols?
• Complexity is exposed– No layering or hierarchy– Many, many details to
manage
• For every problem, we’vecreated a new bandage(protocol)
35
Copyright 2014
Networking Technology is NOT Improving!• New protocol for each problem or function
– For each problem, we slap on a new bandage– Bandages on top of other bandages
• Interactions between protocols– ARP and switch CAM timers (CCIE test question)– Ex: QoS hooks into several protocols
36
L2 Header MPLS Label EXP S+TTL IP Packet
MPLS EXP: 3bits for QoS
DST MAC TPID PCP DEI+VLID Payload
802.1Q PCP: 3bits for CoS
SRC MAC Length FCS
Ver DSCP Remaining Header Payload
IP: 6bits for ToS/DSCP
HLEN
Copyright 2014
Increasing complexity
37 David Meyer image
Copyright 2014
Why Enterprises Are Excited About SDN• Agility
– Match compute & storageconfiguration speeds
– Adapt to migrating VMs– Deploy new apps quickly– Match workloads with
compute & storage
• Simplification– Configuration, operation, troubleshooting– Configuration consistency from one control system
• Utilization– Google increased utilization from 30-40% to 100%– Search for “Google OpenFlow Vahdat”
38
Copyright 2014
Why Enterprises are Excited About SDN• Innovation
– Software speeds feature development– Hardware is typically 5 year dev & deployment
• Lower costs– Less expensive switches– Offset by controller cost?– Lower operational costs
39
Copyright 2014
SDN Example: Big Internet App• App needs more processors to handle the load
– App asks VM controller for more compute– New VMs assigned from available pool
• SDN controller configures the network for VMs– SDN controller acks to VM controller
• What if VMs are in a bad location?– SDN controller tells VM controller to change VMs– Process repeats
40
Web Tier
DB Tier
Copyright 2014
Panel Discussion Points• Why do we trend towards more complexity?
• Can SDN help break the cycle of a new protocol for each problem?
• Is SDN continuing the cycle of a new protocol for each new problem?
• Will SDN really make things simpler?
• Are there other SDN architectures?
• Why are your customers interested in SDN?
41
Copyright 2014
Objective: Become Conversant in SDN
• What is SDN?– Why should you care
• How SDN works– General overview
• SDN and Unified Communications– How SDN will affect UC
• SDN Operations– Changes to management and troubleshooting
42
Copyright 2014
SDN Standards• Openflow
– Southbound interface, Controller to Switch– 1.2 or 1.3 generally accepted; 1.4 published– Standardize only what’s required
43
Open Networking Foundation Working Groups and CommitteesExtensibility OF wire protocol, extensible match & error
messages, forwarding modelConfiguration & Management Protocol & schema for configuration of a switchTesting & Interoperability Interoperabilty tests, plug-fests, conformance
test suites, performance benchmarksHybrid programmable forwarding plane
Insertion of OF into legacy network: hybrid switches, hybrid networks
OpenFlow Future Future of OF and interfaces to other protocolsNorthbound API & SDN abstractions
Object & service models, virtualization, characterization, interaction (WGrp Oct 2013)
Market Education Defining use cases, SDN lexicon, SDN tutorials
Copyright 2014
How OpenFlow-Based SDN Works
44
Specifiesbehavior…
Of a virtualnetwork…
Controlled byOpenFlow…
Via theOpenFlowprotocol.
Copyright 2014
OpenFlow-Based SDN
• OpenFlow protocol– Controller to switch communications– Usually encrypted with TLS– Add, delete, update flow entries
• Controller loads flow tables– Flow tables define forwarding
rules– Multiple tables chained– Group table facilitates multicast,
multipath, fast failover
45
Copyright 2014
Flow Entry• Packet match in flow tables:
– Action to take(forward, drop, modify, etc)
– Counters increment
46
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Match Action Stats
1. Forward packet to port(s)2. Encapsulate and forward to controller3. Drop packet4. Send to normal processing pipeline
+ mask
Packet + byte counters
Copyright 2014
Switch Lookup Mechanism: Web
Ingress Port
Eth Src
Eth Dst
Eth Type
VLAN ID
IP Dst IP Src TCP Dst
TCP Src
IP Proto
Action
Port 0/1 * * * * 10.1.1.10/32 * 80 * * Port 0/3
* * * * * 10.5.5.0/24 10.1.0.0/16 80 * * Port 1/1, Q1
* * * * * 10.5.5.0/24 10.2.2.0/24 * * * Port 2/2, Q2
Port 3/2 * * * * 10.1.1.0/24 * 25 * * Port 0/2
* * * * * * * * * * To Controller
47
Port 0/1 * * * * 10.1.1.10 10.2.2.20 80 1111 * Packetheader
Flow Table Lookup
Action BucketSend packetto Port 0/3,
default queue,incrementcounters
Port 0/3Output
Copyright 2014
Switch Lookup Mechanism: Phone
48
Ingress Port
Eth Src
Eth Dst
Eth Type
VLAN ID
IP Dst IP Src TCP Dst
TCP Src
IP Proto
Action
Port 0/1 * * * * 10.1.1.10/32 * 80 * * Port 0/3
* * * * * 10.5.5.0/24 10.1.0.0/16 80 * * Port 1/1, Q1
* * * * * 10.5.5.0/24 10.2.2.0/24 * * * Port 2/2, Q2
Port 3/2 * * * * 10.1.1.0/24 * 25 * * Port 0/2
* * * * * * * * * * To Controller
48
Port 5/1 * * * * 10.5.5.5 10.2.2.10 2443 1111 * Packetheader
Flow Table Lookup
Send packetto Port 2/2,Queue 2,incrementcounters
Action Bucket
Port 2/2Queue2Output
Copyright 2014
Switch Lookup Mechanism: Unknown
49
Ingress Port
Eth Src
Eth Dst
Eth Type
VLAN ID
IP Dst IP Src TCP Dst
TCP Src
IP Proto
Action
Port 0/1 * * * * 10.1.1.10/32 * 80 * * Port 0/3
* * * * * 10.5.5.0/24 10.1.0.0/16 80 * * Port 1/1, Q1
* * * * * 10.5.5.0/24 10.2.2.0/24 * * * Port 2/2, Q2
Port 3/2 * * * * 10.1.1.0/24 * 25 * * Port 0/2
* * * * * * * * * * To Controller
49
Port 5/3 * * * * 10.6.6.6 10.2.2.20 80 1111 * Packetheader
Flow Table Lookup
Send packetto Controller,
incrementcounters
Action Bucket
Punt toControllerOutput
Copyright 2014
OpenFlow Table Actions
• Forward packet– Group table: multicast, broadcast
• Drop packet– ACL functionality, Not stateful firewall
• Push/Pop new header– Encapsulation (tunnel, IPSec, etc)– VLAN or MPLS tag
• Modify header fields– Decrement TTL, QoS DSCP/CoS, NAT
• Forward to controller– Unknown destination (ARP lookup required)
• Counters kept on all flow entries– Useful for management, troubleshooting, tuning
50
Copyright 2014
Table Processing Mechanism
• Find highest-priority matching flow entry• Apply instructions
– Modify packet & update match fields – Update Action Set (add or delete actions)– Update metadata
• Send match data and action set to next table• At interface output, execute Action Set
51
Copyright 2014
Example Table Processing• Ingress ACL table:
– Match src addr fails: Dropelse:
– Push VLAN tag, Decrement TTL, send to next table• QoS table:
– Match addrs, protocol, port: set_queue• Dst addr table:
– Match dst addr: set group or output interfaceelse:
– Forward to controller (punt)• If group actions:
– Apply group actions and output on interface(s)else:
– Apply actions; output packet on specified interface
52
Copyright 2014
OpenFlow 1.1 Features• Interface groups
– Link aggregation– Multicast/broadcast
• MPLS & VLAN tags• Virtual/Logical ports
– Tunnels, loopback, etc
• Multiple flow tables– Reduces overall
table size
• Controller connection failure– Run disconnected– Revert to normal switch forwarding behavior
53
Matchaddress
(select outputinterface)
Matchingress ACL(permit/deny)
Matchegress ACL
(permit/deny)
Copyright 2014
OpenFlow 1.2 Features• Extensible match support
– Variable length matching – increases flexibility
• Basic IPv6 support
• Controller role-change mechanism– Allows for master/secondary controller
54
2001:0DB8:10BA::4559:1FE2
Master SecondaryX
Copyright 2014
OpenFlow 1.3 Features• Expanded IPv6 support
• Per-flow meters– Facilitates rate limiting functions (QoS, security)– Basic management functionality
• Provider backbone bridging tagging– Allows multi-tenant OpenFlow networks
• Tunnel ID metadata– Used to specify the encapsulation to be used
55
PacketForwarding
PacketForwarding
PacketForwarding
PacketForwarding
PacketForwarding
PacketForwarding
Tunnel0
Tunnel1
Copyright 2014
OpenFlow 1.4 Features• Synchronized tables
– Replicates table changes– Useful where two tables contain the same data (e.g.,
MAC addresses for learning and forwarding)
• Optical interface support– Configure and monitor laser operational parameters
• Bundled table updates– Enables quasi-atomic changes to make changes
simultaneously– Add a flow handling entry:
ACL, QoS, IP Addr, TCP/UDP port number, …
56
Copyright 2014
SDN Controllers (a partial list)• Beacon
– Stanford Univ research project, Java-based• Floodlight
– Java-based controller Open Source from Big Switch– Derived from Beacon
• NOX and POX– The first OpenFlow research controller, C++/Python
• Open Daylight– Cisco & others
• ProgrammableFlow– NEC controller (commercial, closed source)
• Big Network Controller– BigSwitch Networks (commercial, closed souce)
57
Copyright 2014
Panel Discussion Points• How important are standards?
– Northbound API– Management API– Security API
• What’s been your experience at SDN interoperability plugfests?
• SDN is currently relatively simple; Will that change?
• Will SDN remain Open?– Will vendor extensions hurt SDN?
58
Copyright 2014
Hybrid SDN• Switches include traditional forwarding tables
– Progression to a future SDN architecture– SDN doesn’t know how to forward, then use Normal
method
• Centralized control with local backup– Distributed control system needed anyway for
resilience
• Forwarding state maintained locally and by SDN– Challenge: Synchronize
state with otherswitches
– Avoid forwarding loops
59
Copyright 2014
Programming SDNs• App developers write SDN apps?
– App developers don’t know how networks work– High risk of bugs
• Suggestion: App vendors should develop modules– Verified by vendors– Validated by customers– Example: Big web app (Amazon AWS) with
middleware and backend DB– Example: Dynamic UC bandwidth and QoS
• Developers will assemble validated modules– Fewer bugs!– Faster development time (lower cost)
60
Copyright 2014
But It Won’t Work!• SDN doesn’t scale up
– We’ll need a separate control network
• Forwarding table size limits in switches– New silicon developed by researchers– Programmable ASICs from Juniper, Cisco, others
• Round trip delay from switch to controller– Microseconds to milliseconds
• New technology has similar detractors– Recall routing vs switching wars?
“Switch when you can, route when you must!”
• Prediction: – We will learn how to optimize SDN
61
Copyright 2014
Interfacing With the Rest of the Network
• Yes, SDN will need to run network protocols• Routing protocols
– The full suite: RIPv2, OSPF, EIGRP,IS-IS, BGP
– SDN domain = OSPFarea or IS-IS area?
– Emulate a big router at its edge?
62
SiSiSiSi SiSiSiSi SiSiSiSi SiSiSiSi
OSPFBGP
I-Net WAN Sites
SDN
Copyright 2014
Interfacing With the Rest of the Network
• Spanning tree protocol– Not needed internally; controller should create loop-
free topology– Required to interface with STP L2 domains
• Interface protocols– Bidirectional Forwarding Detection (BFD)– LLDP & related link protocols
63
Copyright 2014
Panel Discussion Points• What is your model for SDN programming?
– API only– Functional libraries
• Do SDN detractors have any valid points?– Especially scaling arguments
• There’s a lot of hype around SDN– What is real and what isn’t?
• How will SDNs interface with the rest of the network?– Exchange routes– Avoid loops– Efficiently use all paths
64
Copyright 2014
Objective: Become Conversant in SDN• What is SDN?
– Why should you care
• How SDN works– General overview
• SDN and Unified Communications– How SDN will affect UC
• SDN Operations– Changes to management and troubleshooting
65
Copyright 2014
What Does SDN Mean to UC?• Agility
– Eliminate static configurations– Replace manual processes
• Better service– Support UC QoS marking to untrusted endpoints (the
desktop)– Traffic prioritization based on LDAP login (e.g.,
CEO login)
• Increased efficiency– Higher network utilization (better ROI)– Policy routing without complex mechanisms
66
Copyright 2014
UC Example: SDN Outside the Data Center
67
I-Net
Remote Site
• UC location with 10 concurrent calls expected– More concurrent calls start occurring– Need more call bandwidth on the link
• UC controller asks SDN controller for increase– If BW available, apply QoS, allocate BW, permit call– SDN controller denies if network is at capacity
• UC controller may switch tolower BW codecs to handlenew calls
– UC policy drives what happens
Copyright 2014
• Setting QoS on untrusted endpoints– Classification has typically been problematic
• UC controller tells SDN controller about the call– 10.1.1.50 <-> 10.2.2.100, UDP, QoS marking EF– Other traffic marked QoS BE
• SDN controller configures QoS according to policies– Search: “How-an-SDN-API-could-improve-Microsoft-
Lync-performance”
UC Example: UC on Workstations
68
Untrusted TrafficMark for Best Effort
RealTime (Voice) TrafficMark for EF
10.1.1.50
10.2.2.100
10.2.2.67
Copyright 2014
Policies Drive Operations• Business policies dictate SDN actions
– Define the network reaction when something changes
– Change may be good or bad• New call setup• Failed link or device
• Will need tools & templates to help build good policies
69
Copyright 2014
• Multi-tier network– Central failure– NMS must detect and report
• Network bandwidth reducedto 50%– Multiple failure points– Redundant but perhaps
not resilient– Reduced bandwidth
with one failure
Network Resilience
70
CallController
Failure!
X
Compute & Storage
Copyright 2014
Network Resilience• Leaf/Spine network (folded CLOS)
– Recent data center design– SDN controller detects failure and reroutes flows– Can be non-blocking– Spine switches are not interconnected
• Network bandwidth reduced by 1/N– N = number of spine switches– Graceful degradation– Scales easily
– Search:“folded clos network”
71
SiSiSiSi SiSiSiSi SiSiSiSi SiSiSiSi
Failure!
X
Copyright 2014
Panel Discussion Points
• Are there other examples of SDN for UC?
• Is SDN primarily a data center technology?
• What do you predict for SDN and UC?
72
Copyright 2014
Objective: Become Conversant in SDN• What is SDN?
– Why should you care
• How SDN works– General overview
• SDN and Unified Communications– How SDN will affect UC
• SDN Operations– Changes to management and troubleshooting
73
Copyright 2014
Operational Impact• Networking and applications team
communications must improve– Learn each other’s language– Develop team approach to troubleshooting
• Networking must embrace automation– Staff is trained to use the CLI– Fear of breaking the network faster than manual
methods can fix it– Helpful to learn basic scripting (Python)
• New management & troubleshooting processes– SDN management systems– Troubleshooting application problems– Working with SDN-based routing protocols
74
Copyright 2014
Monitoring and Management• Network performance
– Still need to detect Layer 1 problems– Track and report utilization
• Switch health– Forwarding table utilization– Device functions (fans, power)
• Mapping– Virtual network to underlying
physical network– Finding a VM’s location– Locating App servers
– Search:“sdn management risksand challenges”
75
PSTNGatewayCall
Controller
Errors!Drops!
Copyright 2014
Troubleshooting• Application deployment maps
– Where are the VMs for an app?– High latency: some VMs are in a remote data center
• Mapping overlay to underlay– Identify physical infrastructure when a problem is
detected
• Typical problems– Duplex mismatch– Controller to switch communications failure– VM controller to SDN controller comm failure– Underlay failure that isolates part of the network
– Duplex mismatch on SDN controller; could happen!– SDN controller running in a VM
76
Copyright 2014
Getting Started with SDN• Start small
– Two racks of blade servers– VM and SDN controllers– No need to go fast; SDN will evolve over time
• Learn how to…– Connect SDN domain to the rest of the network– Monitoring and management– Troubleshooting– Transition to SDNs
77
Copyright 2014
Panel Discussion Points
• What are the challenges for monitoring SDNs?
• Will troubleshooting change significantly?
• Recommendations for starting with SDN
• What is your prediction for SDN?
78
Copyright 2014
Summary• SDN will happen
– Network virtualization is needed– The exact form isn’t clear
• Start learning– You are here today… That’s good– Follow your vendor’s progress– Determine how SDN could be deployed in your
network
Thank you for attending!
79
