[[PageOutline]] This is the list of ExoGENI Use Cases sent to exogeni-design@geni.net. When information is exchanged it will be captured here for each use case. Also, any document that is refereed to with a URL was attached to the page for historical reference. Following are notes attributions: {{{ JS: Josh Smift JC: Jeff Chase }}} = ExoGENI Use Cases = There are 8 ExoGENI Use Cases that were discussed in the ExoGENI design review. The Use Cases were also seeded in the mail list exogeni-design@geni.net for discussion. Note that the 6 experimenter use cases all assume that the experimenter is using the GENI AM API (e.g. with the OMNI client). == Experimenter Use Cases == === Use Case 1 === I want to reserve some resources within a single ExoGENI rack. "Resources" includes both compute and network resources in this use case and in the five that follow. === Use Case 2 === I want to reserve some resources in multiple ExoGENI racks, and have them all connected at layer 2. === Use Case 3 === I want to reserve some resources in one or more ExoGENI racks, AND one or more other resources that are connected to NLR or Internet2 at layer 2, and have them all connected to each other at layer 2. (These other resources might be GENI resources or might not be; let us know if this makes a difference.) === Use Case 4 === I want to reserve only some OpenFlow resources in the ExoGENI rack, to connect some non-ExoGENI resources at a site (which are connected at layer 2 to the ExoGENI rack dataplane switch) to some non-ExoGENI resources at another site (via NLR or Internet2). (Aka "how do I use just the OpenFlow switch to connect a site network to an upstream network without using any ExoGENI compute resources".) {{{ I was going to follow up on this one; here's a concrete example of two ways that I think it might work, which I'm hoping y'all will say either "yes, it'll work that way" or "no, it won't work that way" about each. Background for both cases: Alice (experimenter) has (a) some computers in her lab at Enormous State University, which are on an OpenFlow network that she controls; (b) some other resources at other campuses, on OpenFlow networks, that are connected to the GENI mesoscale network, on VLAN 3715 say. She wants to connect these two sets of resources at layer 2, via the OpenFlow switch in the ExoGENI rack, which connects to both (on port X to the GENI mesoscale, and port Y to campus). The FOAM Way: She uses FOAM to allocate some flowspace for her traffic. In FlowVisor terms, she requests flowspace like in_port=X,dl_vlan=3715 in_port=Y,dl_vlan=3715 A FOAM admin (not RENCI; we predict that we will draft a campus admin to do this) reviews and approves her request (or it's automatically approved by FOAM's (forthcoming) policy engine). (This may get slightly more complicated if her OpenFlow network isn't directly connected to port Y, i.e. if it needs to traverse some campus switches (and VLANs) first, but let's start with the simple case.) The ExoGENI Way: She uses ExoGENI to allocate a VLAN, whose endpoints are "port X" and "port Y". (Or something like that? I'm a little fuzzy on this part -- in particular, how does her VLAN get translated onto 3715 via X, and what happens on the campus side?) This functionality may not exist yet, but might soon. This is vague and probably incomplete and perhaps entirely wrong. Please feel free to say "no no no no" and explain how it'll really work. :^) Relatedly: Is this "the on-ramp", or is that something else? Let me generalize your example. Suppose your fixed static VLANs V1 and V2 are adjacent to ports (interfaces) X and Y somewhere in the ExoGENI network. Port X is on switch(X), and port Y is on switch(Y). These might not be the same switch. Suppose first that the VLANs V1 and V2 are not shared, i.e., the slice owns all flows on the VLANs. Then the problem is to provision a point-to-point virtual Ethernet link (VLAN) between switch(X) and switch(Y) as part of your slice, and stitch it to V1 on one end and to V2 on the other end. This is a problem of external stitching: somehow the stitching API needs you to be able to prove to ExoGENI that you own that V1 and V2, and if it does, then we'll be OK. If switch(X) and switch(Y) are OpenFlow switches, and you want to register a controller there, then it is the same, except that you want to skip the stitching steps: instead, you want your virtual link to terminate on the edge switches. With a better hybrid mode we might be able to stitch and use OpenFlow at the same time, but this kind of "real" (to me) hybrid mode is not in the forseeable roadmaps for switch vendors. The weak support for hybrid mode may turn out to be a pretty deep problem. We're still working through the implications. For example, Ilia has pointed out that we're not sure whether a controller can touch any traffic that enters and/or exits a non-OF-aware circuit provider or RON, since ports facing those networks weren't planning to be in OpenFlow mode. But that's a separate issue. Leaving that aside, both of these cases should be doable. There are some limitations in our NDL request model that prevent us from requesting virtual links that terminate at interfaces of named switches: we need this for all the OpenFlow cases, but currently the virtual links must terminate at interfaces of virtual hosts. But we can fix that. But there's a deeper authorization problem here that gets at the heart of your question. If V1 and V2 are shared, then how is ExoGENI to know what flows on them belong to you? The issue here is that you want to bridge traffic from a shared link onto a private link. FOAM might be a solution to this problem, and we have no objection to its use to authorize flows manually. ExoGENI itself has no sharing of virtual links among slices. (Except by on-ramp, which is not implemented. On-ramp is a stitch between private links owned by two different slices, by mutual consent of both slices. It is the moral equivalent of slices peering their virtual networks.) I didn't directly address the exact case you mentioned: switch(X) == switch(Y). That case is unique because the slice doesn't need to allocate any resources from the aggregate (except flowspace). This is a good question. It should be possible for a slice to use the stitching API to prove to ExoGENI that it owns external adjacent VLANs V1 and V2, and have it authorize your OpenFlow controller for flows on those VLANs, whether you allocated anything from that aggregate or not. This should work. We will have to think about this some more. There is a new paper draft that says more about ExoGENI. It has some overlap with the design document, and some of the same figs, and it is still missing some figs, references, polish, etc. It is still a draft, but the text itself is pretty tight. section 4 in particular is highly relevant. You can find it at http://www.cs.duke.edu/~chase/exogeni.pdf. We welcome comments. }}} === Use Case 5 === Same scenario as (2) above, but I want the relevant network resources to be OpenFlow-controlled. === Use Case 6 === Same scenario as (3) above, but I want the relevant network resources to be OpenFlow-controlled. ''Note: If there's more than one way to do some of these (e.g. "you can either talk to an individual rack SM, or to the ExoSM"), we'd be interested in knowing that too, and in hearing some compare-and-contrast about the different options.'' == Operator Use Cases == === Use Case 7 === An update is available for some part of the software/firmware in the rack; I want it to be installed. (Related question: How are currently-running slivers affected by updates to various components?) {{{ 14) No real SW update plan is in place. This isn't a surprise, but it's an ongoing concern. We would of course love to see a package repo for all pieces that they commit to maintaining. We probably want an item by item list of who maintains it, how it is updated, and the expected impact on experimenters when it is updated. Using outside knowledge: i'd be a little surprised if they didn't have a package repo, given that Victor O maintains the duke-neuca CentOS repo already, so they have this power in-house. Should we explicitly ask about/and or encourage that? I think using a repo at RENCI would be perfectly fine --- what we really want is to be able to use packaging to easily verify whether things are up-to-date, right? }}} === Use Case 8 === Something in the rack is misbehaving; I want to identify which resources are causing the symptoms, which sliver those resources are currently allocated to, which slice that sliver is a part of, and who the owner of that slice is. (Corollary: I receive a report of past misbehavior from a resource; I want to identify the sliver/slice/owner who had that resource at the time.).