(sdn) abstractions for network management
DESCRIPTION
(SDN) Abstractions for Network Management. Nick Feamster Georgia Tech [email protected]. Students. Arpit Gupta. Muhammad Shahbaz. Hyojoon Kim. Networks are difficult to manage. What Does Software Defined Networking Have to Do With It?. Distributed configuration is a bad idea - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/1.jpg)
(SDN) Abstractions for Network Management
Nick FeamsterGeorgia Tech
Students
Arpit Gupta
HyojoonKim
MuhammadShahbaz
![Page 2: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/2.jpg)
2
Networks are difficult to manage.
![Page 3: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/3.jpg)
What Does Software Defined Networking Have to Do With It?
• Distributed configuration is a bad idea• Instead: Control the network from a logically
centralized system
3Feamster et al. The Case for Separating Routing from Routers. Proc. SIGCOMM FDNA, 2004 Caesar et al. Design and implementation of a Routing Control Platform. Proc NSDI, 2005
Network
RCP
2004 2005
Decision
DisseminationDiscovery
Data
2008
![Page 4: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/4.jpg)
SDN Forwarding Abstraction
4
![Page 5: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/5.jpg)
5
Can SDN help?(Yes…but we must understand why configuration is hard in the first
place.)
![Page 6: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/6.jpg)
Configuration Changes are Frequent
• Changes to the network configuration occur daily– Errors are frequent
• Operators must determine– What will happen in
response to a configuration change
– Whether the configuration is correct
6
![Page 7: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/7.jpg)
Configuration Exposes the (Complex) Physical Topology
7
http://www.ratemynetworkdiagram.com/?i=526
![Page 8: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/8.jpg)
The Need for Abstractions• Configuration changes are frequent
– Policies are dynamic, depend on temporal conditions defined in terms of external events
– Abstraction: State machine
• Configuration exposes the physical topology– Operators do not need to know about the physical topology when
configuring policies. Instead, they need a logical view of the network– Abstraction: Virtual network
• Configuration languages are too low-level– Need to configure networks at a higher level– Abstraction: Functional programming primitives
8
![Page 9: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/9.jpg)
Abstractions for Network Management
• State machines for event processing– State-based network policies– Composition operators– Example applications: Home, campus
• Virtual networks for policy specification– Network operators can express policies in terms of a
virtual topology, without needing to know about details of underlying topology
– Example applications: Internet exchange point (IXP)
![Page 10: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/10.jpg)
The Need for Event Processing
![Page 11: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/11.jpg)
The Need for Event Processing
• Rate limit all Bittorrent traffic between the hours of 9 a.m. and 5 p.m.
• Do not use more than 100 GB of my monthly allocation for Netflix traffic
• If a host becomes infected, re-direct it to a captive portal with software patches
• …
11
![Page 12: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/12.jpg)
12
State Machine Abstraction
• State: A set of domain values.
• Events: Trigger state transitions in the controller’s finite state machine.– Intrusions– Traffic fluctuations– Arrival/departure of hosts
• State machine transitions update the current policy/program that is “running” in the network.
![Page 13: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/13.jpg)
Domains that Can Define States
13
![Page 14: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/14.jpg)
Resonance: Event-Based Network Control
14
Idea: Express network policies using state machines.
http://resonance.noise.gatech.edu/
![Page 15: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/15.jpg)
Resonance: Dynamic Event Handler
• Controller reacts to events
• Determines event source
• Updates state based on event type
• Can process both internal and external events
15
![Page 16: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/16.jpg)
Example FSMs and Programs
![Page 17: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/17.jpg)
Composition Mitigates State Explosion
17
Unauthenticated
Authenticated Clean
Quarantined
SuccessfulAuthentication
Timeout orAuthenticationFailure
Clean after Scan
VulnerabilityDetected
AuthFSM IDSFSM>>Simpler: Use Pyretic to sequentially compose FSMs!
![Page 18: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/18.jpg)
Mitigating State Explosion
![Page 19: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/19.jpg)
Campus Network Deployment• Software-defined
network in use across three buildings across the university
• Redesign of network access control
• Also deployed at other universities
19
![Page 20: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/20.jpg)
20
Application: Campus Access Control
3. VLAN with Private IP
6. VLAN with Public IP
1. New MAC Addr 2. VQP
7. REBOOT
Web Portal
4. Web Authentication 5. Authentication
Result
VMPS
Switch
New Host
8. Vulnerability Scan
![Page 21: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/21.jpg)
21
Problems with Conventional Approach
• Access control is too coarse-grained– Static, inflexible and prone to misconfigurations– Need to rely on VLANs to isolate infected machines
• Cannot dynamically remap hosts to different portions of the network– Needs a DHCP request which for a windows user would
mean a reboot
• Monitoring is not continuous
![Page 22: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/22.jpg)
22
Policy: State Machine, OpenFlow Rules
Unauthenticated
AuthenticatedClean
Quarantined
SuccessfulAuthentication
Vulnerability detected
Clean after update
Failed Authentication
Infection removed or manually fixed
Still Infected after an update
Complicated, especially as the number of inputs increases!
![Page 23: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/23.jpg)
Home Network Deployment
23
• User monitors behavior and sets policies with UI
• Resonance controller manages policies and router behavior
• Clean UI built on top of abstractions
![Page 24: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/24.jpg)
Abstractions for Network Management
• State machines for event processing– State-based network policies– Composition operators– Example applications: Home, campus
• Virtual networks for policy specification– Network operators can express policies in terms of a
virtual topology, without needing to know about details of underlying topology
– Example applications: Internet exchange point (IXP)
![Page 25: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/25.jpg)
Limitations of BGP
• Routing only on destination IP prefix– No customization of routes by application, sender
• Influence only over neighbors– No ability to affect end-to-end paths
• Indirect expression of policy– Indirect mechanisms to influence path selection (e.g.,
local preference, AS path prepending)
![Page 26: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/26.jpg)
SDX: Evolution at Internet Exchanges
• New technology at a single IXP can yield benefits for tens to hundreds of ISPs.
• IXPs are currently experiencing a rebirth (e.g., Open IX) and wanting to differentiate
• New traffic demands and applications create the need for richer peering
![Page 27: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/27.jpg)
Things We’d Like to Do
• Application-specific peering: Peering for specific applications like video
• Redirection to middleboxes: Redirection of specific traffic subsets to middleboxes
• Traffic offloading: Avoiding sending traffic through intermediate peers at IXPs
• Preventing free-riding: Dropping inbound traffic that is not associated with any peering relationship
• Wide-area load balancing: Rewriting destination IP address for load balancing (vs. DNS)
![Page 28: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/28.jpg)
Evolve BGP at Internet Exchanges
• New technology at a single IXP can yield benefits for tens to hundreds of ISPs.
• IXPs are currently experiencing a rebirth (e.g., Open IX) and wanting to differentiate.
• New applications create need for richer peering.
![Page 29: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/29.jpg)
SDN: Challenges and Opportunities
• Opportunities: Freedom from constraints– Matching of different packet header fields– Control messages from remote networks– Direct control over data plane
• Challenges: No existing SDN control framework for interdomain routing– Scaling: Hundreds to thousands
of ISPs at an IXP
![Page 30: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/30.jpg)
SDX Design: Multiple “Applications”
• Problem: Each participant needs to see its own version of the topology.
• Soluton: Each AS sees only its own virtual IXP topology• Applications run on top of SDX runtime
– Makes decisions, resolves conflicts based on both participants’ applciations and policies and auxiliary information (e.g., route server information)
![Page 31: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/31.jpg)
SDX Architecture
• Each AS sees only its own virtual IXP topology (isolation)– Applications run on top of SDX runtime– Runtime makes decisions based on both participants’ applicationsand
policies and auxiliary information (e.g., route server information)• No changes to BGP• ASes do not need to deploy custom hardware
![Page 32: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/32.jpg)
Virtual SDX Abstraction
• ISPs that do not have business relationships with one another cannot see each other – (e.g., AS A and C have no direct connection)
• Enforced using symbolic execution at SDX
![Page 33: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/33.jpg)
Two Kinds of Applications
• Routing Applications– ASes that transit traffic – ASes that terminate traffic
• Integration of SDX with Services
![Page 34: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/34.jpg)
New Primitive: Remote Control
• Ases can control exchange traffic remotely
• Opportunity to process packets and control routing decisions remotely
• Applications– Traffic engineering– Prevent selection of paths via problematic ASes – DDoS Squelching
34
![Page 35: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/35.jpg)
Remote Control
AS A
35
SDX
AS B
AS C
• For WAN load balancing, AS A can remotely apply its load balancing policy at SDX
DC1
DC2
130.267.2.0/24
130.267.3.0/24
130.267.1.0/24
![Page 36: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/36.jpg)
Deployment Status• Deployment at 55 Marietta Street in Atlanta, GA (SNAP)
• Two servers:– Floodlight controller– Virtual machine/network host– Brocade switch
• Connectivity– 56 Marietta (TelX)– Southern Crossroads– Georgia Tech (via SOX)– Experimental rack at 55 Marietta
![Page 37: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/37.jpg)
Abstractions for Network Management
• State machines for event processing– State-based network policies– Composition operators– Example applications: Home, campus
• Virtual networks for policy specification– Network operators can express policies in terms of a
virtual topology, without needing to know about details of underlying topology
– Example applications: Internet exchange point (IXP)
![Page 38: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/38.jpg)
The Need for Abstractions• Configuration changes are frequent
– Policies are dynamic, depend on temporal conditions defined in terms of external events
– Abstraction: State machine
• Configuration exposes the physical topology– Operators do not need to know about the physical topology when
configuring policies. Instead, they need a logical view of the network– Abstraction: Virtual network
• Configuration languages are too low-level– Need to configure networks at a higher level– Abstraction: Functional programming primitives
38
![Page 39: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/39.jpg)
Procera: Functional Programming Abstractions
39
• Input signals from environment• Windowing and aggregation functions that process and combine• Periodically updates a flow constraint function that controls the
forwarding elements
Define a signal function for a device going over (or under) the usage cap:
Define the set of devices over the cap:
![Page 40: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/40.jpg)
40
Procera Language Properties• Declarative Reactivity: Describing when events
happen, what changes they trigger, and how permissions change over time.
• Expressive and Compositional Operators: Building reactive permissions out of smaller re- active components.
• Well-defined Semantics: Simple semantics, simplifying policy specification.
• Error Checking & Conflict Resolution: Leveraging well-defined, mathematical semantics.
![Page 41: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/41.jpg)
Summary• Configuration changes are frequent
– Policies are dynamic, depend on temporal conditions defined in terms of external events
– Abstraction: State machine
• Configuration exposes the physical topology– Operators do not need to know about the physical topology when
configuring policies. Instead, they need a logical view of the network– Abstraction: Virtual network
• Configuration languages are too low-level– Need to configure networks at a higher level– Abstraction: Functional programming primitives (Procera)
41
![Page 42: (SDN) Abstractions for Network Management](https://reader037.vdocuments.net/reader037/viewer/2022102606/568168b5550346895ddf8bf1/html5/thumbnails/42.jpg)
Other Collaborators
• Resonance– Josh Reich (Princeton)
• SDX– Jennifer Rexford (Princeton)– Scott Shenker (Berkeley)– Laurent Vanbever (Princeton)
• Procera– Andi Voellmy (Yale)
42