Gísli Hjálmtýsson – Reykjavík University Architecture Challenges in Future Network Nodes Prof. Gísli Hjálmtýsson Network Systems and Services Laboratory

Gísli Hjálmtýsson – Reykjavík University

Architecture Challenges in Future Network NodesArchitecture Challenges in Future Network Nodes

Prof. Gísli HjálmtýssonNetwork Systems and Services Laboratory

Department of Computer ScienceReykjavík University, Reykjavík, Iceland

http://netlab.ru.is

Gísli Hjálmtýsson – Háskólinn í Reykjavík – [email protected]

Overview

• Background and Motivation• Reality Check & Implications for Routers• A New Approach to Rapid Service Creation• A New Architecture for Network Nodes• Example Services• Summary


Acknowledgements

• Björn Brynjúlfsson, Heimir Sverrisson, Ólafur R. Helgason @ Reykjavik University

• Bernhard Plattner, Kostas Katrinis @ ETH


Active Networking Motivation

• Service deployment – rapid service creation– High margin for new services – competitive edge– Same drivers as for AIN in telephony

• Standardization takes too long– IETF's complexity is growing exponentially– So is time to standardize – Multicast, mobile IP, IPv6, etc. has taken forever

• Technology trends– Rapid growth in bandwidth and # of transistors (cycles)– Counting instructions in data-path is passé


Proven that it can be done

• No technical show-stoppers• Time scale of programmability – NOT AN ISSUE

– Auto-deployment sufficient, timescales of minutes or hours

• Time scale of activity – Principle of timescale– Per packet timescale hard, 100 times that easy

• Model of programmability – Practical convergence• Interfaces – a number of viable alternatives

– Packet processors minimize this interface

• Program @ levels – services vs. extensible routers• Composability – Doable to some extent

– Feature interaction problem remains.

• Granularity – NOT a critical issue


Did Active and Programmable Fail?• No, but it does not warrant a separate

discipline– AN ideas have gone mainstream

• Sensor networks, adaptive middleware, autonomic networks, overlays

• Significant impact on Router Architecture– All kinds of functions now appearing on routers– Modular routers, FORCES working group

• Some of the same ideas appearing in overlays


Overview

• Motivation• Reality check & Implications for routers• A new approach to rapid service creation• A New Architecture for Network Nodes• Example Services• Summary


Reality check – Impact

• No significant impact on router vendors– No significant router vendor offers an open

programmable interface

• No significant impact on the “Sigcomm” crowd– AN as a research agenda has died– AN has had some but limited direct impact on the

agenda of other researchers

• AN adds to the complexity of the Internet


Reality check – Complexity

• Complexity is a real threat to the Internet• Configuration causes most Internet failures• … and dominates management cost

– AN has NOT help with routing, addressing, or protocols

• Need simplicity - must reduce the complexity– Self-configuration etc. is needed– Automation is not enough

• The pressing problem that need to be solved is reduction in (distributed) complexity


Overlays have taken over

• Service deployment is focused on overlays and P2P– The new network service has become DHT

• Incremental deployment a critical issue– Application layer approaches inherently solve this

• Increasing push for a cycle/pipe model– Nodes not offering cycles seen as dumb forwarders

• PlanetLab the mother of all overlays• Application level overlays offer a very simple

programming interface– Inherent driver to maintain end-system model


Problems with Overlays

• Introduce significant complexity – Cross-layer conflicts source of complexity– Prevent information exchange between layers.

• Fail to exploit capabilities of the underlying facilities – Specific hardware support and network processors– Increasing agility of the lower layers (tunable lasers)– On-demand allocation of optical light-paths.

• This is the architecture challenge in future networks– Finding the best (node) architecture for overlay based services


Overview

• Motivation• Reality Check & Implications for Routers• A New Approach to Rapid Service Creation• A New Architecture for Network Nodes• Example Services• Summary


Architecture goals

• To self-configure and self-optimize, fully exploiting the hardware facilities at each node and across a network of nodes, without explicit instructions from network programmers.


Implications – Departure from AN• Operate with very limited service information• Move away from direct manipulation of facilities• Instead adapt to observed use and traffic

patterns• Autonomic properties – observe and adapt

– Self-configuring, self-optimizing, self-healing

• Cross-node coordination of services– Largely ignored in AN research

• Measurements become a first class functionality


Measurement: first class function• Measure and monitor service level

topologies– Maintain consistent service quality– Monitor protocol behavior

• Require observations inside the network– Accuracy, detail, timeliness and responsiveness– Network tomography only computes long term averages

• Want generic mechanisms to provide– The right abstractions for service generic monitoring– Extensibility for service specific monitoring


Distributed Service Level Control • Control plane across multiple nodes

– Common services need coordination between nodes

• Much od the overlay/P2P work has nice ideas– Want to exploit them at control level– Still continue to get the benefits of network layer

forwarding facilities

• Maintaining and adapting the topology • Programmability is not a research issue

– Easy to do – use with discretion where needed


Overview

• Motivation• Reality Check & Implications for Routers• A New Approach to Rapid Service Creation• A New Architecture for Network Nodes

– The old model– The new model

• Example Services• Summary


The Pronto Router – A Node OS

Environment

manager

ActiveServices

Signaling Other CPU Sched

Classifier Packet Processors

Node OS

EE

Kernel

User

