Changes between Version 11 and Version 12 of WorryingSlivers
- Timestamp:
- 12/15/11 11:14:42 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WorryingSlivers
v11 v12 23 23 So when we describe a virtual resource, we might also have to say something about the details of the service instance. For example, we might have to describe properties of the scheduler, like the degree of assurance that the instance will be permitted to occupy space or time on any actual substrate. 24 24 25 Some virtual resources mix software with the hardware to varying degrees. Surely a Python environment like Google's AppEngine is a programmable virtual resource, for example. There is more to say about the distinction between an infrastructure service and any other kind of software service along the continuum from grid job services to application services. NIST has already laid out that space for us, so I will leave that question. People sometimes seem uncomfortable that we do not know how far down this continuum we might go with the GENI virtual resource abstractions. What we do know is that we can describe physical resources fairly easily, but it gets harder to describe our virtual resources as we move down the continuum toward application services. At some point we can no longer say precisely what we mean by "virtualization".25 Some virtual resources mix software with the hardware to varying degrees. Surely a Python environment like Google's !AppEngine is a programmable virtual resource, for example. There is more to say about the distinction between an infrastructure service and any other kind of software service along the continuum from grid job services to application services. NIST has already laid out that space for us, so I will leave that question. People sometimes seem uncomfortable that we do not know how far down this continuum we might go with the GENI virtual resource abstractions. What we do know is that we can describe physical resources fairly easily, but it gets harder to describe our virtual resources as we move down the continuum toward application services. At some point we can no longer say precisely what we mean by "virtualization". 26 26 27 27 == OpenFlow == 28 28 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.29 Before I move on, let me say a little about OpenFlow, which is an interesting case of programmable substrate. OpenFlow enables external controllers to install "flow entries" in the network datapath to manage traffic. Flow entries define pattern-action rules: the patterns match packets flowing through the network, and the actions operate on matching packets, e.g., to redirect or transform them. The patterns may match packets with specific combinations of header values (the controller's "flowspace"). 30 30 31 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. 31 In GENI it is common to speak of flowspace as a "resource" that an experiment requests from an OpenFlow aggregate and receives as a sliver. Clearly this a very different concept of a GENI resource than, say, a virtual machine (VM). A VM is an abstraction of a substrate element (a physical machine), and can be bound to a set of substrate resources (CPU, memory, etc.). The challenges for managing VMs are to decide who gets use of the substrate resource (resource allocation) and how to connect a VM to other virtual resources (stitching). 32 32 33 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.33 Flowspace represents something quite different: a right to control packets that may belong to someone else. When I say "virtual resource" I am not talking about flowspace granted to a controller, which I see as an issue of authorization rather than resource management. It is true that flowspace consists of combinations of network names (VLANs, MAC addresses, IP addresses), and that these names are "resources" allocated from some pool. But they are allocated to the owners of the packets, and not to the controller. 34 34 35 Third, the amount of actual substrate resource that an OpenFlow ruleset consumes depends in part on the amount of network traffic generated by someone else. But in this third respect OpenFlow is no different from any service that is driven by requests from external users. The resource demands of these services may be hard to predict in advance, but some resources must be assured for acceptable service quality. Which brings us back to the need to describe scheduling properties. But I digress. 36 37 The point is that active OpenFlow rulesets represent virtual resources, so OpenFlow is a good test case for a GENI sliver abstraction. But we should be very careful when we talk about OpenFlow. 35 The point is that OpenFlow is a good test case for a GENI sliver abstraction, but we should be very careful when we talk about slivers in OpenFlow. I don't subscribe to the "slivers of flowspace" view. It makes more sense to me that an OpenFlow sliver would be a group of flow entries (which I will call a "ruleset") installed in the datapath at a particular location on behalf of a controller. That concept of a sliver is similar to a VM: we can think of a ruleset as a program that runs in the network and consumes hardware resources there. The amount of substrate resource that a ruleset consumes depends in part on the amount of network traffic generated by someone else, but in this respect OpenFlow is no different from many uses of VMs whose resource demands are driven by external requests and may be hard to predict in advance. Some resources must be assured for acceptable service quality, which brings us back to the need to describe scheduling properties. And it would be good if we could apply our sliver abstraction to the problem of managing the hardware resources consumed by OpenFlow rulesets. But I digress. 38 36 39 37 == Semantic Models == … … 41 39 So: there are many kinds of virtual resources, and the goal of GENI is to operate on them. To operate on them we must describe them. But there are so many kinds to describe. And as [http://www.fecundity.com/pmagnus/humpty.html Alice] said, the question is whether you *can* make words mean so many different things. But what do we want to say about these virtual resources? 42 40 43 When we talk about virtual resources, we can often identify distinct elements within them to talk about. For example, there are virtual machines, and network pipes, and logical storage containers. These examples suggest that our virtual resources tend to closely match the shapes and behaviors of actual substrate elements (components). Indeed, a physical component might be allocated directly as a virtual resource (as in early Emulab). But virtual resources are above the component layer: a component might host more than one virtual resource, or a virtual resource might span components. And when we describe virtual resources we find other elements that do not map easily onto components. There are VLAN tags and other flowspace labels, and running programs, and standing queries such as active OpenFlow rulesets.41 When we talk about virtual resources, we can often identify distinct elements within them to talk about. For example, there are virtual machines, and network pipes, and logical storage containers. These examples suggest that our virtual resources tend to closely match the shapes and behaviors of actual substrate elements (components). Indeed, a physical component might be allocated directly as a virtual resource (as in early Emulab). But virtual resources are above the component layer: a component might host more than one virtual resource, or a virtual resource might span components. 44 42 45 43 We can describe these various entities independently in terms of their properties and their relationships. That is good, because if our goal is to describe virtual resources precisely enough to process the descriptions automatically, then we are going to need a semantic model, and semantic models are almost by definition based on classifying entities and their relationships. There is a rich literature on entity-relationship models going back 35 years. … … 48 46 We can use these models to create documents that describe virtual resources in terms of elements and relationships. When we request virtual resources or changes to virtual resources, we attach documents that describe the resources and changes we want. If a request is granted, we receive documents describing the virtual resources we got. These documents are called rspec. 49 47 50 What is important here is that virtual resources have an internal structure and properties, and we describe these using declarative specifications. 51 Originally ORCA used simple resource types and property lists. But these descriptions have become significantly more advanced in the GENI project, and they are a key part of the GENI architecture challenge. 52 53 But what does such an rspec document describe? Must it describe a complete slice? Or can we describe different pieces of a slice in different documents? As we will see, this is an essential question for understanding the role of slivers in GENI. 48 What is important here is that virtual resources have an internal structure and properties, and we describe these using declarative specifications. But what does such an rspec document describe? Must it describe a complete slice? Or can we describe different pieces of a slice in different documents? As we will see, this is an essential question for understanding the role of slivers in GENI. 54 49 55 50 == Partitioning Virtual Resources Across Aggregates == … … 145 140 A key property of ORCA resource leases is that they expire if the client does not renew them. That property is important for GENI, but is out of scope for this discussion. The set of slivers in an ORCA lease may be changed in various ways when the lease is renewed (extended). This is one way to grow and shrink slices in ORCA. However, I now believe that the idea of multiple slivers per lease was a mistake. It complicated the code and caused a lot of unnecessary debugging effort (in 2005), is useless for networks, and makes it impossible to change some slivers independently of other slivers if they are in the same lease. In GENI we always use ORCA with one sliver per lease. Used in this way, an ORCA lease is a pretty close analogue of a sliver. One can grow slices by adding leases (slivers), and shrink slices by closing leases or allowing them to expire. 146 141 147 Recently people have started saying that ORCA does not have the UpdateSliver function. An ORCA slice can have many slivers at the same AM, and can create and release them independently, so ORCA has the function of UpdateSliver to grow or shrink a slice at an aggregate. Also, a caller can change certain sliver parameters at lease extension time, which may cover other planned functions of UpdateSliver. ORCA defines another operation on a lease (sliver), called Modify, which has never yet been fully implemented. Modify is intended as a hook for pluggable type-specific actions on the slivers in a lease. One might think of it as sort of a kitchen-sink ioctl. But this seems different from theUpdateSliver planned for the AM-API.142 Recently people have started saying that ORCA does not have the !UpdateSliver function. An ORCA slice can have many slivers at the same AM, and can create and release them independently, so ORCA has the function of !UpdateSliver to grow or shrink a slice at an aggregate. Also, a caller can change certain sliver parameters at lease extension time, which may cover other planned functions of !UpdateSliver. ORCA defines another operation on a lease (sliver), called Modify, which has never yet been fully implemented. Modify is intended as a hook for pluggable type-specific actions on the slivers in a lease. One might think of it as sort of a kitchen-sink ioctl. But this seems different from the !UpdateSliver planned for the AM-API.
