Introducing Active Networks and SDN Innovations
Explore the convergence of active networks and SDN (Software-Defined Networking), empowering users to introduce new services through overlays and middleboxes while addressing security and performance challenges. Discover the concept of running mobile code within the network, merging pre-installed modules for enhanced modularity, and reducing network wastage through fine-grain control mechanisms.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Programmable Networks: Active Networks + SDN
How to Introduce new services Overlays: user can introduce what-ever Ignores physical network perf overhead Overlay nodes software routing perf overhead Middleboxes: ops can introduce what-ever Must be placed in a specific location Must determine apriori what type of MB you want
In the ideal work Ideal Anyone can introduce services So, like overlay Can achieve Data-plane throughput So, like MB Can introduce anything So like Overlay Problem: How to run untrusted code in your environment We want flexible but need to deal with security, performance, safety
Enter Active Networks Motivated by advances in RPC Goal: run mobile code in network Code implementation of a new service Active Extensions: User ships code to network devices All packets use the code No change to packet format Active Packets: Each packet carries the code or pointer to the code Very fine-grain control Packet is larger A lot of redundant data
REALITY, MERGE BOTH: The How? Entities are a set of pre-installed modules. The Active packet include the graph of which entities to use. Active Packet! Network Router TCP Header Serv 1 Serv 2 Type:Serv 1 Type:Serv5 Type:Serv6 Serv 7 Serv 5 Serv 6 IP Header
REALITY, MERGE BOTH: The Why? Promotes more modularity and reuse Entities can be smaller; since packet can be used to stitch together multiple entities. Reduces waste of N/W A flow multiple packets If each Packet carries code lot of n/w wasted Lots of Waste CPU, load/unloading code Wasted n/w b/w because of code in pkt
REALITY, MERGE BOTH: End-to-End Picture Global Entity Store Signs code with special Key, so routers know to trust the code Serv 1 Serv 2 Serv 3 The type is an MD5 hash Of the code. This way pkts are treated by the exact code you downloaded from store Network Router Network Router Active Packet! Type: serv1 Serv 1
REALITY, MERGE BOTH: End-to-End Picture Network Router Network Router Active Packet! Type: serv1 Serv 1
REALITY, MERGE BOTH: End-to-End Picture Network Router Network Router Active Packet! Type: serv1 Serv 1 Serv 1
REALITY, MERGE BOTH: End-to-End Picture Network Router Network Router Active Packet! Type: serv1 Serv 1 Serv 1
REALITY, MERGE BOTH: End-to-End Picture Each router caches the code so that it can be used for Next packet. Packet only caries a pointer to the code. Network Router Network Router Active Packet! Type: serv1 Serv 1 Serv 1 Serv 1
Active Packet: Capsules Recall: OSI layering A.P. just random modules no need to stick to layers
Routers: Active Nodes A VM (JVM? Language level safety) Protect code from each other Prevent for interfering with each other A Trusted Operating system Allow sharing of resources Need Some that interfaces directly with H/W Network Router Serv 1 Serv 1 JVM JVM Linux OS
Challenges: Performance Traffic must be similar + bursty Or else caching wouldn t work Network has diff types of nodes Not all can run code at line rate Think: Core V Edge Only run on edge nodes
What impacts Performance of Node Code distribution Caching of code minimizes this Random management tasks Cleanup memory (GBC), run normal protocols Running code Main performance bottle-neck
Challenges: Security Network Router one code changing with another code's state No sharing of state due to sandbox. Serv 1 Node O.S. maybe corrupted by code Sandbox prevents this. JVM JVM Linux OS Sending bad/malicious code to a node The person signing should catch bad code (Think Apple s App store) Bad Serv 1 Good Serv 1 10001 10111 01000 10001 00110 01000 Pkt/Capsule using the wrong code at node Wrong code will have diff finger print, so finger print in pkt would make finger print of code at node
Challenges: Resource Sharing code using too much resource on a node Limit resource consumption (also limit code size) Kill code if it runs for too long code using too much resource across a set of nodes: Tricky Use TTL to prevents loops. If I make copies then they all get the same TTL Divide TTL when making copies Doesn't work for multicast. an app sending too many capsules/pkts Similiar to today's internet.
Limitation of API Fixed assumption that code must work around: 1. format of IP 2. resource limits (TTL & size & time) 3. code distribution 4. how code types are computed and calculated
Limitation in terms of Architecture Things that can't be easily specified: FW --> since it should work for all flows just not the flows with the type specified. Web-Cache/transcoders --> code is short lived.
Why this Never took off? Performance. Still relatively slow only at edge Complex changes to routers Routers should run JVM Only a few types of networks ISP and maybe Enterprise networks So very limited use-cases
A New Problem Interface vlan901 ip address 10.1.1.5 255.0.0.0 ospf cost 100 ip access-group 9 out ! Router ospf 1 router-id 10.1.2.23 network 10.0.0.0 0.255.255.255 ! access-list 9 10.1.0.0 0.0.255.255 Operator s Goal Network Reality 23
Old Solution: Programmable Networks Ethane Sw1 Sw2 Sw3 Packet
Ethane Drawbacks Require complex hardware Each switch needs to encrypt/decrypt packets Performance issues The controller is involved with every packet
Practical Solution: SDN (e.g. OpenFlow) If (port == 22) Then send on if 2 If (port == 80) Then Drop
OpenFlow API (0.9) Layer 3.5: (Firewall/ACL) 1. Matches on IP address OR 1. Matches on a port 2. Drops or forwards the pkt Match IP Mac Port VLAN TOS Layer 3: (OSPF) 1. Matches on IP address 2. Forwards on a port Layer 2.5: (Spanning Tree) 1. Matches on VLAN 2. 2. Floods the packet Action: Forward/flood on specific interfaces Drop packet Rewrite ip or mac headers Layer 2: (Spanning Tree) 1. Matches on MAC address 2. Forwards on a port 2. Floods the packet OR
OpenFlow API Layer 3.5: (Firewall/ACL) 1. Matches on IP address OR 1. Matches on a port 2. Drops or forwards the pkt HP ACL OSPF VLAN SPT HP Magic Protocols Layer 3: (OSPF) 1. Matches on IP address 2. Forwards on a port Cisco ACL OSPF VLAN SPT Layer 2.5: (VLAN) 1. Matches on VLAN 2. 2. Floods the packet Cisco Magic Protocols Juniper Layer 2: (Spanning Tree) 1. Matches on MAC address 2. Forwards on a port 2. Floods the packet ACL OSPF VLAN SPT Juniper Magic Protocols OR
OpenFlow API HP ACL OSPF VLAN SPT HP Magic Protocols OpenFlow Switch Cisco Simple Firmware patch ACL OSPF VLAN SPT ACL OSPF VLAN SPT Cisco Magic Protocols Juniper ACL OSPF VLAN SPT Juniper Magic Protocols
Lesson A rigid network is impractical Doesn t support new services Programmable Networks allow great flexibility Allows anyone to introduce new services Into which ever nodes they have access to But this flexibility introduces new challenges Security, performance, Resource control For Technological adoption Minimal overhead for transition is good New h/w is hard to get created
