230 likes | 328 Vues
Explore the integration and interoperability of Network Resource Provisioning Systems (NRPSs) in a multi-domain testbed, focusing on dynamic resource allocation and provisioning across NRENs. Discover how GLIF and GOLEs facilitate global lambda networking and efficient connection requirements. Learn about the Harmony, IDC, and Phosphorus projects for seamless cross-domain path reservation and provisioning.
E N D
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 in collaboration with SURFnet
Overview • Background • E-science and dynamic resource allocation and provisioning • NRENs • Lightpaths/deterministic paths • Network Resource Provisioning Systems (NRPSs) • Harmony and IDC • Phosphorus project: Harmony Network-Service Plane • Dante/Internet2/Canarie/ESnet IDC • Network service- and control-planes • General NRPS architecture • Interoperability requirements • Harmony-IDC interoperability (detailed) • 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
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 Single-domain NRPSs: IDC (Internet2) Multi-domain NSP: OSCARS & DRAGON (IDC)
Inter-domain path reservation and provisioning:Two models • Centralized model: unification of request interface through an adaptation layer, overlay topology and central event management • Federated model: uniform request interface, topology exchange and event notification among peers
Harmony: Phorphorus NSP centralized approach • 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
Topology translation Viola-Internet2 reservation request Web GUI request ->(10.7.11.8, 10.9.2.3) -> Harmony NSP Harmony NSP -> (10.7.11.8, 10.7.12.106) -> VIOLA (ARGON) Harmony NSP -> (10.7.2.6, 10.7.3.2) -> VIOLA (ARGON) Harmony NSP -> (10.9.2.1, 10.9.2.3) -> Internet2 Gateway Internet2 Gateway -> (urn:ogf:network:domain=uvalight.net:node=SURFnet-OME4T_VIOLA:port=s1p3:link=10.9.2.1, urn:ogf:network:domain=dcn.internet2.edu:node=LOSA:port=S27135:link=10.100.100.9) -> UvA IDC UvA IDC -> (urn:ogf:network:domain=uvalight.net:node=SURFnetOME4T_I2:port=s10p1:link=10.9.2.3, urn:ogf:network:domain=dcn.internet2.edu:node=LOSA:port=S27135:link=10.100.100.9) -> Internet2 IDC
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