OSCARS Architecture Overview April 2012

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 TeamEnergy Sciences Network (ESnet)

Lawrence Berkeley National Laboratory

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

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

OSCARS 0.6Module APIs

Notification Broker Module API




• Auditing


Coordinator


Computations


Management


WS Communications


Interface



• Costing



5

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.

Internal API (Notification Broker)

• Coordinator sends notify messages as events occur• Notify messages NOT used between OSCARS

modules

Lookup Module API




Coordinator


Computations


Management


WS Communications



• Costing



8


• Auditing


Interface

Internal API (Lookup)

• Find location of services (i.e. IDC services) that control a particular domain

• Register location of externally facing services

Topology Bridge Module API




Coordinator


Computations


Management


WS Communications



• Costing



10


• Auditing


Interface

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

AuthN Module API




Interface


Coordinator


Computations


Management


WS Communications


• Auditing



• Costing



12

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

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

AuthZ Module API




Interface


Coordinator


Computations


Management


WS Communications


• Auditing



• Costing



15

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

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

Coordinator Module API

Notification Bridge Forward Notifications



Coordinator


Computations


Management


WS Communications



• Costing



18


• Auditing


Interface

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

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

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.

PCE Module API




Coordinator


Computations


Management


WS Communications



• Costing



22


• Auditing


Interface

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

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

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

Resource Manager Module API




Coordinator


Computations


Management


WS Communications



• Costing



26


Interface


• Auditing

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

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

Path Setup Module API




Coordinator


Computations


Management


WS Communications



• Costing



29


• Auditing


Interface

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.

API (Path Setup)

• Operations supported:– setup, teardown, status, modify

• All calls have as argument a complete OSCARS reservation object.

• Possibility for standardization here!

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

IDC API Module API




Coordinator


Computations


Management


WS Communications



• Costing



33


• Auditing


Interface

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

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

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)

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

OSCARS 0.6Code and Directory Structure

Overview

• Maven, Eclipse, Subversion • Latest code at 0.6 branch• Root project (“OSCARS”) has

– main pom.xml– some documentation– directories, one per maven module

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

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

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

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

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

Date post:	23-Feb-2016
Category:	Documents
Upload:	paxton
View:	83 times
Download:	0 times

OSCARS Architecture Overview April 2012

Documents