dice: authorizing dynamic networks for vos jeff w. boote senior network software engineer, internet2...
DESCRIPTION
Outline Goals Use cases History of AA in perfSONAR and DCN Current implementations Future directionsTRANSCRIPT
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