Transcript Controller

REN SDN Use Cases
With OpenFlow and P4 status
TNC2016
Curt Beckmann
[email protected]
Chair of Open Datapath Working Group, ONF
Chief Technology Architect for EMEA
Agenda
• SDN Perspective from 50 km
• SDN Deployments for REN
• OpenFlow deployment: Challenges (what you see)
• OpenFlow standards progress (what is being done)
• “Next Generation” SDN activity
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
2
SDN: Perspective from 50km
Customer driven movement
Traditional
• ONF “technical” definition of SDN
‒ “Control physically separated from Data Plane”
Controller
• Real customer desire
Control Plane
(software)
‒ “Control and Data are VENDOR separated”
•
That means “Ecosystem”-ouch!
‒ Oh, and key customers (SPs) also want NFV- yikes!
APIs
• How to “bootstrap” an ecosystem?
‒ Add OpenFlow to legacy boxes (done)
Router
‒ Converge on small # of controllers (done)
Control Plane
(software)
‒ Common NB APIs (In process)
‒ Find buyers content with *one* ecosystem (in process)
‒ Sell “open vertical” solutions (in process)
SDN /
OpenFlow
Data Plane
(hardware)
Router
Control Plane
(software)
Data Plane
(hardware)
Hybrid
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
3
SDN: Perspective from 50km
Customer driven movement
Traditional
• ONF “technical” definition of SDN
‒ “Control physically separated from Data Plane”
Controller
• Real customer desire
Control Plane
(software)
‒ “Control and Data are VENDOR separated”
•
That means “Ecosystem”-ouch!
‒ Oh, and key customers (SPs) also want NFV- yikes!
APIs
• How to “bootstrap” an ecosystem?
‒ Add OpenFlow to legacy boxes (done)
Router
‒ Converge on small # of controllers (done)
Control Plane
(software)
‒ Common NB APIs (In process)
‒ Find buyers content with *one* ecosystem (in process)
‒ Sell “open vertical” solutions (in process)
SDN /
OpenFlow
Data Plane
(hardware)
Router
Control Plane
(software)
Data Plane
(hardware)
Hybrid
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
4
SDN Deployments for REN
SDN Use Cases
CONTROL
•
•
•
•
•
•
Volumetric Attack Mitigation
Elephant Flow Management
Firewall Bypass
Policy Based Flow Forwarding
Botnet Attack Mitigation
Campus Access Management
AUTOMATION
• SDN Based MPLS Traffic
Engineering
• Bandwidth Scheduler
• Packet-Optical Integration
VISIBILITY
•
•
•
•
WAN Network Virtualization
Flow Metering
SDN Based Wiretap
VXLAN Monitoring
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
6
SDN Use Cases… popular in REN context
CONTROL
•
•
•
•
•
•
Volumetric Attack Mitigation
Elephant Flow Management
Firewall Bypass
Policy Based Flow Forwarding
Botnet Attack Mitigation
Campus Access Management
AUTOMATION
• SDN Based MPLS Traffic
Engineering
• Bandwidth Scheduler
• Packet-Optical Integration
VISIBILITY
•
•
•
•
WAN Network Virtualization
Flow Metering
SDN Based Wiretap
VXLAN Monitoring
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
7
SDN for Policy-Based Firewall Insertion / Bypass
Operator or sFlow driven policy enforcement for large trusted flows
Evaluating: Indiana U, CERN
REN DC X
One-armed Firewall
REN DC Y
Inline Firewall
WAN
SDN App
Default Traffic Flow
Trusted Traffic Flow
SDN
Controller
Internet
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
SDN-based Education Campus Access
Shippingfor
In Planning
v1.1
Dynamic policy for flexible network access control and security
Programmable Access Control
via Northbound API
Path Explorer
Flow
Policy
Policy
Developing: ASU
Evaluating: Cornell
Visual
Engine
I’m consultant for
project Y. Can I
access the RED
network?
OF rule
OF 1.3
Matching
Normal Forward
IPsec Tunnel to Secure Resources
Guest
Re-direct
GRE Tunnel to Guest
Network
Campus / DC
Drop
MLXe
• Access based on MAC / IP addresses
• Redirect to IPsec, GRE or MPLS tunnel
(Placeholder imagery: will update)
• Suitable for consultants, mobile workers for
short-term network access
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. INTERNAL USE ONLY
SDWAN
SDN Backbone
Longterm deployment: Internet2
Evaluating: AARNET
(Placeholder imagery: will update)
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
10
OpenFlow Deployment: Challenges (1 of 2)
Not to “insult” OpenFlow, but show ONF is aware of the challenges
• Two categories of implementation
‒ Well-deployed traditional “Fixed Function” (e.g. ASIC) platforms
‒ Flexible / programmable platforms (NPUs, etc), often from start-ups
• OpenFlow Applicability Challenge
‒ OF1.x (x > 0) too flexible for ASICs, not enough for NPUs
‒ Lack of “pipeline config” step assumes all boxes do all things
• API Challenges
‒ Hardware independence tricky  no common stable northbound APIs
‒ Even OpenFlow itself has not insisted on backward compatibility
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION
OpenFlow Deployment: Challenges (2 of 2)
Not “OpenFlow bashing”, but to show ONF is aware of challenges
• Interoperability challenge (close to API challenge)
‒ Apps coded for specific devices
‒ Extensions often required
• Conformance testing challenges
‒ Lack of config step, 2 categories of device with many subcategories
‒ OF1.3 basic test defined, no long term support (LTS) for OF1.4 & OF1.5
• Pipeline config mechanism: “Table Type Patterns” (TTP) v1.0
‒ Upside: Designed to address most OpenFlow challenges
‒ Challenges: limited examples, “machine consumability”, YANG issues
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY PROPRIETARY INFORMATION
OpenFlow standards progress
• OF1.6 coming late 2016, with long term support, more modular
‒ LTS and modularity will help adoption, simplify extensions
‒ Optical / wireless expanding OF down OSI stack, beyond packet processing
• Increased market adoption of TTPs: e.g. China Mobile SPTN use case
‒ More interest in TTP-based interoperability testing
• TTP v1.1 syntax is ready, English language spec in process
‒ “machine” / YANG friendly, better Extension support, 1.0  1.1 converter
‒ More examples, TTP Validation & mapping tools planned or in development
‒ Stage set for abstract, human oriented language (Jsonnet?) on top of TTP
• This abstract language will include Library support for even more re-use
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
13
OpenFlow reassessment
• OpenFlow was created as an L2/L3 control language
‒ It mostly assumed an “implicit” network device feature set / pipeline
‒ “flexible” vs “limited” platform not reconciled architecturally (no config phase)
• Too many options, lack of conformance tests, lack of stable NBAPIs: both platforms held back
• Consensus on need for multiple device “profiles” (TTPs) came slowly
‒ TTPs (pipeline profiles) work for both platforms and support a “config phase”
‒ Allow the industry / market / customers to develop, evolve the profiles
‒ Growing collection of TTPs will provide the needed context for:
• Well-defined, hardware-independent (abstraction-based) NBAPIs for app development
• A basis for interoperability and a collection of conformance tests
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
14
“Next Generation” SDN activity
• NG SDN activity emerged from as OpenFlow issues recognized
‒ One element of wisdom: deeper validation is needed “prelaunch”
• Despite strong interest and demonstrations, a recognition that gaps remain
• Persistent challenge: A truly platform independent “Intermediate Representation” is elusive
• P4 is the dominant next-gen effort
‒ OpenFlow and P4 communities have significant overlap
‒ Focuses on “pipeline definition”, recognizes need for “config phase”
‒ P4 does not define the control protocol
• As a result, P4 is complementary to (not competitive with) OpenFlow
• OpenFlow will need some adjustments, which ODWG is prepared to address
‒ P4 is packet centric, will need augmentation for non-packet devices
• OpenFlow transport extensions will offer that augmentation
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
15
(2nd slide on P4)
• Additional P4 information from meetings coming in next 2 weeks
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
16
Conclusions (P4 items tentative, will revise)
• Low level control protocol is important to SDN
‒ OpenFlow is still the only open control protocol
• OpenFlow has faced challenges, and is evolving to address them
• Patient investment in P4 is underway
‒ More tools and examples and “ecosystem readiness” will be needed
‒ OpenFlow compatibility likely
© 2015 BROCADE COMMUNICATIONS SYSTEMS, INC. COMPANY: USE WITH PERMISISION
17