Changes between Initial Version and Version 1 of Proto-GENI-2Q09-status


Ignore:
Timestamp:
08/12/09 16:44:56 (11 years ago)
Author:
Aaron Falk
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Proto-GENI-2Q09-status

    v1 v1  
     1[[PageOutline]]
     2
     3= ProtoGENI Project Status Report =
     4
     5Period: 2Q 2009
     6
     7== I. Major accomplishments ==
     8
     9=== A. Milestones achieved ===
     10
     11While we have not finished any milestones this quarter, we have made
     12significant progress towards may of them. This progress is detailed throughout
     13this report.
     14
     15=== B. Deliverables made ===
     16
     17We have continued to make our software available under open source licenses
     18(the GENI Public License and the GPL). This software includes not only our
     19component manger, clearinghouse, etc., but also example scripts demonstrating
     20and documenting the use of this software. (This supports the milestone "Support
     21experiments on ProtoGENI cluster".)
     22
     23We continue to release documentation and design decisions on our wiki at
     24http://www.protogeni.net/ . Many design discussions take place on an open
     25mailing list, linked to from the ProtoGENI wiki. Some important recent
     26additions to the wiki:
     27
     28 * Significant progress on our RSpec, including the first stages of
     29   extensibility, some examples, and modifications for our Manifest.  http://www.protogeni.net/trac/protogeni/wiki/RSpec [[BR]]
     30 *  Updates to the Component Manager and Slice Authority APIs[[BR]]
     31 * New Slice Embedding Service API (see below for more details on this)[[BR]]
     32 * Details about our backbone deployment (see below for more details)
     33
     34== II. Description of work performed during last quarter ==
     35
     36=== A. Activities and findings ===
     37
     38A major focus of our activity this quarter has been on the deployment of the
     39ProtoGENI backbone with Internet2. Details of our plans can be found on these
     40pages:
     41
     42    http://www.protogeni.net/trac/protogeni/wiki/Backbone [[BR]]
     43    http://www.protogeni.net/trac/protogeni/wiki/BackboneNode
     44
     45We have acquired almost all of the hardware we need for the deployment, which
     46has been a very difficult process. (This addresses the milestone "Integrate,
     47install 3 nodes in I2".)
     48
     49First, Dell is end-of-lifing the servers we had planned to use at the backbone
     50sites, and the replacement does not suit our needs (it us unable to support the
     51NetFPGA cards.) Thus, we have purchased (through other funding) the PCs for all
     52backbone sites expected to be deployed over the next three years. We did
     53extensive testing of these PCs to ensure that they would work in the
     54configuration needed, and that the remote access capabilities (console and
     55power control over IP) are sufficient for recovery in case of problems. We also
     56re-worked our boot process to be more robust, since getting physical access
     57will be difficult and costly. Our usual wide-area PCs boot from a single USB
     58flash drive that is write-protected; this way, experimenters cannot maliciously
     59or accidentally interfere with the boot process. However, we were concerned
     60that this did not provide enough flexibility: if we ever needed to update the
     61boot code, that would be very hard to do, since it would require a physical
     62swap of the flash drive. However, we were not willing to make the boot device
     63read-write, as it would not be possible to prevent it from being overwritten by
     64experimenters (since we intend to give full control over some machines to
     65them.) Our solution now involves two USB drives, one of which is write
     66protected, and one of which is not. This way, we can normally boot from the
     67read-write drive, but if there is some problem, we can boot from the read-only
     68drive, which can be used to re-flash the read-write drive. These PCs are
     69spec'ed to be very sliceable: they have eight cores, sixteen GB of RAM, four
     70disks, and six network interfaces. (We will be able to meet the milestone
     71"Control Plane integration of backbone nodes" shortly after these nodes are
     72installed.)
     73
     74Second, the nature of our relationship with HP changed (see the "project
     75participants" section for more details). This delayed the purchase of the
     76switches. A number of other issues conspired to delay the purchase, including
     77getting organizational approval on both sides, some confusion over quantities,
     78and the fact that the purchase was not done through usual channels. A piece of
     79good news, however, is that due to the change in our relationship with HP, we
     80were able to purchase equipment without being subject to F&A charges from the
     81University. This allowed us to purchase the set of equipment included in our
     82original proposal, rather than the reduced amount in our amended proposal due
     83to budget cuts in the subcontract awarded. This will give us additional ports
     84in some switches for connections to other projects, some of which we are
     85already planning uses for. These switches have *almost* all arrived at Utah at
     86this point; we are missing two power supplies, which are still on their way
     87from HP. We have spares from another project that can be used if the ones on
     88order do not arrive in time. Before shipping equipment for the first site, we
     89have done extensive testing in our lab of the software for controlling the
     90switches. (This testing ensures that we will be able to meet the milestone "L2
     91control in backbone nodes" shortly after installation.)
     92
     93We moved from using UUIDs to identify resources in ProtoGENI to URNs. URNs
     94offer the advantage of a hierarchical namespace, mirroring the hierarchical
     95set of authorities we plan to deploy. This scheme was proposed by the GMOC,
     96with refinements based on our feedback. Our current software supports both
     97UUIDs and URNs for backwards compatibility, but UUIDs will be faded out over
     98time.
     99
     100(The following text describes important progress made under other funding.)
     101
     102We have added support for native shared nodes to the Emulab and ProtoGENI
     103software. This enables us to create VLAN-based virtual networks on sliced
     104nodes. Specifically, we have added support for Linux-based virtual nodes using
     105OpenVZ. OpenVZ is a Linux kernel modification that provides lightweight,
     106container-based virtualization by contextualizing the kernel's operation on
     107many namespaces and objects on a per-container basis. When using OpenVZ-based
     108virtual nodes, Emulab provides the user with one OpenVZ container per logical
     109node. OpenVZ is an excellent match for ProtoGENI since it virtualizes much of
     110the network stack down to Layer 2, meaning that it can present virtual MAC
     111layer devices to containers, allowing users to configure device and protocol
     112properties fully above that layer (i.e., each container has its own private,
     113configurable IPv4 routing table).  Currently, we provide a Fedora 8 Linux file
     114system inside each container. In the future, we will support multiple Linux
     115distributions and user-customizable container "disk" imaging and loading like
     116we provide for physical nodes.
     117
     118While developing the OpenVZ support itself, we also explored and prototyped a
     119standard API for configuring Emulab and ProtoGENI virtual nodes, called
     120libvnode.  Eventually, we believe Emulab should support more vitualization
     121technologies, since each can expose a different point along the realism versus
     122cost spectrum (i.e., heavyweight Xen or VMWare that provide a fully emulated
     123machine, or lightweight process-level virtualization like Linux Vservers or
     124OpenVZ that provide only a customizable user space environment). libvnode
     125provides a single Emulab virtual node configuration API that can support
     126multiple back-end virtualization technologies. We have used and modified the
     127libvnode API to add preliminary Xen virtual node support to Emulab.
     128
     129We have deployed a Slice Embedding Service: Emulab' resource mapping program,
     130assign, has many of the key properties required for a GENI slice embedding
     131service. A slice embedding service takes a description of the experimenter's
     132desired virtual network and a description of the facility's physical resources,
     133and then selects an appropriate set of components on which to instantiate the virtual topology. The assign program fills this role in Emulab, and we
     134have extended it to become a prototype Slice Embedding Service (SES).
     135
     136Our SES runs as a service, not tightly coupled to any of the federated
     137facilities. It is an optional step in the process of creating a slice, taking
     138two parameters in RSpec format: a description of the topology that the user has
     139designed, and the set of resources available at some Component manager. The SES
     140annotates the user's requested topology, filling in the identities of nodes and
     141links that can be used to satisfy it. By offering the SES as a standalone
     142service, we make it possible for multiple SESes to exist; some could specialize
     143in embeddings for particular types of hardware or topologies. The user may also
     144give a "partial solution": part of the topology could already be embedded by
     145the user himself or by another SES. This enables the use of multiple embedding
     146services, in serial, on a single request topology.
     147
     148Currently, our SES supports only embedding to a single aggregate at a time.
     149Future work on this service will enable it to map slices across multiple
     150aggregates.
     151
     152=== B. Project participants ===
     153
     154University of Utah[[BR]]
     155Internet2[[BR]]
     156    The subcontract with Internet2 has been successfully signed, and we have
     157    been working closely with Internet2 staff (as well at the GPO) to plan
     158    and deploy our backbone nodes.
     159
     160HP Labs[[BR]]
     161    The exact nature of our relationship with HP has changed. Originally, HP
     162    was going to be a sub-contractor to us. This turned out to require some
     163    legal arrangements that didn't seem necessary for what was essentially
     164    a hardware purchase. Thus, at HP's suggestion, we purchased the equipment
     165    from them using a purchase order (at the steeply discounted price
     166    originally agreed to), as well as consulting services for HP
     167    representatives to attend GECs, participate in GENI-related activities,
     168    etc. This change was approved by the GPO.
     169
     170=== C. Publications (individual and organizational) ===
     171
     172=== D. Outreach activities ===
     173
     174We participated in the second GENI-FIRE Workshop in Seattle, giving a talk
     175about the current state of federation in ProtoGENI and the future possibilities
     176for international federation.
     177
     178We have kept in touch with several projects that proposed to join our control
     179framework cluster under Solicitation 2.
     180
     181Robert Ricci served on three program committees that received GENI-related
     182papers:[[BR]]
     183  * The First ACM SIGCOMM Workshop on Virtualized Infrastructure Systems and
     184    Architectures (VISA), held in conjunction with SIGCOMM 2009 [[BR]]
     185  * The 2009 workshop on Cyber Security Experiment and Test (CSET), held in
     186    conjunction with the USENIX security conference [[BR]]
     187  * The Fourth Workshop on Real Overlays and Distributed Systems (ROADS), to be
     188    held alongside SOSP 2009
     189
     190=== E. Collaborations ===
     191
     192We have continued to organize bi-weekly Cluster C conference calls, which
     193have helped our cluster members to make progress together. In addition to
     194the members assigned to our cluster, the Security Architecture project has been
     195a frequent participant, and some calls have featured members of the GPO and
     196other invited projects. (These collaborations are in support of the milestone
     197"control plane integration of cluster-mates".)
     198
     199Two new projects have joined our cluster this quarter, the Million Node GENI
     200project from Washington and the Digital Object Repository from CNRI.
     201
     202In addition to the existing members of our federation (Utah, Wisconsin, CMU,
     203Kentucky), two new facilities have joined our federated clearinghouse: [[BR]]
     204    Programmable Edge Node (UMass-Lowell) [[BR]]
     205    BBN (test facility being set up by intern Evan Zhang)
     206
     207We have also interacted with a number of other GPO-funded projects outside of
     208our cluster, including:[[BR]]
     209    __SPP Overlay Nodes:__ Will be connected through the Internet2 donated wave, using equipment from our project.[[BR]]
     210
     211    __GMOC:__ Have adopted a proposal by the GMOC for using URNs to identify users and resources in GENI. Ongoing discussions about the [[BR]]
     212
     213    __Million-Node GENI:__ Many design discussion about how the Seattle abstractions are not perfectly matched to our APIs, and we are working on refining some of our design to encompass Seattle-like resources.[[BR]]
     214
     215    __Mid-Atlantic Network:__ Have worked out connectivity at 10GB between our equipment in the Washington, DC POP and the MAX equipment in the same POP. Will be used to connect to Cluster B projects (such as SPP) as well as Cluster C projects.[[BR]]
     216
     217    __Great Plains Network:__ Are talking about possible connectivity to our equipment, so that they can connect to SPP, MAX, and Cluster C projects[[BR]]
     218
     219    __GUSH:__ Have given them accounts on Emulab to experiment with using GUSH on Emulab[[BR]]
     220
     221
     222We have held talks with our campus and regional networks, who have been very
     223supportive of our efforts. The expected outcome of these talks is dedicated
     224connectivity between the Utah Emulab facility and the donated Interet2 wave.
     225Our campus is also being supportive of the BGPMux project, agreeing to provide
     226a BGP feed for experimenter use.
     227
     228We participated in two GPO-sponsored workshops: one about the RSpec and
     229connections between substrates, in Chicago, and another about measurement
     230hosted in Madison.
     231
     232Robert Ricci has been named incoming co-Chair of the Control Framework
     233Working Group.
     234
     235We have continued to work with the GPO and EDJ Associates to plan GEC6 in
     236Salt Lake City.
     237
     238=== F. Other Contributions ===