Transcript Leveraging Internet2 Facilities for the Network Research

DICE: Authorizing Dynamic
Networks for VOs
Jeff W. Boote
Senior Network Software Engineer, Internet2
Cándido Rodríguez Montes
RedIRIS
TNC2009
Malaga, Spain
8 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
Analysis &
Visualization
API
Measurement
Infrastructure
Measurement
Infrastructure
API
Data
Collection
Performance
Tools
perfSONAR Components
Infrastructure
Data Services
Measurement
Points
Measurement
Archives
Information Services
Service
Lookup
Analysis/Visualization
User GUIs
Topology
Service
Configuration
Web Pages
NOC
Alarms
Transformations
Auth(n/z)
Services
perfSONAR
perfSONAR allows
autonomous measurement
systems to be aggregated in
analysis
user
performance GUI
m1
m4
measurement
archive
m1
measurement
archive
m4
m1
m1
m4
GEANT (AS20965)
[Europe]
m3
m3
ESnet (AS293)
[US]
measurement
archive
m1
m4
m3
m3
m3
FNAL (AS3152)
[US]
9
Analysis tool
measurement
archive
measurement
archive
m4
DESY (AS1754)
[Germany]
DFN (AS680)
[Germany]
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
Intradomain is domain dependent
Interdomain – IDC is agreed upon between domains
IDC to IDC
communication
IDC
User Request/
IDC Response
IDC to IDC
communication
IDC
IDC
Domain
Controller
Domain
Controller
Domain
Controller
Network 1
Network 2
Network 3
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