Inter-Domain Network Provisioning Technology for LHC data transfer Jeonghoon Moon (jhmoon@kisti.re.kr) KISTI 2013.02.26 Inter-Domain Network Provisioning Technology for LHC data transfer

Contents Outline Automated-GOLE project Network Service Interface (NSI) Current Status Summary

Outline Purpose of this presentation is to support large scale data transferring of HEP by GLIF Automated GOLE facility and Network Resource Management System based on Network Service Interface Connection Protocol Outline: GLIF Automated GOLE Pilot Project: What is it? how does it work? 2013 Goals for GOLEs Network Service Interface: What is it? how does it work? How can support transferring

The Automated GOLE Fabric USLHCnet PSNC JGN-X MANLAN NetherLight Cern UvA CzechLight KRLight AIST KDDI Labs StarLight ESnet Cal Tech GLORIAD GEANT ACE Nordunet The GLIF Automated GOLE Pilot Project was initiated in 2010 to provide a global fabric of Open Lightpath Exchanges for the express purpose of maturing dynamic provisioning software, demonstrating the value of GOLEs to emerging network service models, and to develop a set of BCP for these services.

What is the AG “Fabric”? The Automated GOLE fabric includes many facilities: Exchange Points (& “distributed” facilities) Inter-exchange transport links Networks GOLEs link networks together … Organizations that are willing to contribute people, facilities, hdw/sfw, etc. Users/applications entities Etc.

NSI CS (Connection Service) NSI is a consensus framework for defining a set of globally adopted services/protocols that will [ultimately] allow guaranteed performance services (Connection Services) to be ubiquitously available, extensible, secure, and fully automated. NSI Connection Service Protocol “NSI-CS” is the first protocol within the NSI framework. A simple set of messages between a “Requesting Agent” and a “Provider Agent” that manage a Connection through its life cycle A “Connection” A logical path between two endpoints over which user data is carried, unmodified, from ingress to egress. (Note: says nothing about the technology used to realize the service instance.)

NSI is being standardized within the Open Grid Forum (OGF) The NSI Connection Service Protocol v2.0 finalized To get a information v3.0 requirements Korea status – dynamicKL Based on NSI v2.0 Deploy for domestic service and test international connection at 2013

A Basic Overview: Requesting Agent (RA) Network Resource Manager Provider Agent (PA) NRM Network Services Interface NSA Network Services Agent (NSA) NSI “Network Service” Application NSA NSI protocol A B C Domain A Domain B Domain C

Network Service Agents An “ultimate Requesting Agent” (uRA) the agent that originated the Connection request issues CS primitive request - but does not accept primitive requests Applications are typically uRAs A “ultimate Provider Agent” (uPA) the leaf provider agent – the agent that interfaces to the NRM in a particular domain. An “aggregator agent” An Aggregator agent is capable of inter-domain topology analysis and path selection (it can process and understands global [N3] topology) Aggregators do path segmentation and “aggregate” the state of children Connection segments to present a single view back up to the RA. A “provider only” agent Accepts service requests, but does not issue service requests Does not (cannot) do inter-domain path finding - can only service requests that are completely in the local domain. uPAs are typically local NRMs with a simple NSI-protocol-to- local-command translational interface. Application NSA RA Aggregator NSA PA RA A RA PA PA Aruba Bonaire Curacao

CS Primitives and life cycle Basic CS Primitives Reserve, Provision, Release, Query, Terminate Message communication always between with RA(Request Agent) and PA(Provide Agent) Other messages Detail Query, Notify, Modify Lifecycle

How NSI-CS Works…. The user application

NSI Request Segmentation Chain model Tree model A 6 uRA PA PA PA 1 2 3 1 3 5 A B C D 2 4 6 5 4 B C D A Z A Z M 3rd party request 3 4 5 6 1 2 A B C D 7 8 Chain model Tree model 1 6 2 4 B C D 3 5 A Z

NSI Implementations Network Service Agent (NSA) packages: OSCARS: http://code.google.com/p/oscars-idc Developed by Esnet, deployed by Esnet, Internet2, other networks and on several GOLES, AutoBAHN: ffi: Radek Krzywania <radek.krzywania@man.poznan.pl> Developed by GEANT Consortium, deployed within/across GEANT OpenNSA: http://git.nordu.net/?p=opennsa.git;a=summary Developed by NORDUnet, deployed (experimentally) in NORDUnet, UvA, StarLight, GLORIAD, others OpenDRAC: ffi: John MacAuley <john.macauley@surfnet.nl> Devloped by NORTEL/Ciena and now SURFnet, deployed in NetherLight G-LAMBDA-A ffi: Tomohiro Kudoh <t.kudoh@aist.go.jp> Developed by AIST in Japan contact: Tomohiro Kudoh G-LAMBDA-K ffi: Takahiro Miyamoto <tk-miyamoto@kddilabs.jp> Developed by KDDI Labs, deployed experimentally in JGNX DynamicKL: ffi: Jeonghoon Moon <otello90@gmail.com> Developed by KISTI (Daejeon, KR) deployed in KreoLight GOLE (exp) All of these have at least one node in the Automated GOLE So you can test against any/all of them

The NSI + A-GOLE Demo at SC2012 A Supercomputing 2012 demonstrations: Global inter-domain network capacity provisioning using the Network Service Interface protocols and the emerging Global Open Lightpath Exchange fabric NSIv2.0 deploy and control/data plane demo

Monitoring & Visualization NSA Client RA 4 6 QA VZ 1 3 NSA Aggregator A 5 2 NSA PA Reservation Request Segmentation of Reservation to children Reservation confirmed ConnectionID registered with Query Agent Query Agent walks tree to discover Path and Polls for state (10 sec interval) Path and state info returned to vizualization app. Viz app renders realtime image

Monitoring & Visualization “Automated Earth” viz (Takatoshi Ikeda, KDDI-Labs) “Status Monitor” viz (Tomohiro Kudoh, AIST)

Current Status NSI as a standard and framework is still evolving NSI CS version 2 is being drafted and demo’d.. NSI should plan strategically with a long view Incremental and iterative improvement NSI v3 requirements/objectives gathering will commence in spring 2013…ETA 2014Q2(?) Dynamic Topology Distribution Service (TS) Improved message distribution (NSA-to-NSA comms, FW/NATs,..) Improved state processing (SM exploded with Modify()) Items missing yet to be developed: Better path planning implementations (aggregators, path finders, topology analysis) Better operational control tools (NOC tools) Automated connection performance verification techniques Automated fault processing Logging and Accounting Training and educational workshops (!) Security/AA policy – Security and privacy guards must be integral

Summary Global NSI deployment @2013 KREONET NSI deploy Support HEP large scale data transfer Also support distributed large scale data transfer areas (Bio, eVLBI…) Medical data transfer and education KREONET NSI deploy dynamicKL : begin to support domestic area and a few international connection service Remaining issues Last mile problem : Different last mile solutions (VLAN, dedicated fiber to router, OpenFlow, TRILL, SPB(802.1aq) Dynamic Distributed Topology Exchange NSI Performance Verification Common Service Definition Firewall, NAT issues Etc… Webportal

Thank you !