Changes between Version 10 and Version 11 of WorryingSlivers

Timestamp:

12/08/11 10:48:45 (12 years ago)

Author:

chase@cs.duke.edu

Comment:

--

WorryingSlivers

@@ -29 +29 @@
 Before I move on, let me say a little about OpenFlow.  OpenFlow is an interesting case for several reasons.  OpenFlow is pretty far down this continuum, and it is not an accident that some of the most pointed questions about slivers have come from OpenFlow voices.
 
-Clearly OpenFlow switches are programmable substrate.  Flow rules are programs and those programs consume switch resources.  Those flow rules are a kind of service: what OpenFlow does is apply the rules to packets flowing through the network.  All packets are labeled with names allocated from various name spaces.  Those name spaces are also virtual resources---flowspace.   If a rule matches the labels on a packet, then the rule may redirect or even transform the packet, which consumes more switch resources.  Before OpenFlow we called such rulesets packet filters.
+Clearly OpenFlow switches are programmable substrate.  Flow rules are programs and those programs consume switch resources.  Those flow rules are a kind of service: what OpenFlow does is apply the rules to packets flowing through the network.  All packets are labeled with names allocated from various name spaces.  Those name spaces are also virtual resources---flowspace.   If a rule matches the labels on a packet, then the rule may redirect or even transform the packet, which consumes more switch resources.
 
 OpenFlow is interesting first because the packets matching the rules might belong to someone else.   An OpenFlow rule is like a service that queries someone else's data.    So we should first be sure that the owner of a rule has a right to operate on the data.  Thus OpenFlow presents an interesting authorization challenge that is quite different from other kinds of virtual resources.   Second, OpenFlow rules match against flowspace labels on the packets, and the label values are themselves virtual resources.   Thus authorization of OpenFlow rules is often strangely conflated with resource allocation of flowspace.  But it is not resource allocation because the flowspace is allocated to the owner of the packet, and not to the owner of the rule (unless these happen to be the same entity).  In any case, flowspace is allocated to a network endpoint or path independently of any rules being activated for that flowspace, so OpenFlow has little to do with flowspace allocation.
@@ -72 +72 @@
 The key challenge to overcome for partitioning our resource descriptions is that there are relationships among the virtual resource elements.  And to the extent that we have these relationships among virtual resources on different aggregates, those aggregates may need to interact, perhaps through some intermediary.   In GENI we call these interactions [GeniNetworkStitching stitching].    Many of the driving use cases for stitching involve interconnecting virtual resources within a slice.  For example, we use stitching to connect virtual network pipes into paths or networks terminating at virtual nodes.  
 
-Can our semantic models describe all the relationships that might require such interactions?   If the answer is yes, then we can talk to each aggregate about the relationships that cross its borders, without it having to be aware of any virtual resources that are unrelated to what we want that aggregate to do.  The graph is partitionable.   If the answer is no, then we might need to tell every aggregate about every virtual resource, in case there is some important relationship that we missed.  Perhaps there is some relationship that is not represented explicitly in the description, but that an aggregate can infer from the descriptions of other virtual resources at other aggregates.  In that case, the aggregate must have all of those descriptions available to it.  The graph is not partitionable.
+Can our semantic models describe all the relationships that might require such interactions?   If the answer is yes, then we can talk to each aggregate about the relationships that cross its borders, without it having to be aware of any virtual resources that are unrelated to what we want that aggregate to do.  In other words, the graph is partitionable.   If the answer is no, then we might need to tell every aggregate about every virtual resource, in case there is some important relationship that we missed.  Perhaps there is some relationship that is not represented explicitly in the description, but that an aggregate can infer from the descriptions of other virtual resources at other aggregates.  In that case, the aggregate must have all of those descriptions available to it.  The graph is not partitionable.
 
 It is logical that we would seek to describe all such relationships in our semantic resource descriptions.  If we discover that we have missed an important relationship, that means our semantic model is insufficient, and we should go back and extend it or rethink it.