Interoperability of Lightpath Provisioning Systems in a Multi-domain Testbed

Fred Wan

Paola Grosso

Cees de Laat

University of Amsterdam

System and Network Engineering research group

Overview

• Background

– E-science and dynamic resource allocation and provisioning

– GLIF, NRENs and GOLEs

– Lightpaths/deterministic paths

– Network Resource Provisioning Systems (NRPSs)

• Network service- and control-planes

– General NRPS architecture

– Multi-domain NRPSs: Chain versus Tree model

– Harmony, Fenius, IDC

– Interoperability requirements

– Automated GOLE pilot, Fenius

– SC10 demo

• Conclusions and future work

Dynamic Resource Allocation and Provisioning

• National Research and Education Networks (NRENs) facilitate data transport between

– compute resources

– scientific instruments

– data-storage

– distributed measurement equipment

• Dynamic resource allocation: The network as a dynamic resource

• Efforts to combine international e-science resources:

– EU projects Phosphorus (finished), Geysers (current), FEDERICA, Panlab, FIRE, etc.

– US projects, e.g. GENI

• Problem: how to combine, allocate and control the inter-NREN network?

• Current status: manually by NREN NOCs

• Goal: automate request processing for network connections (advance reservation and provisioning)

GLIF and GOLEs

• Global Lambda Integrated Facility

• Virtual international organization promoting paradigm of lambda networking

• Collaborative initiative among worldwide NRENs, consortia and institutions

• World-scale Lambda based Laboratory to facilitate application and middleware development

• GOLE – GLIF Open Lightpath Exchange

– Peering point for lightpaths

– Global model: MANLAN, NetherLight, UKLight, Starlight, NorthernLight, …

• Open anyone can bring lambdas

– Lambda owner controls port

– GOLE owner makes cross connects happen

– Limitations only in technology

GLIF: Global Lambda Integrated Facility

http://www.glif.is

GLIF Europe

Global Open Lightpath Exchanges (GOLEs):

NetherLight

NorthernLight

CERNLight

Netherlight GOLE: Global Open Lightpath Exchange

Connection requirements and Control

• Overprovisioning best-effort networks does not work

• Requirements:

– deterministic bandwidth

– point to point connection

– capacity and timeliness guarantees when transferring large chunks asynchronously

– Bandwidth guarantees and jitter-free transport when transferring synchronously

• Available technologies: GMPLS, WDM, TDM (layer 1) and PBT (layer 2)

• TDM: provision a number of VC-4 (or other capacity) channels by creating cross connects on the switches comprising the path

• Configuration: CLI, TL1, SNMP

• Integrate NEs into workflow: Network Resource Provisioning Systems (NRPSs) so lightpaths can be reserved in advance

• General design abstracted from various implementations

General inter-domain NSP design and implementations

IDC Internet2, ESnet

Single-domain NRPSs:

Multi-domain NSP: OSCARS & DRAGON (IDC)

Inter-domain path reservation and provisioning: Two models

• Federated model: uniform request interface, topology exchange and event notification among peers

Inte

rop

era

bility

laye

r

Network Service Plane

Adapter

ARGON driver UCLP driver DRAC driver

Topology

Service

Path

Computer

Grid

Middleware

Database

NRPS Manager

Reservation

service

Topology

client

Reservation service client

Adapter

Reservation

service

Topology

client

Adapter

Reservation

service

Topology

client

ARGON domain UCLP domain DRAC domain

Topology information

Resource reservations

Reservation service interface

Topology service interface

Legend: East / West interfaces

----------------------------------------------------------

Request for end-to-end resource

provisioning

NRPS address information

Reservation WS:

• Availability Request

• Create Reservation Request

• Query Reservation(s) Request

• Activate Reservation Request

• Cancel Reservation Request

• Status Request

Topology WS:

• Add domain

• Delete domain

• Edit domain

• Retrieve domain

• Add Endpoints

• Delete Endpoint

• Edit Endpoints

• Retrieve Endpoints

• Add Link

• Delete Link

• Edit Link

• Retrieve Link

Centralized model: unification of request interface through an adaptation layer, overlay topology and central event management

Automated GOLE pilot

• 16 Networks/GOLEs

• NRPSs: IDC, ARGIA, DRAC, G-Lambda, AutoBAHN

• Central controller: Fenius

• Fenius: simpler version of Harmony

SC09 setup (UvA view)

• Dynamic lightpath provisioning between GOLEs/Networks

• Each domain: perfSONAR deployed

• Demo: light turns green when connections are made

Pinger matrix

Example Scenario: UvA-StarLight

• Fenius translator on each domain

• Super-Agent:

– central request handler,

– inter-domain path-finder

– messaging to translators

• Domain-NRPSs handle path-setup

• Translators can be queried

Endpoints involved in the UvA-StarLight path

Starlight starlight:arista-sl:1/13 to USLHCNet / NetherLight USLHCNet & NetherLight

Starlight starlight:arista-sl:1/14 to JGN2 JGN2

Starlight starlight:arista-sl:1/24 StarLight PerfSONAR StarLight PerfSONAR

UvALight urn:ogf:network:domain=uvalight.net:node=geller:port=s8p4:link=geller_8630_GBR_s8p4 geller_8630_GBR_s8p4 netherlight.net:f25s1t:0-5:UvA

UvALight urn:ogf:network:domain=uvalight.net:node=geller:port=s8p5:link=geller_8630_GBR_s8p5 geller_8630_GBR_s8p5 netherlight.net:f25s1t:0-6:UvA

UvALight urn:ogf:network:domain=uvalight.net:node=sweggb2:port=g2:link=sweggb2_RJ-45_g2 NetherLight-UvALight VM_fooyoung (perfSONAR)

NetherLight netherlight.net:f25s1t:0-5:UvA Force10_Ge0/5 (to UvALight) UvA : geller_8630_GBR_s8p4

NetherLight netherlight.net:f25s1t:0-6:UvA Force10_Ge0/6 (to UvALight) UvA : geller_8630_GBR_s8p5

NetherLight netherlight.net:f25s1t:0-7:StarLight To StarLight StarLight

Conclusions and future work

• Interoperability between heterogeneous Network Resource Provisioning Systems is possible

• An hierarchical model is easiest to realize for heterogeneous NRPSs (lesson learned from Harmony)

• A federated model is more flexible (design changes in the interface apply to all instances), has enhanced interoperability and scalability

• We have show that mixing the two models is possible, but leads to a lot of ad-hoc solutions

• Ideal solution is a standardized Network Service Interface: work underway in the OGF-NSI working group. However: slow progress

• Future work:

– Investigate automation of GOLES: OGF automated-GOLE WG

– Improve the design and application of the current prevalent hierarchical design component: Fenius

– Investigate if an IDC service interface can be designed to improve integration with DRAC

Questions?

Thank you!