The CoABS Grid: An Overview

1. The CoABS Grid: An Overview Brian Kettler, Ph.D. ISX Corporation bkettler@isx.com 11 January 1999 OMG Agent Working Group Meeting

2. Agenda • Brief overview of CoABS program • Caveat 1: Views are mine, not DARPA's (etc.) • Caveat 2: Program is young (6 months) and still evolving… (more will be known after late January workshop in Las Vegas) • Caveat 3: Program just beginning to reach out to wider community (FIPA, OMG, etc.) • Overview of “The Grid” • Caveat 4: Very much a “Work in Progress” (2-3 months old) • We need input!

3. The DARPA Control of Agent-based Systems (CoABS) Program • Goal: research/develop agent technologies supporting: • semantic interoperability among heterogeneous agents • efficient interagent communication at level of goals/tasks, problem/domain elements (shared context, intent, etc) • dynamic (run-time) collaborator discovery and cooperative problem-solving behavior (dynamic teams, etc.) • greater levels of autonomous action (taskability, adaptability, etc.) • easier integration of software components (including agents, legacy) • large scale multiagent systems • many agents of varying sophistication/complexity on large scale, real-world problems in dynamic, uncertain environments • exploitation of parallelism • efficient use of resources • avoidance of chaotic behavior

4. CoABS Program Organization • Government • PM: Prof. James Hendler (DARPA Information Systems Office) • Mr. Rick Metzger (USAF Research Lab/Rome) • Potential Customers • AMC, Other DARPA programs (ALP, etc.), ??? (TBD) • Integration Contractor • Global Infotek, Inc. (GITI) • ISX Corporation • Research Groups (university and industry) (~20)

5. CoABS Researchers

6. CoABS Program Efforts • Technology Integration Experiments (TIEs) • Operationally-focused TIEs • 3 for late Spring 1999 • existing components/architectures (OAA, RETSINA, Prodigy, etc.) • NEO (Noncombatant Evacuation Operation) scenario • Scientific TIEs • experiments on control, scalability, etc. • The Grid

7. The Grid: Broad Vision • A Scenario [by Paul Cohen & CoABS Steering Cmte] • You are an infantry battalion commander who connects your PDA online... • Your personal assistant agent connects to the Grid • tells Grid your physical location, current tasks/goals/plans, resources, capabilities, needs, etc. • Meanwhile, the Grid adjusts to you... • i.e., can take advantage of your extra resources (physical, computer, etc.) & capabilities: • sends you the latest status reports relevant to your goals/interests • run a meteorological simulation on some of your battalion PCs • due to your expertise in Arabic, sends you documents to translate • Grid resources, priorities, and goals adjusted dynamically • When you (temporarily) disconnect from Grid... • it prepares for your return (generates reports, filters email, etc.)

8. The Grid • The Grid is an infrastructure supporting the semantic interoperability of agent groups, each with potentially different agent architectures • e.g., A group of OAA agents talking to a group of RETSINA agents • Analogous to the Internet’s support for interoperability among networks with different protocols GA = Grid-aware Agents

9. Grid Development Approach • GITI/ISX is coordinating this effort • Define Vision for Grid • define operational scenarios for its use • Define Requirements - top down approach • define basic set of use cases (later expand for different kinds of applications - e.g., planning agents) • define minimal services Grid must have - produce service-level description (message syntax/semantics) • Define Requirements - bottom up approach • canvass community (initially CoABS but also wider) • look at existing agent services • e.g., CMU’s RETSINA, Dartmouth’s D’Agents, SRI’s OAA

10. Grid Development Approach (cont’d) • Design/Develop Prototypes • build something (and they will come…) • a strawman versus waiting on the definitive specification • initially implement base subset of use cases • deploy and let community experiment with it • multiple implementations of a service are desirable • enumerate design assumptions & issues • many are open research problems! • Enumerate additional requirements • from operational/functional TIEs, scientific TIEs • incrementally refine, replace, update service specifications and implementations

11. Some Initial Simplifying Assumptions • Focus on functionality, vs. performance • “Real” Grid must consider fault tolerance, failure recovery, comm bandwidth, CPU cycles, etc. • scalability will be paramount • Keep it simple (at least for now) • define a minimal set of Grid services • agent communities also will have their own services • define a minimal set of messages an agent on the Grid must support

