« Return to Thread: connectedness & coordination
Re: connectedness & coordination
by Robert P Ricci
::
Rate this Message:
Thus spake Aaron Falk on Tue, Nov 06, 2007 at 04:55:02PM -0500:
> Larry, John-
So, I'm not Larry or John, but I'll make an attempt at answering this
question.
> I've been having a discussion with Chip and and struggling with a
> topic that I've heard discussed but doesn't seem to be written down
> anywhere (nor can I find a note that indicates someone is writing
> about it).
>
> The question is about how connectivity is represented and how
> connectivity constraints are represented and managed.
The extent to which this is written down depends on what, exactly, you
mean by "represented". In terms of the RSpec, I have wrote a fairly
small amount of text in the latest draft (0.4) of the Rspec document
that has been circulate:
As GENI is a network substrate, the connectivity between components is
one of its most important properties. Connectivity between resources
can be expressed in RSpec with the help of those resources' unique
identifiers: an RSpec can include a reference to a resource in another
RSpec - an interface, for example, in one RSpec can indicate that it
connects to a point-to-point link found in another RSpec. Thus, an
RSpec describing a component need not include descriptions of all of
the components adjacent to that component; it can simply include
"external references" to those components. Connectivity
information can even be expressed in an RSpec separate from the
components themselves: in such an arrangement, one might obtain the
RSpecs for individual components from their component managers, but
obtain their connectivity information from a higher-level source, such
as an aggregate.
This is clearly a first cut, and needs to be fleshed out more, but it's
somewhere to start from.
In higher-level terms than RSpec (ie. what abstraction(s) we apply to
links), I think you're correct, there is nothing written down, and there
needs to e.
> Consider, for example, a researcher who desires to use a collection
> of co-located servers and storage devices attached to a common
> switch. How and by whom is the switch configured? If the current
> state of the switch, say because of support for other experiments,
> prevents interconnection between some components, how is that
> represented and resolved?
>
> I have pieces of two possible answers: First, the switch may be
> considered a component and its configuration is the responsibility of
> the experimenter. If so, there needs to be a way to express the
> desired connectivity and constraints within RSpecs or some other
> way. (I recall discussion of the need for a connectivity graph of
> some sort. Is that right? Where does such a thing live? How is it
> accessed?)
>
> Alternatively, an aggregate controller could be used to configure the
> switch and select connectable components. This makes the resource
> allocation problem the controller's, which makes sense since the
> controller would presumably also be handling the resource reservations.
I think that a network element is a component to the extent that it is
configurable and slice-able.
A Cat5 wire between two nodes is not a component - likewise, an old,
unmanaged Ethernet hub, would not be a component. A big, configurable
Ethernet switch or optical hardware that allows slices to share a fiber
link would be a component. A "tunnel broker" that sets up virtual
network connections over some substrate (ie. the GENI backbone or the
legacy Internet).
In your example, I would say that the switch is a component (though it
could also be a part of an aggregate). The user submits an RSpec to that
switch's component manager, describing the network resources (ie.
links/LANs) that they would like to bind to a slice. The CM does the job
of actually configuring the switch, and making sure that the
configuration changes it makes to not impact other slices. Just as the
resources on a "regular" components, it is the component manager's job
to make sure that it does not issue not accept tickets that would
violate the promises it has made to other slices.
> But what about the case when there are connectivity constraints that
> cross aggregates? (Or, there are no aggregates?) For example,
> consider an experiment requiring components are distributed across
> the GENI system. There may be multiple, diverse networking resources
> available connecting subsets of the facility. How does a researcher
> discover whether or not "he can get there from here."
I think that the answer to this question is fundamentally tied to the
answer to "how do we do resource discovery?", which we know we still
have to answer (and I believe John was going to write up a node as a
starting point.)
> Finally, once an experiment has been established (thinking of long-
> running, perhaps popular services), how does one add resources into
> an existing, operational experiment? This seems harder than
> upgrading a production-grade live service: resources like link
> bandwidth may become unmanageably fragmented and few operating
> systems handle graceful addition of, say, network interfaces (even if
> it's only virtual hardware) without interruption.
This sounds like "just (maybe very tricky) implementation" to me - do
you think it's an architectural issue?
--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------
_______________________________________________
narrow-waist-wg mailing list
narrow-waist-wg@...
http://lists.geni.net/mailman/listinfo/narrow-waist-wg
> Larry, John-
So, I'm not Larry or John, but I'll make an attempt at answering this
question.
> I've been having a discussion with Chip and and struggling with a
> topic that I've heard discussed but doesn't seem to be written down
> anywhere (nor can I find a note that indicates someone is writing
> about it).
>
> The question is about how connectivity is represented and how
> connectivity constraints are represented and managed.
The extent to which this is written down depends on what, exactly, you
mean by "represented". In terms of the RSpec, I have wrote a fairly
small amount of text in the latest draft (0.4) of the Rspec document
that has been circulate:
As GENI is a network substrate, the connectivity between components is
one of its most important properties. Connectivity between resources
can be expressed in RSpec with the help of those resources' unique
identifiers: an RSpec can include a reference to a resource in another
RSpec - an interface, for example, in one RSpec can indicate that it
connects to a point-to-point link found in another RSpec. Thus, an
RSpec describing a component need not include descriptions of all of
the components adjacent to that component; it can simply include
"external references" to those components. Connectivity
information can even be expressed in an RSpec separate from the
components themselves: in such an arrangement, one might obtain the
RSpecs for individual components from their component managers, but
obtain their connectivity information from a higher-level source, such
as an aggregate.
This is clearly a first cut, and needs to be fleshed out more, but it's
somewhere to start from.
In higher-level terms than RSpec (ie. what abstraction(s) we apply to
links), I think you're correct, there is nothing written down, and there
needs to e.
> Consider, for example, a researcher who desires to use a collection
> of co-located servers and storage devices attached to a common
> switch. How and by whom is the switch configured? If the current
> state of the switch, say because of support for other experiments,
> prevents interconnection between some components, how is that
> represented and resolved?
>
> I have pieces of two possible answers: First, the switch may be
> considered a component and its configuration is the responsibility of
> the experimenter. If so, there needs to be a way to express the
> desired connectivity and constraints within RSpecs or some other
> way. (I recall discussion of the need for a connectivity graph of
> some sort. Is that right? Where does such a thing live? How is it
> accessed?)
>
> Alternatively, an aggregate controller could be used to configure the
> switch and select connectable components. This makes the resource
> allocation problem the controller's, which makes sense since the
> controller would presumably also be handling the resource reservations.
I think that a network element is a component to the extent that it is
configurable and slice-able.
A Cat5 wire between two nodes is not a component - likewise, an old,
unmanaged Ethernet hub, would not be a component. A big, configurable
Ethernet switch or optical hardware that allows slices to share a fiber
link would be a component. A "tunnel broker" that sets up virtual
network connections over some substrate (ie. the GENI backbone or the
legacy Internet).
In your example, I would say that the switch is a component (though it
could also be a part of an aggregate). The user submits an RSpec to that
switch's component manager, describing the network resources (ie.
links/LANs) that they would like to bind to a slice. The CM does the job
of actually configuring the switch, and making sure that the
configuration changes it makes to not impact other slices. Just as the
resources on a "regular" components, it is the component manager's job
to make sure that it does not issue not accept tickets that would
violate the promises it has made to other slices.
> But what about the case when there are connectivity constraints that
> cross aggregates? (Or, there are no aggregates?) For example,
> consider an experiment requiring components are distributed across
> the GENI system. There may be multiple, diverse networking resources
> available connecting subsets of the facility. How does a researcher
> discover whether or not "he can get there from here."
I think that the answer to this question is fundamentally tied to the
answer to "how do we do resource discovery?", which we know we still
have to answer (and I believe John was going to write up a node as a
starting point.)
> Finally, once an experiment has been established (thinking of long-
> running, perhaps popular services), how does one add resources into
> an existing, operational experiment? This seems harder than
> upgrading a production-grade live service: resources like link
> bandwidth may become unmanageably fragmented and few operating
> systems handle graceful addition of, say, network interfaces (even if
> it's only virtual hardware) without interruption.
This sounds like "just (maybe very tricky) implementation" to me - do
you think it's an architectural issue?
--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------
_______________________________________________
narrow-waist-wg mailing list
narrow-waist-wg@...
http://lists.geni.net/mailman/listinfo/narrow-waist-wg
« Return to Thread: connectedness & coordination
| Free embeddable forum powered by Nabble | Forum Help |
