research on networks presentation at surfnet, november 8th 2010
DESCRIPTION
TRANSCRIPT
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!