1 / 44

OSCARS Architecture Overview April 2012

OSCARS Architecture Overview April 2012. ESnet OSCARS Development Team Energy Sciences Network ( ESnet ) Lawrence Berkeley National Laboratory. OSCARS 0.6 Design / Implementation Goals. Support production deployment of service, and facilitate research collaborations

paxton
Download Presentation

OSCARS Architecture Overview April 2012

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OSCARS Architecture OverviewApril 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 • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Resource Manager • Manage Reservations • Auditing Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Path Setup • Network Element Interface • IDC API • Manages External WS Communications

  4. OSCARS 0.6 Module APIs

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

  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 • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Resource Manager • Manage Reservations • Auditing Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Path Setup • Network Element Interface • IDC API • Manages External WS Communications

  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 • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Resource Manager • Manage Reservations • Auditing Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Path Setup • Network Element Interface • IDC API • Manages External WS Communications

  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 • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Path Setup • Network Element Interface Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Resource Manager • Manage Reservations • Auditing • IDC API • Manages External WS Communications

  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 • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Path Setup • Network Element Interface Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Resource Manager • Manage Reservations • Auditing • IDC API • Manages External WS Communications

  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 BridgeForward Notifications • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Resource Manager • Manage Reservations • Auditing Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Path Setup • Network Element Interface • IDC API • Manages External WS Communications

  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 • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Resource Manager • Manage Reservations • Auditing Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Path Setup • Network Element Interface • IDC API • Manages External WS Communications

  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 BridgeForward Notifications • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Resource Manager • Manage Reservations • Auditing Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Path Setup • Network Element Interface • IDC API • Manages External WS Communications

  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 • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Resource Manager • Manage Reservations • Auditing Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Path Setup • Network Element Interface • IDC API • Manages External WS Communications

  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 • Topology Bridge • Topology Information Management • Lookup • Lookup service • PCE • Constrained Path Computations • AuthN • Authentication • Coordinator • Workflow Coordinator • Resource Manager • Manage Reservations • Auditing Web Browser User Interface • AuthZ* • Authorization • Costing • *Distinct Data and Control Plane Functions • Path Setup • Network Element Interface • IDC API • Manages External WS Communications

  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”)

More Related