DICE: Authorizing Dynamic Networks for VOs

Jeff W. BooteSenior Network Software Engineer, Internet2

Cándido Rodríguez MontesRedIRIS

TNC2009

Malaga, Spain8 June, 2009

DICE• Informal partnership made up of:• CANARIE, ESnet, GÉANT, Internet2, USLHCnet• Focus of collaboration is in aligning respective

resources to best support the shared user base• Coordinating network infrastructure• Coordinating new service development

• Basis for perfSONAR collaboration and DICE control-plane (dynamic circuit) collaborations

• Started discussing a common framework for middleware to support monitoring and dynamic circuit efforts about a year ago

Outline

• Goals• Use cases• History of AA in perfSONAR and DCN• Current implementations• Future directions

AAI Integration Goal• AAI Systems that are interoperable and support

Dynamic Circuit Networks (IDC) and perfSONAR (PS). They may be built out of different components for various organizations, but having a common interface

• IDC and PS components then need to be modified to support that common AAI interface

• Desire to leverage existing middleware infrastructure

• Necessary because a common identity infrastructure is needed from a complete network management perspective. Those who provision the network, need to be able to diagnose performance issues with it.

What is perfSONAR• An architecture & a set of protocols• Services Oriented Architecture (SOA)• Web Services Interfaces• Protocols being standardized in the OGF NMC-WG

• Also• A collaboration

• Production network operators focused on designing and building tools that they will deploy and use on their networks to provide monitoring and diagnostic capabilities to themselves and their user communities.

• Several interoperable software implementations• Java & Perl

• A Federated set of Deployed Measurement Infrastructures

perfSONAR Architecture• Interoperable network measurement middleware:

• Modular• Web services-based• Decentralized• Locally controlled

• Integrates:• Network measurement tools and archives• Discovery• Authentication and authorization• Data manipulation• Topology

• Based on:• Open Grid Forum Network Measurement Working Group schema.

Decouple 3 phases of a Measurement Infrastructure

Analysis & Visualization

Measurement Infrastructure

Data Collection Performance

Tools

Analysis & Visualization

Measurement Infrastructure

API

API

perfSONAR Components

MeasurementPoints

Data Services

MeasurementArchives

Transformations

Service Configuration

Auth(n/z)Services

Infrastructure

Information Services

Topology

Service Lookup

Analysis/Visualization

User GUIs

Web Pages

NOC Alarms

perfSONAR

9

FNAL (AS3152)[US]

ESnet (AS293)[US]

GEANT (AS20965)[Europe]

DFN (AS680)[Germany]

DESY (AS1754)[Germany]

measurement archive

m1m4

m3

measurement archive

m1m4

m3

measurement archive

m1m4

m3

m1m4

m3

m1m4

m3

measurement archive

measurement archive

performance GUI

user

Analysis tool

perfSONAR allows autonomous measurement systems to be aggregated

in analysis

perfSONAR – AAI issues

• Not all clients are web browsers• Interesting data for a single end-to-end path

is typically ‘owned’ by several different organizations• May have different release policies• Related to home institution, job function, VO

membership

• On demand multi-domain measurements create a real need for multi-domain AAI

DCN Comparisons to IP

Parallels with the IP Network• IP Network• Hosts have one-armed connections• Can communicate with other hosts on the network• Data paths are shared – the “atomic” elements are

packets on shared data paths• Control plane protocols include IGP and EGP protocols

• Dynamic Circuit Networks• Hosts have one-armed connections• Can communicate with other hosts on the network• Data paths are dedicated – the “atomic” elements are

circuits with non-shared data flows• Control plane protocols being developed – Interdomain

(IDC) protocol

IDC Control Plane

Domain Controller

Network 1

IDC

Domain Controller

Network 2

IDCUser Request/IDC Response

IDC to IDC communication

Domain Controller

Network 3

IDC

IDC to IDC communication

Intradomain is domain dependentInterdomain – IDC is agreed upon between domains

IDC Flow Diagram - Web Service Based

• Four Primary Web Services Areas: • Topology Exchange, Resource Scheduling, Signaling, User Request

Web Service Based Components• Topology

• Topology Exchange• Domain Abstraction• Varying levels of dynamic information

• Resource Scheduling and Path Computation• Multi-Domain path computation techniques• Resource identification, reservation, confirmation

• Signaling• path setup, service instantiation

• Host Lookup Service (Information Services - think DNS in the IP world)• Uses DNS pointers

• AAI integration (Architecture under investigation)• There is significant overlap with perfSONAR!

Dynamic Circuits – AAI issues

• Not all clients are web browsers• Interesting data for a single end-to-end path

is typically ‘owned’ by several different organizations• May have different release policies• Related to home institution, job function, VO

membership

• On demand provisioning creates a real need for multi-domain AAI

Basic Architecture - PS

Basic Architecture - IDC

Currently Exploring

• N-tier issue• ShibuPortal work may be a solution here• Advantage is to more closely align pS/IDC efforts

with MACE efforts• SAML ECP profile• Deal with non-web browser issues

• Hope to leverage attribute aggregation solutions for virtual/collaborative organizations

Conclusion

• All of this is a work in progress!• We are interested in your input!

Thanks!

Demonstration

• Demonstration of current work in perfSONAR