FIBRE-BR Meeting GENI I&M

1. FIBRE-BR MeetingGENI I&M Marcelo Pinheiro

2. Agenda • GENI Overview • GENI Usergroups • GENI I&M Use Cases • GENI I&M Services

3. GENI Overview • Runexperiment (repeatability, realisticsenvironment, virtualized management interfaces) • Credentials management (Authentication, AuthorizationandAccountability) • Privilegesand roles definition • Integritycontrolamongallaggregates (in case of crash/restart)

4. GENI Overview • Federationsupport & Trustrelationship • Inter-aggregatemonitoring • Experimentmonitoring in order to avoidinfrastructuremisusage • Debug facility (OperationandUserlevel) • Status monitoring • Policy Management (i.e., cannot reserve more than 40% ofanyaggregate)

5. Typeofusers • 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.

6. TypeofUsers (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.

7. 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

8. 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

9. 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

10. 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)

11. Opt-InUsers • 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

12. 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

13. 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

14. 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

15. 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

16. ArchiveProvidersandOperators • 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

17. 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

18. Typesof 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

19. 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.

20. 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.

21. 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.

22. 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.

23. 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)?