1. Supporting Advanced Scientific Computing Research Basic Energy Sciences Biological and Environmental Research Fusion Energy Sciences High Energy Physics Nuclear Physics OSCARS Architecture Overview April 2012 ESnet OSCARS Development Team Energy Sciences Network (ESnet) Lawrence Berkeley National Laboratory

2. OSCARS 0.6 Design / Implementation Goals Support production deployment of service, and facilitate research collaborations Distinct functions in stand-alone modules Supports distributed model Facilitates module redundancy Formalize (internal) interface between modules Facilitates module plug-ins from collaborative work (e.g. PCE) Customization of modules based on deployment needs (e.g. AuthN, AuthZ, PSS) Standardize external API messages and control access Facilitates inter-operability with other dynamic VC services (e.g. Nortel DRAC, GÉANT AuthBAHN) Supports backward compatibility of IDC protocol

3. OSCARS 0.6 Architecture Notification Bridge Forward Notifications AuthN Authentication Resource Manager Manage Reservations Auditing Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Path Setup Network Element Interface Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 3

4. OSCARS 0.6 Module APIs

5. Notification Broker Module API Notification Bridge Forward Notifications AuthN Authentication Resource Manager Manage Reservations Auditing Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Path Setup Network Element Interface Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 5

6. External API (Notification Broker) Push interface for event notification Contacts external notification services: –Sends emails to user or administrators –Sends messages to “wsnbroker”, a component that implements WS-Notification and allows people to subscribe to topics of events.

7. Internal API (Notification Broker) Coordinator sends notify messages as events occur Notify messages NOT used between OSCARS modules

8. Lookup Module API Notification Bridge Forward Notifications AuthN Authentication Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 8 Resource Manager Manage Reservations Auditing Path Setup Network Element Interface

9. Internal API (Lookup) Find location of services (i.e. IDC services) that control a particular domain Register location of externally facing services

10. Topology Bridge Module API Notification Bridge Forward Notifications AuthN Authentication Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 10 Resource Manager Manage Reservations Auditing Path Setup Network Element Interface

11. Overview (Topology Bridge) An abstraction of topology storage API is trivial: getTopology() Two implementations: –“bridge” to PerfSONAR topology server –Local storage at a static file

12. AuthN Module API Notification Bridge Forward Notifications AuthN Authentication Path Setup Network Element Interface Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Resource Manager Manage Reservations Auditing Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 12

13. Overview (AuthN) AuthNService takes a validated identity token and returns attributes for the users Modeled on a Shibboleth or VOMS IDP and returns attributes of the identity (could be easily replaced by a shim to other IDPs) ID token is either –x.509 DistinguishedName (DN) –Previously registered login name and password AuthNPolicy* manages user and institution tables *Resides in AuthN module but run as a separate service

14. Internal API (AuthN) VerifyDN is called by the IDC API (v0.5 and 0.6), and passes the user attributes* to all its calls in the Coordinator VerifyLogin is called by the WBUI, and passes on the user attributes* to all its calls to other modules *User attributes are SAML 2 AttributeTypes which contain a name and a value. The login name of the user and his/her institution are always included in the attribute list

15. AuthZ Module API Notification Bridge Forward Notifications AuthN Authentication Path Setup Network Element Interface Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Resource Manager Manage Reservations Auditing Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 15

16. Overview (AuthZ) AuthZ takes a list of user attributes, a resource and a requested action and returns an AuthorizationDecision which may be DENIED, ALLUSERS, SELFONLY, SITEONLY and a list of Auth Conditions consisting of name, values pairs AuthConditons –permittedLoginId/loginName, –permittedDomains/.institutionName, –internatlHopsAllowed/true AuthZPolicy manages permissions, actions and attributes

17. Internal API (AuthZ) CheckAccess is called by the Coordinator, which will reject a request if permission is DENIED or will pass the AuthCondition on to calls to the Resource Manager which will base its decision on the specific reservation that is being accessed Setup and teardown calls to the PSS it checks verifies the owner or site of the reservation if there is a permitttedLogin or permittedDomains condition Calls to the PCEs are permitted as regardless of any AuthConditions MutliCheckAccess is called by the WBUI in order to know what functions to make available to a user

18. Coordinator Module API Notification Bridge Forward Notifications AuthN Authentication Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 18 Resource Manager Manage Reservations Auditing Path Setup Network Element Interface

19. Coordinator API (Coordinator) Provided to modules such as the API, WebUI, and PSS SOAP based, Java bindings provided Matches the IDC API: same datatypes, without security with a list of user attributes Does not implement protocol adaptation: this is an internal, intra-domain API Last but not least: implements the coordination of the IDC protocol

20. IDC Protocol Coordination API (Coordinator) Create Reservations (provides end points, Virtual Circuit requested constraints) Modify/Delete Reservations Query/Monitor Reservations Handles request from both clients and inter-domain messages Issues messages to other domains via the API module

21. Intra-Domain API (Coordinator) Provided to modules such as the PSS and Resource Manager Implements service level tasks such as path setup, teardown. Each request, IDC protocol, or service level task consist of coordinated exchange of messages to other modules.

22. PCE Module API Notification Bridge Forward Notifications AuthN Authentication Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 22 Resource Manager Manage Reservations Auditing Path Setup Network Element Interface

