Changes between Initial Version and Version 1 of GENIRacksHome/ExogeniUseCases


Ignore:
Timestamp:
03/08/12 12:51:07 (12 years ago)
Author:
lnevers@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • GENIRacksHome/ExogeniUseCases

    v1 v1  
     1[[PageOutline]]
     2
     3This 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:
     4{{{
     5JS: Josh Smift     JC: Jeff Chase
     6}}}
     7
     8= ExoGENI Use Cases =
     9
     10There 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).
     11
     12== Experimenter Use Cases ==
     13
     14=== Use Case 1 ===
     15I 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.
     16
     17=== Use Case 2 === 
     18I want to reserve some resources in multiple ExoGENI racks, and have them all connected at layer 2.
     19
     20=== Use Case 3 === 
     21I 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.)
     22
     23=== Use Case 4 ===
     24I 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".)
     25{{{
     26<JS>I was going to follow up on this one; here's a concrete example of two
     27    ways that I think it might work, which I'm hoping y'all will say either
     28    "yes, it'll work that way" or "no, it won't work that way" about each.
     29
     30    Background for both cases: Alice (experimenter) has (a) some computers in
     31    her lab at Enormous State University, which are on an OpenFlow network
     32    that she controls; (b) some other resources at other campuses, on OpenFlow
     33    networks, that are connected to the GENI mesoscale network, on VLAN 3715
     34    say. She wants to connect these two sets of resources at layer 2, via the
     35    OpenFlow switch in the ExoGENI rack, which connects to both (on port X to
     36    the GENI mesoscale, and port Y to campus).
     37   
     38    The FOAM Way: She uses FOAM to allocate some flowspace for her traffic.
     39    In FlowVisor terms, she requests flowspace like
     40   
     41      in_port=X,dl_vlan=3715
     42      in_port=Y,dl_vlan=3715
     43   
     44    A FOAM admin (not RENCI; we predict that we will draft a campus admin to
     45    do this) reviews and approves her request (or it's automatically approved
     46    by FOAM's (forthcoming) policy engine).
     47   
     48    (This may get slightly more complicated if her OpenFlow network isn't
     49    directly connected to port Y, i.e. if it needs to traverse some campus
     50    switches (and VLANs) first, but let's start with the simple case.)
     51
     52    The ExoGENI Way: She uses ExoGENI to allocate a VLAN, whose endpoints are
     53    "port X" and "port Y". (Or something like that? I'm a little fuzzy on this
     54    part -- in particular, how does her VLAN get translated onto 3715 via X,
     55    and what happens on the campus side?) This functionality may not exist
     56    yet, but might soon.
     57
     58    This is vague and probably incomplete and perhaps entirely wrong. Please
     59    feel free to say "no no no no" and explain how it'll really work. :^)
     60   
     61    Relatedly: Is this "the on-ramp", or is that something else?
     62
     63<JC> Let me generalize your example.  Suppose your fixed static VLANs V1 and V2
     64     are adjacent to ports (interfaces) X and Y somewhere in the ExoGENI network.
     65     Port X is on switch(X), and port Y is on switch(Y).  These might not be the
     66     same switch.
     67
     68    Suppose first that the VLANs V1 and V2 are not shared, i.e., the slice owns all
     69    flows on the VLANs.
     70
     71    Then the problem is to provision a point-to-point virtual Ethernet link (VLAN)
     72    between switch(X) and switch(Y) as part of your slice, and stitch it to V1 on
     73    one end and to V2 on the other end.    This is a problem of external stitching:
     74    somehow the stitching API needs you to be able to prove to ExoGENI that you own
     75    that V1 and V2, and if it does, then we'll be OK.
     76
     77    If switch(X) and switch(Y) are OpenFlow switches, and you want to register a
     78    controller there, then it is the same, except that you want to skip the stitching
     79    steps: instead, you want your virtual link to terminate on the edge switches. 
     80    With a better hybrid mode we might be able to stitch and use OpenFlow at the same
     81    time, but this kind of "real" (to me) hybrid mode is not in the forseeable roadmaps
     82    for switch vendors.  The weak support for hybrid mode may turn out to be a pretty
     83    deep problem.  We're still working through the implications.   For example, Ilia
     84    has pointed out that we're not sure whether a controller can touch any traffic
     85    that enters and/or exits a non-OF-aware circuit provider or RON, since ports
     86    facing those networks weren't planning to be in OpenFlow mode.  But that's a
     87    separate issue.
     88
     89    Leaving that aside, both of these cases should be doable.  There are some limitations
     90    in our NDL request model that prevent us from requesting virtual links that terminate
     91    at interfaces of named switches: we need this for all the OpenFlow cases, but currently
     92    the virtual links must terminate at interfaces of virtual hosts.  But we can fix that.
     93
     94    But there's a deeper authorization problem here that gets at the heart of your question.
     95    If V1 and V2 are shared, then how is ExoGENI to know what flows on them belong to you?
     96    The issue here is that you want to bridge traffic from a shared link onto a private link.
     97    FOAM might be a solution to this problem, and we have no objection to its use to authorize
     98    flows manually.   ExoGENI itself has no sharing of virtual links among slices.  (Except
     99    by on-ramp, which is not implemented.  On-ramp is a stitch between private links owned by
     100    two different slices, by mutual consent of both slices.  It is the moral equivalent of
     101    slices peering their virtual networks.)
     102
     103    I didn't directly address the exact case you mentioned: switch(X) == switch(Y).  That
     104    case is unique because the slice doesn't need to allocate any resources from the aggregate
     105    (except flowspace).  This is a good question.   It should be possible for a slice to use the
     106    stitching API to prove to ExoGENI that it owns external adjacent VLANs V1 and V2, and have it
     107    authorize your OpenFlow controller for flows on those VLANs, whether you allocated anything
     108    from that aggregate or not.  This should work.  We will have to think about this some more.
     109
     110    There is a new paper draft that says more about ExoGENI.   It has some overlap with the
     111    design document, and some of the same figs, and it is still missing some figs, references,
     112    polish, etc.  It is still a draft, but the text itself is pretty tight.  section 4 in particular
     113    is highly relevant.  You can find it at http://www.cs.duke.edu/~chase/exogeni.pdf.  We welcome
     114    comments.
     115}}}
     116=== Use Case 5 ===
     117Same scenario as (2) above, but I want the relevant network resources to be OpenFlow-controlled.
     118
     119=== Use Case 6 === 
     120Same scenario as (3) above, but I want the relevant network resources to be OpenFlow-controlled.
     121
     122''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.''
     123
     124== Operator Use Cases ==
     125=== Use Case 7 ===
     126An 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?)
     127{{{
     128<AH> 14) No real SW update plan is in place.
     129    This isn't a surprise, but it's an ongoing concern. We would of course
     130    love to see a package repo for all pieces that they commit to
     131    maintaining. We probably want an item by item list of who maintains it,
     132    how it is updated, and the expected impact on experimenters when it is
     133    updated.
     134<CG>Using outside knowledge: i'd be a little surprised if they didn't have a
     135    package repo, given that Victor O maintains the duke-neuca CentOS repo
     136    already, so they have this power in-house.  Should we explicitly ask
     137    about/and or encourage that?  I think using a repo at RENCI would be
     138    perfectly fine --- what we really want is to be able to use packaging
     139    to easily verify whether things are up-to-date, right?
     140}}}
     141
     142=== Use Case 8 ===
     143Something 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.).
     144
     145
     146
     147