connectedness & coordination

[Aaron Falk]

Larry, John-

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.

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.

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."

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.

--aaron

_______________________________________________
narrow-waist-wg mailing list
narrow-waist-wg@...
http://lists.geni.net/mailman/listinfo/narrow-waist-wg

[Aaron Falk]

On Nov 6, 2007, at 4:55 PM, Aaron Falk wrote:

> 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.
>
> 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 realize the note above focuses on expressing constraints but there  
is the more fundamental problem of exchanging coordinates.  For  
example, imagine a VLAN or dynamic MPLS network connecting two  
components.  If I want to establish a new network connection, how are  
the coordinates associate with that connection passed to the  
endpoints?  It seems the architecture needs to say something about  
this since it will happen between components managed by different folks.

--aaron


_______________________________________________
narrow-waist-wg mailing list
narrow-waist-wg@...
http://lists.geni.net/mailman/listinfo/narrow-waist-wg

[Robert P Ricci]

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

[Schwab, Stephen]

Rob, Aaron --
I think JTW has made the argument that the place to put connectivity is
_not_ the RSpec, but in some other thing (``the CONSpec?'') that does
not yet exist, but collects these kinds of
component-is-connected-to-component relationships.

I can't articulate the why behind this architectural decision to near
any degree of clarity as John can, but basically RSpecs need to focus on
the properties or configurations of components individually, and the
graph or relationship between a set of components needs to be defined
and manipulated elsewhere as its own, distinct, first-class object.
(The rationale there is mine, not John's, and others may agree/disagree
with the idea of incorporating this sort of connectedness information in
the RSpec, or even if they agree about putting it somewhere else, may
cite entirely different reasons for doing so.)

I haven't given much thought to what sort of grammar would be used to
describe connectivity.   Presumably John is thinking of something
different from the nodes-connected-by-links level of ns2, because that
ball-and-stick construction is too mechanical, and doesn't carry any of
the semantics of nodes belonging to, or being on, a network, or being
interconnected via a wireless medium.

(Rob: not to take away from your pragmatic write-up, but I suspect that
it won't be enough in the long run to just embed
connectivity-by-reference inside RSpecs.   But I'm sure you could use
that to get started in protoGENI, and things wouldn't break. :-) )
--Steve

-----Original Message-----
From: narrow-waist-wg-bounces@...
[mailto:narrow-waist-wg-bounces@...] On Behalf Of Robert P Ricci
Sent: Friday, November 09, 2007 1:59 PM
To: Aaron Falk
Cc: narrow-waist-wg@...
Subject: Re: [nwwg] connectedness & coordination

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

_______________________________________________
narrow-waist-wg mailing list
narrow-waist-wg@...
http://lists.geni.net/mailman/listinfo/narrow-waist-wg