FIBRE-BR MeetingGENI I&M

Marcelo Pinheiro

Agenda

• GENI Overview• GENI User groups• GENI I&M Use Cases• GENI I&M Services

GENI Overview

• Run experiment (repeatability, realistics environment, virtualized management interfaces)

• Credentials management (Authentication, Authorization and Accountability)• Privileges and roles definition

• Integrity control among all aggregates (in case of crash/restart)

GENI Overview

• Federation support & Trust relationship• Inter-aggregate monitoring

• Experiment monitoring in order to avoid infrastructure misusage• Debug facility (Operation and User level)

• Status monitoring• Policy Management (i.e., cannot reserve more than 40% of any aggregate)

Type of users

• Experimenters: Users that run Internet-scale experiments in slices comprising of multiple GENI resources to address research problems of the future-Internet.

• Opt-In Users: Users within the GENI suite or general Internet users who participate or “opt-in” to a GENI experiment to utilize resources, applications or services that are hosted within the GENI experiment.

• Central (i.e., GMOC) Operators: Group that monitors the GENI facility resources and processes in order to bring consistency, reliability and repeatability to GENI’s federated infrastructure.

Type of Users (II)

• Aggregate Providers and Operators: Groups that provide a set of network or computing components to GENI experiments along with software to manage the components, and allow users to check the availability and status of the various components.

• Archive Providers and Operators: Groups that catalog indexes of GENI-related measurement datasets in a repository and provide tools for users to share, annotate, search and cite the measurement datasets.

• Researchers that use Archived Measurement Data: Users that utilize the measurement datasets provided by Archive Providers in order to test hypotheses, and promote reproducible research.

Experimenters

• Make sure all resources are reserved accordingly “Are all the resources with the performance expectations that were specified in the RSpec? For example: 2 Mbps available bandwidth connection between Nodes A and B, run a 2 Mbps UDP Iperf test so that I can check there is no packet loss.”

• Provide a dashboard of resource performance measurements as the experiments are run (real-time).

• Allow to query the status of user slice resources

Experimenters (II)

• Allow to setup up TCPdump passive measurement taps

• Allow to setup Netflow measurements collection

• Allow to setup vendor-specific measurements collection

• Allow to Setup up active measurement capabilities on paths x, y, z using p, q, r tools

Experimenters (III)• Allow to Setup one-way delay active

measurements • Notify anomalies and forecasts of system and

network performance at hops a, b, c on paths x, y, z pertaining to tools p, q, r

• Provide an archive of some or all of the slice resource performance measurements

• Provide an archive of the slice resource performance measurements

Experimenters (IV)

• Generic “I am running an experiment to deploy a novel IPTV system protocol, provide me with PSNR measurements of video quality between paths x, y, z (e.g., Evalvid tool that will need source and destination packet captures)”

• Provide access to the experimenter opt-in users who want to query measurement data within the experiment slice using web-service clients

• Provide mechanisms to share slice measurements archive with researchers and opt-in users at different levels of permissions sharing (i.e., whitelist/blacklist, sign-in, public)

Opt-In Users

• Provide the end-to-end delay and loss characteristics of the network paths

• Show whether the Opt-in user got all the resources (e.g., CPU, Memory, Disk space) with the performance expectations

• Allow the Opt-In user to query the latest status of his/her application resources so that he/she can know the reason for the poor performance

Central Operators

• Setup vendor-specific measurements collection

• Setup up active measurement capabilities on paths x, y, z using p, q, r tools

• Provide capabilities for looking at the measurements being collected via a weathermap interface (Flack)

• Provide an archive of some or all of the slice resource performance measurements

Central Operators

• Monitor slice behavior (Clearinghouse)• Notify status of user slice resources via a dashboard

with some or all of the resource performance measurements in the user slice;

• Keep meta-data of all the experiments• Setup Netflow measurements collection

Aggregate Providers and Operators

• Have an authentication mechanism based on the privileges assigned to the different user roles (Clearinghouse)

• Monitor the slice behavior • Notify status of the user slice resources via a

dashboard • Keep meta-data of all the running/expired

experiments • Setup Netflow measurements collection

Aggregate Providers and Operators

• Setup vendor-specific measurements collection• Setup up active measurement capabilities on

paths x, y, z using p, q, r tools • Provide capabilities for looking at the

measurements being collected via a weathermap interface (Flack)

• Provide an archive of some or all of the slice resource performance measurements

Archive Providers and Operators

• Publish measurement archives with suitable keywords• Have an authentication mechanism based on privileges• Provide policies relating to the measurement archive

sharing permissions (i.e., whitelist/blacklist, sign-in, public)

• Allow users to use tools and transformation libraries that deal with various data formats to: share, annotate, search and cite the measurement datasets in my repositories

• Contribute various tools that will allow researchers using the archived measurement data to analyze and visualize their corresponding published data sets more effectively

Researchers that use Archived Measurement Data

• Search results and access to measurement archives published by the experiment researchers, aggregate providers and GMOC

• Share (e.g., email, post on Twitter), annotate, search and cite the measurement datasets in repositories of several Archive Providers

Types of I&M Services

• Type 1: Service contained within a slice.• Type 2: Common service platform plus

multiple slivers dedicated to multiple experiments.

• Type 3: Common service with shared data provided to multiple experiments.

• Type 4: MDA service with a portal for sharing data

I&M Services – Type 1

• A Type 1 I&M service is completely contained within a slice, where the slice is owned and managed by an Experimenter to instrument and measure an experiment, or by a Service Provider or an Operator to instrument and measure GENI infrastructure.

I&M Services – Type 2

• Includes a common service platform that is assembled, configured and managed by a Service Provider plus multiple slivers that are acquired, configured and managed by multiple slice owners, e.g., Experimenters and/or Operators.

I&M Services – Type 3

• Includes a common service that is assembled, configured and managed by a Service Provider and that provides measurement data to multiple slices, e.g., those owned by Experimenters and/or Operators.

I&M Services – Type 4

• It is a Measurement Data Archive (MDA) service that is assembled, configured and managed by a Service Provider and that archives data for multiple slices, e.g., those owned by Experimenters and/or Operators. The MDA service includes a portal that allows a Slice Owner to access their MD and share it with others.

Pergunta (provocativa)

• Devemos e/ou podemos ter serviços de configuração de experimentos customizados (genéricos) pelos experimentadores no I&M (mesmo que seja num planejamento mais longo que o FIBRE)?