23. Semi-Public PCE API (PCE) Provided to the modules implementing intra-domain path computation SOAP based, Java bindings provided Implements the tree of PCE’s used to resolve a path. Implements flow of messages between PCE’s in an enforced asynchronous model Translate path into topologies and vice-versa Implemented within the Coordinator for performance reason, but could be separated Provides hook for co-scheduling

24. Fine Grain API (PCE) PCE stands for Topology Computation Element and for the sake of consistency, a topology is called “a path” Allows for roles in the overall topology computation and resource reservation. Currently support Path Aggregation and Path Computation Compute paths with constraints and temporary reserve intra-domain resources for them Reserve intra-domain resources for scheduled paths Modify/Delete resources for existing reserved paths

25. Packaged API (PCE) Standalone library is provided for independent PCE developer Java packaging is provided in the form of a JAR file containing all classes and packages that are required to run a PCE module (Python and Perl bindings are possible) Packaged IDC simulator used for testing PCE development, or experiment offline on topologies

26. Resource Manager Module API Notification Bridge Forward Notifications AuthN Authentication Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 26 Path Setup Network Element Interface Resource Manager Manage Reservations Auditing

27. Internal API (Resource Manager) Provided to modules such as Coordinator and PCE SOAP based, Java bindings provided Implements the persistent, source of truth for the state and set of intra-domain resources for all reservation (GRI) Authorization Final Authority Transparently uses backend database (mySQL) Contains scheduler that detects circuit setup/teardown time and notifies PSS via the coordinator

28. Resource API (Resource Manager) Store/Load/Modify domain, user, path resources used by other modules. Synchronous API: resources are modified or committed upon completion of the call. Create GRI resources Query the database for resources

29. Path Setup Module API Notification Bridge Forward Notifications AuthN Authentication Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 29 Resource Manager Manage Reservations Auditing Path Setup Network Element Interface

30. Overview (Path Setup) Talks to network devices Is called by the Coordinator on demand – does not have an internal schedule Fully asynchronous - when a task is done, PSS notifies Coordinator with a callback.

31. API (Path Setup) Operations supported: –setup, teardown, status, modify All calls have as argument a complete OSCARS reservation object. Possibility for standardization here!

32. Framework (Path Setup) An ad-hoc internal Java API and workflow engine for PSS “agents” Different agent interfaces for different tasks (i.e. SetupAgent, StatusAgent etc) A WorkflowAgent receives tasks from Coordinator, then choreographs the other agents according to desired logic Sample implementation: FifoWF

33. IDC API Module API Notification Bridge Forward Notifications AuthN Authentication Coordinator Workflow Coordinator PCE Constrained Path Computations Topology Bridge Topology Information Management IDC API Manages External WS Communications Lookup Lookup service AuthZ* Authorization Costing *Distinct Data and Control Plane Functions Web Browser User Interface 33 Resource Manager Manage Reservations Auditing Path Setup Network Element Interface

34. Overview (IDC API) Implements the public IDC API: –Provides SOAP-XML API to client application –Provides API to other domains –Provides hooks for the IDC built-in Web UI –Provides IDC protocol backward compatibility NB: 0.6 protocol and API is changed from 0.5

35. Client API (IDC API) Authenticate user/query (see AuthN module) Create Reservations (provides end points, Virtual Circuit requested constraints) Modify/Delete Reservations Query/Monitor Reservations

36. Public IDC API (IDC API) SOAP based, Java binding provided Provided to other IDC (other domains), security model defined by AuthN and AuthZ Compute intra-domain path within a defined set of constraints and topology Reserve and schedule intra-domain resources Manage (setup/teardown) intra-domain resources Event Management (intra-domain state change, intra-domain faults)

37. Private API (IDC API) Provided to the modules making up the IDC, such as the Coordinator, WBUI, Notification Broker SOAP based, Java bindings provided Implements inter-domain messaging, inter-domain security model Provides inter-domain protocol adaptation (backward compatibility, protocol translation) Currently limited to the local server: no security model

38. OSCARS 0.6 Code and Directory Structure

39. Overview Maven, Eclipse, Subversion Latest code at 0.6 branch Root project (“OSCARS”) has –main pom.xml –some documentation –directories, one per maven module

40. Module Overview Commons: common-xxx, database, utils PCE: pce, xxxPCE, coordinator (*) PSS: pss, xxxPSS Auth: AuthN/Z, AuthN/ZStub Web UI: wbui, oscars-war Other: api, RM, lookup, topoBridge

41. Directory Structure Generally follow Maven paradigm $OSCARS_HOME is deployed directory $OSCARS_DIST is development dir bin/exportconfig will deploy config, other files $module/config holds config files

42. OSCARS_HOME Where certs, config files, etc will be during production One directory per module / category Plus misc stuff (wsdls, logs) By default will not get overwritten during exportconfig

43. Java Code Root package is net.es.oscars One package per module category: –net.es.oscars.pss WSDL2Java generated packages in common- soap –net.es.oscars.XXX.gen

44. Dependencies Generally kept to a minimum, managed with Maven Pretty much all modules depend on utils Most are either SOAP servers or clients, so they get common-soap Implementation modules (“stubPSS”) generally depend on the category libraries (“pss”)