GENI Architecture: Transition

1
GENI Architecture Transition
Facility Architecture Working Group
July 18, 2007
2
Outline

• Requirements
• Top Level
• Derived
• Facility Design
• Hardware Configuration
• Software Configuration
• Minimal Core
• Construction Plan

3
Top-Level Requirements

• Generality
• Minimal Constraints
• allow new packet formats, new functionality, new
  paradigms,
• allow freedom to experiment across the range of
  architectural issues (e.g., security,
  management,...)
• Representative Technology
• include a diverse and representative collection
  of networking technologies, since any future
  Internet must work across all of them, and the
  challenges/opportunities they bring
• Slicability
• support many experiments in parallel
• isolate experiments from each other, yet allow
  experiments to compose their experiments to build
  more complex systems

4
Top-Level Req (cont)

• Fidelity
• Device Level
• expose the right level of abstraction, giving the
  experimenter the freedom to reinvent above that
  level, while not forcing him or her to start from
  scratch (i.e., reinvent everything below that
  level)
• these abstractions must faithfully emulate their
  real world equivalent (e.g., expose queues, not
  mask failures)
• Network Level
• arrange the nodes into a representative topology
  and/or distribute the nodes across a physical
  space in a realistic way
• scale to a representative size
• expose the right network-wide abstractions (e.g.,
  circuits, lightpaths)
• GENI-Wide
• end-to-end topology and relative performance
• economic factors (e.g., relative costs, peering)

5
Top-Level Req (cont)

• Real Users
• allow real users to access real content using
  real applications
• Experiment Support
• Ease-of-Use
• provide tools and services that make the
  barrier-to-entry for using GENI as low as
  possible (e.g., a single PI and one grad student
  ought to be able to use GENI)
• Observability
• make it possible to observe and measure relevant
  activity

6
Top-Level Req (cont)

• Sustainability
• Extensible
• accommodate network technologies contributed by
  various partners
• accommodate new technologies that are likely to
  emerge in next several years
• support technology roll-over without disruption
• Operational Costs
• the community should be able to continue to use
  and support the facility long after construction
  is complete

7
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
8
Derived Requirements

• Generality
• Minimal Constraints

• All devices are programmable with open interfaces
• All devices expose multiple levels of
  abstraction, with the lowest level coming as
  close to the raw hardware as possible
• sockets
• virtual links
• point-to-point
• multipoint
• virtual radio
• virtual wire
• framed TDM electrical
• unframed TDM electrical
• unframed raw wavelength

9
Derived Req (cont)

• Generality
• Representative Technology

• Architected to accommodate a wide range of
  technologies
• Initially selected technologies
• national fiber backbone
• connected edge clusters
• mobile client devices sensors
• 802.11 access network
• WiMAX access network
• cognitive radio access net

10
Derived Req (cont)

1. Slicability

• Virtualize resources
• Partition resources (time space)
• Isolate and contain slices
• Support slice composition
• Minimum capacity
• 1000-10000 total projects
• 100-1000 active experiments
• 10-100 continuously running services
• 1-10 high-performance/low-jitter nets

11
Derived Req (cont)

• Fidelity
• Node Level
• Network Level
• GENI-Wide

• For each selected technology (1.B.ii)
• support interfaces as appropriate (1.A.ii)
• sliver behavior (e.g., jitter)
• node capacity
• transmission capacity

• For each selected technology (1.B.ii)
• points-of-presence
• distribution/topology

1. Rich topology
2. Federation of autonomous domains

12
Derived Req (cont)

1. Real Users

• Wide coverage
• Opt-in mechanisms
• Generic proxies
• GENI-aware applications
• Legacy Internet connectivity
• number of edge connection points
• number of peers
• capacity per peer

13
Derived Req (cont)

• Experiment Support
• Ease-of-Use
• Observability

• Rich set of user services
• slice embedding
• experiment management
• legacy Internet
• building block services

• For each selected technology (1.B.ii)
• instrumentation sensors
• Data collection/archiving/analysis tools

14
Derived Req (cont)

• Sustainability
• Extensible
• Operational Costs

1. Same as 1.B.i (representative technology)
2. Support federated ownership

• Renewal costs contribute to 1.B.ii.
• Adopt sustainable software engineering practices
• Architect for security
• Develop monitoring diagnosis tools

15
National Fiber Facility
16
Programmable Routers
17
Clusters at Edge Sites
18
Wireless Subnets
19
ISP Peers
MAE-West
MAE-East
20
Sensor Network
backbone wavelength(s)
Programmable Edge Node
Programmable Core Node
Edge Site
Programmable Edge Node
Programmable Edge Cluster
Programmable Wireless Nodes
Commodity Internet
Internet
Wireless Subnet
21
(No Transcript)
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 (Proxy for set of components)
Resource Controller
Auditing Archive
O M Control Slice Coordination
CM
Virtualization SW
Substrate HW
26
Federation
27
User Portals
Researcher Portal (Service Front-End)
28
OM Control
Backbone Mgmt Aggregate
Slice Control
Operations Portal
OM Control
Wireless Mgmt Aggregate
Ops Team
Slice Control
Researcher Portal
OM Control
Wireless Mgmt Aggregate
Researchers
Slice Control
OM Control
PEC (Site 1)
PEC (Site n)
Edge Site Mgmt Aggregate
Internet
Slice Control
. . .
29
Hour-Glass Revisited
User Services
Bootstrap Structure
Universal
Minimal Core
Fixed Point
Reference Implementations
Substrate Components
30
Minimal Core

• Principals
• Slice Authorities (SA)
• Management Authorities (MA)
• User (experimenter, not end user)
• Objects
• Slices
• Registered, Embedded, Accessed
• Components
• Data Types
• GENI Global Identifiers (GGID)
• Tickets (credentials issued by component MA)
• rspec resource specification
• Slice Credentials (express live-ness, issued by
  SA)

31
Core (cont)

• Default Name Registries
• Slice Registry (e.g., geni.us.princeton.codeen)
• Component Registry (e.g., geni.us.backbone.nyc)
• Component Interface
• Get/Split/Redeem Tickets
• Control Slices
• Query Status

32
Construction Plan

• Objectives
• Allow broader community to contribute (not just
  subs)
• Scale (federate) the integration effort
• Strategy
• Feature Development
• Roughly equivalent to open source development
  process
• Component/Aggregate Integration
• Roughly equivalent to preparing a Linux
  distribution

33

• Features (hardware and software) are developed
  through the working group and tested locally
• Once complete a feature is passed to a feature
  repository where acceptance testing occurs
  (queued until dependencies resolve)
• Features in the repository can be picked up to
  enable development of other features

Design
Develop
Unit Test
Distribution
Dependency
Acceptance Testing
Feature Repository
Node Integration
Node Testing
Distribution

• A collection of hardware and software features
  are integrated into a canonical node
• The canonical node is distributed to a node
  repository for acceptance testing
• Nodes are available for specialization

Specialization
Acceptance Testing
Component Repository
Aggregate Integration
Aggregate Testing
Distribution

• A collection of nodes and communication features
  are integrated into a coherent aggregate
• Aggregates are themselves integrated to create,
  ultimately, the GENI Facility

Specialization
Acceptance Testing
Aggregate Repository
DEPLOY