[services-wg] [cfwg] a proposal for slice stitching

[Jeff Chase]

Sorry Rob, two weeks have elapsed, but in reading this message again I 
see that you asked some questions about ORCA that I don't think I 
addressed.  Answers inline in the excerpted message below.

Jeff

Robert P Ricci wrote:
> Thus spake Jeff Chase on Sat, Feb 06, 2010 at 04:57:36PM -0500:
>   
> ...
>> In ORCA, the producing AM signs the label, and the coordinator presents 
>> the signed label to the consuming AM.   The public keys of the AMs are 
>> endorsed by some mutually trusted third party, such as a CH (or a 
>> certifying authority for a federation).  In ORCA, tickets issued by a 
>> broker/CH can serve as the endorsement, since they contain the public 
>> key of the AM named in the ticket, and are signed by the broker.  (I 
>> gloss over the multi-broker case.)   This allows the SM to coordinate 
>> stitching without any special privilege.
>>     
>
> So, if I understand this right, this requires the coordinator to be the
> intermediary for label information? One of our earlier designs had this
> property too, but we decided to move away from it for two reasons:
>
> 1) Ordering: in some cases, link setup must be done in a specific order
>     - eg. for many types of tunnels, one end must be set up to listen
>     before the other can connect. If labels pass through a third party,
>     this seems to require the third party to have some knowledge about
>     the ordering required for every stitchable link type. The more
>     aggregates a single link passes through, the worse this problem
>     gets. I'd rather 'hide' all that knowledge in the AMs which have to
>     know it anyway.
> 2) Negotiation: if there is actual negotiation required for labels rather
>     than just a 'label exchange', having a third party act as
>     intermediary makes things a lot more complicated. The exception to
>     this statement would be if the two (or more) aggregates are
>     unwilling to trust each other, but *are* willing to trust the third
>     party. This seems like an unlikely scenario for GENI, and even if
>     it happens, our design does support it.
>
> How does ORCA deal with these issues?
>   
Ordering:

The coordinator (the SM) has to know which party produces each label and 
which party consumes it.   It builds a dependency graph from this 
information, and uses that graph to serialize the ticket redeems, as 
described in the USENIX 2006 paper "Sharing Networked Resources with 
Brokered Leases". 

The label produce/consume information is represented in the substrate 
description (NDL-OWL).  It should pass through to the tickets, but the 
code to do that is not in our current release.  The SM plugin for our 
last round of demos (end-to-end VLAN over BEN dynamic circuits and NLR) 
had those dependencies wired in.

Negotiation:

One virtue of the ORCA scheme is that it does not require AMs to know 
about each other, beyond what is represented in the declarative 
substrate description, or to talk to each other.  On the other hand, in 
the case of aggregates that are physically adjacent, they might know 
about each other anyway (as you correctly point out), or at least their 
operators do, and we can propagate trust information along the adjacency 
graph.   As far as ORCA is concerned, if adjacent AMs need to talk to 
negotiate a tag or label, that is OK, as long as the producer eventually 
produces the tag or label.
> I like the fact that the SM has no special privileges in your design -
> would it be fair to say that it's more a service than a 'core' part of
> the control framework?
>   
As with the other ORCA actor types, there can be multiple SMs, so there 
certainly isn't one shared SM service.   Every user could (in principle) 
run their own SM.  Like other actor types, SM is programmable.  Each SM 
has a per-slice adaptation policy, event-driven plugins to launch and 
control the "guest" (experiment or other slice inhabitant), and so on.  
As conceived, the SM plays the role of "experiment control tools", but 
for interoperability in GENI we are moving toward running it as a 
service invoked by those tools.

The rub is that SM does have state: it maintains the global view of its 
slice(s), and coordinates adaptation of those slices.  And it does 
receive unsolicited notifications about changes to the slice from the 
AMs.  So it is a service that must be reachable from the AMs through 
some public or private network.   In that sense it is a first-class 
actor in ORCA's event-driven peer-to-peer control plane.  Like every 
actor, it is both a client and a server.
>  
>   
>> The ORCA protocol does not require any AM to know anything about what 
>> the slice looks like in other domains, except for the labels imported at 
>> the stitching points.   Only the SM/coordinator knows the entire 
>> structure of the slice.   This is important because we want to avoid 
>> assuming that slices are static entities, or that there is some central 
>> controlling authority for the entire "testbed".
>>     
>
> In our current implementation, we do pass the researcher's entire
> request RSpec around to every AM, and each AM simply ignores the parts
> that aren't relevant to it. We could, I think, give each AM only the
> relevant bits (components it controls + stitched links) - the main reason
> we're not doing it now just is simplicity on the client side (it doesn't
> have to worry about carving up the RSpec by AM.)
>
> Your point about not wanting a single controlling entity is a good one,
> and that's why I'm glad to see that the OMF and ORCA (as well as
> ProtoGENI) designs don't have a trusted stitcher - in the limit, such a
> stitcher has to have a global view of the physical substrate and be
> globally trusted, which doesn't scale well.
>