• Consistent with the DARPA Node OS framework• Service programming provided in EE• Router extensibility supported by packet processors


Service programming with Pronto• Dynamic introduction into EE (user level)

– Program using C++, Perl, Java

• Programmed by service providers• Typed flows, rather than typed datagrams

– Still acts at connectivity level or at data level– May assign, and reassign policies at any time

• Principle of timescales• Push functionality to the highest layer/plane

viable for the timescale of a given task


Extensibility of the Pronto router• Packet processors – A new kernel abstraction

– Provides programmability for hardware vendors

• Simple abstract interface– Type specific service interface (SAPI)

• Chains of packet processors make paths– Assigned to a filter in the classifier

• Paths can cross into user space• … or cross CPU boundaries (NP)• Examples:

– Forwarding, Tunnel entry/exit, IPSEC tunnels, NAT, TCP splicing, dropping, QoS, restoration, snooping

EM


Service Description Layer

Facilities

Resources

A model refinement – New Node OS

Distributed Control Plane

Node OS

EE

Kernel

User

• AN has not observed the boundaries• Focus has been more lower level

HW, Network Pocessors, Optics

Abstract facilitiesIncl. measurem.


Four layers of abstraction

• Service Description layer– Goal oriented description of the service requirements – e.g. delay, jitter, loss rate; more fuzzy “interactive media”

• Distributed Control Plane – Transforms the requirements to the available facilities – Coordinates across the nodes involved in the service delivery

• Facilities layer – Abstract interface to the forwarding engine’s functions – Examples: packet classification, forwarding and tunneling

• Resources layer – Special purpose resources for network functions on the node – E.g. tunable lasers, specialized hw, network processors


Overview



Examples

• Basic IP Services– Service description: TCP/UDP– Distributed control: Routing, Network wide measurement

collection and observation, load balancing, topology adaptation– Facilities: Classification, forwarding, local measurements,

tunneling– Resources: Topology adaptation (e.g. optical path allocation),

network processors, other special purpose hardware

• Peer-to-peer CDN– Service description: Interactive streaming audio/video, cashing

style CDN– Distributed control: DHT or other structure for locate/find, load

balancing, overlay topology management, measurements– Facilities: Forwarding, tunneling for topology adaptation, local

measurements– Resources: Low level topology adaptation


Examples II

• Mobile support for streaming media– Service description: Whatever the base service is, e.g. interactive

audio and/or video– Distributed control: user/entity registry used for locate/find,

locate/find, user tracking – Facilities: 1-N classifier mappings, tunneling, local basic

measurements (same as for multicast)– Resources: Same as for basic IP services

• Enterprise level VPN– Service description: SLA– Distributed control: Basic IP, SLA conformance enforcement,

dedicated topology management (e.g. for performance, or privacy/security), VPN specific routing, Authentication etc.

– Facilities: Basic IP services, plus IPSEC– Resources: Same as basic IP services


Autonomic Multicast

• Service description: – multipoint streaming - interactive or not, – delay/loss sensitivity

• Distributed control: – Gtrace – measurement and monitoring, – SLIM multicast protocol daemon, – Autonomic service adaptation

• Facilities: – 1-N classifier mappings, tunneling, local measurements

• Resources: – Same as for basic IP services


Autonomic multicast service

• Have built network layer SSM (SLIM)– Self-configures over the unchanged Internet

• Monitoring protocol to collect distribution attributes– Combines a multicast/gathercast protocol– Collect basic properties of distribution trees

• Height, weight, losses, etc.

• Each node in the distribution tree participates– Rapid tracking of tree properties

• Every node in the tree knows subtree stats– Each node recursively can act like a root of a subtree


Gtrace monitoring

• Local maintenance and collection– Collect information from local topology manager

• Information distribution– Propogates queries and information from a collection point to

nodes of the collection channel• Information gather

– Gather information from nodes of the topology the root• Can dynamically change the ÷ and + functions

+

Gather

Local Topology

State

Information from downstream nodes

Information toward root

Information to downstream nodes

Distribution

÷

Information from upstream node

Local Topology

State


Effectiveness of the monitoring


Autonomic adaptability

• Distribution tree recursively monitors performance

• Provides consistent service quality throughout the distribution tree, by– Activate local retransmissions (reduce observed losses)– Increase priority of the data-stream (reduce latency)

• Includes recovery/restoration (rapid rejoin)• Dynamic adaptation of the distribution tree

– From shortest reverse path to minimum cost spanning

• Example: TV station– Declares service level objectives (e.g. loss/delay)– Autonomically maintain consistent service quality


Overview



Summary

• Direct manipulation of network facilities by service programmers increases complexity

New paradigm – promote simplicity for services• Autonomically adapt to offered services

– Adapt topology and functionality to match needs

• Coarse grained service descriptions/objectives• Principle of timescales – match action and

urgency• Local operations – service wide coordination


Summary

• New architecture for network nodes • Four layers of abstraction

– Service Description layer – fuzzy service requirements – Distributed Control Plane – coordinates across nodes– Facilities layer – Abstract interface to facilities– Resources layer – Allows cross layer manipulation

• Goal to build the best node for overlay networks

• See: http://netlab.ru.is

Documents

Gísli Hjálmtýsson – Reykjavík University Architecture Challenges in Future Network Nodes Prof. Gísli Hjálmtýsson Network Systems and Services Laboratory