GENI: Global Environment for Network Innovation

1
GENI Global Environment for Network Innovation
Oct 22 , 2007 DPNM Lab. Dept. of Computer
Science Engineering POSTECH, Korea Email
kiss_at_postech.ac.kr
2
References

• Thomas Anderson, Larry Peterson, Scott Shenker
  and Jonathan Turner Overcoming the Internet
  Impasse through Virtualization, Proc. 3rd
  Workshop on Hot Topics in Networks (HotNets-?),
  2004
• Larry Peterson and John Wroclawski, Overview of
  the GENI Architecture, GENI document, GDD-06-11,
  January 2007

3
Introduction

• Internets increasing ubiquity and centrality has
  brought
• A number of challenges for which the current
  architecture is ill-suited
• Increasing interest in new architectures
• Adopting a new architecture requires
• Not also changes in routers and host software
• But, given multi-provider nature of the Internet
• ISPs jointly agree on any architectural change
• Goal of this paper is to issue a call to action
• Status quo is not acceptable
• Unable to deploy, evaluate new architectures
• Return to roots of applied architectural research
  with the intention of once again changing the
  world

4
Introduction contd

• Live experimentation
• Currently through testbeds
• But, there is severe limitation
• We are not able to deploy, or even evaluate new
  architecture
• Overcoming Internet impasse will require
• 1. researchers must be able to easily experiment
  with new architectures on live traffic
• 2. there must be a plausible deployment path
  where architectural ideas, once validated, can
  come into practice
• 3. proposed architectural solutions should be
  comprehensive, capable of addressing the broad
  range of current architectural problem
• Constructing a virtual testbed to meet these
  three requirements
• Supports multiple simultaneous architectures
• Provides a clean path for radical new
  architectures to be unilaterally and globally
  deployed

5
Physical testbeds and overlays

• Before proposed architecture is considered for
  deployment
• It must be adequately evaluated
• Simulation and emulation cant be substitute for
  experimentation with live traffic
• Preparing an implementation to deal with the real
  world
• Challenges to designer
• multiple providers
• lagacy network
• anomalous failures and traffic conditions
• unexpected and diverse application requirements
• Physical testbeds and overlays
• Are the two ways in which researchers currently
  experiment with new architectures

6
Physical testbeds

• Physical testbeds
• Traditional platform for live experimentation
• Leased lines connecting a limited set of
  locations
• 1. production oriented testbed
• Support real traffic form real users
• Users expect the performance and reliability
• Must be extremely conservative in their
  experimentation
• 2. research oriented
• Do not carry traffic from a wide variety of real
  users
• Allow research to perform more adventural
  experiments
• Lack of real traffic
• Neither kind of testbed produces the data needed
  to evaluate new architectures

7
Overlays

• The definition of an overlay The Growth of
  Internet Overlay Network Implications for
  Architecture, Industry Structure and Policy
• An overlay is a set of servers deployed across
  the Internet that
• A) provide some sort of infrastructure to one (or
  ideally several) applications,
• B) in some way take responsibility for the
  forwarding and handling of application data in
  ways that are different from or in competition
  with what is part of the basic Internet
• C) are operated in an organized and coherent way
  by third parties to provide a well understood
  service that is infrastructure-like
• D) are not thought of as part of the basic
  Internet

8
Overlays contd

• Overlays
• Are not limited geographically
• Usage is voluntary
• Do not involve significant expenditures
• But, requiring substantial effort to create and
  maintain
• So, Overlays remain underutilized tool for
  architectural experimentation
• As a deployment path for radical architectural
  innovation
• 1.overlays have been seen as a way of deploying
  narrow fixes to specific problems
• 2.overlays have been architecturally tame
• What is needed is not so much a technical change
  in how overlay are built, but rather a
  philosophical change in how they are used
• Proposal of Virtual testbeds is less of a
  technical advancement than focal point for a new
  attitude towards overlays

9
Virtual Testbed (VT)

• VTs have two basic components
• 1. overlay substrate
• A set of dedicated but multiplexed overlay nodes
• 2. client-proxy mechanism
• Proxy mechanism treats a nearby overlay node as
  the hosts first-hop router
• For more radical architecture
• Deploy a prototype of this approach on Planetlab
• Planetlab includes over 440 nodes that span 207
  sites and 25 countries, and peers with nearly
  6000 autonomous systems
• PlanetLab software architecture multiplexes
  multiple slices
• Challenges
• It is not possible for Planetlab nodes to compete
  with custom hardware
• E.g., PlanetLab nodes can forward packets at
  60Mbps, but we expect to achieve 100Mbpsrate with
  modest optimizations

10
Virtual Testbed (VT) contd

• Since almost all client applications use name
  translation as the first step in communication
• Proxies interpose themselves on any IP address or
  port as seen by the legacy client software
• Be able to interpose on DNS requests, and either
  return the IP address of the server or a fake IP
  address
• By then interposing on the fake IP addresses,
  the packets can be forwarded to the nearst VT
  node (ingress VT node)
• Then the VT is free to do whatever it wants with
  the packet using whatever IP or non IP protocols
  are
• On the far end of VT node (egress VT node)
  reconverts the packet back into internet format
  for delivery to server

11
Deployment

• We do not need to know precisely how new
  architectures might be adopted all we require is
  that
• Deployment is at least remotely possible
• Deployment scenario
• A new generation service provider (NGSP) chooses
  a particular new architecture
• Constructs an overlay supporting that
  architecture
• NGSP also distributes proxy software (any one can
  access their overlay)
• If overlay is successful, NGSP begins offering
  direct access to customers (by signing
  agreements with current ISPs, or setting up
  access technology of their own) or current ISPs

12
Deployment contd

