ࡱ> %'"#$ -_bjbj 0wUv?"+++8c| +vw!""""$!&&Pvvvvvvvdz}^v '$$ ' 'v""w,... '&""v. 'v..e,-k"+3)h6v:w<vwKhd})+ld}l-k-kRd}od ' '. ' ' ' ' 'vv, ' ' 'vw ' ' ' 'd} ' ' ' ' ' ' ' ' ' : GENI Goals for Spiral 2, and Cluster D Roadmap to end of Spiral 1 and for Spiral 2 Revised during conference call on June 11, 2009 Additions on July 1, 2009 Needs to be finalized in Cluster D meeting on July 2, 2009 Contents  TOC \o "1-3" \h \z \u  HYPERLINK \l "_Toc234229424" 1. GENI goals for Spiral 2  PAGEREF _Toc234229424 \h 1  HYPERLINK \l "_Toc234229425" 2. Cluster E roadmap to end of Spiral 1 and for Spiral 2  PAGEREF _Toc234229425 \h 2  HYPERLINK \l "_Toc234229426" 2.1 Live Experiments  PAGEREF _Toc234229426 \h 2  HYPERLINK \l "_Toc234229427" 2.2 Identity Management  PAGEREF _Toc234229427 \h 3  HYPERLINK \l "_Toc234229428" 2.3 Improved Integration  PAGEREF _Toc234229428 \h 3  HYPERLINK \l "_Toc234229429" 2.4 Instrumentation  PAGEREF _Toc234229429 \h 6  HYPERLINK \l "_Toc234229430" 2.5 Interoperability  PAGEREF _Toc234229430 \h 7  HYPERLINK \l "_Toc234229431" 3. ORCA Integration Roadmap  PAGEREF _Toc234229431 \h 9  HYPERLINK \l "_Toc234229432" Brief ORCA overview  PAGEREF _Toc234229432 \h 9  HYPERLINK \l "_Toc234229433" Software integration overview  PAGEREF _Toc234229433 \h 10  HYPERLINK \l "_Toc234229434" Substrate  PAGEREF _Toc234229434 \h 10  HYPERLINK \l "_Toc234229435" Portals/tools  PAGEREF _Toc234229435 \h 10  HYPERLINK \l "_Toc234229436" Infrastructure integration overview  PAGEREF _Toc234229436 \h 11  HYPERLINK \l "_Toc234229437" ORCA feature/capability roadmap  PAGEREF _Toc234229437 \h 11  1. GENI goals for Spiral 2 1) -Live experiments The central goal of Spiral 2 is to support significant numbers of research experiments in the end-to-end prototype systems. The GPO expects live experimentation to begin near the end of Spiral 1, which will intensify through Spiral 2 as we begin continuous operation of the prototype systems. This will begin to give us all substantial (early) operational experience, as these experiments will help us all understand the prototypes' strengths and weakness, which will drive our Spiral 3 goals. Additionally, we expect development in Spiral 2 to emphasize: 2) - Identity management 3) - Improved integration (data & control planes, within clusters) 4) - Instrumentation 5) - Interoperability (permitting clusters to access the widest number of aggregates) 2. Cluster E roadmap to end of Spiral 1 and for Spiral 2 These are proposed items (from the June 11 meeting) that have been organized according to the Spiral 2 goals. Some items have been added. What items should be added? Deleted? What is the importance of each item (H, M, L)? What is the difficulty of each item (H, M, L)? 2.1 Live Experiments a)The GPO expects live experimentation to begin near the end of Spiral 1. b) What experiments can be done with BEN by the end of Spiral 1? c) What experiments can be done with DOME by the end of Spiral 1? (By the end of summer, GENI will be the only way to access DOME.) d) What experiments can be done with ViSE by the end of Spiral 1? (By the end of summer, will GENI be the only way to access ViSE?) e) What experiments can be done with Kansei by the end of Spiral 1? f) In Spiral 2, we begin continuous operation of the prototype systems. Perhaps divide into local access and centralized GENI Cluster D access. Substrate owner is responsible for continuous local access. RENCI is responsible for clearinghouse (broker). Who is responsible for overall Cluster D availability? What are responsibilities of GMOC? g) The central goal of Spiral 2 is to support significant numbers of research experiments in the end-to-end prototype systems. What is end-to-end? Between which aggregates? What are likely needs for experimenters? Servers? 2.2 Identity Management As Cluster D seeks to include more users (researchers), it needs better identity management. a) What will be done by the end of Spiral 1 to serve other GENI users by the individual aggregates? b) Would it be helpful to define a master list (registry) of other GENI users? How? Where would it be stored? How would it be used? c) How could Cluster D move to use Shibboleth/ InCommon for identity management? Note: RENCI has written a solicitation 2 proposal that covers this. 2.3 Improved Integration a) Inter-actor SOAP implementationCurrent implementation is functional and undergoing robustness testing.Fully functional SOAP implementation capable of interconnecting actors located in different containers with no restrictions on actor/container arrangements.06/2009  b) Simplify admin and operation of security mechanisms between servers, and messages between actors. Distribution of keys? c) Privacy not currently provided for messages between actors; add? d) Configuration manager Both at site authority and slice controller Current configuration manager is capable of invoking a series of Ant tasks that always execute in the same sequence. Limited to idempotent driver implementations using either a node agent or XML-RPC interface described above.Flexible configuration manager with an abstraction layer for device capabilities using XML and perhaps a scripting language (Groovy, Jython, Ruby), capable of executing arbitrary sequences of configuration actions with complex control flows on complex substrates. At site authority, support for complex slivers From slice controller, configures sliver Configuration commands can be created using either NDL toolkit or custom mechanisms.TBD, expected late 2009 e) Clean-up and fully specify interfaces between actors. SOAP interfaces with WSDL used today, plus piggybacked resource descriptions Mainly a resource description problem; how to describe and then extend? All need to be extensible e) Resource description mechanisms Most commonly used resource description mechanism is table driven (i instances of type T). NDL-OWL based resource description framework extended to multiple substrate types: optical networks, wireless networks, edge resources. Of interest to Cluster E ViSE: VMs with sensors DOME: as a VM today; towards a cloud KANSEI: may be of useOn-going work. Early prototype schema available 07/2009 g) Resource allocation policiesCurrent policies rely on the current table-driven resource description model.Policy framework to allow for co-scheduling of disparate types of resources including wireless, optical network links, edge resources, core network resources as well as cross-layer path computation under multiple constraints. Needed as improve resource description, for multiple substrates, for dispirate resourcesOn-going work. Early prototype API available 07/2009 h) Management interfaceCurrent management interface is embedded in the portal attached to each container. Allows for implementation of custom plugins that implement management tasks. Undocumented Not remoted, only by local Java code As move forward, need to retain the local interfaceAn extensible SOAP-based interface allowing ORCA to interface with management entities (e.g. GMOC, distributed network operations, visualization tools etc.). Look at actors, slices, etc. Perhaps add emergency stop, but not general manipulationTBD i) ORCA clearinghouseNo externally accessible clearinghouse available.Externally accessible clearinghouse maintained as a production capability. Ready to accept broker implementations from other teams07/2009 In order to support the needs of Cluster D and fulfill the Spiral 1 Year 1 requirements of the GPO, ORCA-BEN project will create an ORCA clearinghouse, capable of supporting delegation of resources by multiple participating institutions and testbeds. This clearinghouse will be represented by a host running a Tomcat container with multiple brokers contained within it. ORCA team will be responsible for maintaining this hardware/software configuration. The brokers, deployed into the clearinghouse, will be responsible for allocating different types of substrate. The integration of other projects with the ORCA clearinghouse will occur in multiple phases: Individual projects implement and test their brokers locally and, when ready, deploy their broker(s) into the ORCA clearinghouse. The teams continue running other actors (site authorities and slice controllers) locally and change their configuration to communicate with their broker(s) inside the ORCA clearinghouse using SOAP. For slices that span multiple testbeds, service managers will be designed to acquire resources from more than one broker inside the ORCA clearinghouse. This will be accomplished by the end of Spiral 1 year 1 to satisfy GPO integration goals. Limited capabilities for co-scheduling of resources exist today that can be used in this phase. (add drawing) j) Support use of both local broker (near aggregate) and centralized broker. Can be done by site authority today. k) Extended brokers In conjunction with other teams, ORCA team will design and implement brokers capable of co-scheduling resources from multiple testbeds as well as slice controllers capable of communicating with the new brokers. This work will involve integration of NDL, it will begin at the end of Spiral 1 and proceed during Spiral 2 (year 2). l) Implement broker-to-broker messages. Having one broker allocate resources to another broker is not too hard. However, hard if brokers are peers m) How is resource discovery done by service managers? Need to find all brokers. How do service managers know about available brokers? One central registry with pointers to brokers? Use CNRI (handle system) as central registry? n) Experiments involving multiple aggregates Between which aggregates? What are likely needs for experimenters? Also servers? Requires backbone connectivity of VLANs o) Backbone connectivity between aggregates. Layer 2 (VLANs) via Internet2 How to connect aggregate? How to setup in the aggregate? How to setup connections within Internet2? p) VLANs from BEN to Internet2? q) VLANs from DOME/ViSE to Internet2? r) VLANs from Kansei to Internet2? 2.4 Instrumentation a) GMOC feed from ORCA actors. b) Better way to parse and understand logs in ORCA actors. c) Way to examine and decode ORCA messages. Only via logs? d) BEN: not much for solicitation 1; proposal written for solicitation 2. GMOC feed from BEN. e) DOME: monitoring of the operations is there now, status, etc Mechanism to allow experimenter to get the data off the bus GMOC feed from DOME f) ViSE: rudimentary monitoring of the nodes, their wireless connectivity GMOC feed from ViSE g) KANSEI: promised measurement for job scheduling, what nodes and links are up, etc. GMOC feed from KANSEI By the end of year 1: Kansei users can check the status of his experiments (e.g., success, failure, or pending) By the end of year 2: Kansei users can interact and control his experiments through the "Experiment Interaction User Service" h) Plan for Embedded Real-Time Measurements in Spiral 2? 2.5 Interoperability Interoperability with other clusters would be very helpful in Spiral 2. a) Export ProtoGENI interface from Slice Controller actor. Interface for external experiment control tools or experiment managers.Custom XML-RPC built for Gush and DOME. Based on current code (JAWS), that needs to be cleaned upThese interfaces allow externally built-actors/tools to interact with a generic ORCA slice controller. We plan a generic XML-RPC interface for use by experiment control tools written in multiple languages. Stable, public interface This interface supports a subset of ORCA resource reservation capabilities modeled after the ProtoGENI XML-RPC interface. Might enable ProtoGENI experiment controller to configure and launch experiment in Cluster D Would not generally allow a researcher in Cluster C (ProtoGENI) to access a resource in Cluster D.TBD  b) Integrate ORBIT as an aggregate into Cluster D. Start with common resource representations Then, tighter integration might be done c) Coordinated Layer 2 connections between slivers in aggregates in different clusters. Layer 2 (VLANs) via Internet2 How to connect aggregate? How to setup in the aggregate? How to setup connections within Internet2? d) Generalized resource discovery What about queries from other clusters? What about queries to other clusters? One central registry for pointers to all resources in all clusters? 3. ORCA Integration Roadmap Provided by ORAC/BEN project on May 26, 2009 This document describes the roadmap for integration within ORCA. Various options for software integration with ORCA codebase are outlined. Future code features/enhancements, permanent infrastructure (ORCA-BEN GENI clearinghouse) are also discussed. This document is intended for the Cluster D projects as well as any other project wishing to integrate their infrastructure (substrate) and tools with ORCA control framework. Brief ORCA overview ORCA implements a number of actors (as Java classes) capable of running on a single host (within a single Tomcat container) or on different hosts, communicating with each other using secure SOAP. These actors are: Broker, containing a policy for allocating resources of different types (runs within a Clearinghouse). Aggregate manager or Authority for a site or domain, administratively responsible for some elements of a substrate. An authority delegates allocation of its resources to a broker. Service manager/slice controller, acting on behalf of a researcher to request resources from the broker, and then configure them for the experiment A Site authority contains a configuration manager (class Config), capable of installing slice-specific configurations into the substrate hardware elements on behalf of either the broker or the slice controller. The current configuration manager is capable of invoking a series of Ant tasks for a specific type of a substrate to accomplish substrate configurations (discussed in more detail below). Actors within a single Tomcat container are configured by using a web front-end attached to the container. Using the web front-end, for example, resources can be granted to site authority using the web front end. A site authority can delegate the resources to a specific broker. Service manager allows for the creation of plugins that act as slice controllers on the substrate by requesting and configuring resources from one or more brokers. Software integration overview Substrate In order to integrate elements of substrate with ORCA, one must identify the different types of substrate available and create a broker policy to allow for the allocation of the substrate. A policy, implemented as a Java class, can contain any number of rules and constraints on how specific types of substrate must be allocated. The current ORCA codebase contains a number of policy examples, the most commonly used of which is a table-driven scheduling policy, capable of allocating a certain number i of units of type T from pools of interchangeable units of type T, which were delegated to the broker by one or more site authorities. The second part of substrate integration is needed to allow ORCA to create slivers of the substrate by allowing it to pass configuration commands to the substrate elements. Each substrate component type (sliver type) provides a handler script to setup or teardown slivers on a component of that type. In principle, handlers could be written in any scripting language that can be invoked from Java (e.g., Jython, JRuby, Groovy), but all current handlers are scripted using Ant. Using the Ant approach at least two alternatives are possible for handlers to pass configuration commands to the components: The handler uses secure SOAP to invoke component-specific driver modules. Drivers are written in Java and run within a Java-based Node Agent supplied with the Orca code. The node agent is either deployed into the substrate component (if it supports Java VMs) or into a proxy. The drivers are capable of executing commands on the component, based on properties passed through the handler. Examples of such mechanisms are ORCA-BEN integration with Cisco 6509, Polatis fiber switches and Infinera DTNs. The handler uses a messaging protocol such as XML-RPC to configure the substrate. The substrate elements exposes custom configuration interfaces in XML-RPC, which are invoked by the handler. An example of this type of integration is contained in the DOME code. This approach does not require a node agent and allows using non-Java based substrate drivers. Portals/tools To integrate a portal or tool acting on behalf of a user it is necessary to create a communications mechanism between the portal/tool and the ORCA service manager. This mechanism would allow the portal/tool to manage requests for resources from the ORCA broker(s) mediated by the slice controller. This mechanism could be fully custom or can be built using the currently available examples of such a mechanism implemented as XML-RPC to allow for the integration with Gush, as well as a similar example implemented for the integration of DOME project. Infrastructure integration overview In order to support the needs of Cluster D and fulfill the Spiral 1 Year 1 requirements of the GPO, ORCA-BEN project will create an ORCA clearinghouse, capable of supporting delegation of resources by multiple participating institutions and testbeds. This clearinghouse will be represented by a host running a Tomcat container with multiple brokers contained within it. ORCA team will be responsible for maintaining this hardware/software configuration. The brokers, deployed into the clearinghouse, will be responsible for allocating different types of substrate. The integration of other projects with the ORCA clearinghouse will occur in multiple phases: Individual projects implement and test their brokers locally and, when ready, deploy their broker(s) into the ORCA clearinghouse. The teams continue running other actors (site authorities and slice controllers) locally and change their configuration to communicate with their broker(s) inside the ORCA clearinghouse using SOAP. For slices that span multiple testbeds, service managers will be designed to acquire resources from more than one broker inside the ORCA clearinghouse. This will be accomplished by the end of Spiral 1 year 1 to satisfy GPO integration goals. Limited capabilities for co-scheduling of resources exist today that can be used in this phase. In conjunction with other teams, ORCA team will design and implement brokers capable of co-scheduling resources from multiple testbeds as well as slice controllers capable of communicating with the new brokers. This work will involve integration of NDL, it will begin at the end of Spiral 1 year 1 and proceed during Spiral 1 year 2. ORCA feature/capability roadmap The following roadmap describes features and capabilities of ORCA software as well as the development of the infrastructure required to roll out production-level ORCA clearinghouse capable of supporting other projects. Feature/ capabilityCurrent state/limitationsFuture enhancementsExpected dateORCA clearinghouseNo externally accessible clearinghouse available.Externally accessible clearinghouse maintained as a production capability. Ready to accept broker implementations from other teams07/2009Inter-actor SOAP implementationCurrent implementation is functional and undergoing robustness testing.Fully functional SOAP implementation capable of interconnecting actors located in different containers with no restrictions on actor/container arrangements.06/2009 Configuration managerCurrent configuration manager is capable of invoking a series of Ant tasks that always execute in the same sequence. Limited to idempotent driver implementations using either a node agent or XML-RPC interface described above.Flexible configuration manager with an abstraction layer for device capabilities using XML and perhaps a scripting language (Groovy, Jython, Ruby), capable of executing arbitrary sequences of configuration actions with complex control flows on complex substrates. Configuration commands can be created using either NDL toolkit or custom mechanisms.TBD, expected late 2009Resource description mechanisms Most commonly used resource description mechanism is table driven (i instances of type T). NDL-OWL based resource description framework extended to multiple substrate types: optical networks, wireless networks, edge resources.On-going work. Early prototype schema available 07/2009Resource allocation policiesCurrent policies rely on the current table-driven resource description model.Policy framework to allow for co-scheduling of disparate types of resources including wireless, optical network links, edge resources, core network resources as well as cross-layer path computation under multiple constraints.On-going work. Early prototype API available 07/2009Interface for external experiment control tools or experiment managers.Custom XML-RPC built for Gush and DOME.These interfaces allow externally built-actors/tools to interact with a generic ORCA slice controller. We plan a generic XML-RPC interface for use by experiment control tools written in multiple languages. This interface supports a subset of ORCA resource reservation capabilities modeled after the ProtoGENI XML-RPC interface. TBD Management interfaceCurrent management interface is embedded in the portal attached to each container. Allows for implementation of custom plugins that implement management tasks.An extensible SOAP-based interface allowing ORCA to interface with management entities (e.g. GMOC, distributed network operations, visualization tools etc.). TBD  See feature/capability roadmap at the end of the document for full SOAP availability  See feature/capability roadmap at the end of the document for notes on enhancements to the configuration manager  See feature/capability roadmap for introduction of semantic resource representations using NDL  See feature/capability roadmap for XML-RPC enhancements  As of 05/2009     PAGE  PAGE 1 Ver. 1.1 www.geni.net RS    7 8 9 S T U V W X Y Z [ w x ѾwewwP)hT@iCJOJPJQJ^JaJmHnHu#j}hT@iUmHnHujhT@iUmHnHuhT@imHnHu*jh=hT@i0J UmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHujhM}UhM}hIdh 1hch`h9 hIdCJ aJ hIdCJ aJ SY . < I H 12gd9 gdM}1 ! * ! $ ! #gd`gdIdx y z  ( ) * + , - . / 0 L M ɾ׈iɾW׈#jqhT@iUmHnHu*jh=hT@i0J UmHnHuhT@imHnHu)hT@iCJOJPJQJ^JaJmHnHu#jwhT@iUmHnHujhT@iUmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHu*jh=hT@i0J UmHnHu M N O g h i   ɾ׈iɾW׈#jehT@iUmHnHu*jh=hT@i0J UmHnHuhT@imHnHu)hT@iCJOJPJQJ^JaJmHnHu#jkhT@iUmHnHujhT@iUmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHu*jh=hT@i0J UmHnHu       6 7 8 9 : ; < = > Z [ \ ] r s t ɾ׈iɾW׈#jYhT@iUmHnHu*jh=hT@i0J UmHnHuhT@imHnHu)hT@iCJOJPJQJ^JaJmHnHu#j_hT@iUmHnHujhT@iUmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHu*jh=hT@i0J UmHnHu     ' ( ) C D E F G H I J K g h ɾ׈iɾW׈#jMhT@iUmHnHu*jh=hT@i0J UmHnHuhT@imHnHu)hT@iCJOJPJQJ^JaJmHnHu#jShT@iUmHnHujhT@iUmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHu*jh=hT@i0J UmHnHu h i j   ɾ׈iɾW#jA hT@iUmHnHu*j h=hT@i0J UmHnHuhT@imHnHu)hT@iCJOJPJQJ^JaJmHnHu#jG hT@iUmHnHujhT@iUmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHu*jh=hT@i0J UmHnHu    % & ' A B C E F G H I J f g h i ɾהɔ~ɾlWɔ)hT@iCJOJPJQJ^JaJmHnHu#j5 hT@iUmHnHu*j h=hT@i0J UmHnHuhT@imHnHu#j; hT@iUmHnHujhT@iUmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHu*j h=hT@i0J UmHnHu   12I%y}Gɾ׈|xthYhYhYhYhYhYhYhYhYh<<h{CJOJQJaJh{CJOJQJaJh1*hIdhM}jhM}U)hT@iCJOJPJQJ^JaJmHnHu#j/ hT@iUmHnHujhT@iUmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHu*j h=hT@i0J UmHnHu"2HI9:xyHIJ89igdIdgdM}gd9 'gd{GIJ>?@A  "'NOaɺ{oooh.CJOJQJaJh&ORCJOJQJaJh)Ph)PCJOJQJaJh7CJOJQJaJh)PCJOJQJaJh&oCJOJQJaJh<<h&oCJOJQJaJh@ECJOJQJaJh CJOJQJaJ h"hJKhchIdh{h{CJOJQJaJ+?@ MN%ap'gd&o'gd)P'gdj'gdqKgdIdgd1*mpS,ACDGrPvͩ{rnnnnhhBh<<hhBCJ hhBCJhhBCJOJQJaJhSCJOJQJaJh&ORhShW;@hIdhIdCJOJQJaJh&ORCJOJQJaJhjCJOJQJaJh<<hjCJOJQJaJh&oCJOJQJaJh7CJOJQJaJh)PCJOJQJaJ+NO ,BC h  $Ifgd+\gdIdgdId'gdqK'gdj &!'gdqKkd $$Ifl\,"f  X  t(0"44 lap(yt+\ $Ifgd+\ !"<e $Ifgd+\gdhB'gdqK!"# e7 q r s v !"R"T"U"X" #r#$h$n$o$p$s$D%E%''s******* +H,I,J,K,Q,R,T,U,V,,,,żۨۨۨ۬۬۬פ h5)hQ@hQ@h_hUh.h.CJOJQJaJh<<h_hUCJ h_hUCJhIdCJOJQJaJhhBh&ORhhBCJOJQJaJh<<hhBCJ hhBCJ h&ORCJ>[/*%%gdhB'gdqKkd$$Ifl\,"f  X  t(0"44 lap(yt+\[B! 8 p $Ifgd+\'gdqKgdhB p q r /*! $Ifgd+\'gdqKkd$$Ifl\,"f  X  t(0"44 lap(yt+\ !"Q" $Ifgd+\Q"R"S"T"/**'gdqKkd$$Ifl\,"f  X  t(0"44 lap(yt+\T"m" ##?#s#$/$0$i$m$ $Ifgd+\ m$n$o$$/*! $Ifgd+\'gdqKkd $$Ifl\,"f  X  t(0"44 lap(yt+\$$;%C%D%&kd=$$Ifl\,"f  X     t(0"44 lap(yt+\ $Ifgd+\D%E%A&''s******* +T,U,~,,,,,%-?-w---gd&ORgdQ@gdhBgd_hU $^a$gd_hU$a$gd.'gdqK,,>-?-w------.J.Y.Z.x...V/W//////'030H0X0Y0Z0^00000000;1<1Q1R1U111111 2 2#2hjCJOJQJaJ h7:hjhcCJOJQJaJhIdCJOJQJaJh7CJOJQJaJhIdh-<h<<hhBCJOJQJaJh-<CJOJQJaJhhBhhBCJOJQJaJ h&ORh&ORh&ORhQ@2--.".Z...... /5/6/W/X////////////gdIdgd&ORgd-<gd_hUm$'gdhBgdhB'gdqK/00Y0Z00000;1P1Q1111 2#223O3P3Q3R3h3i3gdIdgdId dd[$\$gd7'gd7gdj'gdqK#2$2%2;2B2222222333N3O3P3R333333_44k555666666R7S7777/818S8T88889~~~~zvhbh&ORhc hCJh<<hCJhiCJOJQJaJhihhIdhIdCJOJQJaJhjCJOJQJaJhwCJOJQJaJh7CJOJQJaJhcCJOJQJaJh/hjPJ hjPJ h7PJ hcPJ.i33333384`44l5566^6_6666$Ifgd+\oզ $Ifgd+\$Ifgd+\oզ'gdqKgd6666(7/***gdikdZ$$Ifl\,"f  X  t(0"44 lap(yt+\(7P7Q7R77778/80818T8|8888895969790:::;gdb$a$gdbgdbgdb'gdqKgd&ORgdcgdcm$gdi9495979;;==>>@@BBBB$C%CiCjCRDYDZK[KQQRSSISJSTT)U*UWWXXYZZZ\\t]u]v]w]x]]]]@^A^B^^ h^Hhb hqKh=y hrhbhbhbCJ h3hb jhbhb0J5CJUhbhb5CJ h5)hbhzhb6 hb6 hvUhbh0JUh[ h)]hGh9 jh+\Uh+\ hW#hb h/bhbhbjhb0JU he hb%.:pll/ =!"#$% }DyK _Toc234229424}DyK _Toc234229424}DyK _Toc234229425}DyK _Toc234229425}DyK _Toc234229426}DyK _Toc234229426}DyK _Toc234229427}DyK _Toc234229427}DyK _Toc234229428}DyK _Toc234229428}DyK _Toc234229429}DyK _Toc234229429}DyK _Toc234229430}DyK _Toc234229430}DyK _Toc234229431}DyK _Toc234229431}DyK _Toc234229432}DyK _Toc234229432}DyK _Toc234229433}DyK _Toc234229433}DyK _Toc234229434}DyK _Toc234229434}DyK _Toc234229435}DyK _Toc234229435}DyK _Toc234229436}DyK _Toc234229436}DyK _Toc234229437}DyK _Toc234229437$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(yt+\$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(yt+\$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(yt+\$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(yt+\$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(yt+\$$If!vh5f5 5 5X#vf#v #v #vX:V l     t(0"5f5 5 5Xp(yt+\$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(yt+\$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(ytb$$If!vh5f5 5 5X#vf#v #v #vX:V l     t(0"5f5 5 5Xp(ytb$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(ytb$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(ytb$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(ytb$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(ytb$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(ytb$$If!vh5f5 5 5X#vf#v #v #vX:V l  t(0"5f5 5 5Xp(ytbj2 666666666vvvvvvvvv666666>6666666666666666666666666666666666666666666666666hH6666666666666666666666666666666666666666666666666666666666666666662 0@P`p2( 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p8XVx OJPJQJ_HmH nH sH tH D`D QNormalCJ^J_HaJmH sH tH j@j  -+0 Heading 1$$d@&\$'5B*CJ OJPJQJ\^JaJ ph4ZX@X \ Heading 2$<@&56CJPJ\]^JaJR@R m* Heading 3$<@&5CJPJ\^JaJDA`D Default Paragraph FontRi@R 0 Table Normal4 l4a (k ( 0No List XX  -+0Heading 1 Char#5B*CJ OJQJ\^JaJ ph4ZHH Q0 Balloon TextCJOJQJ^JaJNN 670Balloon Text CharCJOJQJ^JaJb>@b jBi0Title,POm$)@B* CJ4KHOJPJQJ^JaJ4ph:cRO1R jBi0 Title Char%@B* CJ4KHOJQJ^JaJ4ph:c4B4 jBi0InParaxx`@@R@ ( List Paragraph ^m$>@b> >p0 Footnote TextCJaJDqD >p0Footnote Text CharCJaJ@&@@ >p0Footnote ReferenceH*4@4 5]0Header !.. 5]0 Header Char4 @4 5]0Footer !.. 5]0 Footer Char.)@. 5]0 Page NumberRR m*Heading 3 Char5CJOJPJQJ\^JaJXX \Heading 2 Char$56CJOJPJQJ\]^JaJ6U@6 W%0 Hyperlink >*B*phVV W% Table text!d((CJOJPJQJ^JaJ:!: W%style41CJOJQJaJo(` A` Cp TOC Heading#d@& \$B*CJOJQJ^JaJph6_&@& CpTOC 1$eR &L0HTML Preformatted7%2( Px 4 #\'*.25@9!B*CJOJPJQJ^JaJph^a^ %L0HTML Preformatted CharB*OJPJQJ^JphHZ@rH (@0 Plain Text'CJOJ PJQJ ^JaJNN '@0Plain Text CharCJOJ PJQJ ^JaJFVF 90FollowedHyperlink >*B* ph*@* 9pTOC 2*^R^R 9 0 Normal (Web)+dd[$\$OJPJQJ^J  9 iconB'B <<0Comment ReferenceCJaJHH /<<0 Comment Text.OJPJQJ^JRR .<<0Comment Text CharCJOJPJQJ^JaJzz << Table Grid7:V000OJPJQJ^J.@. T@ipTOC 3 1^PK![Content_Types].xmlj0Eжr(΢Iw},-j4 wP-t#bΙ{UTU^hd}㨫)*1P' ^W0)T9<l#$yi};~@(Hu* Dנz/0ǰ $ X3aZ,D0j~3߶b~i>3\`?/[G\!-Rk.sԻ..a濭?PK!֧6 _rels/.relsj0 }Q%v/C/}(h"O = C?hv=Ʌ%[xp{۵_Pѣ<1H0ORBdJE4b$q_6LR7`0̞O,En7Lib/SeеPK!kytheme/theme/themeManager.xml M @}w7c(EbˮCAǠҟ7՛K Y, e.|,H,lxɴIsQ}#Ր ֵ+!,^$j=GW)E+& 8PK!Ptheme/theme/theme1.xmlYOo6w toc'vuر-MniP@I}úama[إ4:lЯGRX^6؊>$ !)O^rC$y@/yH*񄴽)޵߻UDb`}"qۋJחX^)I`nEp)liV[]1M<OP6r=zgbIguSebORD۫qu gZo~ٺlAplxpT0+[}`jzAV2Fi@qv֬5\|ʜ̭NleXdsjcs7f W+Ն7`g ȘJj|h(KD- dXiJ؇(x$( :;˹! I_TS 1?E??ZBΪmU/?~xY'y5g&΋/ɋ>GMGeD3Vq%'#q$8K)fw9:ĵ x}rxwr:\TZaG*y8IjbRc|XŻǿI u3KGnD1NIBs RuK>V.EL+M2#'fi ~V vl{u8zH *:(W☕ ~JTe\O*tHGHY}KNP*ݾ˦TѼ9/#A7qZ$*c?qUnwN%Oi4 =3ڗP 1Pm \\9Mؓ2aD];Yt\[x]}Wr|]g- eW )6-rCSj id DЇAΜIqbJ#x꺃 6k#ASh&ʌt(Q%p%m&]caSl=X\P1Mh9MVdDAaVB[݈fJíP|8 քAV^f Hn- "d>znNJ ة>b&2vKyϼD:,AGm\nziÙ.uχYC6OMf3or$5NHT[XF64T,ќM0E)`#5XY`פ;%1U٥m;R>QD DcpU'&LE/pm%]8firS4d 7y\`JnίI R3U~7+׸#m qBiDi*L69mY&iHE=(K&N!V.KeLDĕ{D vEꦚdeNƟe(MN9ߜR6&3(a/DUz<{ˊYȳV)9Z[4^n5!J?Q3eBoCM m<.vpIYfZY_p[=al-Y}Nc͙ŋ4vfavl'SA8|*u{-ߟ0%M07%<ҍPK! ѐ'theme/theme/_rels/themeManager.xml.relsM 0wooӺ&݈Э5 6?$Q ,.aic21h:qm@RN;d`o7gK(M&$R(.1r'JЊT8V"AȻHu}|$b{P8g/]QAsم(#L[PK-![Content_Types].xmlPK-!֧6 +_rels/.relsPK-!kytheme/theme/themeManager.xmlPK-!Ptheme/theme/theme1.xmlPK-! ѐ' theme/theme/_rels/themeManager.xml.relsPK] 36i;ZCK-WW+eux-W >>>Ax M  h  G,#29^-_02345678:<@JMQ_2 [p Q"T"m$$D%-/i36(7; SJST U@UWX$ZZ\t]w]-_19;=>?ABCDEFGHIKLNOPRSTUVWXYZ[\]^8TVWYy )+,.Nh79:<\s(DFGIi&BEFHh -W X%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%T̕!#A!!\# AA@H X0(  X0(  B S  ?A _Toc223505258 _Toc222304945 _Toc222642379 _Toc234229424 _Toc234229425 _Toc222642773 _Toc223505260 _Toc234229426 _Toc234229427 _Toc234229428 _Toc234229429 _Toc234229430 _Toc234229431 _Toc234229432 _Toc234229433 _Toc234229434 _Toc234229435 _Toc234229436 _Toc234229437J 'R+0288'A^CI.W 0 'g+12884ACJ.W F J t z s{()%op6>?!G!##l'p'''U)Y)));*A***++--....55L8S8::= = ==????sD{D{GG-I5INNOOSTTTwUVVVVVVVVVVVV+W.WV ` d e z((4t"w"""$$w%%%%&&L&Y&''J(X(((* *++R+g+ --0044}BBIIOP#hx1%Qm%6T#s<&*=s*<&#s[0-<&`LZw.)@S)@1{\\zp&76T`M:S)@1;] eb;6T#sN<)@ Z*xaA&BM:AFF;WGWXJwLjO,>#ODP6T T-VAYZ6T`t`[{\\`Q\`(Ub6T`0cf<&#ssj<&`ckWGbr |ck}(}.M~$M j<&#s0aj|Dzj), ` --A@-*^zS7= 9 ?F x e ) d x 3!bz~-GaL@g>foA|(,1SKOt)@>@N <qYq'._ @!U!""i"##,#%]%a%8?&4p&}&>'6'Nr'v#(O5(o)u)z*>*1*{*$+ -+>?+c+/>R/=w/0 1r71|]1f1E-2]e4v45[!5.65+_55`64)7(99 :7:\E:-<<< =ZC=K=i=k=w=df>hv>W;@BS:C~CqED@EfFRqFxFbHLI~(JtJ K&KbKqdKqKlL|FMOTM8NO9O4?ON)P|nPPQ|Q&OR$S'{TwU|pepufphsys[tiat(tu<&vgwwDwCx=y[yvoy{K{N{5|H|}M}q|}~}x~R&DL^f<(4H$]^4JqL(L%YVaCJ]KV1EJKLDU`:1tt$6b (2 EN&oiru;j{/X4fpHY1{Q@s+[zeCXa%-P* 0?7Z %9 w;sm*_:bw-O4oh9?&:<z/32nafjnK3z@*N CPS9b#}q9;J>]S'>2[F*.m O[,=q@RKd"g =a67r|/ X"x;cM<OF &/Sv~Yz}v]S@&)$bo0rMf6EO+-*)P.}E$]I( Ecz #< xg@iX{KqyaF5]Npr&RPQsc#%C 9W%g+Y`6\^e7hB(FMZl!+8^h4e+I}wUyU@-W@Unknown Jeff Chase G* Times New Roman5Symbol3. * Arial7.{ @Calibri7K@Cambria[Lucida GrandeCourier New;|i0Batang7.  Verdana?= * Courier New9=  K @Consolas;WingdingsA BCambria Math"1hi&( f fm H + I ,!4dLUV >qHP $Pfp2! xx Harry Mussman Harry Mussmanl                   Oh+'0 ( H T ` lxHarry Mussman Normal.dotmHarry Mussman109Microsoft Office Word@F8O}@@@)=@G  HGVT$m h&" WMFCF $s$lVT$m EMF$U"   % %  Rp@Cambria@ 8@ @ @ P`2@ @ @ @ O`2@ @ jEU1@ @ !FU1%4X$7K@Cambri O!@ 2@ PM1@ @ =RK1,@ !dv% % %  TT , UU@@ LP ITT ,F UU@@ LP F;!"  Tl'UU@@LXVer. 8<1)TT'UU@@LP1k7TX'1UU@@LP.17TT2'UU@@2LP IT' UU@@ Ldwww.geni.netMMM11881"TT 'UU@@ LP {TT'UU@@LP ITT'NUU@@LP [;!" !' TT'UU@@L'P1k7TT'UU@@L'P I;!'" "  Rp{@"Calibri,P`2tO`2 jEU1 \+FU1'4X%7.{ @Calibr`A`2&0a<+,]PM1=RK1 \+dv% % %  :cT,W UU@@%LGENI Goals for Spiral 2, and Cluster aVCX$ VHB!6 )H0!?H"-B! F# BHH!I!H5.D0!TT W UU@@ LPDTTT W. UU@@ LP T/ WUU@@/ LRoadmap to end of Spiral HH@IlBH .H DIH G+ ?H"-B!    :cTUU@@zLp1 and for Spiral 2E BHH )H1 ?H"-B! FTTUU@@zLP P ! 'O% Ld (!??% ( "  % % % ThD UU@@/LRevised during conference call on June 11, 2009 >12+1777)81,581)28,1,158781777787TT D& UU@@ LP ; T-UU@@ L`Additions >77"58+T`$-UU@@LTon 58T%-UU@@% LdJuly 1, 20097278787TTX-UU@@LP ; TH/ UU@@*LNeeds to be finalized in Cluster D meetingD117+"57181-17887+"1)BS11"81TT / UU@@ LP T /r UU@@ Llon July 2, 2009587277878TTs / UU@@s LP ; TT(UU@@LP ; Rp@Cambria@ 8@ @ @ P`2@ @ @ @ O`2@ @ jEU1@ @ &FU1%4X$7K@Cambri j A`2:bk%]@ PM1@ @ =RK1,@ &dv% % %  6_T|hUU@@OL\ContentsCCF+>F+5TT hUU@@OLP E  % % % T~$UU@@L1. GENI goals for Spiral 27=:D 151+5)28)17TT%~7UU@@%LP T 8~ UU@@8 L................................T  ~w UU@@  L................................T x ~UU@@x  L................................T~UU@@Lt....................TT~UU@@LP TT~UU@@LP17Rp@"Calibri@ X@ @ <@ P`2@ @ $@ @ O`2@ @ jEU1@ @ <)FU1'4X%7.{ @Calibrc A`2bk)d]@ PM1$@ $@ =RK1L@ <)dv% % % TT/UU@@LP 6!"  % % % T% hUU@@S:L2. Cluster E &" WMFC $S$ roadmap to end of Spiral 1 and for Spiral 2787+"1):)517S18"5187528)171875*28)17TT& 8 hUU@@& SLP T 9 hUU@@9 S L................................ThUU@@SL|.......................TThUU@@SLP TThUU@@SLP2@7% % % TT/kUU@@SLP 6!"  % % % TRiUU@@RLx2.1 Live Experiments77621:081)S18"*TTiUU@@LP T i UU@@ L................................T  i8 UU@@  L................................T 9 iUU@@9  L................................TiUU@@L|.......................TTiUU@@LP TTiUU@@LP2@7% % % TTp/UU@@LP 6!"  % % % TRR UU@@R= L|2.2 Identity Management77 718""2R18111S18"TTR UU@@= LP T @ R UU@@= L................................T A  R UU@@A = L................................T  R UU@@ = L................................TR UU@@= Ll...............TTR UU@@= LP TTR UU@@= LP3@7% % % TT/U UU@@= LP 6!"  % % % TRS  UU@@R L2.3 Improved Integration77 S8)5227 8"11)1"58TTS  UU@@ LP T S @ UU@@ L................................T A S UU@@A L................................T  S  UU@@ L................................TS  UU@@ Ll...............TTS  UU@@ LP TTS  UU@@ LP3@7% % % TTZ / UU@@ LP 6!"  % % % TR = UU@@R( Lt2.4 Instrumentation77 8+")7S18"1"58TT = UU@@( LP T  n = UU@@( L................................T o  = UU@@o ( L................................T  = UU@@ ( L................................T = UU@@( L.........................TT = UU@@( LP TT = UU@@( LP6@7% % % TT /@ UU@@( LP 6!"  % % % TR>  UU@@R Lx2.5 Interoperability77 8"1)581)17"2TT> &" WMFC $3$ UU@@ LP T > Y UU@@ L................................T Z > UU@@Z L................................T  >  UU@@ L................................T>  UU@@ L..........................TT>  UU@@ LP TT>  UU@@ LP7@7% % % TTE / UU@@ LP 6!"  % % % T ' UU@@ L3. ORCA Integration Roadmap7A>8> 8"12)1"58>517S18TT ' UU@@ LP T   ' UU@@  L................................T  I ' UU@@  L................................T J ' UU@@J  L................................T ' UU@@ L`..........TT ' UU@@ LP TT ' UU@@ LP9@7% % % TT /* UU@@ LP 6!"  % % % TR(  UU@@R LtBrief ORCA overview=)1A>8>621)21NTT(  UU@@ LP T ( UU@@ L................................T  ( # UU@@ L................................T $ (  UU@@$ L................................T(  UU@@ L|........................TT(  UU@@ LP TT(  UU@@ LP9@7% % % TT/ / UU@@ LP 6!"  % % % TR g UU@@R LSoftware integration overview25"M1)18"11)1"58521)21NTTh r UU@@h LP T s   UU@@s L................................T   UU@@ L................................T  R UU@@ L................................TXS | UU@@S LP..TT}  UU@@} LP TX  UU@@ LP1078% % % TT / UU@@ LP 6!"  % % % T N UU@@r L`Substrate277+")1"0TTO T UU@@Or LP T U  UU@@Ur L................................T  UU@@r L................................T   4 UU@@ r L................................T 5   UU@@5 r L................................T| | UU@@r L\........TT}  UU@@}r LP TX  UU@@r LP1078TT 4 UU@@r LP ;!"  T  UU@@ &" WMFC $$LhPortals/tools95)"1+1"55+TT  UU@@ LP T   UU@@ L................................T  < UU@@ L................................T = UU@@= L................................T  | UU@@ L................................TT}  UU@@} LP TX  UU@@ LP1078TT 4 UU@@ LP ;!"  % % % T R E q UU@@R\ #LInfrastructure integration overview 8)1+")7,"8)18"11)1"58521)21NTTF Y q UU@@F \ LP T Z q UU@@Z \ L................................T  q UU@@ \ L................................T |q UU@@\ L|.......................TT} q UU@@}\ LP TX q UU@@\ LP1178% % % TT /t UU@@\ LP 6!"  % % % TRr  UU@@R LpORCA feature/capaA>8>11"7)11,181Tr  UU@@ Lhbility roadmap7"2)517S19TTr  UU@@ LP T  r UU@@ L................................T  r E UU@@ L................................TFr | UU@@F L...........................TT}r  UU@@} LP TXr  UU@@ LP1178% % % TTy / UU@@ LP 6!"  % % % TT (\UU@@GLP ; TT](UU@@LP ; Rp{@"Calibri@ 8@ @ @ P`2@ @ @ @ O`2@ @ jEU1@ @ L*FU1'4X%7.{ @CalibrA`2:bk,*T\@ PM1@ @ =RK1,@ L*dv% % %  4ZTW;UU@@L1. GENI goals for Spiral 2C$UAX#?HB!5*H/?G!/B!DTTX;UU@@XLP O  % % % TT(&UU@@LP ; Td'vUU@@LT1) 7&TTw'UU@@wLP-!T'zUU@@LlLive experiments6211081)S18"+TT{'UU@@{LP ; TT(UU@@LP ; TUU@@pKLThe central goal of Spiral 2 is to support significant numbers of research ;71,18")1151528)17+"5+7885)"+18,18"87S71)+5)1+11),7 TUU@@Lxexperiments in the end1081)S18"+8"71087TTUU@@LP-!TX<UU@@LPto"5TT=]UU@@=LP-!T^U UU@@^ Ldend prototy@1878)5"5"2TU A UU@@U  Ldpe systems.@81+2+"1S+TTB | UU@@B LP ; TT(pUU@@[LP ; T@qUU@@SLThe GPO expects live experimentation to begin near the end of Spiral 1, which will ;71=9A1081,"+211081)S18" &FWMFC$$1"58"57118811)"71187528)17M7,7M TZUU@@EMLintensify through Spiral 2 as we begin continuous operation of the prototype 8"18+2"7)571728)171+M17118,58"8757+581)1"585"718)5"5"281 T@\9UU@@SLsystems. This will begin to give us all substantial (early) operational experience+2+"1S+;7+M7118"51217+1+77+"18"1&11)2&581)1"5811081)18,1Tl:\UU@@:LX, as 1+ TEUU@@0HLthese experiments will help us all understand the prototypes' strengths "71+11081)S18"+M7187+17871)+"187#718)5"5"281++")181"6+TdEUU@@0LTand 187 TFUU@@Lweakness, which will drive M11481++M7,7M8*21TFz UU@@Ltour Spiral 3 goals.57)28)17151+TT{ F UU@@{ LP ; TT(/UU@@LP ; T0D UU@@=LAdditionally, we expect development in Spiral 2 to emphasize:>77"5812M11081,"712158S18"828)16"51S871+-1TTE 0 UU@@E LP ; TT(UU@@LP ;% % 666666666666666666666666666666666666 6 66 6  6 66 6  6 66 6  6 66 6  6 66 6 66666666666666666666  DK."System--@Cambria---  2 AJD d 2 AJD d ,DJ'2 |JDVer. .  2 JD1d 2 JD.1 2 JD d2 t JDwww.geni.net     2 JD d 2 JD d 2 JD d ,DJ', 2 1d 2  d ,''@"Calibri--- :cC2 x|%JDGENI Goals for Spiral 2, and Cluster             2 xJDDd 2 xJD d12 xJDRoadmap to end of Spiral         :c&2 |JD1 and for Spiral 2      2 JD d  ,DJO- @ !Vz-'---R2 |/JDRevised during conference call on June 11, 2009          2 JD d 2 | JDAdditions  2 JDon  2 JDJuly 1, 2009   2 -JD d J2 |*JDNeeds to be finalized in Cluster D meeting           2 JD d"2 JDon July 2, 2009     2 JD d  2 |JD d @Cambria--- 6_2 6|JDContents   2 6JD d  ---42 M|JD1. GENI goals for Spiral 2       2 M.JD d;2 M1 JD................................;2 M JD................................;2 M JD................................)2 M~JD.................... 2 MJD d 2 MJD1d @"Calibri--- 2 MJD d ,DJ'---b2 a|:JD2. Cluster E roadmap to end of Spiral 1 and for Spiral 2               2 aJD d;2 a JD.................................2 asJD....................... 2 aJD d 2 aJD2d --- 2 aJD d ,DJ'---+2 tJD2.1 Live Experiments.       2 t$JD d;2 t' JD................................;2 t JD................................;2 t JD.................................2 tsJD....................... 2 tJD d 2 tJD2d --- 2 tJD d ,DJ'---/2 JD2.2 Identity Management         2 @JD d;2 B JD................................;2  JD................................;2   JD................................"2 JD............... 2 JD d 2 JD3d --- 2 JD d ,DJ'---12 JD2.3 Improved Integration       2 BJD d;2 B JD................................;2  JD................................;2   JD................................"2 JD............... 2 JD d 2 JD3d --- 2 JD d ,DJ'---)2 JD2.4 Instrumentation      2 JD d;2   JD................................;2  JD................................;2  JD................................12 lJD.......................... 2 JD d 2 JD6d --- 2 JD d ,DJ'---+2 JD2.5 Interoperabilitye      2 JD d;2  JD................................;2  JD................................;2  JD................................22 iJD.......................... 2 JD d 2 JD7d --- 2 JD d ,DJ'---52 |JD3. ORCA Integration Roadmap       2 RJD d;2 T JD................................;2  JD................................;2 1 JD................................2  JD.......... 2 JD d 2 JD9d --- 2 JD d ,DJ'---(2 JDBrief ORCA overviewt     2  JD d;2 # JD................................;2  JD................................;2  JD................................/2 pJD........................ 2 JD d 2 JD9d --- 2 JD d ,DJ'---72 JDSoftware integration overview        2 cJD d;2 e JD................................;2  JD................................;2 C JD................................2 JD.. 2 JD d2 JD10 --- 2 JD d ,DJ'---2  JDSubstrate  2 JD d;2  JD................................;2 P JD................................;2  JD................................;2 . JD................................2 JD........ 2 JD d2 JD10 2 JD d ,DJ'2 # JDPortals/tools   2 #JD d;2 # JD................................;2 #l JD................................;2 # JD................................;2 #J JD................................ 2 #JD d2 #JD10 2 #JD d ,DJ'---@2 6#JDInfrastructure integration overviewr       2 6JD d;2 6 JD................................;2 6 JD.................................2 6iJD....................... 2 6JD d2 6JD11 --- 2 6JD d ,DJ'---%2 IJDORCA feature/capa    2 IJDbility roadmap   2 I|JD d;2 I} JD................................;2 I JD................................42 I[JD............................ 2 IJD d2 IJD11 --- 2 IJD d ,DJ'--- 2 ]|JD d  2 p|JD d @"Calibri--- 4Z42 |JD1. GENI goals for Spiral 2        2 aJD d  --- 2 |JD d 2 |JD1)  2 JD-d#2 JDLive experiments     2 JD d  2 |JD d |2 |KJDThe central goal of Spiral 2 is to support significant numbers of research             ,2 !|JDexperiments in the end      2 !JD-d2 !#JDto 2 !2JD-d2 !7 JDend prototy   2 ! JDpe systems.   2 !JD d  2 4|JD d 2 G|SJDThe GPO expects live experimentation to begin near the end of Spiral 1, which will                     2 [|MJDintensify through Spiral 2 as we begin continuous operation of the prototype                     2 n|SJDsystems. This will begin to give us all substantial (early) operational experience             2 nJD, as .w2 |HJDthese experiments will help us all understand the prototypes' strengths                 2 uJDand  42 |JDweakness, which will drive      (2 =JDour Spiral 3 goals.     2 JD d  2 |JD d g2 |=JDAdditionally, we expect development in Spiral 2 to emphasize:            2 1JD d  2 |JD d --DDJJDDJJDDIIDDIIDDIIDDIICCIICCIICCHHCCHHCCHHCCHHBBHHBBHHBBGGBBGGBBGGBBGGAAGG՜.+,D՜.+,4 hp   UC Davis+LU 1. GENI goals for Spiral 2;2. Cluster E roadmap to end of Spiral 1 and for Spiral 2 2.1 Live Experiments 2.2 Identity Management 2.3 Improved Integration 2.4 Instrumentation 2.5 Interoperability3. ORCA Integration Roadmap Brief ORCA overview" Software integration overview Substrate Portals/tools( Infrastructure integration overview$ ORCA feature/capability roadmap Title Headings 8@ _PID_HLINKSAdT0P_Toc2342294370J_Toc2342294360D_Toc2342294350>_Toc23422943408_Toc23422943302_Toc2342294320,_Toc2342294310&_Toc2342294300 _Toc2342294290_Toc2342294280_Toc2342294270_Toc2342294260_Toc2342294250_Toc234229424  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`bcdefghijklmnoprstuvwxyz{|}~      !&Root Entry F(Data a_1Tableq}WordDocument0SummaryInformation(DocumentSummaryInformation8CompObjy  F'Microsoft Office Word 97-2003 Document MSWordDocWord.Document.89q