Transcript Programmable Networks

Programmable Networks
Jennifer Rexford
Fall 2010 (TTh 1:30-2:50 in COS 302)
COS 561: Advanced Computer Networks
http://www.cs.princeton.edu/courses/archive/fall10/cos561/
Today’s Passive Networks
• Dumb store-and-forward network
– Smart end hosts implement key functions
– Simple routers store and forward packets
– Limited network processing (e.g., routing, forwarding,
buffering, and packet scheduling)
• Packet header used in a simple way
– Common, standardized format
– Causes one of a small set of operations to occur
– Packet forwarded or dropped based on those rules
– Network (largely) ignores higher-layer headers
Enable experimentation and innovation inside the networks?
Active Networks
3
Proposed Active Networks
• Packet == data + code
– Smart hosts, as before
– Active nodes that can execute code on the data
– Active packets that carry code to active nodes
• Postscript analogy
– Contains both your data, and the program the printer
runs to print your data
• Active networks
– allow an individual user, or groups of users,
– to inject customized programs
– into the nodes of the network.
Motivation for Active Networks
• High-level goal
– Leverage computation in the network
• User pull
– Automatically adaptive streaming
– Data aggregation to reduce data volumes
– Computation closer to users to reduce latency
• Industry push
– Ad-hoc collection of middleboxes emerging
– Replace with generic, multi-purpose active nodes
– Otherwise, proliferation of active components will
happen anyway, without any common framework
Motivation for Active Networks
• Big mismatch in rates of innovation
– Applications change quickly (e.g., Web, P2P, IM)
– The network changes slowly
• Deploying new network technology is hard
– Delay for standardization (at the IETF)
– Additional delays for vendors to implement and service
providers to deploy the new technology
• Better to decouple services from hardware
– Minimize the amount of global agreement
– Load new services on demand
Motivating Examples
• Customized packet-drop policy
– User watching video stream (MPEG)
– Congestion leads to bandwidth limits
– Drop selectively the B frames
– Requires application-specific intelligence
• Other examples
– Forward error correction: adapt to loss rate.
– TCP-SYN filtering
– Web caching
– Reliable multicast (or any multicast)
– Support for mobility
Enabling Technologies for Active Networks
• Component-based software engineering
– Building blocks for composing software
• Code mobility (e.g,. Java)
– Previously between end hosts, not network nodes
– Innovation in safe and efficient code mobility
• Field-programmable gate arrays (FPGAs)
– Enabling higher speed of packet processing
• Research in programming languages
– And PL folks’ interest in networking
Two Models of Active Networks
• Active networks are active in two ways
– Switches run code on data flowing through them
– Individuals can inject programs into the network
• Programmable switches: discrete ANs
– Separation of program loading and execution
– E.g. program loading only by network operator
– Packet is demultiplexed to the right program
• Capsules: integrated ANs
– Every packet is a program, and carries its code
– Perhaps in a restricted programming language
Three Parts to an Active Network
• Execution environment
– Virtual machine with access to node resources
– General, Turing-complete vs. restricted models
• Active applications
– Provide an end-to-end, customized service
– Load code on to the routers to program the VM
• Node operating system
– Support multiple execution environments at once
– Provide safety between execution environments
Example: Capsules
• Capsule = code + data
– Extension of IP packet format
• Type identifies which code handles the capsule
– E.g., may indicate a Java class
• Code runs in transient execution environment
– Destroyed when the capsule evaluation ends
• Active storage
– Capsules can leave information behind in a node’s nontransient storage for subsequent capsules
• External methods cached on the node
Security, Safety, and Performance
• Protection
– Can my service damage yours?
– Need to run code in a sandbox
• Resource management
– Can my service consume arbitrary resources?
– Need careful control over resource allocation
• Performance
– Can my program complete quickly enough to avoid
introducing excessive latency?
– Need to limit the complexity of the programs
– … or run them only on lower-speed links
Efficiency and Performance
• Running programs on packets
– Questionable on higher-speed links
– E.g., where you have just a few nsec per packet
• Feasible at the edge (e.g., 100 Mbps, 1 Gbps)
– Firewall, NAT, shaper, proxy, intrusion detection
• Feasible for control plane in the core
– Running routing protocols
• Computer architecture advances help
– Faster conventional processors
– Network processors and FPGAs
– Multi-processor cores
Stepping Back
• Was active networks a success or failure?
– General idea of computation/services in the network?
– Need for a principled approach to middleboxes, and a
blurring of router vs. general network node?
– Specific mechanism of packets carrying code?
• Devil in the details
– What granularity: packets vs. flows
– When is code loaded: on demand vs. in advance
– Who programs: user vs. network operator
– What programming environment: specialized secure
languages/OSes vs. commodity Linux platforms
Network Virtualization
15
Rethinking the Network Architecture
• The Internet is showing signs of age
– Security, mobility, availability, manageability, …
• Challenges rooted in early design decisions
– Weak notion of identity, tying address & location
– Not just a matter of redesigning a single protocol
• Revisit definition and placement of function
– What are the types of nodes in the system?
– What are their powers and limitations?
– What information do they exchange?
Hurdle #1: Deployment Dilemma
• An unfortunate catch-22
– Must deploy an idea to demonstrate feasibility
– Can’t get an undemonstrated idea deployed
• A corollary: the testbed dilemma
– Production network: real users, but can’t change
– Research testbed: easy changes, but no users
• Bad for the research community
– Good ideas sit on the shelf
– Promising ideas do not grow up into good ones
Hurdle #2: Too Many Design Goals
• Many different system-engineering goals
– Scalability, reliability, security, privacy, robustness,
performance guarantees, …
– Perhaps we cannot satisfy all of them at once
• Applications have different priorities
– Online banking: security
– Web surfing: privacy, high throughput
– Voice and gaming: low delay and loss
• Compromise solution isn’t good for anyone
Hurdle #3: Coordination Constraint
• Difficult to deploy end-to-end services
– Benefits only when most networks deploy
– No single network wants to deploy first
• Many deployment failures
– QoS, IP multicast, secure routing, IPv6,…
– Despite solving real, pressing problems
• Increasing commoditization of ISPs
1
sender
2
3
receiver
Virtualization to the Rescue
• Multiple customized architectures in parallel
– Multiple logical routers on a single platform
– Isolation of resources, like CPU and bandwidth
– Programmability for customizing each “slice”
Overcoming the Hurdles
• Deployment Dilemma
– Run multiple experimental networks in parallel
– Some are mature, offering services to users
– Isolated from others that are works in progress
• Too Many Design Goals
– Run multiple operational networks in parallel
– Customized to certain applications and users
• Coordination Constraint
– Run multiple end-to-end services in parallel
– Over equipment owned by different parties
Economic Refactoring
Infrastructure Providers
Service Providers
• Infrastructure providers: Maintain routers, links, data
centers, and other physical infrastructure
• Service providers: Offer end-to-end services (e.g., layer
3 VPNs, SLAs, etc.) to users
Today: ISPs try to play both roles, and cannot offer end-to-end services
Enabling End-to-End Services
• Secure routing protocols
• Multi-provider Virtual Private Networks
• Paths with end-to-end performance guarantees
Today
Competing ISPs
with different goals
must coordinate
Virtualized Network
Single service
provider controls
end-to-end path
Discussion: Internet vs. Pluralism
• Internet architecture
– End-to-end argument
– Best-effort packet-delivery service
– Narrow waist of IP
– Separation of intradomain from interdomain
• Virtualized programmable networks
– Complete control within a virtual network
– Programmable functionality inside the network
– Different (virtual) networks for different services
– No “interdomain,” except for instantiating topologies