Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Section
Column
width40%
Panel
bgColorwhite
titleColorwhite
titleBGColordarkblue
titleAutoGOLE MEICAN Pilot
Panel
bgColorwhite
titleColordarkblue
titleBGColorlightblue
titlePilot Proposal

Run a pilot of the RNP's Cipó Service front-end interface – the MEICAN– being used by
participant research and education networks (RENs) and exchange point (IXP) operators
to configure multidomain point to point circuits. The participants will evaluate the MEICAN
as the main interface for AutoGOLE GLIF Project.

Panel
bgColorwhite
titleColordarkblue
titleBGColorlightblue
titleParticipants
Research and Education Networks and Exchange PointsContacts

1. Cenic / Pacific Wave

John Hess

2. NetherLight

Hans Trompert
3. RNP (Cipó)Alex Moura
Marcos Schwarz
4. SouthernLight (SOL)Alex Moura
Marcos Schwarz
5. StarLight (Northwestern University)Jim Chen
6. SURFnetGerben van Malenstein
Panel
bgColorwhite
titleColordarkblue
titleBGColorlightblue
titleSuggestions

As a guideline for experimenting MEICANwe propose that each participant evaluates
the list of features below:

  • Circuit Management
  • Topology Visualization
  • Bug reports
  • Suggestions

Other interesting features

  • Approval Workflow
  • Automated Tests
  • Monitoring (Beta)
Panel
bgColorwhite
titleColordarkblue
titleBGColorlightblue
titleDocumentation
Panel
titleABOUT AUTOMATED GOLE PROJECT

The GLIF “Automated GOLE Pilot” Project

The Global Lambda Integrated Facility (GLIF) is a cooperation between NRENs and research institutes with a twofold goal: to create a forum for engineers and researchers to exchange experiences, and to cooperate to make lambdas available for researchers and projects involved in data-intensive research.

In order to make global optical networking possible, GLIF exchange points have been created where long connections can be linked together to create multi-domain lightpaths. These exchange points typically connect users on layers below L2. In order to clarify the policy applied at exchange points, the concept of a GLIF Open Lightpath Exchange (GOLE) has been defined. This mandates that GOLEs treat everyone the same, and be open about any policy that may be applied [GOLE].

Since the start of GLIF, inter-domain lightpath provisioning has involved much manual processing and actions, since each actor has to play an active role in the process of creating the lightpath, ranging from approving the request to changing the configuration of the network to accommodate the request. Often these are distributed over several time zones, which means that a lightpath request can take about two weeks to be implemented. Based on the Network Services Interface [NSI], the Automated GOLE testbed created by thirteen GOLEs with different implementations of the NSI Connection Service has made it possible for lightpaths to be created and destroyed within seconds. The early experiments with the Automated GOLE testbed have also helped to improve the NSI Connection Service version 2, which is now submitted as a draft standard. 

Ref.: https://geant3plus.archive.geant.net/Resources/White_Papers/Documents/MS101_MJ1-2-1_Network-Architectures-for-Cloud-Services.pdf, Page 17

Column
Panel
bgColorwhite
titleColorwhite
titleBGColordarkblue
titleDocumentation and Contacts
Panel
bgColor#FFFFFF
titleColordarkblue
titleBGColorlightblue
titlePilot Results
  • Pilot Report
  • WRNP'17 SURFnet Talk about the MEICAN Pilot

Widget Connector
urlhttps://www.youtube.com/watch?v=qHRPEUrQpuM
PDF
nameMEICAN.pdf


Panel
bgColorwhite
titleColordarkblue
titleBGColorlightblue
titleDocumentation
Panel
bgColorwhite
titleColordarkblue
titleBGColorlightblue
titleLinks
Panel
bgColorwhite
titleColordarkblue
titleBGColorlightblue
titleAutoGOLE Contacts
Panel
bgColorwhite
titleColordarkblue
titleBGColorlightblue
titleBasic initial tests

Try to create a circuit reservation and testcommuncationbetween endpoints using hosts

  1. Create a basic circuit reservation
  2.  Try to create circuit between hosts (from the list of available hosts)
  3. Try communication between hosts (ping etc)
Panel
bgColorwhite
titleColordarkblue
titleBGColorlightblue
titleDevelopment Efforts
  •  

    1) Parser update (priority: low) (complexity: low)

    Expand

    Review of the URN parsing for NMWG format to consider the URN unified parser and support ESnet intradomain topology format.

    Support for extracting geographic coordinates from topology file as example from ESnet.

    Support for extracting bandwidth information from topology file as example from ESnet.

  •  

    2) Reservation (priority: low) (complexity: low)

    Expand

    Support reservation requests for Zero Bandwidth (low)

    Support reservation with Undefined Start time (medium)

    Support reservation with Undefined End time (medium)

    Support reservation with the Protection tag (RNP will ask ESnet to implement the Protection tag support on the OSCARS NSI Bridge (medium)

  •  

    3) STP representation review (priority: medium) (complexity: high)

    Expand

    MEICAN inherited the STP interpretation from OSCARS where the URN of an STP encodes the domain/network, device and port. This logic is not applicable to the NSI URN representation, which is only officially compose of two informations only: network-id and local-id. Consider the definition at [4].

    It is necessary a new STP representation internally at MEICAN that doesn't break the NSI specification and is compatible with other domains not based on OSCARS.

    An initial proposal is to merge the current representation for device and port to a single entity called local-id.

    The representation of this new entity on the map visualization can be done initially as follows:

    1. All STPs from a given network that have the same coordinate should be plotted on a single point in the map. And should be labeled with the longest unique prefix match.

    2. All STPs from a given network that don't have coordinates should be plotted as a single point in the map. Using the Network coordinate and label.

    3. In the reservation form merge the device and port fields into a single local-id or STP field. Defining a more intuitive name is recommended.

    4. An additional possibility for this proposal is to provide a custom parser configuration for the domain, to allow.

  •  

    3.b) STP representation temporary fix (priority: high) (complexity: medium)

    Expand

    Since 3) is considered too complex, a temporary fix will be to develope a feature to disable the device parsing on a domain (as in OpenNSA domains) and use the local-id part of the URN as port and use the network for device.

  •  

    4) User management (priority: medium) (complexity: medium/high)

    Expand

    Better  user management scalability, through the ability of a domain administrator to add new users to that given domain, or to add/remove permission to it's domain to existing users. Suggestions?

  •  

    5) NSI Authentication and Authorization compliance (priority: high) (complexity: medium)

    Expand

    SURFnet implements authentication using Oauth2, but meican currently doesn't provide a way to input the authentication token. The Autentication and Authorizatoin in NSI procotol is documentated in the following file: draft-gwdi-trompert-nsi_aa-public-comment-v7.pdf