GENI Research PlanRequirement for GENI

2007.09.21

Yeongjae Yu

yuyeongjae@gmail.com

Table of Contents1. Requirement for GENI 1.1 Multiple Simultaneous Experiments

1.2 Generality

1.3 Support for Real Applications

1.4 Support for Real Users

1.5 Fidelity

1.6 Support for All Aspects of a New Network Architecture

1.7 Support for Experimenters

1.8 Federation & Sustainability

1.9 Striking a Balance

2. Related Work 2.1 PlanetLab & Virtual Network Infrastructure

2.2 User Controlled LightPath & Articulated Private Network

2.3 Relation among PlanetLab, VINI and UCLP

1. Requirement for GENI

1.1 Multiple Simultaneous Experiments• The concept behind GENI - It can be used to multiple ideas and concepts

• To support multiple experiments simultaneously

=> The concept of slices - The resources of GENI can be divided up among many different researchers in

such a way that each can run his own experiment

• Virtualization - One approach to slices

- A processor, a fiber link, wireless system, ...

• Controlled Isolation - GENI must provide strong containment for experiments

- GENI must support controlled interconnection of slices to each other and to the

current Internet

1.2 Generality• We want to build an experimental platform that can support

a wide range of future Internets

• How much generality is required to support the anticipated

experiments? - To experiment with packet formats that materially differ from those of the

Internet

- To move beyond the paradigm of packet switching and explore other modes for

sharing and resource allocation

- To exploit specific features of the different technologies included in GENI

- To experiment with architectures that include network-level operations other

than simple packet forwarding

• Diversity of technology

• Balancing generality with cost

1.3 Support for Real Applications• GENI should be able to support not just a future network,

but also the applications that might run on that network

• To attract real applications, the GENI must include facilities

for development and deployment of applications, not just

data transport

1.4 Support for Real Users• If we are to gain real experience with real applications, we

must allow real users to try them out, and make real use of

them

• What does it mean to support real users? - The GENI facility must reach “to the edge” of the network, where the users

connect

- There must be a rich connectivity between GENI and the Internet of today

- There must be an adequate pool of potential users that have end-node

computers directly connected to, and a part of, the GENI infrastructure

- Some support for slices needs to be provided for the end-nodes that are

attached to GENI

1.5 Fidelity• Reach - As wide a reach as possible

• Topology - Keeping delays within a small factor of physical distance

- Path diversity

- Underlying fiber paths

- Major interconnection points (exchange points, aggregation points)

• Realism of virtualization

• Physical distribution

• Scale

• Failure modes - Intentionally induced failure, unanticipated failure

1.6 Support for All Aspects of a New Network Architecture

• Support for management - It must important that the management aspects of all devices be fully virtualized

- We can have the equivalent of “virtual system operators”

• Support for security - The GENI infrastructure itself must be stable and secure

- The mechanisms for isolation among slices must be very robust

- There may be a requirement for specialized security technology

• Support for anticipated future capabilities - In 10 years, there may be features that will be commonplace then, but are not

yet realized in any effective way

1.7 Support for Experimenters• Ease of Use - GENI must remove as many practical barriers as possible to researchers being

able to make full use of the facility

• Observability - GENI must offer strong support for measurement-based quantitative research

• Fail-safe - GENI must be secure, so that its resources cannot accidentally or maliciously

be used to attack today’s Internet

• Sources of real traffic - GENI must provide a way experiments can be run with real traffic

- One approach: to have several large-scale popular services

ex) content distribution networks

1.8 Federation & Sustainability• GENI must be designed for a 15-20 year lifetime

• To ensure the sustainability - Support for federation

- Design with operational costs in mind

• Addition of new technology - Open hardware interfaces

- The ability to virtualize devices

- The ability to incorporate new devices into the GENI management mechanisms

• Living in the future - GENI is supposed to be a tolerably realistic emulation of a networking

technology base 10 years in the future

1.9 Striking a Balance• What makes GENI a unique and compelling instrument is

how it balances requirements to support research that

simply cannot be done today - Resolving conflicts among requirements (ex. Sliceability vs Fidelity)

- Recognizing the specific combination of capabilities that are unique to GENI

(1) wide-spread deployment

(2) a diverse and extensible collection of network technologies

(3) support for real user traffic

2. Relate Work

2.1 PlanetLab & VINI• PlanetLab - PlanetLab is a global overlay network for developing and accessing broad-

coverage network services [Chun 03]

- PlanetLab allows multiple services to run concurrently and continuously, each in

its own slice of PlanetLab [Chun 03]

* Slice: A horizontal cut of global resources [Chun 03]

The substrate resources bound to a particular experiment [Clark 07]

• Virtual Network Infrastructure (VINI) - VINI is a virtual network infrastructure that allows network researchers to

evaluate their protocols and services in a realistic environment that also

provides a high degree of control over network conditions.

- PL-VINI is a prototype of a VINI that runs on the public PlanetLab. PL-VINI

enables arbitrary virtual networks, consisting of software routers connected by

tunnels, to be configured within a PlanetLab slice.

2.2 UCLP & APN• User Controlled LightPath (UCLPv2) - UCLP is a network virtualization management tool built using web services

[Lemay 06]

ex) XC-WS(Cross Connect Web Service) for SONET, SDH and Lambda Cross

Connects

- Users can create several parallel application specific networks from a single

physical network through UCLP [Lemay 06]

• Articulated Private Network (APN)

- An aggregate mix of resources [St.Arnaud 07]

2.3 Relation among PlanetLab, VINI and UCLP

<Current Relation> <Target Relation>