12. Use Cases • Actors • Users • Application End User • Grid/System Administrator • Agents • Grid-Aware Agents - can join the Grid • Application Agents (problem solvers, resource mgrs., interface agents) • Grid Service Agents (Registration Agent, Security Agent, etc.) • Non Grid-Aware Agents • System • The Grid • Grid Services (Agents)

13. Use Cases for Any Grid-aware Agent (GA) • Most basic: • GA connects to Grid • GA disconnects from Grid • GA posts request/need to Grid • GA posts capability/service advertisement to Grid • GA asks/requests another GA (i.e., direct agent-agent comm) • Additional use cases: • GA makes log/checkpoint entry • GA sets/clears timer • GA gets a security “check” • ???

14. Grid Registration Agents (GRAs) • Map Grid ID of GAs to their address • I.e., naming/white pages service • Store addresses of some (local?) GAs • DNS-style address scheme? • Assign new Grid IDs to new GAs • globally unique, persistent IDs • Communicate with other GRAs • Check GAs credentials, permissions, etc. with Grid Security Agent

15. Grid Matchmaker Agents (GMMAs) • Map capabilities/services to IDs of GAs • i.e., yellow pages service • Store capability descriptions (i.e, ads) • need some language for these (vocabulary -> ontology) • Have query capability (e.g., nearest neighbor matching, etc.) • Communicate with other GMMAs • organized hierarchically? by topic (or location)?

16. Grid Management Agents (GMAs) • Support management of Grid by agents and users • Provide Grid status (to other agents) • Grid comm infrastructure (i.e., network sensing) • Can obtain status info from other GAs • status info can be sent to Grid Visualization Services (i.e., interface agents on the Grid) • Detect problems • deadlock, livelock, etc. • Can exert control over GAs • request they start/stop/suspend, etc. • Can startup/shutdown other GSAs

17. Other Grid Service Agents (GSAs) • Grid Event Management Agents • support setting/clearing timers • may support other kinds of events (and possibly triggers/sentinels) • keep GMT (Grid Mean Time) • Grid Logging Agents • store activity/state info for GAs • support querying of this info for debugging, visualization, etc. • Grid Security Agent • provide authentication, access control, etc.

18. Other Potential Grid Services • Mobility • support transport of running agents • interface with control services for load balancing, etc. • Exception Handling • handling of common exceptions • reduce burden on agent programmer • Programming Tools • facilitate construction of Grid-aware agents • e.g., wrapping legacy agents and non-agent components, debugging, etc.

19. Some General Design Issues • Services provided by Grid (versus elsewhere) • also customizability via policies, tuning, etc. • Grid Comm (messaging infrastructure, ACLs, etc.) • e.g., sockets or some higher level messaging mechanism (RMI, CORBA, etc.) • e.g., one or several mechanisms/ACLs supported • GA-to-GA, GSA-to-GSA, etc. • translation services provided? • consider platforms, footprint, COTS software required, etc. • lightweight vs. heavyweight ACLs (vocabulary vs. ontology) • Built-in (vs. add-on) support for mobility, security, fault tolerance/recovery, etc.

20. What We Need (1) • Additional use cases • higher-level/more specific? • e.g., planner requests sentinel agent to monitor for threats to plan • Refinements on service-level descriptions of Grid • Components to leverage for services • other CoABS and non-CoABS agent services • other services? (CORBA trader, event, etc.)

21. What We Need (2) • Agent communication mechanisms • low-level messaging mechanisms (e.g., sockets, CORBA, etc.) • wrapper language (e.g., KQML-Lite, etc.) • content language (e.g., KIF, etc.) • ontology, service description language • HPKB upper level ontology, etc. • Agent Visualization techniques/tools • for debugging, demonstration, etc. • low-level activity (comm level, CPU, etc.) • comm content, patterns, etc. • higher-level activity (teams, subproblems, etc.)

22. Additional Information • CoABS • http://dtsn.darpa.mil/iso/ • The Grid • Use Case document • email bkettler@isx.com