• But, easing the creation of new overlay might
  result in
• Ever-changing, collection of more narrowly
  targeted overlays
• In order to avoid architectural chaos and achieve
  some form of synergy
• There must be consideration of how this union of
  overlays form a coherent framework by the overlay
  designers
• Overlay deployments can occur quite independently
  without any coordination
• To lead to a substantially different future
• Coordination will be required

13
Virtualization means or ends

• Virtual testbed approach uses virtualization in
  two crucial ways
• 1. typically overlay sense
• 2. multiplexing of overlay nodes allows there to
  be many virtual testbeds operating simultaneously
• Internet purists have a monolithic view of
  architecture
• Overlays are seen as blights on the architectural
  landscape
• Virtualization is only a means by which new
  architectures are installed
• Internet pluralist approach
• The architecture is dynamic and evolving and is
  defined the union of various existing overlays
  and protocols
• The ability to support these multiple overlays
  and protocols
• Becomes the crucial universal piece of the
  architecture
• In the view of evaluation
• Internet Purists aiming for flexibility of an
  architecture (since it will remain in place for a
  long time)
• Internet Pluralists put more emphasis of
  short-term performance improvements

14
Concluding remarks

• Canonical story about the potential impact of
  architectural research
• If testbed experiments show an architecture to be
  promising
• It might be adopted by ISPs and router vendors
• But it no longer applies
• Traditional testbeds are no longer an effective,
  and certainly not a cost-effective
• Research community has narrowed its focus
• Our hope is that providing easy access to VT
• There will be a renaissance in applied
  architectural research
• It is time to directly confront impasse and
  overcome it

15
Overview of the GENI Architecture

• The overall GENI architecture can be divided into
  three levels
• Physical substrate (e.g., routers, processors,
  links, wireless devices)
• User services
• GMC (GENI Management Core) Sitting between the
  physical substrate and the user services is the
  GENI management Core, or GMC
• Purpose of GMC to define a stable, predictable,
  long-lived framework-a set of abstractions,
  interfaces, name spaces, and core services to
  bind together the GENI architecture

16
Facility Architecture
User Services

• name space for users, slices, components
• set of interfaces (plug in new components)
• support for federation (plug in new partners)

GMC
Physical Substrate
17
GMC

• Players
• Owners of parts of the substrate
• Administrators of parts of GENI
• Developers of infrastructure services
• Researchers employing GENI
• End users not affiliated with GENI
• Third parties
• Actions
• Allow owners to declare resource allocation and
  usage policies for substrate facilities under
  their control, and provide mechanisms for
  enforcing those policies
• Allow administrators to manage the GENI substrate
• Allow researchers to create and populate
  experiments
• Expose low-level information about the state of
  the GENI substrate to developers

18
GMC contd

• Naming
• GMC defines GENI Global Identifiers (GGID)
• The object identified by GGID holds the private
  key? forming the basis for authentication
• Name repository maps string to GGIDs
• GMCI (GENI management core implementation)

19
Abstractions

• Three major abstractions that the GMC defines
• Components
• Slices
• Aggregates
• Components
• A collection of resources
• Physical resources (e.g., CPU, memory, disk,
  bandwidth)
• Logical resources (e.g., file descriptors, port
  numbers)
• E.g., Programmable edge node (PEN) (i.e., a
  conventional compute server), Programmable core
  node (PCN) (a customizable router, i.e., a
  backbone router), Programmable access point (PAP)
  (e.g., for wireless connectivity)
• uniquely identified using GGIDs (GENI global
  identifiers)
• E.g., geni.us.backbone.nyc
• Each component is controlled via a component
  manager (CM), the entity responsible for
  allocating resources at a component
• Sliver
• A distinct partition of the components resources
• Each component must include HW or SW mechanisms
  that isolate sliver from each other
• E.g., virtual server, virtual router, virtual
  switch, virtual access point

20
Abstractions contd

• Slices
• A distributed, named collection of slivers that
  collectively provides the execution context for
  an experiment, service, or network architecture
• Slices are uniquely identified by GGIDs (GENI
  global identifiers)
• E.g., geni.us.princeton.codeen
• Aggregates
• A GMC object representing a group of components,
  where a given component can belong to zero, one,
  or more aggregates
• Example aggregate might correspond to a physical
  location (components co-located at the same
  site), a cluster (components that share a
  physical interconnect), an authority (a group of
  components managed by a single authority), a
  network (a group of components that collectively
  implement a backbone network or a wireless
  subnet)
• Researcher portal
• Coordinate resource allocation
• Manage set of components

21
Users and Authorization

• Users
• GENI users create and manipulate slices
• Each user is identified by a certificate and key
  pair issued by one of the GENI authority
• Authorization
• Authorization model for slice creation
• Slices are represented in the GMC by names
• Based on controlling access to the slice name
  space
• Slice Authority (SA) naming hierarchy rooted at
  a top-level
• Authorization model for Physical resources
• GENI physical resources are encapsulated as
  components
• Owner is responsible for defining and
  implementing the authorization policy
• Ticket GENI- specific authorization mechanism
  used to implement this model
• Represents a principals right to (1)create
  sliver (2) bind component resources to an
  existing slice

22
Substrate Hardware
Substrate HW
Substrate HW
Substrate HW
23
Virtualization Software
Virtualization SW
Virtualization SW
Virtualization SW
Substrate HW
Substrate HW
Substrate HW
24
Components
CM
CM
Virtualization SW
Virtualization SW
Substrate HW
Substrate HW
25
Aggregates
Aggregate
Resource Controller
Auditing Archive
Slice Coordination
CM
Virtualization SW
Substrate HW
26
User Portals
Researcher Portal (Service Front-End)
27
Questions
Question??