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
Type:Serv 1
Type:Serv5
Type:Serv6
IP Header
Serv 1
Serv 2
Serv 7
Serv 6
Serv 5
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
The type is an MD5 hash
Of the code.
This way pkts are treated
by the exact code you
downloaded from store
Serv 1
Network Router
Active Packet!
Type: serv1
Serv 1
Serv 2
Serv 3
Signs code with special
Key, so routers know to
trust the code
Network Router
REALITY, MERGE BOTH:
End-to-End Picture
Network Router
Active Packet!
Type: serv1
Serv 1
Network Router
REALITY, MERGE BOTH:
End-to-End Picture
Network Router
Active Packet!
Type: serv1
Serv 1
Serv 1
Network Router
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
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
• one code changing with another code's state
– No sharing of state due to sandbox.
• Node O.S. maybe corrupted by code
– Sandbox prevents this.
Network Router
Serv 1
JVM
Linux OS
• Sending bad/malicious code to a node
– The person signing should catch bad code
– (Think Apple’s App store)
• Pkt/Capsule using the wrong code at node
Good
Serv 1
10001
00110
01000
– Wrong code will have diff finger print,
– so finger print in pkt would make finger print of code at node
Bad
Serv 1
10001
10111
01000
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
A New Problem
Operator’s
Goal
Network
Reality
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
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)
• Match
–
–
–
–
–
IP
Mac
Port
VLAN
TOS
• Action:
– Forward/flood on specific interfaces
– Drop packet
– Rewrite ip or mac headers
Layer 3.5: (Firewall/ACL)
1. Matches on IP address
OR
1. Matches on a port
2. Drops or forwards the pkt
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
Layer 2: (Spanning Tree)
1. Matches on MAC address
2. Forwards on a port
OR
2. Floods the packet
OpenFlow API
HP
ACL OSPF VLAN SPT
HP Magic Protocols
Cisco
ACL OSPF VLAN SPT
Cisco Magic Protocols
Juniper
ACL OSPF VLAN SPT
Juniper Magic Protocols
Layer 3.5: (Firewall/ACL)
1. Matches on IP address
OR
1. Matches on a port
2. Drops or forwards the pkt
Layer 3: (OSPF)
1. Matches on IP address
2. Forwards on a port
Layer 2.5: (VLAN)
1. Matches on VLAN
2. 2. Floods the packet
Layer 2: (Spanning Tree)
1. Matches on MAC address
2. Forwards on a port
OR
2. Floods the packet
OpenFlow API
HP
ACL OSPF VLAN SPT
HP Magic Protocols
OpenFlow Switch
Cisco
ACL OSPF VLAN SPT
Cisco Magic Protocols
Juniper
ACL OSPF VLAN SPT
Juniper Magic Protocols
Simple
Firmware
patch
ACL OSPF VLAN SPT
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