1 / 32

Interoperability of Future Information Systems

Interoperability of Future Information Systems. ONR Grant Number: N00014-02-1-0499. Daniel Siewiorek, Katia Sycara (PI’s) Joseph Giampapa, Ritika Sanghi, Aaron Steinfeld School of Computer Science Carnegie Mellon University. Outline. Motivation Research Approach Taxonomy Findings

jeff
Download Presentation

Interoperability of Future Information Systems

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. Interoperability of Future Information Systems ONR Grant Number: N00014-02-1-0499 Daniel Siewiorek, Katia Sycara (PI’s) Joseph Giampapa, Ritika Sanghi, Aaron Steinfeld School of Computer Science Carnegie Mellon University

  2. Outline • Motivation • Research Approach • Taxonomy Findings • Agent Development Process • What’s Next

  3. Motivation • Resolving network interoperability problems is difficult and time consuming • heterogeneity, admin policies, etc • Advances in network flexibility will improve underlying performance • New HCI methods and tools will be required to enhance user awareness and problem resolution

  4. Outline • Motivation • Research Approach • Taxonomy Findings • Agent Development Process • What’s Next

  5. Research Questions • How does the user diagnose and remedy network interoperability problems? • What options exist given the obstacles imposed by intermediary policies?

  6. Research Plan • Generate taxonomy of remote access interoperability problems • Define agent interactions with existing network tools and formulate service profiles for future tools • Develop agents for the resolution of network interoperability problems

  7. Interoperability Problem Resolution Model (IPRM)

  8. Interoperability Problem Resolution Model - 1

  9. Interoperability Problem Resolution Model - 2

  10. Outline • Motivation • Research Approach • Taxonomy Findings • Agent Development Process • What’s Next

  11. Taxonomy Findings • SCS remote access trouble ticket case data for 6/5/2000 - 1/15/2003 • 528 Cases • Help only: 414, of these… • Single configuration events (“Single”): 88 • Requests for modem numbers: 137 Core (SCS) Leaf (external user) Network (not SCS)

  12. Analysis Set 1 • 414 Help cases without outliers: • Zero or null Hours to Resolve: 12 • Over 1,000 Hours to Resolve (notes): 4

  13. By Type • Phone number queries (significant) • Network problems consume time fast

  14. Analysis Set 2 • 414 Help cases without outliers or phone number requests: • Zero or null Hours to Resolve: 12 • Over 1,000 Hours to Resolve: 4 • Requests for modem numbers: 132

  15. 1.0 0.8 0.6 Percent Unresolved 0.4 Network Single Core Leaf 0.2 0.0 0 168 336 504 672 840 1008 Hours to resolve Duration, by Type

  16. Modes: DSL, Modem, Wireless • Combined are usually requests for same IP # in both modes • No significant effects

  17. Security Policies: VPN, Realm • 41% cases & 47% time involved either VPN or other security, authentication, or registration issues • VPN and VPN*Realm (significant)

  18. Very Little Knowledge Re-use • Root Cause or Solution either • Not found • Not documented • No significant effects

  19. Taxonomy Findings Summary • 22% from configuration changes • 49 hrs/case for all help related • 60 hrs/case for subset not including phone number requests • Security policy issues are frequent • Very little knowledge sharing/re-use • Extracted by hand, rarely in existing database fields

  20. Outline • Motivation • Research Approach • Taxonomy Findings • Agent Development Process • What’s Next

  21. Agent Development Process • Model the Problem Domain • Map Agents and Service Descriptions to: • Interoperability Problem Resolution Model, and • Problem Domain • Implement, Deploy, Test, Evaluate • Automatic Process Refinement

  22. The Problem Domain Model • Multiple Views and Options Intersect • Connectivity Model • Connectivity Security Model • Security Programs and Features • VPN, SSH, SCP, Kerberos • Typical Motivating Applications • Interact with the above 3 models • Multiple ways to achieve application goals • Users get lost in the intersections

  23. Typical Motivating Applications • E-mail • Send and receive • From: on- or off- campus • Intranet Quality of Service (QoS) • Institute-wide access • Printing, e-service subscriptions • Software licenses, downloads and updates • Bandwidth/speed • File Transfer & File System Access

  24. Generic Connectivity Model Public CMU MODEM LAN / Ethernet End User @ Leaf Node ISP Entity Internet Wireless (802.11) Other MODEMS (DSL, cable, broadband, etc.) ISP Authentication Private CMU SCS Realm Security Programs

  25. Mappings • Each Connection between nodes: • Indicates a possibly new authentication step • Puts the user in a new application and access rights context • Potentially grants the user new privileges • Can be modeled as a service description • Each Node: • Has (potentially) verifiable configuration parameters • Can be modeled as an agent • A User’s Connectivity Problem • Possibly parameterized by goals of using certain applications • Resolved automatically by agent / service description matching

  26. System Architecture • Agents will have models of application, connectivity, and security tasks • Agents will shadow local and remote applications • Agents will also interact with SysAd agents for updates and policy changes

  27. Service Descriptions • Service profile: represents what a service does • Service model: describes how a service works • Service grounding: specifies service access information

  28. Functional Architecture

  29. Four parallel threads: • Communicator • for conversing with other agents • Planner • matches “sensory” input and “beliefs” to possible plan actions • Scheduler • schedules “enabled” plans for execution • Execution Monitor • executes scheduled plan • swaps-out plans for those with higher priorities Agent Architecture

  30. MAS Infrastructure MAS Infrastructure Individual Agent Infrastructure MAS Interoperation Translation Services Interoperator Services Interoperation Interoperation Modules Capability to Agent Mapping Middle Agents Capability to Agent Mapping Middle Agent Components Name to Location Mapping Agent Name Service Name to Location Mapping ANS Component Security Certificate Authority Cryptographic Service Security Security Module Private/Public Keys Performance Services MAS Monitoring Reputation Services Performance Services Performance Service Modules Multi-Agent Management Services Logging Activity Visualization Launching Management Services Logging and Visualization Components ACL Infrastructure Public Ontology Protocol Servers ACL Infrastructure Parser, Private Ontology, Protocol Engine Communications Infrastructure Discovery Message Transfer Communication Modules Discovery Message Transfer Modules Operating Environment Machines, OS, Network, Multicast Transport Layer, TCP/IP, Wireless, Infrared, SSL

  31. Outline • Motivation • Research Approach • Taxonomy Findings • Agent Development Process • What’s Next

  32. What’s Next • Implement proof of concepts • Monitoring agent that collects parameter settings during problem solving and stores them in a centralized location • Implement resolution models • Quantitative analysis of resolution agent use

More Related