ࡱ> 79456 dbjbj 0[v?"+++8cT+jzC Q""s"s"s"_$y&'Pyyyyyyy$X}^ye'[$[$e'e'ys"s"z,M1M1M1e's"s"yM1e'yM1M1h,ms"0 +'*Vj6y.z<jzjX},nXlmmRX/re'e'M1e'e'e'e'e'yy.be'e'e'jze'e'e'e'Xe'e'e'e'e'e'e'e'e' : 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 Revised after 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? Karen Bergman, Measurement Project 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.) Deploy on busses this summer. Offer to undergraduate class in fall on Introduction to Networking; 39 students; expect 1-2 projects using 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?) See slides. Likely: Rapidly deployable sensor node. e) What experiments can be done with Kansei by the end of Spiral 1? See slides. Keep old Kanasei interface, as well as new ORCA-Kansei interface. Expect internal researchers, federation. 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? Sensors with clouds Content with buses Buses with radar 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? Dome login on sc local db Kansei local db 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. H Sol2 Shibboleth at unc and duke Supports direct login by user at portal Have used shibboleth in portal to actor shibboleth plugins for apache and tomcat jeff not too hard 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 done b) Simplify admin and operation of security mechanisms between servers, and messages between actors. Distribution of keys? Manual ugly not scale requires documentation security look H c) Privacy not currently provided for messages between actors; add with https? Not soon M 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 2009Important ant is too limitedWho does work handler or next portalH 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/2009H 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/2009H 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 manipulationTBDH i) ORCA clearinghouseNo externally accessible clearinghouse available.Externally accessible clearinghouse maintained as a production capability. Ready to accept broker implementations from other teams07/2009H 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 J,k,l: H 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? See slides q) VLANs from DOME/ViSE to Internet2? See slides r) VLANs from Kansei to Internet2? See slides 2.4 Instrumentation a) GMOC feed from ORCA actors. b) Better way to parse and understand logs in ORCA actors. Better working on it c) Way to examine and decode ORCA messages. Only via logs? d) BEN: not much for solicitation 1; proposal written for solicitation 2. Experiment tool support 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 data to researcher data to repository embargo for some time see orbit for repository GMOC feed from DOME f) ViSE: rudimentary monitoring of the nodes, their wireless connectivity also xen stats GMOC feed from ViSE Radar 10Mbps - 100Mbps continuous time-stamped 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" Store data at source, process it there? Data between sensor fabrics, and to clouds Towards producer consumer network h) Plan for Embedded Real-Time Measurements in Spiral 2? H Prototype hardware Interface with BEN Interface with cf i) also from paul barford, etc. 2.5 Interoperability Interoperability with other clusters would be very helpful in Spiral 2. How to utilize multiple clusters 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 H 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    , - . H I J K L M N ͺsassL)hT@iCJOJPJQJ^JaJmHnHu#j}hT@iUmHnHujhT@iUmHnHuhT@imHnHu*jh=hT@i0J UmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHujhM}UhM}hIdhc[h 1hch`h9 hIdCJ aJ hIdCJ aJ SN # ~ 1 > =   &'gd9 gdM}1 ! * ! $ ! #gd`gdIdN O P l m n o       ! " # $ % ߵiߵW#jqhT@iUmHnHu*jh=hT@i0J UmHnHu)hT@iCJOJPJQJ^JaJmHnHu#jwhT@iUmHnHujhT@iUmHnHuhT@imHnHu*jh=hT@i0J UmHnHuhT@imHnHuh=hT@i0J mHnHu$jh=hT@i0J UmHnHu"% A B C D \ ] ^ x y z { | } ~  ҿ败~h败V~#jehT@iUmHnHu*jh=hT@i0J UmHnHu)hT@iCJOJPJQJ^JaJmHnHu#jkhT@iUmHnHujhT@iUmHnHuhT@imHnHu$jh=hT@i0J UmHnHu*jh=hT@i0J UmHnHuh=hT@i0J mHnHuhT@imHnHu!    + , - . / 0 1 2 3 O P Q R g h i 񽮽ȇ~h񽮽Vȇ~#jYhT@iUmHnHu*jh=hT@i0J UmHnHuhT@imHnHu)hT@iCJOJPJQJ^JaJmHnHu#j_hT@iUmHnHujhT@iUmHnHuhT@imHnHu$jh=hT@i0J UmHnHu*jh=hT@i0J UmHnHuh=hT@i0J mHnHu!       8 9 : ; < = > ? @ \ ] ɾ׈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 ] ^ _ | } ~ ɾ׈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    6 7 8 : ; < = > ? [ \ ] ^ ɾהɔ~ɾ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  &'>nr<ɾ׈|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"'=>./mn=>?z{-.^gdIdgdM}gd9 'gd{<>?z{34WXYpqr,-.r2ɺ{{oh&ORCJOJQJaJh)Ph)PCJOJQJaJhc[CJOJQJaJh7CJOJQJaJh)PCJOJQJaJh&oCJOJQJaJh<<h&oCJOJQJaJh@ECJOJQJaJh CJOJQJaJ h"hJKhchIdh{h{CJOJQJaJ+4WXpq,-r~3{'gd&o'gd)P'gdj'gdqKgdIdgd1* CD+,CDWXijklmLMrsgdIdgdId'gdqK'gdj'gd&oCDEH *+jklm.JMHjlm赩~z~zvzrznzvnv~rz~z~z~h&ORh7E7788 8U8V8͵hwCJOJQJaJ hEhPJh/hjPJ hjPJ h7PJ hcPJhEhCJOJQJaJhBCJOJQJaJhjCJOJQJaJ h7:hEhhEhhjhcCJOJQJaJh7CJOJQJaJ566'777788V8X8Y8l8m88888888888899=9gdgdIdgdId dd[$\$gd7'gd7V8W8X8Y8888888888999=9{9|99%::;;M<T<U<V<W<X<z<<<<!=7=9=====v>w>x>>>>>CADABCȴġĝĝĝĝęܴjhb0JUhT@ihbh&ORhchc[ hCJh<<hCJhiCJOJQJaJhEhhihhIdhwCJOJQJaJhIdCJOJQJaJhEhCJOJQJaJhc[CJOJQJaJ2=9>9?9{9|999&::;;;;;N<R<S<$Ifgd+\oզ $Ifgd+\$Ifgd+\oզ'gdqKgdS<T<V<W<</***gdikd$$Ifl\,"f  X  t(0"44 lap(yt+\<<<<<9=W=s====== >0>v>w>x>>>>>?m@@gdb$a$gdbgdbgdb'gdqKgd&ORgdcgdcm$gdi@XAAuB CDSFqF{FHXKQMNNPQ RS=VWWX $ & Fa$gdb $ & Fa$gdbgdbgdb$a$gdb  & FgdbgdbBCHCMDNDzF{FqHrHHHHHHHIIPPWWXXXXXYYZZ%]&]d^e^__aaccccc[c\c]cccc/d0d1didijĬ he hb h^Hhb hqKh=y hrhbhbhbCJ h3hb jhbhb0J5CJUhbhb5CJ h5)hbhzhb6 hb6 hvUhbjhb0JUhbh0JUh[ h)]hGh9 jhHUhH hW#hbhbjhb0JU h/bhb"ddgdb.: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(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:cR1R 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] C9M<@HP\W+eux\ >>>AN % ] <m$"/3V8BCidd356789:;=@BKUXZ_l's !2!5!###%%''((Q1H36=9S<<@XXYZZ%],^^0`abcdd4<>?ACDEFGHIJLMNOPQRSTVWY[\]^`abcdefghijkm-IKLNn !#C]y{|~,./1Qh9;<>^} 7:;=]\ 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 _Toc234229437 ? mH+0y6m8S>q>FHO\  %y \+068p>z>FIO\ S Y syIQFMgkGKs|PW!!$$&'Z(_(**&+,+----....>/D/00000000J1S1n3w333 4)4V4V4B;H;==q@r@BBBB'E.EBEJEJ J MMNN5T;TUUYY6Z=Z[{\{\}\}\~\~\\\\\\\\\K U Y Z @ E "*mz %:.;%%?&c&t'x'[(_(()))))H+\+,,?,J,----....00000022V4W406s6@:U: HH6O:OUUXX[{\{\}\}\~\~\\\\\\\\\33333333333333333333333333333333333333333-L!]|/h<};3 V o + q 57 Y(c(Q)S))***** ++;+E+.B./0U0000001<1T4V4[{\{\}\}\~\~\\\\\\\\\\\\\\\-L!]|/h<};3 V o + q 57 Y(c(Q)S))***** ++;+E+.B./0U0000001<1T4V4[{\{\}\}\~\~\\\\\\\\\\\\\gr~K[:^pRbL#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>foAp'|(,1SKEhOt)@>@N <qYq'._ @!U!""i"##,#%]%a%8?&4p&}&>'6'Nr'v#(O5(o)u)z*>*1*{*$+ -+>?+c+/>R/=w/0 1r71|]1f1E-2f3]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]S'>2[F*.m O[,=q@RKd"g =a67r|/ X"x;cM<OF &/Sv~Yz}v]S@&)$bo0rMf6EO+-*)P.}E$]I(Al Ecz #< xg@iX{KqyaF5]Npr&RPQsc#%C 9W%g+Y`6\^e7hB(FMZl!+8^h4eB+I}[[@V4V4("V4V4@{\p@Unknown Jeff Chase G* Times New Roman5Symbol3. * Arial7.{ @Calibri7K@Cambria[Lucida GrandeCourier New;|i0Batang7.  Verdana?= * Courier New9=  K @Consolas;WingdingsA BCambria Math"1hi&F fo pM. N/!4dZK\ >qHP $Pfp2! xx Harry Mussman Harry Mussmanl                   Oh+'00 ( H T ` lxHarry Mussman Normal.dotmHarry Mussman111Microsoft Office Word@:@@@)=@` pMGVT$m h&" WMFCl rܒlVT$m EMFܒU"   % %  Rp@Cambria pP`2phTO`2ph jEU1hp lFU1MoX$7K@CambrihQT1XhPM1=RK1ldv% % %  TT , UU@@ LP TT ,F UU@@ LP ;!"  T`'UU@@LTVer<1)TX'UU@@LP. T`'1UU@@LT1.177TT2'UU@@2LP T' UU@@ Ldwww.geni.netMMM11881"TT 'UU@@ LP TT'UU@@LP TT'NUU@@LP ;!" !' TT'UU@@L'P17TT'UU@@L'P ;!'" "  Rp{@"Calibri,P`2tO`2 jEU1 |FU1-CX%7.{ @Calibr`2$nP1PM1=RK1 |dv% % %  :cTWUU@@@LGENI Goals for Spiral 2, and Cluster D Roadmap to end of Spiral VCX$ VHB!6 )H0!?H"-B! F# BHH!I!H5.D0!T 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@@LAdditions on July 1, 2009>77"58+587278787TTX-UU@@LP ; TT/+UU@@LPR>T,/UU@@, Ldevised after12+171"1)TT/4UU@@LP T5/0UU@@5LpCluster D meeting87+"1)BS11"81TT1/FUU@@1LP TG/ UU@@GLlon July 2, 2009587277778TT / UU@@ LP ; TT(UU@@LP ; Rp@Cambria pP`2phTO`2ph jEU1hp FU1MoX$7K@CambrihQT1XhPM1=RK1dv% % %  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,P`2tO`2 jEU1 FU1-CX%7.{ @Calibr1("M("|PM1=RK1 dv% % % TT/UU@@LP 6!"  % % % T% hUU@@S:L2. Cluster E roadmap to end of Spiral 1 and for Spiral 2787+"1):)517S18"51875&" WMFC Rܒ28)171875*28)17TT& 8 hUU@@& SLP T 9 hUU@@9 S L................................ThUU@@SL|.......................TThUU@@SLP TThUU@@SLP27% % % TT/kUU@@SLP 6!"  % % % TRiUU@@R L`2.1 Live77621TTiUU@@LP TiUU@@ LdExperiments:081)S18"*TTiUU@@LP T i UU@@ L................................T  i8 UU@@  L................................T 9 iUU@@9  L................................TiUU@@L|.......................TTiUU@@LP TTiUU@@LP27% % % 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@@= LP37% % % 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@@ LP37% % % 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@@( LP67% % % TT /@ UU@@( LP 6!"  % % % TR>  UU@@R Lx2.5 Interoperability77 8"1)581)17"2TT>  UU@@ LP &" WMFC 2ܒT > Y UU@@ L................................T Z > UU@@Z L................................T  >  UU@@ L................................T>  UU@@ L..........................TT>  UU@@ LP TT>  UU@@ LP77% % % 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@@ LP97% % % 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@@ LP97% % % 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@@ LhPortals/tools95&" WMFC ܒ)"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 LORCA feature/capability roadmapA>8>11"7)11,1817"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 pP`2phTO`2ph jEU1hp FU1-CX%7.{ @CalibrhQT1XhPM1=RK1dv% % %  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^A UU@@^Lxend prototype systems.1878)5"5"281+2+"1S+TTB | UU@@B LP ; TT(pUU@@[LP ; Tq UU@@:LThe GPO expects live experimentation to begin near the end;71=9A1081,"+211081)S18"1"58"57118811)"71187TT q UU@@ LP T qUU@@ L|of &WMFCܒ Spiral 1, which will 528)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\\UU@@XLsystems. This will begin to give us all substantial (early) operational experience, as +2+"1S+;7+M7118"51217+1+77+"18"1&11)2&581)1"5811081)18,11+ T EUU@@0BLthese experiments will help us all understand the prototypes' stre"71+11081)S18"+M7187+17871)+"187#718)5"5"281++")1Tp EUU@@ 0LXngths 81"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  2 AJD ,DJ'2 |JDVer 2 JD. 2 JD1.1  2 JD 2 t JDwww.geni.net     2 JD 2 JD  2 JD ,DJ', 2 1 2  ,''@"Calibri--- :ck2 x|@JDGENI Goals for Spiral 2, and Cluster D Roadmap to end of Spiral                     :c&2 |JD1 and for Spiral 2      2 JD  ,DJO- @ !Vz-'---R2 |/JDRevised during conference call on June 11, 2009          2 JD 12 |JDAdditions on July 1, 2009      2 -JD  2 |JDR 2 JDevised after  2 JD %2 JDCluster D meeting2        2 ZJD "2 ^JDon July 2, 2009    2 JD  2 |JD @Cambria--- 6_2 6|JDContents   2 6JD  ---42 M|JD1. GENI goals for Spiral 2       2 M.JD ;2 M1 JD................................;2 M JD................................;2 M JD................................)2 M~JD.................... 2 MJD  2 MJD1 @"Calibri--- 2 MJD ,DJ'---b2 a|:JD2. Cluster E roadmap to end of Spiral 1 and for Spiral 2               2 aJD ;2 a JD.................................2 asJD....................... 2 aJD  2 aJD2 --- 2 aJD ,DJ'---2 t JD2.1 Live    2 tJD 2 t JDExperiments    2 t$JD ;2 t' JD................................;2 t JD................................;2 t JD.................................2 tsJD....................... 2 tJD  2 tJD2 --- 2 tJD ,DJ'---/2 JD2.2 Identity Management         2 @JD ;2 B JD................................;2  JD................................;2   JD................................"2 JD............... 2 JD  2 JD3 --- 2 JD ,DJ'---12 JD2.3 Improved Integration       2 BJD ;2 B JD................................;2  JD................................;2   JD................................"2 JD............... 2 JD  2 JD3 --- 2 JD ,DJ'---)2 JD2.4 Instrumentation      2 JD ;2   JD................................;2  JD................................;2  JD................................12 lJD.......................... 2 JD  2 JD6 --- 2 JD ,DJ'---+2 JD2.5 Interoperabilitye      2 JD ;2  JD................................;2  JD................................;2  JD................................22 iJD.......................... 2 JD  2 JD7 --- 2 JD ,DJ'---52 |JD3. ORCA Integration Roadmap       2 RJD ;2 T JD................................;2  JD................................;2 1 JD................................2  JD.......... 2 JD  2 JD9 --- 2 JD ,DJ'---(2 JDBrief ORCA overviewt     2  JD ;2 # JD................................;2  JD................................;2  JD................................/2 pJD........................ 2 JD  2 JD9 --- 2 JD ,DJ'---72 JDSoftware integration overview        2 cJD ;2 e JD................................;2  JD................................;2 C JD................................2 JD.. 2 JD 2 JD10 --- 2 JD ,DJ'---2  JDSubstrate  2 JD ;2  JD................................;2 P JD................................;2  JD................................;2 . JD................................2 JD........ 2 JD 2 JD10 2 JD ,DJ'2 # JDPortals/tools   2 #JD ;2 # JD................................;2 #l JD................................;2 # JD................................;2 #J JD................................ 2 #JD 2 #JD10 2 #JD ,DJ'---@2 6#JDInfrastructure integration overview       2 6JD ;2 6 JD................................;2 6 JD.................................2 6iJD....................... 2 6JD 2 6JD11 --- 2 6JD ,DJ'---:2 IJDORCA feature/capability roadmap      2 I|JD ;2 I} JD................................;2 I JD................................42 I[JD............................ 2 IJD 2 IJD11 --- 2 IJD ,DJ'--- 2 ]|JD  2 p|JD @"Calibri--- 4Z42 |JD1. GENI goals for Spiral 2        2 aJD  --- 2 |JD 2 |JD1)  2 JD-#2 JDLive experiments     2 JD  2 |JD |2 |KJDThe central goal of Spiral 2 is to support significant numbers of research             ,2 !|JDexperiments in the end      2 !JD-2 !#JDto 2 !2JD-,2 !7JDend prototype systems.      2 !JD  2 4|JD b2 G|:JDThe GPO expects live experimentation to begin near the end               2 G JD /2 G$JDof Spiral 1, which will      2 [|MJDintensify through Spiral 2 as we begin continuous operation of the prototype                     2 n|XJDsystems. This will begin to give us all substantial (early) operational experience, as              n2 |BJDthese experiments will help us all understand the prototypes' stre              2 JJDngths  2 uJDand  42 |JDweakness, which will drive      (2 =JDour Spiral 3 goals.w     2 JD  2 |JD g2 |=JDAdditionally, we expect development in Spiral 2 to emphasize:a            2 1JD  2 |JD --DDJJDDJJDDIIDDIIDDIIDDIICCIICCIICCHHCCHHCCHHCCHHBBHHBBHHBBGGBBGGBBGGBBGGAAGG՜.+,D՜.+,4 hp   UC Davis.Z 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[\]^_`abcdefghijklmnpqrstuvwxyz{|}~      !"#$%&'()*+-./01238Root Entry F:Data o"1TableĀWordDocument0SummaryInformation(`DocumentSummaryInformation8,CompObjy  F'Microsoft Office Word 97-2003 Document MSWordDocWord.Document.89q